symmetric signed types

Brad Roberts braddr at puremagic.com
Fri Jan 24 15:25:42 PST 2014


On 1/24/14 6:08 AM, Dominikus Dittes Scherkl wrote:
> On Friday, 24 January 2014 at 13:30:06 UTC, Meta wrote:
>> On the Rust mailing list, there's recently been discussion about auto-promotion to BigInt in case
>> of overflow. Maybe that's a discussion we should be having as well?
>
> Nice idea. But is any overflow known at compile-time?
> Also really unexpected auto-type...
>
> I had something very simple in mind:
> 1) get rid of the asymmetric T.min value
>     that always causes problems with abs()
> 2) instead use this special value as NaN
> 3) let NaN be the init-value of the signed types
> 4) let every over-/underflow result in NaN
> 5) let every operation involving NaN result in NaN
> 5) let any cast from other types to the save
>     signed types check range and set NaN if the
>     value doesn't fit
> None of that should be too expensive, but with such a type you can simply execute the program and if
> it result in NaN you know there had been some overflow (or uninitialized variable). That makes
> analyzing easy, it allows for simple contracts, is easy to catch and allows easy to decide what
> solution would be the best (e.g. using next bigger type or limit the values).
>
> And if performance is critical (which should be true only in some inner loop where one can be sure
> that no overflow is possible) as next step the now fool-prove program can be changed to use unsave
> types (because they use the same range + one extra value that hopefully never occures anyway).

The only reason that NaN works in the FP world is that it's done in hardware as part of existing 
operations.  For it to work in the integer world it'd require adding operations to do the extra 
checking and handling with the resulting performance costs of doing so.  It's, pretty much by 
definition, too expensive for a set of people and the apps they care about.  The only practical way 
is to introduce a new type that behaves like this and use that instead.  If, over the course of 
years, becomes popular enough, it's not impossible that some cpu makers could decide to enshrine it 
in new instructions.  But I wouldn't hold your breath. :)

None of this is new.  It comes up periodically and ends up in the typical place of many feature 
requests, unimplemented.  Create the type, share it, see who uses it and how much they gain from the 
benefits and if they're worth the costs.  Conjecture will only get you so far.

My 2 cents,
Brad



More information about the Digitalmars-d mailing list