Huh.  Even shorter:

function is_nan(x) = x!=x;

That is somehow both elegant in its simplicity and horribly twisted in its logic.

• Revar

On 07.02.20 11:02, Revar Desmera wrote:

Also nobody will claim any responsibility if it breaks at
some point.

If it makes sense to have that check, it would probably be
better to actually implemented it in the core like the other
test functions.

The missing tokens are indeed a problem as that is one case
where we can export files as CSG that can't be imported back.

nan = 0/0;
inf = 1/0;
ninf = -1/0;
echo(inf, ninf, nan);

Just to highlight the point it's not an OpenSCAD invention:

$ python3
Python 3.7.6 (default, Jan 19 2020, 22:34:52)
[GCC 9.2.1 20200117] on linux
Type "help", "copyright", "credits" or "license" for more information.

False

True

ciao,
Torsten.

Nan is pretty much defined to not be equal to itself, part of the floating
point spec

On Fri, 7 Feb 2020, 15:01 Torsten Paul, Torsten.Paul@gmx.de wrote:

The IEEE floating point standard provides programming languages with two different options
when evaluating 0/0: either it raises an exception, or it returns the NaN value.

Once you have a NaN value x, then x!=x must return true, according to IEEE.

In Python, 0.0/0.0 raises an exception, it doesn't return NaN.
In OpenSCAD, 0/0 returns NaN instead of raising an exception.
Both languages are compatible with the IEEE standard in this circumstance.

If you prefer your programming language to report an error when you have performed
an illegal operation, rather than silently returning Nan or undef, then you probably
want the Python semantics of 0/0 raising an exception.

In my own 3D modelling language (Curv), arithmetic operations always report an error
rather than return NaN. Since there's no way to generate a NaN, I don't need an is_nan()
function, and it is guaranteed that x==x is always true and x!=x is always false.
The only time I've actually seen this error reported was due to a bug in my program, that
would otherwise have resulted in exporting an invalid STL file if the bug hadn't been fixed.

My opinion is that disabling floating point exceptions and returning NaN for invalid arithmetic
operations is something that should only be attempted by numerical analysts who know what
they are doing. The semantics of NaN are too confusing, and propagating NaN values through
an OpenSCAD program will probably result in bad geometry. I don't think that 0/0 should
return NaN by default in a programming language that isn't targeted at high performance
numerical analysis. Python gets this right.

Doug Moen.

On Fri, Feb 7, 2020, at 8:00 PM, Torsten Paul wrote:

Yeah, I'd like to see a proper is_nan(x) builtin.  And an is_range(x) as well.

IEEE754 is correct to specify that nan!=nan, as that is what you want when comparing results from two calculations.
Most languages, however, also provide ways to test for nan.

$ python3

True

True

Even C/C++ has isnan(x).

I'm fine with nan!=nan, so long as there exists a clean way to test for it.  We need is_nan().

• Revar

Here's an is_range function I came up with a while ago:
is_range = function (x) !is_list(x) && !is_string(x) && !is_undef(x[0]);

It works because you can access start,step,end as the first 3 "elements",
but its not a list.

On Fri, Feb 7, 2020 at 6:55 PM Revar Desmera revarbat@gmail.com wrote: