Python and Anenome - fast solver

I described what I'm trying to do in this post nine days ago but got no replies:

Fast Solver (B-Solve?): float my boat

http://www.grasshopper3d.com/forum/topics/fast-solver-b-solve-float...

Off and on since then, I have tried to write a solution using Python and Anenome but am getting absolutely nowhere. I've been a programmer for ~40 years but don't know Python. I'm sure my "binary search" code is wrong but there are so many other problems getting the code to run at all that I can't debug it.

One of the frustrations is GH's prohibition against recursion, of course, but that doesn't always stop the code from producing results - I just can't see any consistency about why it fails?

Another problem is code errors often don't show up unless I save the file, quit GH, restart GH and re-open the file. THEN I see error messages that might be useful.

I sincerely believe that a "fast solver" component like this could be widely useful for GH applications. Can anyone here please make this (or something like it) work?

The output of the Anenome 'Loop End' component connects to the 'V' input of 'ReMap', replacing the 'Z-offset' slider in the green panel, which is otherwise used to "solve" the problem manually, by trial and error.

Attachments:

HydroSolve_2015_Sep11a.gh, 35 KB

Replies to This Discussion

Permalink Reply by David Rutten on September 18, 2015 at 2:39pm

The attached C# component runs a Divide-and-Conquer search on the entire slider domain. There's a bunch of cases that aren't handled correctly, especially if certain slider positions result in no values at all.

Attachments:

BinarySolver.gh, 14 KB

Permalink Reply by Joseph Oster on September 18, 2015 at 4:17pm

Thank you very much David, I re-wired your code into my example and it seems to work!

Infinitely faster than Galapagos!!!

I'll be playing with it further, adding back some code I had weeks ago to record the 'Target', and also looking at your C code (is the 'Compute' toggle necessary?).

I really appreciate this. I will also be trying two instances operating at the same time... one for pitch and one for roll. I have no doubt that many people will find this very useful.

Permalink Reply by David Rutten on September 19, 2015 at 3:19am

Compute isn't technically necessary, but you don't want that code to start twiddling sliders when you least expect it. Ideally it'd all be exposed via a window rather than a component.

Permalink Reply by Joseph Oster on September 19, 2015 at 7:02am

I haven't had the chance to play with this very much yet and can understand wanting to control when it is operational or not. I'm quite sure, however, that I don't want a "window" popping up (like Galapagos) and usurping control of the UI. I can incorporate an on/off switch into my work flow; no need for a pop-up window just for that.

Coordinating two of these solver widgets that work at the same time will likely be a problem though...