hmm. I hesitate to add yet another discussion of an offset curve problem, but this one crashes with a zero offset on a simple circle. works on other curve shapes. I would expect behavior to be to simply ignore the zero offset
Weird! The zero offset is extremely slow too (18.5 secs.!?) while positive and negative values give instant results.
zero-offset-bug_2021_Jul9a.gh (8.6 KB)
P.S. But only with circles? A different closed curve works much more quickly, though 0 offset still slows it down (1.7 secs.).
zero-offset-bug_2021_Jul9b.gh (9.3 KB)
hmm. numbers generated from a straightforward series command
Good eye! Weird that circles are treated differently. I added a ‘round(x,3)’ expression and all is well.
The start and increment values don’t guarantee “true zero”. Add the ‘round(x,3)’ expression to the Offset ‘D’ input.
zero-offset-bug_2021_Jul9c.gh (8.8 KB)
1 Like
I’m pretty sure series component is doing only what you asked it to do… check, you’ll see its inputs have already not-simple numbers.
Do as Joseph just said ^
Good eye Richard, thank you joseph. but just for a head scratcher, here is the series command, there is nothing there to cause an issue
series.gh (3.7 KB)
Yes, there is. See above:
thanks guys, got a flat spot on my head beating it against the wall on this one.
You are right.
This is a Round-off error - Wikipedia .
Any number is written in binary, base-2 numbering … but displayed as decimal, base-10.
Decimal 0.3 is 0.01001100110011001101 in binary, that have a periodic part, so it has lost some precision already.
Decimal 0.044 probably have a similar problem, leading in that almost-zero number.
Hello floating point, my old friend. Come to cuss at you again. You would think I’d have learned to check that by now.