On 10/21/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
At least with divide-and-conquer your space requirements goes logarithmic with the size of the problem. I don't know deCasteljau's algorithm, but assuming it only needs one non-tail call and it scales
If it's a divide and conquer algorithm, it's probably making more than one recursive call for each function call. We need to figure out how much state information is described in a recursion call and how much state info is used during the processing of a function call. We also need to know what the combine step is like. The ideal situation is arbitrary "local variables", a small number of parameters to a recursion call, and no combine step. This way, the state machine could push however many subproblems onto the stack, then forget everything and start working on the top of the stack. If there's a combine step, then we have to push a bunch of state info so that the machine can restore its state fully when combining subproblems.
with the pixels in one dimonsion, you could assume 2048 pixels max. That means you can limit the depth of the stack to 11. If it scales with the number of pixel in total, you still only need twice that. If my assumptions are right, it seems feasible to use the block RAM. I'll leave it to Tim to knock me in the head with a strict block RAM budget ;-)
This depends on where you want to put it. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
