Thread overview | ||||||
---|---|---|---|---|---|---|
|
February 05, 2004 Floats and NANs | ||||
---|---|---|---|---|
| ||||
There are very few languages that take seriously the concept of NAN, or infinity, for that matter. If a language purports to be seriously mathematically oriented, (as I believe D does (with success, I might add!), then these are the two things that such a language has to support -- implicitly. (I have to admit that smarter than I people have had considerable time to figure out some issues about this. One example is why Math Coprocessor folks have decided that zero in float is represented as 000... .) That issue was (as recently discussed here) about whether an uninitialized variable should be zero or something unrepresentable. For ints we are at a loss, since anything you can represent with the number of bits that a quantity (a signed or unsigned integral type of the relevant size) is a valid value. So, deciding that 0xdeadbeef or 0x000 or 0b1111111111111111 or whatever, represents the Not Initialised Value, is just hiding your head in the sand. I once had an argument with my then university professor (and the argument was in front of 200 students -- luckily I won the argument, but that does not prove I was right :-) about whether the Non-Valid pointer value should be null (that is zero), or wheteher it should just be any value that is not possible in actual surroundings. I argued for the "Null" value being whatever is deemed impossible, and the professor that it is exactly zero. "Zero will typically, but not necessarily, be represented by the bit pattern _all zeros_, of the approriate size." (1) "We write NULL instead of zero, however, to indicate more clearly that this is a special value for a pointer. In general, integers cannot meaningfully be assinged to pointers; zero is a special case." (2) "Nothing seems to create more heat than a discussion of the proper way to express a pointer that doesn't point to an object, the the null pointer." ... "The ARM further warns: 'Note that the null pointer need not be represented by the same bit pattern as the integer 0.' " (3) 1: The C++ Programming Language, Stroustrup, p88. 2: The C programming Language, Kernighan & Ritchie, pp97-98. 3: The Design and Evolution of C++, Stroustrup, $11.2.3 So, what's the point of all this pomposity???? It has to do with whether we want to initialize all variables, or not. And if we do, then what should we initialize them to? Math people decided for long ago, that the bit pattern 0000... represents the zero value of a float. This was because some languages guaranteed that no variable would have an initial value based on the arbitrary bit pattern of the location of memory it happened to point at. The easiest way (and fastest) was to run over the bits in the area with all zeros. This would lead all bits to be initialized to zero, all floats to be zero too, and all pointers to be initialized to NULL. (If defined as such in that particular language.) Now, D is a language that is exceptionally aware of Serious Math. This means we have Imaginary numbers, complex numbers, and a natural extension of that would be to return serious values for what cheap calculators would return as "domain error". |
February 05, 2004 Re: Floats and NANs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Georg Wrede | "Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bvsa3h$g9a$1@digitaldaemon.com... > There are very few languages that take seriously the concept of NAN, or infinity, for that matter. > > If a language purports to be seriously mathematically oriented, (as I believe D does (with success, I might add!), then these are the two things that such a language has to support -- implicitly. > > (I have to admit that smarter than I people have had > considerable time to figure out some issues about this. > One example is why Math Coprocessor folks have decided > that zero in float is represented as 000... .) > > That issue was (as recently discussed here) about whether > an uninitialized variable should be zero or something > unrepresentable. For ints we are at a loss, since anything > you can represent with the number of bits that a quantity > (a signed or unsigned integral type of the relevant size) > is a valid value. So, deciding that 0xdeadbeef or 0x000 > or 0b1111111111111111 or whatever, represents the Not > Initialised Value, is just hiding your head in the sand. > > I once had an argument with my then university professor > (and the argument was in front of 200 students -- luckily > I won the argument, but that does not prove I was right :-) > about whether the Non-Valid pointer value should be null > (that is zero), or wheteher it should just be any value > that is not possible in actual surroundings. I argued for > the "Null" value being whatever is deemed impossible, and > the professor that it is exactly zero. > > "Zero will typically, but not necessarily, be represented by the bit pattern _all zeros_, of the approriate size." (1) > > "We write NULL instead of zero, however, to indicate more > clearly that this is a special value for a pointer. In > general, integers cannot meaningfully be assinged to > pointers; zero is a special case." > (2) > > "Nothing seems to create more heat than a discussion of > the proper way to express a pointer that doesn't point > to an object, the the null pointer." ... "The ARM > further warns: 'Note that the null pointer need not be > represented by the same bit pattern as the integer 0.' " > (3) > > > 1: The C++ Programming Language, Stroustrup, p88. > 2: The C programming Language, Kernighan & Ritchie, pp97-98. > 3: The Design and Evolution of C++, Stroustrup, $11.2.3 > > So, what's the point of all this pomposity???? > > It has to do with whether we want to initialize all variables, or not. And if we do, then what should we initialize them to? > > Math people decided for long ago, that the bit pattern 0000... > represents the zero value of a float. This was because some > languages guaranteed that no variable would have an initial > value based on the arbitrary bit pattern of the location of > memory it happened to point at. The easiest way (and fastest) > was to run over the bits in the area with all zeros. This would > lead all bits to be initialized to zero, all floats to be > zero too, and all pointers to be initialized to NULL. (If > defined as such in that particular language.) > > Now, D is a language that is exceptionally aware of Serious Math. This means we have Imaginary numbers, complex numbers, and a natural extension of that would be to return serious values for what cheap calculators would return as "domain error". Did you forget to finish this post? If not, I don't get what you're saying. You need a conclusion for us thickies! |
February 05, 2004 Re: Floats and NANs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Georg Wrede | Georg Wrede wrote:
> [ lots of smart things ]
>
Honestly, I don't understand how it's such a big deal. What's important to me is merely that attributes have a default value. Whether that value be 0, NaN, or pi seems a minor detail in comparison.
-- andy
|
February 05, 2004 Re: Floats and NANs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | Andy Friesen wrote:
[...]
> Whether that value be 0, NaN, or pi seems a minor detail
[...]
I do not agree.
With 0.0 or pi one can uninitialize a variable.
But not with Nan, except the language provides support.
So long.
|
Copyright © 1999-2021 by the D Language Foundation