On Fri, 9 May 2008 03:48:20 -0700 (PDT), James Dow Allen
<jdallen2000@yahoo.com> wrote:

>On May 7, 11:24pm, sophia <sophia.ag...@gmail.com> wrote:
>> The cutting sticks problem---given a stick of length L and a set of
>> points where it has to be cut. If the cost of making a cut is equal to
>> the length of the stick, what is the best algorithm to find the
>> optimal sequence of cuts(giving minimum cost)
>
>Contrary to a suggestion in this thread,
>the straightforward solution to this puzzle
>is not of exponential complexity, but rather N^3/3.
>Yes, I know O(N^3) = O(N^3/3) but I show the constant
>divisor to emphasize that the iterative structure is
>related to the volume of a pyramid.
>
>I'm enclosing my source code (and cross-posting to
>comp.lang.c) for critique. The program is *not*
>thoroughly tested; I estimate it still has 1.84 bugs.
>(Certain peculiar code layout details are to ensure
>short lines for Usenet.)
>
>/* begin bestcutter.c */
[snip code]

>
>James Dow Allen
I think that you could use a better algorithm. You are repeatedly
calculating the cost of the same sticks as part of your subproblems.
If there is a stick with marks at a, b, c, ... x, y, z then if you
make the first cut as a and the second cut at z you are left with a
stick of length z-a with cuts at b, c, ... x, y. If you make the
first cut at z and the second cut at a then you will have exactly the
same subproblem to solve. Saving the result and retrieving it would
be much faster than re-solving a problem you had already solved. This
needs more memory than the simple algorithm of course.

It would probably not be worthwhile storing intermediate results for
0, 1 or 2 cuts since there is no choice possible for 0 or 1 cuts and
there is an obvious algorithm for 2 cuts (cut off the longer
end-piece). I am not sure if there is an easy algorithm for three
cuts, not having thought about it at any length.

rossum

On May 11, 3:49pm, rossum <rossu...@coldmail.com> wrote:
> On Fri, 9 May 2008 03:48:20 -0700 (PDT), James Dow Allen
> <jdallen2...@yahoo.com> wrote:
> >the straightforward solution to this puzzle
> >is not of exponential complexity, but rather N^3/3.
>
> >I'm enclosing my source code (and cross-posting to
> >comp.lang.c) for critique.

> I think that you could use a better algorithm. You are repeatedly
> calculating the cost of the same sticks as part of your subproblems.

No. Reread the source to see that the code calculates and saves the
intermediate results exactly as you describe. It is the caller of
bestcut()
rather than bestcut() itself that saves these results -- is that
where your confusion lies?

My algorithm is O(N^3). Are your comments intended to suggest
existence of a less complex algorithm?

James

On Sun, 11 May 2008 02:51:38 -0700 (PDT), James Dow Allen
<jdallen2000@yahoo.com> wrote:

>On May 11, 3:49pm, rossum <rossu...@coldmail.com> wrote:
>> On Fri, 9 May 2008 03:48:20 -0700 (PDT), James Dow Allen
>> <jdallen2...@yahoo.com> wrote:
>> >the straightforward solution to this puzzle
>> >is not of exponential complexity, but rather N^3/3.
>>
>> >I'm enclosing my source code (and cross-posting to
>> >comp.lang.c) for critique.
>
>> I think that you could use a better algorithm. You are repeatedly
>> calculating the cost of the same sticks as part of your subproblems.
>
>No. Reread the source to see that the code calculates and saves the
>intermediate results exactly as you describe.
It does indeed, my mistake. Thankyou for the correction.

>It is the caller of
>bestcut()
>rather than bestcut() itself that saves these results -- is that
>where your confusion lies?
Probably because I am more used to Java rather than C, and your
solution is expressed in procedural rather than OO terms.

>
>My algorithm is O(N^3). Are your comments intended to suggest
>existence of a less complex algorithm?
No. Since I thought you were recalculating intermediate results I
thought there was an obvious speed improvement that wasn't actually
there.

Apologies for my mistake.

rossum

>
>James

On May 11, 6:44pm, rossum <rossu...@coldmail.com> wrote:
> On Sun, 11 May 2008 02:51:38 -0700 (PDT), James Dow Allen wrote
>
> >No. Reread the source to see that the code calculates and saves the
> >intermediate results exactly as you describe.
>
> It does indeed, my mistake. Thankyou for the correction.

Thank *you* for bringing closure to this subthread.
Everyone can (and does) make mistakes. *Acknowledging*
a mistake, especially in these newsgroups, is as rare
as spotting a beautiful butterfly on a stormy day.

> Apologies for my mistake.

I think mine was the bigger mistake. A few well chosen
comments in the source would have prevented any
confusion.

James

On May 11, 2:51am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>
> My algorithm is O(N^3). Are your comments intended to suggest
> existence of a less complex algorithm?

I'm unclear why the program has a complexity of N^3 instead of N!
(which is the number of ways in which the stick can be cut.)

Greg

On Sun, 11 May 2008 23:27:41 -0700 (PDT), Greg Herlihy
<greghe@mac.com> wrote:

>On May 11, 2:51am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>>
>> My algorithm is O(N^3). Are your comments intended to suggest
>> existence of a less complex algorithm?
>
>I'm unclear why the program has a complexity of N^3 instead of N!
>(which is the number of ways in which the stick can be cut.)
>
>Greg
I am sure James has a more detailed answer, but basically James'
algorithm saves intermediate results so that duplicates among your N!
possibilities are saved and not recalculated. For example on a stick
with cuts at a, b, c, ... x, y, z there will be at some point the need
to calculate the best way to cut the substick f, g, h, i , j. Once
that substick has been calculated for the first time, if the result is
stored then that result can be retrieved in constant time (array
access in James' program) which reduces the run time of the algorithm
greatly. The 5 cut substick is encountered 21! times, only one of
which needs to be calculated.

rossum