Hi all I have a problem with graph mapper component in rhino 6.
I think it’s a bug, because in the previous version of grasshopper it was working differently.
The problem is that with the bezier mode (and some other) every value of the input list is transformed to 1 before remaping them, so all the values are remapped to the same one after processed from the graph mapped. Coutrarywise the correct behaviour should be the one that is still working in the square root mode.
Check the image for the example.
If the graph is defined beyond the input range, then it will be evaluated using the appropriate equation. So roots or parabolas or sine waves all work beyond the x-domain, but a bezier curve effectively stops at the rightmost grip so all values beyond are projected back onto the domain.
Oh I see, probably in the previous works I did, I had domains already between 0 and 1 without noticing it.
Then, it would be usefull to have the domain limits as inputs of the graph editor, just a suggestion ;)!
Thanks a lot for your fast answer!
Isn’t the Bezier equation technically a piecewise cubic polynomial that can also be extrapolated beyond the domain of x values?
It seems to me like the “least surprising” thing to do in this context would be to raise a “Out of range” warning rather than silently clipping the inputs - similar to how Evaluate Curve deals with t-values outside of the curve domain.
Polynomials in two dimensions. The parts beyond the [0,1] interval tend to grow towards infinity very quickly, and not necessarily continuing on along the x-axis.
I did debate whether to extend the curve using tangent lines or horizontal lines, and in the end decided against tangent since the tangent lines could be very steep, again going off to uncomfortably large values very quickly.
A warning would have made sense, something to keep in mind for GH2 certainly.
Ah yes - that makes sense considering you can create asymptotes by making the handles vertical.
Trying out-of-domain values for the other graph types, looks like the Square Root one returns “wrong” results for negative numbers - where it should be “NaN” or at least the magnitude of the complex result - Is this intended behaviour?
Yeah I figured the most likely useful way for the squareroot to behave was to copy the sign of the input to the output, and always use the absolute value. Considering how easy it is to remove negative values or set them all to zero ahead of time, this seems like it would do the most complicated approach for free.
