NaNs could really be useful

If we don't know about 'em, we can't fix 'em.

NaNs could really be useful

PostPosted by drab » Wed Jan 11, 2017 6:25 pm

Non-numbers (NaN's) could actually be extremely useful in some situations.
For example, many applications need to use distinct "missing values".

We can easily create them. Actually, we can create many distinct ones.

x←1 ⎕dr '7FF0000000000001'
y←1 ⎕dr '7FF0000000000002'

But they way they currently behave makes them essentially useless.

1=x
0

So far, so good.

But not this:

x=x
0

That's just wrong, and too bad.

Yes -- all arithmetic on any NaN should be a NaN -- EXCEPT equality.
x=x should ALWAYS be 1, EVEN if x is a NaN.

On the other hand, the result of x=y is somewhat debatable.
It should probably be 0, but it could possibly be defined by a mechanism similar to ⎕ic.

And another thing ...

Why can't they display differently and more sensibly?

x
N.aNE9998
y
N.aNE9998

Please, let's at least make x=x work right!
drab
 
Posts: 283
Joined: Thu Oct 09, 2014 6:23 am

Re: NaNs could really be useful

PostPosted by forummaster » Thu Jan 12, 2017 7:46 pm

NaNs are very interesting objects. At this point, NARS2000 doesn't support them principally because it doesn't have a way to return an "unordered" result as opposed to 0 or 1 when comparing two such objects.

Support for NaNs would involve an analysis of every primitive function/operator that handles numbers to decide what to do with an object that is Not A Number (and Not A Character) as well as extensions to ⎕IC, etc. If you think there is a case for supporting NaNs, then write a paper with all the details, being sure to discuss Quiet vs. Signalling NaNs along with the many representations of a NaN, as well as rebutting the arguments by the IEEE-754 standard committee members who support the unordered result and at the same time making a case for supporting NaNs.

Note that as a consequence of a quirk due to a coding change in the Alpha version, NaN = NaN is true on the Alpha version, which is just another indicator that NaNs are not supported.

Please understand, I'm not against supporting NaNs, it's just that I didn't want to put in the work needed for the above analysis.
forummaster
 
Posts: 534
Joined: Wed Jan 23, 2013 1:00 pm

Re: NaNs could really be useful

PostPosted by drab » Fri Jan 13, 2017 6:54 am

This is how I would want to use NaN's ...

I would called them pseudo-numbers.

I would first define 3 distinct ones:

anything←1 ⎕dr '7FF8000000000010'
nothing ←1 ⎕dr '7FF8000000000100'
missing ←1 ⎕dr '7FF8000000001000'

They are not equal to each other, or to any other numeric value.
They are only equal to themselves.

The result of any monadic numeric function on any pseudo-number is that same pseudo-number.

The result of any dyadic numeric function (except equality) on any pseudo-number and any regular number is that same pseudo-number.

The result of any dyadic numeric function (except equality) on any two pseudo-numbers is the pseudo-number with the largest binary code.

The definitions of the 3 basic pseudo-numbers are spaced apart, so there is room to define additional ones in between them, if that is necessary for some specialized application.

These 3 basic pseudo-numbers are all quiet (non-signalling).
There could possibly be 3 more for use of signalling to force errors.
But that kind of thing could probably be more flexibly managed by a mechanism similar to ⎕ic.
drab
 
Posts: 283
Joined: Thu Oct 09, 2014 6:23 am

Re: NaNs could really be useful

PostPosted by forummaster » Wed Feb 01, 2017 7:13 pm

While this topic remains a future possibility, the latest beta release now displays NaNs in a slightly more pleasing way.

At the moment a Nan displays as with or without a high minus sign (which is ignored when computing or comparing with a NaN) followed by either QNaN (for a Quiet NaN) or SNaN (for a Signalling NaN) (e.g. ¯QNaN).

Note that Signalling NaNs don 't survive for long. For example, if you )SAVE and )LOAD a workspace with NaNs in variables, they are all converted to Quiet NaNs. This raises the question of do we really need to display the difference? Also, do we really need to display the sign bit? Can we get by with just NaN instead of all four possibilities, not to mention the 2*51 possible mantissas?

Note that regardless of how we choose to display a NaN, the hexadecimal value of a NaN including its sign bit, exponent, and all the hex digits in the mantissa (but not the Quiet NaN Bit) are preserved over a )SAVE and )LOAD.

If this value ever is used for anything in the language, we might look for a symbol for a NaN, rather than the above text. Unicode might have something.

http://www.nars2000.org/download/binaries/beta/
forummaster
 
Posts: 534
Joined: Wed Jan 23, 2013 1:00 pm

Re: NaNs could really be useful

PostPosted by drab » Thu Feb 02, 2017 1:17 pm

There are many good choices for better display of a NaN. I think one of the best is
⎕av[⎕io+216]
Ø

Just following a few very simple basic rules would would make them extremely useful right now.
[1] All arithmetic functions on any NaN produce a Nan EXCEPT equality
[2] NaN = NaN
[3] NaN ≠ nonNaN

Later, a good next step would be for different NaN's to be not equal to each other.
And different NaNs could display slightly differently.

Eventually, a full analysis of all arithmetic functions might possibly reveal some reasonable exceptions to the rules.
But they probably won't be very important.
drab
 
Posts: 283
Joined: Thu Oct 09, 2014 6:23 am

Re: NaNs could really be useful

PostPosted by drab » Sat Apr 01, 2017 8:03 am

OK. After a lot of work and refinement ...

NANs REALLY ARE USEFUL.

This is great. Thanks.
drab
 
Posts: 283
Joined: Thu Oct 09, 2014 6:23 am

Re: NaNs could really be useful

PostPosted by drab » Sat Apr 01, 2017 8:50 am

But there is one more enhancement which could make them much better still.
And it's fairly simple, but extremely powerful.

We now have one generic NaN named ∅, which is consistently handled everywhere.

But there are many applications that could make good use of multiple distinct NaN's.

The hardware actually supports a huge number of NaNs, with 53 unused bits.
Those bits could be used to code arbitrary names of distinct NaNs.

The new NaNs could be entered and displayed using the syntax ∅.name, where name may have up to 8 of any of the usual characters allowed in a name.

Here are 2 examples:
∅.missing
∅.other

The special value ∅. with no name is the same as the generic ∅ we already have.

There are only 2 simple new rules:
[1] NaNs with different names are NOT equal
[2] any arithmetic on any NaN with any name always produces the same generic NaN without a name


Here are 2 simple utility functions to convert between a name and its corresponding 12 digit hex code:

c←h2c h;⎕io a n x nc
⎕io←0
n←↑⍴a←'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_¯∆⍙'
x←16⊥a⍳h
c←''
→(x=0)/0
nc←⌈n⍟x
c←a[(nc⍴n)⊤x]

h←c2h c;⎕io a n
⎕io←0
n←↑⍴a←'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_¯∆⍙'
h←a[(12⍴16)⊤n⊥a⍳c]


And this one will actually create a named NaN:

z←nan name
z←1 ⎕dr '7ff8',c2h name


An example to encode a name

⎕← h2c ⎕← c2h 'missing'
01acc0107ea6
missing


An example simulating the named NaN ∅.missing

∅ = nan 'missing'
1
should be 0
drab
 
Posts: 283
Joined: Thu Oct 09, 2014 6:23 am


Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 4 guests

cron