[OT] Sharp Regrets: Top 10 Worst C# Features
H. S. Teoh via Digitalmars-d
digitalmars-d at puremagic.com
Thu Aug 20 10:25:17 PDT 2015
On Thu, Aug 20, 2015 at 04:56:15PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, 20 August 2015 at 16:44:44 UTC, H. S. Teoh wrote:
> >On Thu, Aug 20, 2015 at 04:22:20PM +0000, Jonathan M Davis via
> >Digitalmars-d wrote: [...]
> >>I really don't mind NaN. It really doesn't cause problems normally.
> >>The problem with floating point values is floating point values
> >>themselves. They're so painfully inexact. Even without NaN, you
> >>can't use == with them and expect it to work. Compared to that, how
> >>NaN is dealt with is a total non-issue. Floating points themselves
> >>just plain suck. They're sometimes necessary, but they suck.
> >But how would you work around the inherent inexactness? In spite of
> >all its warts, IEEE floating point is at least a usable compromise
> >between not having any representation for reals at all, and having
> >exact reals that are impractically slow in real-world applications.
> I don't know that there _is_ a good solution, and IEEE floating point
> may realistically be as good as it gets given the various pros and
> cons, but they're still annoying and IMHO really shouldn't be used
> unless you actually need them.
Well, as with any computer representation of a numerical type, one ought
to understand what exactly the representation is capable of, and not
expect more than that. :-) It sounds obvious, but how many programs,
for example, check for integer overflow when performing complex integer
arithmetic? It just so happens that most applications only work with
relatively small magnitudes, so integer overflows are unlikely, but they
do still happen (sometimes opening up security holes), just as using
floating-point numbers without understanding their limitations will
sometimes yield surprising results. It's just that with integers, the
problematic areas are generally rarely encountered, whereas with
floating point you bump into them quite often (e.g., 1/3 + 1/3 + 1/3 may
not exactly equal 1). (Though with *unsigned* integers, you do often see
buggy code when values near 0 are used, or when subtraction is
At the root of it is the fallacious assumption that int == mathematical
integer or float == mathematical real. It may appear to work at first,
but eventually it will cause something to go wrong somewhere.
Food and laptops don't mix.
More information about the Digitalmars-d