for (a7=[ 6.8:1/5:7.8]) echo(A7=a7);
for (a=[ 7.2:1/5:8.2]) echo(A=a);

Consider different approach: OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. This would require to change compiler of course. Just my $0.02 Tim ________________________________________ From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] Sent: 20 December 2016 01:02 To: OpenSCAD general discussion Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: https://gist.github.com/Juanlu001/7383894 This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: I found a remarkable difference in version 2016.10.4 using for statement with increments smaller than 1. Sometimes the end value is not reached. for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); for (a=[ 7.2:1/5:8.2]) echo(A=a); Output is ECHO: A7 = 6.8 ECHO: A7 = 7 ECHO: A7 = 7.2 ECHO: A7 = 7.4 ECHO: A7 = 7.6 ECHO: A = 7.2 ECHO: A = 7.4 ECHO: A = 7.6 ECHO: A = 7.8 ECHO: A = 8 ECHO: A = 8.2 -- View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html Sent from the OpenSCAD mailing list archive at Nabble.com. _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

for (a7=[ 6.8:1/5:7.8]) echo(A7=a7);
for (a=[ 7.2:1/5:8.2]) echo(A=a);

Tim, Your assumption is not true. Openscad CANNOT represent exactly 0.1 in binary floating point. That’s why there are so many issues with rounding errors at boundaries. Just my $0.02, Jean-Paul N1JPL > On Dec 20, 2016, at 3:55 AM, Shaporev, Timur <tim@auriga.com> wrote: > > Consider different approach: > OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. > This would require to change compiler of course. > > Just my $0.02 > Tim > ________________________________________ > From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] > Sent: 20 December 2016 01:02 > To: OpenSCAD general discussion > Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes > > The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. > > The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: > https://gist.github.com/Juanlu001/7383894 > > This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. > > On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: > I found a remarkable difference in version 2016.10.4 using for statement > with increments smaller than 1. Sometimes the end value is not reached. > > > for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); > for (a=[ 7.2:1/5:8.2]) echo(A=a); > > Output is > ECHO: A7 = 6.8 > ECHO: A7 = 7 > ECHO: A7 = 7.2 > ECHO: A7 = 7.4 > ECHO: A7 = 7.6 > ECHO: A = 7.2 > ECHO: A = 7.4 > ECHO: A = 7.6 > ECHO: A = 7.8 > ECHO: A = 8 > ECHO: A = 8.2 > > > > -- > View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

for (a7=[ 6.8:1/5:7.8]) echo(A7=a7);
for (a=[ 7.2:1/5:8.2]) echo(A=a);

So do not implement it as floating point: use rational representation. On 12/20/2016 6:49 PM, Jean-Paul Louis wrote: > Tim, > > Your assumption is not true. > Openscad CANNOT represent exactly 0.1 in binary floating point. > That’s why there are so many issues with rounding errors at boundaries. > > Just my $0.02, > Jean-Paul > N1JPL > > > >> On Dec 20, 2016, at 3:55 AM, Shaporev, Timur <tim@auriga.com> wrote: >> >> Consider different approach: >> OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. >> This would require to change compiler of course. >> >> Just my $0.02 >> Tim >> ________________________________________ >> From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] >> Sent: 20 December 2016 01:02 >> To: OpenSCAD general discussion >> Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes >> >> The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. >> >> The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: >> https://gist.github.com/Juanlu001/7383894 >> >> This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. >> >> On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: >> I found a remarkable difference in version 2016.10.4 using for statement >> with increments smaller than 1. Sometimes the end value is not reached. >> >> >> for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); >> for (a=[ 7.2:1/5:8.2]) echo(A=a); >> >> Output is >> ECHO: A7 = 6.8 >> ECHO: A7 = 7 >> ECHO: A7 = 7.2 >> ECHO: A7 = 7.4 >> ECHO: A7 = 7.6 >> ECHO: A = 7.2 >> ECHO: A = 7.4 >> ECHO: A = 7.6 >> ECHO: A = 7.8 >> ECHO: A = 8 >> ECHO: A = 8.2 >> >> >> >> -- >> View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html >> Sent from the OpenSCAD mailing list archive at Nabble.com. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

Same problem, not all numbers are rational either. Jean-Paul N1JPL > On Dec 20, 2016, at 10:50 AM, Tim V. Shaporev <tim.shaporev@auriga.ru> wrote: > > So do not implement it as floating point: use rational representation. > > On 12/20/2016 6:49 PM, Jean-Paul Louis wrote: >> Tim, >> >> Your assumption is not true. >> Openscad CANNOT represent exactly 0.1 in binary floating point. >> That’s why there are so many issues with rounding errors at boundaries. >> >> Just my $0.02, >> Jean-Paul >> N1JPL >> >> >> >>> On Dec 20, 2016, at 3:55 AM, Shaporev, Timur <tim@auriga.com> wrote: >>> >>> Consider different approach: >>> OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. >>> This would require to change compiler of course. >>> >>> Just my $0.02 >>> Tim >>> ________________________________________ >>> From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] >>> Sent: 20 December 2016 01:02 >>> To: OpenSCAD general discussion >>> Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes >>> >>> The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. >>> >>> The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: >>> https://gist.github.com/Juanlu001/7383894 >>> >>> This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. >>> >>> On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: >>> I found a remarkable difference in version 2016.10.4 using for statement >>> with increments smaller than 1. Sometimes the end value is not reached. >>> >>> >>> for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); >>> for (a=[ 7.2:1/5:8.2]) echo(A=a); >>> >>> Output is >>> ECHO: A7 = 6.8 >>> ECHO: A7 = 7 >>> ECHO: A7 = 7.2 >>> ECHO: A7 = 7.4 >>> ECHO: A7 = 7.6 >>> ECHO: A = 7.2 >>> ECHO: A = 7.4 >>> ECHO: A = 7.6 >>> ECHO: A = 7.8 >>> ECHO: A = 8 >>> ECHO: A = 8.2 >>> >>> >>> >>> -- >>> View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Doesn’t fix the problem - just kicks the can down the road a bit. > On Dec 20, 2016, at 09:50, Tim V. Shaporev <tim.shaporev@auriga.ru> wrote: > > So do not implement it as floating point: use rational representation. > > On 12/20/2016 6:49 PM, Jean-Paul Louis wrote: >> Tim, >> >> Your assumption is not true. >> Openscad CANNOT represent exactly 0.1 in binary floating point. >> That’s why there are so many issues with rounding errors at boundaries. >> >> Just my $0.02, >> Jean-Paul >> N1JPL >> >> >> >>> On Dec 20, 2016, at 3:55 AM, Shaporev, Timur <tim@auriga.com> wrote: >>> >>> Consider different approach: >>> OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. >>> This would require to change compiler of course. >>> >>> Just my $0.02 >>> Tim >>> ________________________________________ >>> From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] >>> Sent: 20 December 2016 01:02 >>> To: OpenSCAD general discussion >>> Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes >>> >>> The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. >>> >>> The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: >>> https://gist.github.com/Juanlu001/7383894 >>> >>> This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. >>> >>> On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: >>> I found a remarkable difference in version 2016.10.4 using for statement >>> with increments smaller than 1. Sometimes the end value is not reached. >>> >>> >>> for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); >>> for (a=[ 7.2:1/5:8.2]) echo(A=a); >>> >>> Output is >>> ECHO: A7 = 6.8 >>> ECHO: A7 = 7 >>> ECHO: A7 = 7.2 >>> ECHO: A7 = 7.4 >>> ECHO: A7 = 7.6 >>> ECHO: A = 7.2 >>> ECHO: A = 7.4 >>> ECHO: A = 7.6 >>> ECHO: A = 7.8 >>> ECHO: A = 8 >>> ECHO: A = 8.2 >>> >>> >>> >>> -- >>> View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org — Kenneth Sloan kennethrsloan@gmail.com

Any value which can be represented in decimal notation can be represented as rational number exactly. On 12/20/2016 7:35 PM, Jean-Paul Louis wrote: > Same problem, not all numbers are rational either. > > Jean-Paul > N1JPL > > >> On Dec 20, 2016, at 10:50 AM, Tim V. Shaporev <tim.shaporev@auriga.ru> wrote: >> >> So do not implement it as floating point: use rational representation. >> >> On 12/20/2016 6:49 PM, Jean-Paul Louis wrote: >>> Tim, >>> >>> Your assumption is not true. >>> Openscad CANNOT represent exactly 0.1 in binary floating point. >>> That’s why there are so many issues with rounding errors at boundaries. >>> >>> Just my $0.02, >>> Jean-Paul >>> N1JPL >>> >>> >>> >>>> On Dec 20, 2016, at 3:55 AM, Shaporev, Timur <tim@auriga.com> wrote: >>>> >>>> Consider different approach: >>>> OpenSCAD is able to represent decimals exactly: 0.2 as 2/10 (or 1/5) etc. >>>> This would require to change compiler of course. >>>> >>>> Just my $0.02 >>>> Tim >>>> ________________________________________ >>>> From: Discuss [discuss-bounces@lists.openscad.org] on behalf of doug moen [doug@moens.org] >>>> Sent: 20 December 2016 01:02 >>>> To: OpenSCAD general discussion >>>> Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes >>>> >>>> The fix I implemented is based on the Haskell implementation of floating point numeric ranges. That was the best reference implementation that I could find at the time. >>>> >>>> The first:step:last syntax is taken from Matlab. I found Matlab source code for the colon operator, it's here: >>>> https://gist.github.com/Juanlu001/7383894 >>>> >>>> This fixes the bug, *and* it is more backward compatible with OpenSCAD than the Haskell implementation. >>>> >>>> On 17 December 2016 at 02:59, Johan Jonker <johangjonker@zonnet.nl<mailto:johangjonker@zonnet.nl>> wrote: >>>> I found a remarkable difference in version 2016.10.4 using for statement >>>> with increments smaller than 1. Sometimes the end value is not reached. >>>> >>>> >>>> for (a7=[ 6.8:1/5:7.8]) echo(A7=a7); >>>> for (a=[ 7.2:1/5:8.2]) echo(A=a); >>>> >>>> Output is >>>> ECHO: A7 = 6.8 >>>> ECHO: A7 = 7 >>>> ECHO: A7 = 7.2 >>>> ECHO: A7 = 7.4 >>>> ECHO: A7 = 7.6 >>>> ECHO: A = 7.2 >>>> ECHO: A = 7.4 >>>> ECHO: A = 7.6 >>>> ECHO: A = 7.8 >>>> ECHO: A = 8 >>>> ECHO: A = 8.2 >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591.html >>>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org<mailto:Discuss@lists.openscad.org> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

On 20. des. 2016 17:42, Tim V. Shaporev wrote: > Any value which can be represented in decimal notation can be > represented as rational number exactly. Try an irrational number, try PI (Hint: 22/7 is not the answer). This whole discussion is bizarre. Carsten Arnholm

>From: Discuss [discuss-bounces@lists.openscad.org] on behalf of Carsten Arnholm [arnholm@arnholm.org] >On 20. des. 2016 17:42, Tim V. Shaporev wrote: >> Any value which can be represented in decimal notation can be >> represented as rational number exactly. >Try an irrational number, try PI (Hint: 22/7 is not the answer). As soon as you give me exact decimal writing of PI (Hint: 3.14 is not the answer). >This whole discussion is bizarre. Agree. Bye Tim

SQRT(2.0) > On Dec 20, 2016, at 13:48, Shaporev, Timur <tim@auriga.com> wrote: > >> From: Discuss [discuss-bounces@lists.openscad.org] on behalf of Carsten Arnholm [arnholm@arnholm.org] > >> On 20. des. 2016 17:42, Tim V. Shaporev wrote: >>> Any value which can be represented in decimal notation can be >>> represented as rational number exactly. > >> Try an irrational number, try PI (Hint: 22/7 is not the answer). > As soon as you give me exact decimal writing of PI (Hint: 3.14 is not the answer). > >> This whole discussion is bizarre. > Agree. > > Bye > Tim > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org — Kenneth Sloan kennethrsloan@gmail.com

I agree absolutely with you, Carsten. A lot of people have no clue about internal representation of numbers. Just my $0.02, Jean-Paul N1JPL > On Dec 20, 2016, at 1:31 PM, Carsten Arnholm <arnholm@arnholm.org> wrote: > > On 20. des. 2016 17:42, Tim V. Shaporev wrote: >> Any value which can be represented in decimal notation can be >> represented as rational number exactly. > > Try an irrational number, try PI (Hint: 22/7 is not the answer). > > This whole discussion is bizarre. > > Carsten Arnholm > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org