for statement doesn't do all the steps sometimes

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

jdawgaz
I did this to come up with the same code doing integer arithmetic:

// your code: for (a7=[ 6.8:1/5:7.8]) echo(A7=a7);

for (a7=[0:2:11]) echo(A7=6.8+a7/10);

Maybe if everyone KNEW what to expect and made the appropriate changes in their code:
So we change the examples in the Documentation, to reflect what is happening, and those who don't change their code takes the consequences. This all blind sided me when I looked at the Documentation.





--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Dec 18, 2016 at 10:56 AM, nop head <[hidden email]> wrote:
I don't understand why the last value should equal the limit. What about [0:2:9]? Surely that should stop at 8.

Perhaps just give a warning if the step is not an integer and deprecate it. A floating point step is just a bad idea because most fractions are inexact in binary.

On 18 December 2016 at 17:37, doug moen <[hidden email]> wrote:
Hi Parkinbot.

I agree with your point, but there is a bigger issue to consider.

The bug only gets triggered with very special values of step, first and last.
In most of the forum posts reporting this bug, a step of 0.2 was used,
although Johan discovered it using a step of 1.2.
Even with a special step value, you also need special first/last values.
For example, [1 : 0.2 : 2] works.
  [1 : 0.2 : 3] fails, 4 through 8 fail.
But [1 : 0.2 : 9] succeeds, and all ints > 9 succeed (that I've tested).

Because the bug is difficult to trigger, you could be using OpenSCAD for
a long time without encountering the bug. For example, Johan has been
a forum member for some time, but he is just now reporting the bug.

There are probably a lot of parameterized models out there that
contain the bug, including on Thingiverse, but the author might be
unaware because he didn't test with the magic parameter values that
trigger the bug.

If we fix this bug, we will likely be fixing bugs in a lot of existing models,
and we will also be removing a weird pitfall that OpenSCAD users
continue to trip over and report in the forum.

Doug Moen.


On 18 December 2016 at 07:09, Parkinbot <[hidden email]> wrote:
Doug,

again a vote for silent behavior and hidden magic - and no means to roll
back. You propose a solution that will potentially break existing code and
algorithms. The semantical difference can be a "hard to spot" problem as
soon as nested loops come into play and can affect each (!) nesting level.

Look at this double loop, (where only the inner loop is effected, as the
outer loop is classical):

> first = 6.8;
> step = .2;
> last = 8;
>
> for (y=[7.4:.05:8.4]) loops(y);
>
> module loops(last)
> {
>   echo(classic = classic_loop(first, step, last));
>   echo(dougs = doug_loop(first, step, last));
>   echo();
> }
>
> function classic_loop(first, step, last) = [for(x = [first: step: last])
> x];
>
> function doug_loop(first, step, last) =
>   let(first_ = 0)
>   let(step_ = sign(step))
>   let(last_ = round((last-first)/step))
>   [for(i = [first_: step_: last_]) first+i*step];

this is the output:

> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2, 8.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2, 8.4]
> ECHO:





--
View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591p19622.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

jdawgaz
or more simply:

for (a7=[ 68:2:78]) echo(myA7=a7/10);



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Dec 18, 2016 at 11:15 AM, Jerry Davis <[hidden email]> wrote:
I did this to come up with the same code doing integer arithmetic:

// your code: for (a7=[ 6.8:1/5:7.8]) echo(A7=a7);

for (a7=[0:2:11]) echo(A7=6.8+a7/10);

Maybe if everyone KNEW what to expect and made the appropriate changes in their code:
So we change the examples in the Documentation, to reflect what is happening, and those who don't change their code takes the consequences. This all blind sided me when I looked at the Documentation.





--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Sun, Dec 18, 2016 at 10:56 AM, nop head <[hidden email]> wrote:
I don't understand why the last value should equal the limit. What about [0:2:9]? Surely that should stop at 8.

Perhaps just give a warning if the step is not an integer and deprecate it. A floating point step is just a bad idea because most fractions are inexact in binary.

On 18 December 2016 at 17:37, doug moen <[hidden email]> wrote:
Hi Parkinbot.

I agree with your point, but there is a bigger issue to consider.

The bug only gets triggered with very special values of step, first and last.
In most of the forum posts reporting this bug, a step of 0.2 was used,
although Johan discovered it using a step of 1.2.
Even with a special step value, you also need special first/last values.
For example, [1 : 0.2 : 2] works.
  [1 : 0.2 : 3] fails, 4 through 8 fail.
But [1 : 0.2 : 9] succeeds, and all ints > 9 succeed (that I've tested).

Because the bug is difficult to trigger, you could be using OpenSCAD for
a long time without encountering the bug. For example, Johan has been
a forum member for some time, but he is just now reporting the bug.

There are probably a lot of parameterized models out there that
contain the bug, including on Thingiverse, but the author might be
unaware because he didn't test with the magic parameter values that
trigger the bug.

If we fix this bug, we will likely be fixing bugs in a lot of existing models,
and we will also be removing a weird pitfall that OpenSCAD users
continue to trip over and report in the forum.

Doug Moen.


On 18 December 2016 at 07:09, Parkinbot <[hidden email]> wrote:
Doug,

again a vote for silent behavior and hidden magic - and no means to roll
back. You propose a solution that will potentially break existing code and
algorithms. The semantical difference can be a "hard to spot" problem as
soon as nested loops come into play and can affect each (!) nesting level.

Look at this double loop, (where only the inner loop is effected, as the
outer loop is classical):

> first = 6.8;
> step = .2;
> last = 8;
>
> for (y=[7.4:.05:8.4]) loops(y);
>
> module loops(last)
> {
>   echo(classic = classic_loop(first, step, last));
>   echo(dougs = doug_loop(first, step, last));
>   echo();
> }
>
> function classic_loop(first, step, last) = [for(x = [first: step: last])
> x];
>
> function doug_loop(first, step, last) =
>   let(first_ = 0)
>   let(step_ = sign(step))
>   let(last_ = round((last-first)/step))
>   [for(i = [first_: step_: last_]) first+i*step];

this is the output:

> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2, 8.4]
> ECHO:
> ECHO: classic = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2]
> ECHO: dougs = [6.8, 7, 7.2, 7.4, 7.6, 7.8, 8, 8.2, 8.4]
> ECHO:





--
View this message in context: http://forum.openscad.org/for-statement-doesn-t-do-all-the-steps-sometimes-tp19591p19622.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

rew
In reply to this post by doug.moen
On Sat, Dec 17, 2016 at 11:16:40AM -0500, doug moen wrote:

> My implementation accounts for floating point imprecision: the 'last' value
> might be an approximation of the final value. So [1 : 0.2 : 2.99] and [1 :
> 0.2 : 3.01] produce the same result as [1 : 0.2 : 3].

Auch!  I know that steps of 0.2 are "inaccurate" and "compensation for
floating point inaccuracies may be necessary". But if I want N steps
where the step size is never smaller than 0.01, and I do NOT want to
include the final object at index "3", I'll write:
[1:3/N:2.99] to make sure that the final one will NOT be rendered.

Fixing the "assumption" that 3/N is never < 0.01, I'll write:
[1:3/N:3-1/N], again to make sure that I don't include the final
one at (floating point accuracy equal to) 3.

This is important if, say I'm building a fence:
N=4;
eps=0.1;
for (i=[0:1/N:3-eps]) translate ([i,0,0]) cube ([0.1,0.1,1]);
for (i=[0:1/N:1-eps]) translate ([3,i,0]) cube ([0.1,0.1,1]);
for (i=[4:1/N:5-eps]) translate ([i,1,0]) cube ([0.1,0.1,1]);

The final values each time are meant NOT to be included each time,
otherwise I get a double post at those points.

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

rew
In reply to this post by doug.moen
On Sun, Dec 18, 2016 at 12:37:41PM -0500, doug moen wrote:
> If we fix this bug, we will likely be fixing bugs in a lot of existing
> models,

But if you suddenly change behaviour for endvalues = X * start+step,
where X = n + [0.5...1];
you will also create bugs in other existing models.

An automatic epsilon of around step / 2^(mantissa_size - 4) sounds
reasonable to me. Mantissa_size is 24 or 23 for floats, and 48 for
doubles.

This will keep the published behaviour unless you're doing on the
order of 2^20 steps....

        Roger.



--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

L Boyd
An easier way is to increase your end value by 1/2 the step size.
Larry
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

doug.moen
In reply to this post by Johan Jonker
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:

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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Shaporev, Timur
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 [[hidden email]] on behalf of doug moen [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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
[hidden email]<mailto:[hidden email]>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

louijp
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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
> 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 <[hidden email]<mailto:[hidden email]>> 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
> [hidden email]<mailto:[hidden email]>
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Tim V. Shaporev
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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
>> 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 <[hidden email]<mailto:[hidden email]>> 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
>> [hidden email]<mailto:[hidden email]>
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

louijp
Same problem, not all numbers are rational either.

Jean-Paul
N1JPL


> On Dec 20, 2016, at 10:50 AM, Tim V. Shaporev <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
>>> 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 <[hidden email]<mailto:[hidden email]>> 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
>>> [hidden email]<mailto:[hidden email]>
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Kenneth Sloan
In reply to this post by Tim V. Shaporev
Doesn’t fix the problem - just kicks the can down the road a bit.

On Dec 20, 2016, at 09:50, Tim V. Shaporev <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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
[hidden email]<mailto:[hidden email]>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Kenneth Sloan
[hidden email]




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Tim V. Shaporev
In reply to this post by louijp
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 <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
>>>> 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 <[hidden email]<mailto:[hidden email]>> 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
>>>> [hidden email]<mailto:[hidden email]>
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> [hidden email]
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

cacb
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Shaporev, Timur
>From: Discuss [[hidden email]] on behalf of Carsten Arnholm [[hidden email]]

>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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Kenneth Sloan
SQRT(2.0)

On Dec 20, 2016, at 13:48, Shaporev, Timur <[hidden email]> wrote:

From: Discuss [[hidden email]] on behalf of Carsten Arnholm [[hidden email]]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Kenneth Sloan
[hidden email]




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

louijp
In reply to this post by cacb
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 <[hidden email]> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

RobWLakes
In reply to this post by Tim V. Shaporev
Surely using "counting" numbers eg integers to count loops, and
separately, use floating point ("measurement numbers") if required for
the solution, is a good idea?  However to mash these two processes
together, and then not expect inconsistencies is a forlorn hope?  I
don't believe the language should have to create a "nanny state" (not a
bad pun there), where misuse of these concepts are auto-magically
corrected. Caveat Emptor! or maybe a User Beware warning, seeing the
software is not purchased, could be spelt out in the support
information.  I suspect for many people openSCAD maybe the first time
some users have crafted scripts and not aware of the linititations of
representing our real world of infinite ranges of precision, with a
finite binary state machine.
Rob
------ Original Message ------
From: "Tim V. Shaporev" <[hidden email]>
To: [hidden email]
Sent: Wednesday, 21 Dec, 2016 At 2:50 AM
Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes

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 <[hidden email]> 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 [[hidden email]] on behalf of doug
>> moen [[hidden email]]
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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
>> [hidden email]<mailto:[hidden email]>
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




Rob Ward

+613 5156 5388  or  +61419 470 734

30 Hillcrest Way, Lake Tyers Beach,3909

http://www.laketyersbeach.net.au



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

jdawgaz
I personally think that:

1. use integer only numbers for the start, step, stop.
2. then do whatever calculation inside the loop to do what you want.

And document the heck out of it, and why.

This way people who are new to OpenScad can turn to the documentation
to see how it works.



--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov


On Tue, Dec 20, 2016 at 8:07 PM, rl.ward rl.ward <[hidden email]> wrote:
Surely using "counting" numbers eg integers to count loops, and separately, use floating point ("measurement numbers") if required for the solution, is a good idea?  However to mash these two processes together, and then not expect inconsistencies is a forlorn hope?  I don't believe the language should have to create a "nanny state" (not a bad pun there), where misuse of these concepts are auto-magically corrected. Caveat Emptor! or maybe a User Beware warning, seeing the software is not purchased, could be spelt out in the support information.  I suspect for many people openSCAD maybe the first time some users have crafted scripts and not aware of the linititations of representing our real world of infinite ranges of precision, with a finite binary state machine.
Rob

------ Original Message ------
From: "Tim V. Shaporev" <[hidden email]>
To: [hidden email]
Sent: Wednesday, 21 Dec, 2016 At 2:50 AM
Subject: Re: [OpenSCAD] for statement doesn't do all the steps sometimes

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 <[hidden email]> 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 [[hidden email]] on behalf of doug moen [[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> 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
[hidden email]<mailto:[hidden email]>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




Rob Ward

<a href="tel:%2B613%205156%205388" value="+61351565388" target="_blank">+613 5156 5388  or  <a href="tel:%2B61419%20470%20734" value="+61419470734" target="_blank">+61419 470 734

30 Hillcrest Way, Lake Tyers Beach,3909

http://www.laketyersbeach.net.au




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: for statement doesn't do all the steps sometimes

Ronaldo
In reply to this post by L Boyd
L Boyd wrote
An easier way is to increase your end value by 1/2 the step size.
Besides breaking codes like Rogier Wolff's ones, Dough's proposal will break the workaround codes following Boyd's suggestion.

first = 0;
step = 0.2;
last = 1+step/2;
end=first + round((last-first)/step) * step;
echo(end=end);
for(i=[first:step:end])  echo(dough=i);
for(i=[first:step:last]) echo(current=i);
12