Unums are unlikely to gain much usage. Posits[1][2], also by Gustafson, are a more reasonable alternative to IEEE-754 floating point (but will still have a difficult time displacing IEEE-754, if they can at all).
Posits seem impressive. My only concern is the lack of NaNs seems like a bug rather than a feature.
It's true that some programmers do the silliest things when faced with NaNs. But the fact is they are useful. You often want to do calculations over big matrices, where some elements simply don't have a mathematically defined answer (usually because of div0s but also because input data might have holes).
It would be a royal pain if the whole calculation stopped every time you had to add two infinities.
Isaac Yonemoto has suggested the use of ±∞ as a NaN, and it seems to work exactly like NaN does other than x/±∞ = 0 whereas you want x/NaN = NaN. I hate hardware exceptions. If you have a code that occasionally hits a NaN, that means the code is still under development. You would never release such a code into the wild, because it clearly is not safe to use and has not done the basic blocking and tackling of guarding against input arguments that will prevent any indeterminate forms, square roots of negative values, etc.
I haven't written them up yet, but _valids_ are what you want if you are want software that can gracefully and mathematically handle the results that make floats generate a NaN. Think of the valid computing environment as the numerical debugging environment for posits. It's slower and ultra-careful and rigorous, but once you get your algorithm to the point where it never tries to color outside the lines, then switch to posits and go FAST.
Leaving a NaN in a number system designed for lean speed is a mixing of computing esthetics. Which do you want? Rigorous and careful and mathematical, or good enough, fast, and cheap? You have to make up your mind, because if you _mix_ the two esthetics in one number system, guess what: You get neither. It won't be fast, because it has to check for exceptions all the time, and it won't be mathematical because it keeps replacing correct answers with answers within its vocabulary (that is, it rounds). IEEE floats are a mixture of the two esthetics, and that is their fatal flaw.
>is the lack of NaNs seems like a bug rather than a feature.
I think this is a reasonable concern. I'll propose to John that we make there be an optional "mode" where the infinity token is treated as "NaN". In reality, this mode just amounts to "ignore NaN traps", because the way that it's done in my hardware models, it requires almost no extra hardware.
if you really want both, then either 1) use IEEE floats or 2) write your own data type, or 3) used a boxed data type, which is really the best solution for the dominant "missing data" abuse case anyways.
Actually, posits handle NaNs already, by interrupting the calculation and doing whatever you have set up to handle the exception. What they do NOT do is represent Not-a-Number with a number. If a programmer is about to compute, say, x/y and in running the code it sometimes hits the case y = 0, then any competent programmer can write a conditional test to guard against that happening. It is not reasonable to ask computer hardware to magically continue to work somehow when it hits a bug in a program.
Think of it this way: posits have a signaling NaN but do not have a quiet NaN.
It's not a number if you are like me and say "a number is an element of a ring." (We're not talking about ordinals or cardinals, the subject being rationals, otherwise I might have a different definition.)
The projectively extended real line doesn't support adding infinity to itself, which is what the grandparent to your comment was talking about. The problem is that the projectively extended real line does not have both a positive and negative infinity.
Mainly, I was poking a bit of fun at the idea that "number" even has a rigorous definition. You can't really assert whether infinity is a number or not without 1) knowing what they mean by "number" or 2) knowing what they mean by "infinity." If you want "numbers" to be a field extension of the reals and you want it to contain an "infinity," then the hyperreal numbers might be appropriate [1]. If you are instead content with having an infinitesimal and having only a ring extension, then the dual numbers might be appropriate [2].
But, anyway, if you can claim infinity is a number because someone thought of the real projective line, I can say polynomials are numbers. Square matrices, too --- I think of square matrices as being big numbers; rank measures how invertible a big number is.
A stranger consequence of my definition is that a continuous real-valued function on a space X is a "number." If X is a single point, then such a function is the same as a real number. If X is a discrete set of n points, then the set of functions is R^n. If X is compact (I think that's sufficient?) then the maximal ideals in the set of continuous functions is in correspondence with X itself. This suggests that for any ring, one may imagine there to be a space that it is the functions of, whose points are the maximal ideals of that ring. For the ring of complex one-variable polynomials, the points correspond to C itself (the maximal ideals are generated by (x-c) for varying constants c). So, yeah, polynomials are numbers now.
If you can consider a “complex number” or a “transcendental number” to be a “number”, then there’s really no reason to not also consider ∞ to be a number.
In general, the boundary of the category of ideas (if you like, elements of some formal model) that can be called “numbers” is a very fuzzy and arbitrary one.
Some people might reject as “numbers” anything other than the counting numbers 1, 2, 3, 4. Others might allow “negative numbers” or ratios. Still others are happy to include quaternions or infinite strings of digits output by some computer program. Meh.
[1] http://web.stanford.edu/class/ee380/Abstracts/170201-slides.... [2] https://www.youtube.com/watch?v=aP0Y1uAA-2Y