On Friday, 24 January 2014 at 23:26:04 UTC, Brad Roberts wrote:
On 1/24/14 6:08 AM, Dominikus Dittes Scherkl wrote:
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
The only reason that NaN works in the FP world is that it's
done in hardware as part of existing operations.
Walter wrote:
"There's no NaN for integrals."
At least the carry-bit is already available in hardware. So the
save type doesn't incure much performance loss in operations. On
the other hand comparison, assignment and casts become slower by
a factor 2 or 3. And then comparison cannot be implemented fully
correct with the current operator overloding system of D.
It's, pretty much by definition, too expensive for a
set of people and the apps they care about.
Yeah, but I think it's a small share and they could use the
unsafe types - like they use manual memory management insted of
GC.
The only practical way is to introduce a new type that behaves
like this and use that instead.
Thats what I did. I will share my code soon.
