inconsistent propagation of $fa

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

Re: inconsistent propagation of $fa

nophead
I assume variables are assigned in order they appear because the order matters.

Yes the module assert is no use for guarding expressions but it could be useful for reporting errors that don't cause expression warnings and guarding bad geometry. For example passing a negative dimension to cube. Or enforcing some constraint on geometry.

On Mon, 29 Jun 2020 at 22:00, adrianv <[hidden email]> wrote:
So is the order of evaluation of expressions at all limited, or it's
unspecified?  Do they execute in the order they appear in the code? 

In the example below, using an assignment means it's now an expression
evaluation instead of a module.  Does that guarantee that in the code

dummy = assert(is_list(a));
b=len(a);

that the first line is run first? 

It's hard for me to think of an example where you use assert and you want
the code after the assert to run, so the behavior of the assert module seems
to really limit its use. 




nophead wrote
>> But I wonder how does assigning the assert to a variable force the assert
> to run before the len evaluation in your example?
>
> I think it is simply that expressions are evaluated before modules are
> instantiated, so the function version of assert runs before the module
> version, just as the function version of echo runs before the module
> version of echo.
>
> The module version of assert doesn't make a lot of sense in this case
> where
> you want it to guard against an error in an expression, rather than just
> stopping broken geometry.
>
>
> On Mon, 29 Jun 2020 at 19:53, adrianv &lt;

> avm4@

> &gt; wrote:
>
>> I asked about this behavior somewhat recently and was told that it had
>> been
>> fixed in the latest OpenSCAD.  Conceivably modules could execute in
>> blocks
>> so that nothing after an assert runs before the assert.  I haven't done
>> further investigations to see if the behavior has in fact changed.  With
>> random execution order, assertions are basically useless in modules.
>>
>> But I wonder how does assigning the assert to a variable force the assert
>> to
>> run before the len evaluation in your example?  The two lines remain
>> independent.  It seems like you would need to do something like
>>
>> x = assert(is_list(a)) 0;
>> b= x+len(a);
>>
>> to ensure that the second line cannot run before the first one.  Of
>> course
>> in this simple case one can do
>>
>> b = assert(is_list(a)) len(b);
>>
>> but this isn't always possible.
>>
>>
>> Ronaldo wrote
>> > and call for instance t(1), I get :
>> >
>> > WARNING: len() parameter could not be converted, in file , line 9
>> >
>> > ERROR: Assertion '(is_list(a)))' failed in file , line 8
>> >
>> > TRACE: called by 'assert', in file , line 8.
>> >
>> > TRACE: called by 't', in file , line 13.
>> >
>> >
>> > That means the system tried to assign len(a) to b *before* the assert
>> is
>> > called.
>> >
>> > To be sure the assert expression is evaluated before, I initialize
>> > something with the assert expression:
>> >
>> > module t(a) {
>> >   x = assert( is_list(a) );
>> >   b = len(a);
>> >   echo(b);
>> > }
>> >
>> > Is that correct? Is there any other alternative?
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.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: inconsistent propagation of $fa

adrianv
It would only be good for guarding against bad geometry if the geometry isn't
the result of computation with expressions.  In my code I tried to do

assert( parameter check);

faces = make_polyhedron(parameters);
polyhedron(vertices,faces=faces);

and this fails because make_polyhedron runs before the module assertion.
It's a pretty simple case of trying to prevent invalid geometry from being
attempted.  


nophead wrote

> I assume variables are assigned in order they appear because the order
> matters.
>
> Yes the module assert is no use for guarding expressions but it could be
> useful for reporting errors that don't cause expression warnings and
> guarding bad geometry. For example passing a negative dimension to cube.
> Or
> enforcing some constraint on geometry.
>
> On Mon, 29 Jun 2020 at 22:00, adrianv &lt;

> avm4@

> &gt; wrote:
>
>> So is the order of evaluation of expressions at all limited, or it's
>> unspecified?  Do they execute in the order they appear in the code?
>>
>> In the example below, using an assignment means it's now an expression
>> evaluation instead of a module.  Does that guarantee that in the code
>>
>> dummy = assert(is_list(a));
>> b=len(a);
>>
>> that the first line is run first?
>>
>> It's hard for me to think of an example where you use assert and you want
>> the code after the assert to run, so the behavior of the assert module
>> seems
>> to really limit its use.
>>
>>
>>
>>
>> nophead wrote
>> >> But I wonder how does assigning the assert to a variable force the
>> assert
>> > to run before the len evaluation in your example?
>> >
>> > I think it is simply that expressions are evaluated before modules are
>> > instantiated, so the function version of assert runs before the module
>> > version, just as the function version of echo runs before the module
>> > version of echo.
>> >
>> > The module version of assert doesn't make a lot of sense in this case
>> > where
>> > you want it to guard against an error in an expression, rather than
>> just
>> > stopping broken geometry.
>> >
>> >
>> > On Mon, 29 Jun 2020 at 19:53, adrianv &lt;
>>
>> > avm4@
>>
>> > &gt; wrote:
>> >
>> >> I asked about this behavior somewhat recently and was told that it had
>> >> been
>> >> fixed in the latest OpenSCAD.  Conceivably modules could execute in
>> >> blocks
>> >> so that nothing after an assert runs before the assert.  I haven't
>> done
>> >> further investigations to see if the behavior has in fact changed.
>> With
>> >> random execution order, assertions are basically useless in modules.
>> >>
>> >> But I wonder how does assigning the assert to a variable force the
>> assert
>> >> to
>> >> run before the len evaluation in your example?  The two lines remain
>> >> independent.  It seems like you would need to do something like
>> >>
>> >> x = assert(is_list(a)) 0;
>> >> b= x+len(a);
>> >>
>> >> to ensure that the second line cannot run before the first one.  Of
>> >> course
>> >> in this simple case one can do
>> >>
>> >> b = assert(is_list(a)) len(b);
>> >>
>> >> but this isn't always possible.
>> >>
>> >>
>> >> Ronaldo wrote
>> >> > and call for instance t(1), I get :
>> >> >
>> >> > WARNING: len() parameter could not be converted, in file , line 9
>> >> >
>> >> > ERROR: Assertion '(is_list(a)))' failed in file , line 8
>> >> >
>> >> > TRACE: called by 'assert', in file , line 8.
>> >> >
>> >> > TRACE: called by 't', in file , line 13.
>> >> >
>> >> >
>> >> > That means the system tried to assign len(a) to b *before* the
>> assert
>> >> is
>> >> > called.
>> >> >
>> >> > To be sure the assert expression is evaluated before, I initialize
>> >> > something with the assert expression:
>> >> >
>> >> > module t(a) {
>> >> >   x = assert( is_list(a) );
>> >> >   b = len(a);
>> >> >   echo(b);
>> >> > }
>> >> >
>> >> > Is that correct? Is there any other alternative?
>> >> >
>> >> > _______________________________________________
>> >> > OpenSCAD mailing list
>> >>
>> >> > Discuss@.openscad
>> >>
>> >> >
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Sent from: http://forum.openscad.org/
>> >>
>> >> _______________________________________________
>> >> OpenSCAD mailing list
>> >>
>>
>> > Discuss@.openscad
>>
>> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> >>
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.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: inconsistent propagation of $fa

nophead
make_polyhedreon is presumably a function that returns lists. By geometry I meant modules that create actual geometry.

On Mon, 29 Jun 2020 at 22:25, adrianv <[hidden email]> wrote:
It would only be good for guarding against bad geometry if the geometry isn't
the result of computation with expressions.  In my code I tried to do

assert( parameter check);

faces = make_polyhedron(parameters);
polyhedron(vertices,faces=faces);

and this fails because make_polyhedron runs before the module assertion.
It's a pretty simple case of trying to prevent invalid geometry from being
attempted. 


nophead wrote
> I assume variables are assigned in order they appear because the order
> matters.
>
> Yes the module assert is no use for guarding expressions but it could be
> useful for reporting errors that don't cause expression warnings and
> guarding bad geometry. For example passing a negative dimension to cube.
> Or
> enforcing some constraint on geometry.
>
> On Mon, 29 Jun 2020 at 22:00, adrianv &lt;

> avm4@

> &gt; wrote:
>
>> So is the order of evaluation of expressions at all limited, or it's
>> unspecified?  Do they execute in the order they appear in the code?
>>
>> In the example below, using an assignment means it's now an expression
>> evaluation instead of a module.  Does that guarantee that in the code
>>
>> dummy = assert(is_list(a));
>> b=len(a);
>>
>> that the first line is run first?
>>
>> It's hard for me to think of an example where you use assert and you want
>> the code after the assert to run, so the behavior of the assert module
>> seems
>> to really limit its use.
>>
>>
>>
>>
>> nophead wrote
>> >> But I wonder how does assigning the assert to a variable force the
>> assert
>> > to run before the len evaluation in your example?
>> >
>> > I think it is simply that expressions are evaluated before modules are
>> > instantiated, so the function version of assert runs before the module
>> > version, just as the function version of echo runs before the module
>> > version of echo.
>> >
>> > The module version of assert doesn't make a lot of sense in this case
>> > where
>> > you want it to guard against an error in an expression, rather than
>> just
>> > stopping broken geometry.
>> >
>> >
>> > On Mon, 29 Jun 2020 at 19:53, adrianv &lt;
>>
>> > avm4@
>>
>> > &gt; wrote:
>> >
>> >> I asked about this behavior somewhat recently and was told that it had
>> >> been
>> >> fixed in the latest OpenSCAD.  Conceivably modules could execute in
>> >> blocks
>> >> so that nothing after an assert runs before the assert.  I haven't
>> done
>> >> further investigations to see if the behavior has in fact changed.
>> With
>> >> random execution order, assertions are basically useless in modules.
>> >>
>> >> But I wonder how does assigning the assert to a variable force the
>> assert
>> >> to
>> >> run before the len evaluation in your example?  The two lines remain
>> >> independent.  It seems like you would need to do something like
>> >>
>> >> x = assert(is_list(a)) 0;
>> >> b= x+len(a);
>> >>
>> >> to ensure that the second line cannot run before the first one.  Of
>> >> course
>> >> in this simple case one can do
>> >>
>> >> b = assert(is_list(a)) len(b);
>> >>
>> >> but this isn't always possible.
>> >>
>> >>
>> >> Ronaldo wrote
>> >> > and call for instance t(1), I get :
>> >> >
>> >> > WARNING: len() parameter could not be converted, in file , line 9
>> >> >
>> >> > ERROR: Assertion '(is_list(a)))' failed in file , line 8
>> >> >
>> >> > TRACE: called by 'assert', in file , line 8.
>> >> >
>> >> > TRACE: called by 't', in file , line 13.
>> >> >
>> >> >
>> >> > That means the system tried to assign len(a) to b *before* the
>> assert
>> >> is
>> >> > called.
>> >> >
>> >> > To be sure the assert expression is evaluated before, I initialize
>> >> > something with the assert expression:
>> >> >
>> >> > module t(a) {
>> >> >   x = assert( is_list(a) );
>> >> >   b = len(a);
>> >> >   echo(b);
>> >> > }
>> >> >
>> >> > Is that correct? Is there any other alternative?
>> >> >
>> >> > _______________________________________________
>> >> > OpenSCAD mailing list
>> >>
>> >> > Discuss@.openscad
>> >>
>> >> >
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Sent from: http://forum.openscad.org/
>> >>
>> >> _______________________________________________
>> >> OpenSCAD mailing list
>> >>
>>
>> > Discuss@.openscad
>>
>> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> >>
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.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: inconsistent propagation of $fa

Ronaldo
In reply to this post by adrianv
assert() is syntactically a mystery. Sometimes it may seem to be an expression but it is not:

a = 2;
echo(a);
assert(a>0);
x = assert(a!=0) 1/a;
echo(x);
y = assert(a>=0);
echo(y);

BTW, the AST Dump of that code is:


//Parameter("")

a = 2;

x = assert((a != 0)) (1 / a);

y = assert((a >= 0));

echo(a);

assert((a > 0));

echo(x);

echo(y);


what may explain a lot! There is no information about the AST dump in the manual. When you run a code the first line at the console is:

Parsing design (AST generation)...


I think the dump shows the order the computation was effectively done. This example suggests that the assignment order is preserved and the non assignment order is also preserved but the later group is processed after the former.

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

Re: inconsistent propagation of $fa

Ronaldo
For the code I comment before:

function f(a) =
  assert( is_list(a) )
  let( b = len(a) )
  b;

module t(a) {
  assert( is_list(a) );
  b = len(a);
  echo(b);
}

the AST Dump is:

function f(a) = assert(is_list(a)) let(b = len(a)) b;

module t(a) {

b = len(a);

assert(is_list(a));

echo(b);

}


confirming the execution order that has been observed.


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

Re: inconsistent propagation of $fa

nophead
In reply to this post by Ronaldo
Yes it definitely does the expressions first and assigns all the variables before it instantiates modules but I am surprised that it does that by reordering the syntax tree.

The order has to be preserved because otherwise the semantics are changed. It does do the weird thing when you assign something twice where it moves the last expression assigned to the first assignment statement, where it might not make sense.

On Mon, 29 Jun 2020 at 22:33, Ronaldo Persiano <[hidden email]> wrote:
assert() is syntactically a mystery. Sometimes it may seem to be an expression but it is not:

a = 2;
echo(a);
assert(a>0);
x = assert(a!=0) 1/a;
echo(x);
y = assert(a>=0);
echo(y);

BTW, the AST Dump of that code is:


//Parameter("")

a = 2;

x = assert((a != 0)) (1 / a);

y = assert((a >= 0));

echo(a);

assert((a > 0));

echo(x);

echo(y);


what may explain a lot! There is no information about the AST dump in the manual. When you run a code the first line at the console is:

Parsing design (AST generation)...


I think the dump shows the order the computation was effectively done. This example suggests that the assignment order is preserved and the non assignment order is also preserved but the later group is processed after the former.
_______________________________________________
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: inconsistent propagation of $fa

Ronaldo
nophead wrote
> Yes it definitely does the expressions first and assigns all the variables
> before it instantiates modules but I am surprised that it does that by
> reordering the syntax tree.
>
> The order has to be preserved because otherwise the semantics are changed.
> It does do the weird thing when you assign something twice where it moves
> the last expression assigned to the first assignment statement, where it
> might not make sense.

Here is another consequence of the order of evaluation. I would expect a
warning for this code:

if(x>0) echo("A");
else echo("B");
x = -1;

But, as the variable x is evaluated /before /the 'if' ('if' is a module !).
no error or warning is reported and "B" is echoed.

The AST Dump makes it clear:

x = -1;
if((x > 0)) echo("A");
else echo("B");






--
Sent from: http://forum.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: inconsistent propagation of $fa

MichaelAtOz
Administrator
Ronaldo wrote
> Here is another consequence of the order of evaluation. I would expect a
> warning for this code:

Why?

That is entirely consistent.


Ronaldo wrote
> But, as the variable x is evaluated /before /the 'if' ('if' is a module
> !).

There is no 'before' with OpenSCAD, there is just 'is'.




-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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.
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent propagation of $fa

Ronaldo
Ronaldo wrote
> But, as the variable x is evaluated /before /the 'if' ('if' is a module
> !).
There is no 'before' with OpenSCAD, there is just 'is'.

There is before! I get a warning bellow at line 3 because x is not defined :

if(x>0) echo("A");
else echo("B");
y = x;
x = -1;

> Here is another consequence of the order of evaluation. I would expect a
> warning for this code:

Why?

That is entirely consistent.

I understand it now. I am not complaining, I am adjusting my mind. ;)

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

Re: inconsistent propagation of $fa

MichaelAtOz
Administrator
Ronaldo wrote
> There is before! I get a warning bellow at line 3 because x is not defined
> :
>
> if(x>0) echo("A");
> else echo("B");
> y = x;
> x = -1;

That is just a broken 'is'. Nothing changes, one way it is broken, the other
way it is not, either way it 'is' doing what you told it to.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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.
12