Confused about comparisons of vectors
According to the manual, a comparison of vectors is true if it is true
pointwise. But I am having trouble finding a situation where a comparison
of inequalities is true.
echo([1,2] < [1,2]); // false
echo([1,2] == [1,2]); // true
echo([1,2] < [10,10]); // false but I expected true
Can somebody clarify this for me?
--
Sent from: http://forum.openscad.org/
Looks like vectors are only equality comparable and not less than
comparable. I think it ends up using boost variant, so I don't know how
easy it is to fix.
On Mon, 8 Apr 2019 at 22:27, adrianv avm4@cornell.edu wrote:
According to the manual, a comparison of vectors is true if it is true
pointwise. But I am having trouble finding a situation where a comparison
of inequalities is true.
echo([1,2] < [1,2]); // false
echo([1,2] == [1,2]); // true
echo([1,2] < [10,10]); // false but I expected true
Can somebody clarify this for me?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
adrianv wrote
According to the manual, a comparison of vectors is true if it is true
pointwise.
That manual edit
https://en.wikibooks.org/w/index.php?title=OpenSCAD_User_Manual/Mathematical_Operators&oldid=3014605
was done in Nov 2015, by 'C.t.chin' (not a name I recall - sorry).
I checked the comparison behaviour in 2015.03 & 2013.06 both are the same
[echo([1,2] < [10,10]); // false]. So it is not a recent regression.
So I'm calling the wiki wrong.
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.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
Ok, so the correct definition of the behavior is that inequality tests
between lists always return false?
--
Sent from: http://forum.openscad.org/
echo([1,2] < [1,2]); // false
echo([1,2] == [1,2]); // true
echo([1,2] < [10,10]); // false but I expected true
I'm not clear what a greater/less comparison would mean, but one of the
key aspects of a "normal" comparison is that one value is either less,
equal, or greater than another.
It seems that's not the case for vectors. If you have two vectors a
and b that are not equal, a is neither less than b nor greater than b:
a=[1,1];
b=[2,2];
echo(lt = a < b);
echo(eq = a == b);
echo(gt = a > b);
results in
ECHO: lt = false
ECHO: eq = false
ECHO: gt = false
... so whatever it's doing, it's not a conventional comparison.
In fact, "less or equal" and "greater or equal" don't seem to include
"equal":
a=[1,1];
b=[1,1];
echo(lt = a < b);
echo(lt = a < b);
echo(le = a <= b);
echo(eq = a == b);
echo(ge = a >= b);
echo(gt = a > b);
yields:
ECHO: lt = false
ECHO: le = false <<<
ECHO: eq = true <<<
ECHO: ge = false <<<
ECHO: gt = false
Results are the same even for single-entry vectors.
On 09.04.19 01:22, adrianv wrote:
Ok, so the correct definition of the behavior is that inequality
tests between lists always return false?
I don't know if that's correct, but looking at the code, that is
how it's implemented.
How would a matrix of all possible combinations (of types) look
like?
ciao,
Torsten.
tp3 wrote
On 09.04.19 01:22, adrianv wrote:
Ok, so the correct definition of the behavior is that inequality
tests between lists always return false?
I don't know if that's correct, but looking at the code, that is
how it's implemented.
How would a matrix of all possible combinations (of types) look
like?
I'm not asking for any kind of change---just trying to understand the
behavior.
If I were going to propose a change I would say that it would be better to
simply return an error or undef instead of always returning false.
Are you asking what does the matrix of types for inequalities look like,
such as if you compare a boolean to a number or a number to a list or a
range? I personally would say that incompatible combinations should be an
error or undef (so any mixed combination of string, number and boolean).
In fact, I discovered that "false<3" evaluates to true, which is sort of
strange. And apparently "true>false" is true. It looks like false=0 for
purposes of inequality comparisons---but not equality. And true=1. I
would say it's better that these tests give an error, or undef. Testing a
string against a number seems to give false in all cases---again I would
suggest than an error or undef would be better.
The question of hows lists are handled is sort of different since lists can
contain all the other types. I would suggest that there are two choices
that make sense for "list > list" where the lists have the same length.
Either the result is a new list of individual comparisons (like in MATLAB)
or the result is (as erroneously documented in the wiki), true if the
elementwise comparisons are all true. When the lists have incompatible
lengths it seems debatable, but I'd suggest that undef makes the most sense.
--
Sent from: http://forum.openscad.org/
adrianv avm4@cornell.edu wrote:
If I were going to propose a change I would say that it would be better to
simply return an error or undef instead of always returning false.
By design, OpenSCAD usually returns undef for ilegal expressions instead of
generating an error. That keeps the code running until some error arises.
It is not a bad design rule if it is taken in account and I often rely on
that behaviour. Take a look for instance in the topic "Caring about undef"
in:
https://en.m.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks
On 4/9/2019 4:54 AM, Ronaldo Persiano wrote:
By design, OpenSCAD usually returns undef for ilegal expressions
instead of generating an error. That keeps the code running until some
error arises.
It's probably not worth changing, but my feeling is that best is to get
an error as early as possible. As the tip you cite says, undef values
may cause unpredictable behavior. (More precisely, unintended
behavior.) The longer you let an error propagate, the harder it is to
debug.
Undef is certainly valuable... to represent undefined values, not as an
error-handling mechanism.
The only rationale I can think of for having ("foo"==5) return undef is
that it allows you to examine the data type of a value... but if that's
considered necessary, better would be to have an explicit way to do it.
It is not a bad design rule if it is taken in account and I often rely
on that behaviour.
What's your use case?