From: Tim P. <ti...@em...> - 2000-10-12 20:33:56
|
[Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages <wink>. Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas <wink>, asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great <wink>. all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). |