What happened to booleans?
However, with an implementation that follows rules 1 and 2 of my previous
post, you still can do such a generic type check by writing:
function is_same_type(op1, o2) = (op1==op2)!=(op1!=op2);
--
Sent from: http://forum.openscad.org/
Another issue of allowing "undef" as result of a logical operation:
What is the value of
(false == undef)?
It obviously can't be "true", otherwise you could not distinguish between
these two values, and if it is "false" you get the following contradiction.
The expression
(1 == "1") == false
would evaluate to
undef == false
and this evalulates to false (or undef?). However "true" is expected.
This is all a can of worms.
--
Sent from: http://forum.openscad.org/
If I may add something to the discussion, I would really like booleans to be
booleans. Also, I LIKE error messages if I am doing something that just does
not make sense. As someone once said, the language should talk to you
(meaning the language gives useful error messages rather than assume
nonsense and do unexpected things).
So if I would compare a boolean with greater or lesser operators, I expect
an error message. True is not more or less than false.
Microsoft languages like Visual Basic used to have a "feature" called "Null
progagation". This meant that if you used a Null value (which would also be
undef) anywhere in an expression, the outcome of that expression would also
be Null. This off course broke all boolean operations, because Null would be
treated as false.
Yes, ("Some value" != null) would thus be treated as false and even (! null)
would be treated the same as null, as false.
This made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.
--
Sent from: http://forum.openscad.org/
Parkinbot wrote
Another issue of allowing "undef" as result of a logical operation:
What is the value of
(false == undef)?
It obviously can't be "true", otherwise you could not distinguish between
these two values, and if it is "false" you get the following
contradiction.
The expression
(1 == "1") == false
would evaluate to
undef == false
and this evalulates to false (or undef?). However "true" is expected.
This is all a can of worms.
I am not sure what gave you the idea that equality or inequality testing
should result in undef under any circumstances. That would be very bad.
Equality testing is well-defined for any pair of objects, they are either
the same (in which case you return true) or they are different (in which
case you return false). Things with different types are clearly different.
Inequality tests are different. They are undefined (meaningless) when given
arguments of different type. Hence my proposal was simply that inequality
tests (<, >, <=, =>) result in undef when given mismatched types. I'd say
printing an error message would be even better.
--
Sent from: http://forum.openscad.org/
MathLover wrote
Microsoft languages like Visual Basic used to have a "feature" called
"Null
progagation". This meant that if you used a Null value (which would also
be
undef) anywhere in an expression, the outcome of that expression would
also
be Null. This off course broke all boolean operations, because Null would
be
treated as false.
Yes, ("Some value" != null) would thus be treated as false and even (!
null)
would be treated the same as null, as false.
This made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.
OpenSCAD already has this feature with undef. And yes indeed, it makes
debugging a nightmare.
Right now any invalid operation---except for a boolean comparison---returns
undef. And any operation containing an undef---except for equality and
inequality testing---produces an undef as a result.
Index out of bounds? You get undef instead of an error. It would be a
thousand times better if all of these things produced immediate error
messages.
So yes, it would make sense for boolean operations on mismatched types to
produce an error message. The reason I didn't suggest that as a possibility
is consistency: all the other bogus operations in OpenSCAD produce undef
instead of an error.
--
Sent from: http://forum.openscad.org/
Perhaps the solution is to have two types of boolean - a true boolean,
and a false boolean. The true boolean only has two members, true and
false, a false boolean can have as many members as you wish, but you
define them, and their relationship to each other. A true boolean can
only have too operators '==' and '!=', a false boolean can have whatever
operators you want. , but you'll need to define your own hierarchy.
Basically, in this scenario, a false boolean is everything else, which
may be further divided into strings, floating point numbers, colours,
whatever.
Historically, There has been a lot of misunderstanding about the true
nature of boolean, by folk who should have known better. Just because
digital computers work the way they do, they bypassed they forgot about
what the ones and zeros truly represented, and manipulated them in the
ways that ones and zeros would be manipulated as normal
bits/bytes/whatever. I blame their parents.
I guess the real concern is that openscad programs are interpreted, not
compiled, so older programs would not work properly in a newer
interpreter. Perhaps an interpreter version number could be included in
the data. (sort of like Microsoft .net asks for versions, but that is
hopefully backwards compatible). Whatever is decided, not everybody will
be happy, but at least we're trying.
Best wishes,
Ray
On 27/07/2020 12:41, MathLover wrote:
If I may add something to the discussion, I would really like booleans to be
booleans. Also, I LIKE error messages if I am doing something that just does
not make sense. As someone once said, the language should talk to you
(meaning the language gives useful error messages rather than assume
nonsense and do unexpected things).
So if I would compare a boolean with greater or lesser operators, I expect
an error message. True is not more or less than false.
Microsoft languages like Visual Basic used to have a "feature" called "Null
progagation". This meant that if you used a Null value (which would also be
undef) anywhere in an expression, the outcome of that expression would also
be Null. This off course broke all boolean operations, because Null would be
treated as false.
Yes, ("Some value" != null) would thus be treated as false and even (! null)
would be treated the same as null, as false.
This made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
'undef' is a nightmare indeed. But it is not the only one: there are 'nan'
and 'inf' too which can turn into undef in the next operation. Should they
be eradicated? Certainly not, they have their place, at least 'undef' has.
To avoid nightmares, to have peace of mind, we need discipline. And
consistent emergence of these values in operations.
What should be the result of a polygon triangulation function if the
polygon has self-intersection? I would say that 'undef' (meaning "no
solution possible") is the best option. To generate an error or an empty
list (or some other signaling value) could be an alternative. The first
seems radical because it is so hard to find whether a polygon has
self-intersection as trying to triangulate it. The triangulation function
would be the check! The other options are falsely safe because a careless
coder may get in trouble later trying to access an element of an empty
list, for instance. There is no way to protect a careless code.That means
we need to always be careful with operations that might have "unusual"
results. That is a place for 'undef'.
Definitely an inequality expression involving pears and apples should
result in 'undef' (as we don't have a complete type order). That is
consistent with the result of trying to divide pears by a number or access
an array component of a single value (and that doesn't mean 'undef' is
another number value or another list) (*). But, yes, a test, either in an
if() or in a ternary expression, of 'undef' should be an error. If you
don't generate the error, the propagation will be uncontrollable. That is
the devil's place. 'undef' should not be taken as 'false'. Why not allow
the 'undef' value of an inequality be set to a variable? Or checked against
'undef' ? 'undef' is 'undef'.
(*) Dividing or multiplying a numerical vector by a scalar is a well
defined operation on linear algebra. There are good well defined
exceptions to the rule that 'pears' can't mix with 'apples'.
If testing undef was an error it would break a lot of my code.
I often use if(list[n]) to mean if the list has a non zero nth element. If
the list doesn't have that element I get undef, which is false. I would
have to guard the test with a check of the length, which is less efficient
and more verbose.
On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
'undef' is a nightmare indeed. But it is not the only one: there are 'nan'
and 'inf' too which can turn into undef in the next operation. Should they
be eradicated? Certainly not, they have their place, at least 'undef' has.
To avoid nightmares, to have peace of mind, we need discipline. And
consistent emergence of these values in operations.
What should be the result of a polygon triangulation function if the
polygon has self-intersection? I would say that 'undef' (meaning "no
solution possible") is the best option. To generate an error or an empty
list (or some other signaling value) could be an alternative. The first
seems radical because it is so hard to find whether a polygon has
self-intersection as trying to triangulate it. The triangulation function
would be the check! The other options are falsely safe because a careless
coder may get in trouble later trying to access an element of an empty
list, for instance. There is no way to protect a careless code.That means
we need to always be careful with operations that might have "unusual"
results. That is a place for 'undef'.
Definitely an inequality expression involving pears and apples should
result in 'undef' (as we don't have a complete type order). That is
consistent with the result of trying to divide pears by a number or access
an array component of a single value (and that doesn't mean 'undef' is
another number value or another list) (*). But, yes, a test, either in an
if() or in a ternary expression, of 'undef' should be an error. If you
don't generate the error, the propagation will be uncontrollable. That is
the devil's place. 'undef' should not be taken as 'false'. Why not allow
the 'undef' value of an inequality be set to a variable? Or checked against
'undef' ? 'undef' is 'undef'.
(*) Dividing or multiplying a numerical vector by a scalar is a well
defined operation on linear algebra. There are good well defined
exceptions to the rule that 'pears' can't mix with 'apples'.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I agree that undef is a useful concept and would be great if OpenSCAD
operated with it differently.
What should happen is that any operation involving an undef is an immediate
fatal error, producing an error message---with the exception of the two
tests x==undef and x!=undef. If OpenSCAD worked like this, then I would
feel comfortable using undef to report a variety of results where
"undefined" is actually the right answer, such as the previously mentioned
intersection point of parallel lines, or the example below of
self-intersecting polygons.
Instead undef is actually the generic signal that the programmer made a
mistake. In this case, I feel it is essential to avoid ever intentionally
producing undef because then you can't distinguish between an error and a
case of valid return. Suppose your triangulation code has a bug and
sometimes returns undef as a result of this bug. You can't distinguish that
situation from the case that the triangulation identified a
self-intersection. If errors produced an error message and program halt
then a mistake in your code is easily distinguished from the undef return,
which happens in the self-intersecting polygon case. But since errors
produce undef, it is critical that in any code, one tries to handle all the
errors and never produce undef intentionally as an output. In this way we
know that if we see undef, there's a programming bug. Otherwise, we can't
distinguish the case of a programming bug from a valid "undefined" return
value.
Ronaldo wrote
'undef' is a nightmare indeed. But it is not the only one: there are 'nan'
and 'inf' too which can turn into undef in the next operation. Should they
be eradicated? Certainly not, they have their place, at least 'undef' has.
To avoid nightmares, to have peace of mind, we need discipline. And
consistent emergence of these values in operations.
What should be the result of a polygon triangulation function if the
polygon has self-intersection? I would say that 'undef' (meaning "no
solution possible") is the best option. To generate an error or an empty
list (or some other signaling value) could be an alternative. The first
seems radical because it is so hard to find whether a polygon has
self-intersection as trying to triangulate it. The triangulation function
would be the check! The other options are falsely safe because a careless
coder may get in trouble later trying to access an element of an empty
list, for instance. There is no way to protect a careless code.That means
we need to always be careful with operations that might have "unusual"
results. That is a place for 'undef'.
Definitely an inequality expression involving pears and apples should
result in 'undef' (as we don't have a complete type order). That is
consistent with the result of trying to divide pears by a number or access
an array component of a single value (and that doesn't mean 'undef' is
another number value or another list) (*). But, yes, a test, either in an
if() or in a ternary expression, of 'undef' should be an error. If you
don't generate the error, the propagation will be uncontrollable. That is
the devil's place. 'undef' should not be taken as 'false'. Why not allow
the 'undef' value of an inequality be set to a variable? Or checked
against
'undef' ? 'undef' is 'undef'.
--
Sent from: http://forum.openscad.org/
The efficiency argument is weak in this case. I tested the run time for
len(foo) >=1001 ? foo[1000] : -1
compared to
foo[1000] ? foo[1000] : -1
where foo had length smaller than 1001.
I ran this 10 millions times. The run time for the length check was 1
microsecond. The undef test shaved this down to 0.7 microseconds.
I cannot conceive of a way that a different of 0.3 microseconds is important
in an OpenSCAD program.
The problem of your code being broken is the serious one. Personally if I
had a body of code written that way and the option to change OpenSCAD to
produce errors with undef I'd jump for errors in a heartbeat. The amount of
time it would take me to fix a megabyte of code would be less than the time
I've wasted already debugging undefs that propagate through my code. But
the backward compatibility problem is a definite problem. Perhaps a
setting could be introduced to optionally make undefs into fatal errors,
similar to the setting that makes warnings into fatal errors.
nophead wrote
If testing undef was an error it would break a lot of my code.
I often use if(list[n]) to mean if the list has a non zero nth element. If
the list doesn't have that element I get undef, which is false. I would
have to guard the test with a check of the length, which is less efficient
and more verbose.
On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano <
rcmpersiano@
>
wrote:
'undef' is a nightmare indeed. But it is not the only one: there are
'nan'
and 'inf' too which can turn into undef in the next operation. Should
they
be eradicated? Certainly not, they have their place, at least 'undef'
has.
To avoid nightmares, to have peace of mind, we need discipline. And
consistent emergence of these values in operations.
What should be the result of a polygon triangulation function if the
polygon has self-intersection? I would say that 'undef' (meaning "no
solution possible") is the best option. To generate an error or an empty
list (or some other signaling value) could be an alternative. The first
seems radical because it is so hard to find whether a polygon has
self-intersection as trying to triangulate it. The triangulation function
would be the check! The other options are falsely safe because a careless
coder may get in trouble later trying to access an element of an empty
list, for instance. There is no way to protect a careless code.That means
we need to always be careful with operations that might have "unusual"
results. That is a place for 'undef'.
Definitely an inequality expression involving pears and apples should
result in 'undef' (as we don't have a complete type order). That is
consistent with the result of trying to divide pears by a number or
access
an array component of a single value (and that doesn't mean 'undef' is
another number value or another list) (*). But, yes, a test, either in an
if() or in a ternary expression, of 'undef' should be an error. If you
don't generate the error, the propagation will be uncontrollable. That is
the devil's place. 'undef' should not be taken as 'false'. Why not allow
the 'undef' value of an inequality be set to a variable? Or checked
against
'undef' ? 'undef' is 'undef'.
(*) Dividing or multiplying a numerical vector by a scalar is a well
defined operation on linear algebra. There are good well defined
exceptions to the rule that 'pears' can't mix with 'apples'.
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/