August Challenge of the Month Discussion

[eejit]

" 3. This recursive routine works in the reverse order from the last (and highest point of array). "

But it could equally be done by working from the lowest to the highest. So how could it be established (maybe not possible) whether it is quicker to work from the top or from the bottom?
(And what about the run time if there is no match!)

The thing that's being overlooked is that the original question wants a routine to match payments against invoices.
W. Pooh has indicated that this is not a practical or worthwhile target - I agree with him.

Sorting by invoice value can(should) substantially reduce the number of combinations to be checked but it will not necessarily produce results that will represent matches in ascending order by invoice date - which surely must be important.
If it's not important, what's the relevance to accounts receivable and why bother trying to match at all?
If it is important, whatever the match happens to be, the payer needs to be asked if the correct invoices are being matched. So why bother to attempt a match - just either ask the payer or set off against the earliest invoces.

Jay Petrulius has said that the challenge is appropriate for identifying errors in a particular situation that he describes.
OK, but this is not what the challenge has asked for.
Different considerations are involved in developing a procedure for J. Petrulius' scenario versus the scenario set by the monthly challenge.

Perhaps the challenge should drop the association with invoices/accoumts receivable, and merely ask for a solution to match a given amount with a range of numbers in any sequence.
That being the case, good luck!
I shall certainly not be wasting any of my time on it.

 

[Sharad Kothari]

"So how could it be established (maybe not possible) whether it (recursive routine) is quicker to work from the top or from the bottom?"

If you build a pyramid from top to bottom or bottom to top, over all time would not vary. However, while working top to bottom, the halfway mark would be reached early and that is why recursive routine is build to work from bottom to top. With a few modifications, it can be turned to work from top to bottom. It's just a matter of preference.


"The thing that's being overlooked is that the original question wants a routine to match payments against invoices."

This is not being overlooked. All the possible combinations is immediately extracted as soon as they are found.

"but it will not necessarily produce results that will represent matches in ascending order by invoice date - which surely must be important."

The dates are not contemplated in the given Challenge. But dates, if they can be used, can certainly be used to filter the results and reduce the processng time.

"So why bother to attempt a match - just either ask the payer or set off against the earliest invoces."

Any person, who has ever tried to reconcile any figures, would certainly appriciate a workable solution to the given challenge.

 

[eejit]

"If you build a pyramid from top to bottom or bottom to top, over all time would not vary. However, while working top to bottom, the halfway mark would be reached early and that is why recursive routine is build to work from bottom to top. With a few modifications, it can be turned to work from top to bottom. It's just a matter of preference."

I'm not sure that your logic is accurate.
Working from bottom to top with the data given in the challenge can eliminate very quickly many of the total possible combinations - I think more quickly than working from top to bottom.

"This is not being overlooked. All the possible combinations is immediately extracted as soon as they are found."

But they are not being extracted in a date sequence - which is relevant for matching invoices with payments.

"The dates are not contemplated in the given Challenge. But dates, if they can be used, can certainly be used to filter the results and reduce the processng time."

This was exactly my point about the relevance to accounts receivable - the Challenge is about accounts receivable so there is an inherent importance re dates.

"Any person, who has ever tried to reconcile any figures, would certainly appriciate a workable solution to the given challenge."

You are missing the point. I hereby state categorically that the solution requested by the Challenge is absolutely useless for the purpose of maintaining accounts receivable records.
There may be other scenarios that might benefit from a solution but then the Challenge refers only to matching payments/invoices. It is highly probable that the structure of a solution for other scenarios would involve different considerations than the scenario per the Challenge.

 

[s-o-s]

Why is it that everybody is looking for a reason to work on this challenge...Just do if you want to try or move on if not....

In addition to Jay's alternate suggestion where this would help...

I have helped out someone in the past who had a problem that this would fix...My solution was using the brute force method I'm afraid and I warned that it was best to limit the number of selections to make up the total starting at 1 selection then rising up to 10 selections. I listed all solutions that came up to the total.

The solution was for the problem...

I work in an accounts office and have just taken over from someone else...he used to amalgamate loads of balances from a detailed trial balance into a summary presented to clients for sign off, however he only ever entered values...How do I find out which balances are included in any given summary figure?

So now a couple of very valid reasons exist and 1 which is arguable(at least so far!). Lets see some proper solutions to this challenge and less rubbish about why not to try.

Personally I'm interested in the challenge to see if better methods come up, I'll even see if I can revamp some of my old code.

_________________<MARQUEE/><A HREF= "http://website.lineone.net/~s-o-s/Index.html">

</MARQUEE>

Edit to correct spellings and delete a duplicate Post...
This message was edited by s-o-s on 2002-08-06 08:28

 

[eejit]

S-O-S said :-
"I have helped out someone in the past who had a problem that this would fix...My solution was using the brute force method I'm afraid and I warned that it was best to limit the number of selections to make up the total starting at 1 selection then rising up to 10 selections. I listed all solutions that came up to the total."

I think this is a very practical approach - W. Pooh suggested the same thing.

However, your other comments about just finding a solution instead of "rubish" about why not to try are rejected.

Any "solution" depends upon what is trying to be achieved.
Payment/invoice matching involves different requirements versus your example of matching summarised figures with a list of balances.

So what is it that is supposed to be achieved?
Matching payments/invoices?
If so, it's a useless exercise - no use to anyone.

If it's something else that is to be achieved, then what is it?
Any solution is dependant upon what is required.

 

[Jay Petrulis]

---snip---
However, your other comments about just finding a solution instead of "rubbish" about why not to try are rejected.

Any "solution" depends upon what is trying to be achieved.
Payment/invoice matching involves different requirements versus your example of matching summarised figures with a list of balances.

So what is it that is supposed to be achieved?
Matching payments/invoices?
If so, it's a useless exercise - no use to anyone.

If it's something else that is to be achieved, then what is it?
Any solution is dependant upon what is required.

For those who want to quibble over the semantics of the challenge, how about this?

<pre>Given a list of numbers, find all possible combinations whose sum equal a certain value.</pre>

What is *required* is for you to list out the combination(s) of values from the list of 54 that equal 4,556.92. Don't read anything else into this, despite what you have read previously. Answer the restated question and then we can go on about its usefulness or lack thereof.

S.O.S. hit it directly -- let's see what you have rather than discuss the "meaning" of the challenge.

This is just a friendly competition and valuable solution time is being wasted while we are arguing about the question.

The routine I originally posted is extremely slow. I have changed it a bit, but it is still a (major) work in progress.

Fastest would likely be Mark W.'s (and Tushar Mehta's suggestion from the original newsgroup thread), yet those *may* not exhaust all possibilities.

Sharad Kothari's post looks very promising (I haven't tested it yet), so in any event there are some nice options out there already.

 

[MrBluesman]

Looking at this challenge it has a similar problem to a previous challenge (The steel Bar one) and best use of material to cut down on waste. So finding a solution to this does have other benefits.

I have to agree with Jay and SOS do it if you want the challenge if you don't you can always phone up the company and ask them what invoices they are paying!

 

[Brabantio]

On 2002-08-08 04:48, MrBluesman wrote:
Looking at this challenge it has a similar problem to a previous challenge (The steel Bar one) and best use of material to cut down on waste. So finding a solution to this does have other benefits.

I have to agree with Jay and SOS do it if you want the challenge if you don't you can always phone up the company and ask them what invoices they are paying!

"I have to agree with Jay and SOS do it if you want the challenge if you don't you can always phone up the company and ask them what invoices they are paying!"

Exactly!
So as far as accounts receivable are concerned, you will have to check with the paying company anyway - whether you find one match, more than one match, or no match.
In other words, it's not applicable to accounts receivable and is therefore not the same as the "Steel Bar one", is it?

 

[manet]

I’ve just read through the whole of this thread and think there is a need to sort out all the ********.

The challenge asks for a solution for matching payments against invoices so that it “could be used every day by accounts receivable departments across the world for similar problems”.

I agree with the posters who say that the challenge is inapplicable to managing accounts receivable.

There are obviously other situations where it may be applicable, but any attempt at a solution has to take account of the actual situation and the aim of the “solution”.

Jay Petrulius has taken it upon himself to re-define the challenge and to re-set the parameters.

I would suggest that the challenge should be the one defined by Jay Petrulius so that no more ******** needs to be posted.

 

[IOANNIS]

If anybody want to try the challenge just open the Excel and wright a macro ..if not just try the www.i_cant.com or www.i_dont.com ...

Anyway ...

I made a macro and after 6 hours i find more than 70000 solutions (more than 10000/hour)

and there are mush more .. until it ends ...

i made olso and a Resume one to continue if stoped it

How Many are the solutions (check=4556,92) ?

Does Anybody knows ?