-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[for (t=[0:step:1-step]) ...] yields one less than expected #13
Comments
Well this is a little odd. I guess this is an openscad bug: step = 0.01;
echo(1.0/step); ECHO: 100 echo([for (t=[0:1.0:1/step]) t]); ECHO: [0, ... 100] echo([for (t=[0:1.0:0.999999999/step]) t]); ECHO: [0, ... 99] echo([for (t=[0:step:1]) t]); ECHO: [0, ... 0.99] I'm not sure what to do with that now. I guess it's a floating point issue but my original point still stands, kinda. Please advise. |
|
I didn't write it but the intent is probably as you say to exclude the last. |
|
This is a good primer to this specific floating point problem. |
I avoid this problem by passing the number of steps rather than the step
size. I then iterate with integers and divide by the the number of steps.
For example: -
function bezier_path(v, steps = 100) = // Returns a Bezier path from
control points v with steps segments
[for(i = [0 : steps], t = i / steps) bezier(t, v)];
Note that this does 101 iterations because a curve with 100 segments has
101 points.
…On Tue, 30 Jul 2019 at 06:19, Michael ***@***.***> wrote:
This is a good primer
<https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/>
to this specific floating point problem.
0.01 as a double is
0.01000000000000000020816681711721685132943093776702880859375
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13?email_source=notifications&email_token=AAEKHBKGRKX4W5GK2JNMW4DQB7FPDA5CNFSM4IHYE7G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3CZRPA#issuecomment-516266172>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEKHBISRMTG55RFYXVWI73QB7FPDANCNFSM4IHYE7GQ>
.
|
I'm guessing here but it seems like the intent of the 1-step end condition in the following is that we exclude 1.0 from the array. Thus:
would print [0 ... 0.99] i.e. 100 values but it doesn't. It prints only 99 values: [0 ... 0.98].
This is a little confusing when trying to adapt the code because I end up with a bunch of -2s where I would expect to find only -1s.
This is not exactly a big deal but if someone would confirm the intent is as I expect I will create a pull request with the fixes.
The text was updated successfully, but these errors were encountered: