Galapagos question -- same result


#1

galapagos always arrives at the same ,not quite exact, solution of -.001021 when running this definition:

galapagosQuest.gh (7.4 KB)

is there a setting i might be able to change to get this to arrive at a perfect solution? or, why is it always ending up with the same answer regardless of how many times i run it?

thanks


#2

So disclaimer - I’m only just learning to use Galapagos myself, but here’s what I threw together:


I threw an absolute value on the result of the length subtraction.

I set Galapagos to minimize the results. I didn’t use the same circles or lines as you, and the results weren’t equal but were close - mine were 19.183 and 19.179.


(Wim Dekeyser) #3

Why is it always ending up with the same answer? Well, that is because it is the correct answer. Given your constraints, that is. – and perhaps a bug?

  1. Constraints: You have the slider for the parameter for the curve domain set to the max of 6 decimal places but in between 0.534290 and 0.534291 there is an infinite amount of space that gets projected to the curve. The longer your curve is, the more space will not be checked. You will therefor never get to the “exact” solution. You can shorten your line to minimize the gap.

  2. Bug: I manually changed the parameter with 0.000001 increments to find the ‘optimal given the constraints’ solution and that appears to be at parameter 0.534294 (giving a difference in length of 0.000129 units). Taking a few screen dumps when the solution is being calculated shows that Galapagos doesn’t try with 0.000001 increments but only 0.000010. That explains why it ends up at 0.534290.


(David Rutten) #4

Not exactly a bug, but a problem nonetheless. Galapagos treats sliders not as floating point values in some floating point domain, but as integers representing indices. Index=0 is the lowest value the slider can assume. Index=1 is the next value up, and so on. However when the total number of distinct values exceeds some large number (a million, I think, I’d have to check) it starts taking larger steps.

It’s a bug by design if you will, the steps could have been smaller (and indeed they will be in GH2, my new slider code supports a maximum of long.MaxValue distinct indices).

One way around this limitation now is to use two sliders to create a single number. Have one slider A control the major spacing, then add a second slider B for making tiny adjustments to that one value. Ie. the final value (assuming both slider are in the (0,1) range) would be A + B/100000


#5

ah. ok… the answer IS the right answer when there are only 5 decimals to work with… got it! thanks

nice. i’ll try that (tonight)… i was trying a work around where the line shrinks (so the t value moves in smaller jumps as the correct solution nears) but didn’t quite get it working properly… using multiple sliders to build a single value sounds easier though.

thanks boys


#6

using multiple sliders to make one value did the trick…

with two sliders (making ten decimal places), the solution is a lot smaller than my typical rhino tolerances… with three sliders (making 15 decimal places), the solution arrives at 0.0

galapagosQuest_2.gh (11.9 KB)


so yeah, thanks again for the workaround idea.


#7

I run into this before and what I did was the following:

I use to run Galapagos twice (Now that I know the issue the multiple sliders option makes sense). Once to get an overall idea where the ideal solution would be located and the second run I would narrow down my search space (reducing the slider range and increase the precision of the slider) and rerun the solution. Might not be an ideal solution if you GH definition takes a few seconds to compute.