For loops not making sense??
I have this code:
lh=0.1;
bh=1.1;
nl = (bh-lh)/lh;
for(i=[0:nl]) {
echo ("i: ", i);
}
echo ("nl: ", nl);
The last 'i" is 10, and nl is '10' which means the for loop is going from 0
to nl inclusive.
Change bh to be 1.2
The last 'i" is still 10, and nl is '11' as I'd expect which means the for
loop is going from 0 to (nl-1) inclusive.
It's late, is there a bug (not in my head)?
I'm using 2015.03-3 if that's useful. This appears to be the latest version
for mac.
--
View this message in context: http://forum.openscad.org/For-loops-not-making-sense-tp19299.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Check out this thread for why iterating over a floating point increment is
not reliable:
Simple addition of numbers introduces error
http://forum.openscad.org/Simple-addition-of-numbers-introduces-error-td14408.html
So, always avoid using fractional as step increment.
$ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 ); $ tips: hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2, 3 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ), text , triang ; $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf )
--
View this message in context: http://forum.openscad.org/For-loops-not-making-sense-tp19299p19304.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
This seems to be a rounding error. Adding this:
echo ("floor(nl):", floor(nl));
Will show that it thinks that nl < 11 as it displays:
ECHO: "floor(nl):", 10
The displayed value is rounded up. The value of nl is prolly
10.999999999999999999...
--
View this message in context: http://forum.openscad.org/For-loops-not-making-sense-tp19299p19305.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
To answer your question, I think this is a bug in OpenSCAD.
I tested this in my OpenSCAD NG prototype, and I got a different result:
ECHO: "i: ",0
ECHO: "i: ",1
ECHO: "i: ",2
ECHO: "i: ",3
ECHO: "i: ",4
ECHO: "i: ",5
ECHO: "i: ",6
ECHO: "i: ",7
ECHO: "i: ",8
ECHO: "i: ",9
ECHO: "i: ",10
ECHO: "i: ",11
ECHO: "nl: ",10.999999999999998
So, I think that there is a problem with ranges, and I think there is a
problem in the way that floating point numbers are printed (instead of
printing the exact value, we print a rounded off approximation, which is
bad for debugging).
The problem with ranges is discussed here:
https://github.com/openscad/openscad/issues/1592
The proposed solution is to use Haskell semantics for ranges, which is what
I've implemented in my prototype.
On 21 November 2016 at 15:21, nigeljohnson73 nigel@nigeljohnson.net wrote:
I have this code:
lh=0.1;
bh=1.1;
nl = (bh-lh)/lh;
for(i=[0:nl]) {
echo ("i: ", i);
}
echo ("nl: ", nl);
The last 'i" is 10, and nl is '10' which means the for loop is going from 0
to nl inclusive.
Change bh to be 1.2
The last 'i" is still 10, and nl is '11' as I'd expect which means the for
loop is going from 0 to (nl-1) inclusive.
It's late, is there a bug (not in my head)?
I'm using 2015.03-3 if that's useful. This appears to be the latest version
for mac.
--
View this message in context: http://forum.openscad.org/For-
loops-not-making-sense-tp19299.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
and I think there is a
problem in the way that floating point numbers are printed (instead of
printing the exact value, we print a rounded off approximation, which is
bad for debugging).
Tell me about it...I came across that debugging that fractional code.
From the results, initially it looked like echo() & str() were producing
different results.
Looking closer, it appears to output 6 significant digits.
Echo'd -1.62891, -1 = -0.628906 ( where the float came from "-1-5/8-1/256")
& -1.62109 -1 = -0.621094 (from "-1-5/8+1/256")
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/For-loops-not-making-sense-tp19299p19312.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MichaelAtOz wrote:
I think there is a
problem in the way that floating point numbers are printed (instead of
printing the exact value, we print a rounded off approximation, which is
bad for debugging).
Tell me about it...I came across that debugging that fractional code.
From the results, initially it looked like echo() & str() were producing
different results.
Looking closer, it appears to output 6 significant digits.
Echo'd -1.62891, -1 = -0.628906 ( where the float came from "-1-5/8-1/256")
& -1.62109 -1 = -0.621094 (from "-1-5/8+1/256")
My code for echoing floating point numbers always prints an exact
representation which, when read back, unambiguously reproduces the original
number. And it prints the shortest such representation, eg 1 instead of
1.0000000000000000 and 0.2 instead of the actual binary approximation.
This is the same behaviour you will see in Python, Javascript, and most
other modern languages. But there is no support for printing floating point
numbers like this in the C and C++ standard libraries. The best way to do
this is to use the Google "double-conversion" library, which is portable
and multiplatform. It is a standard package on Ubuntu, and available on
github. Google's "double-conversion" is just a repackaging of the code they
wrote to print floating point numbers in Javascript on Chrome: the library
works on every platform that Chrome runs on. So that's what I use.
So I could integrate my change into OpenSCAD, but the problem is that it
would introduce a new package dependency. I have no way to test my change
on MacOS or Windows, I only have an Ubuntu dev system. So, that's a barrier
to submitting a pull request for this change.
If somebody in the dev team wants me to submit this change, please advise.
It would require extra work for somebody to make this work on Mac and
Windows.
On 21 November 2016 at 18:48, MichaelAtOz oz.at.michael@gmail.com wrote:
doug.moen wrote
and I think there is a
problem in the way that floating point numbers are printed (instead of
printing the exact value, we print a rounded off approximation, which is
bad for debugging).
Tell me about it...I came across that debugging that fractional code.
From the results, initially it looked like echo() & str() were producing
different results.
Looking closer, it appears to output 6 significant digits.
Echo'd -1.62891, -1 = -0.628906 ( where the float came from "-1-5/8-1/256")
& -1.62109 -1 = -0.621094 (from "-1-5/8+1/256")
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/For-
loops-not-making-sense-tp19299p19312.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Nov 21, 2016, at 19:31, doug moen doug@moens.org wrote:
If somebody in the dev team wants me to submit this change, please advise. It would require extra work for somebody to make this work on Mac and Windows.
It’s worth a shot.
We’ll just add platform packaging and testing to the TODO list before merging the pull request.
It will likely be somewhat of a job to update regression tests as well.
-Marius