4 ms·

Fwiw I can't tell if you're being pedantic for fun or not. I'm going to stick with fun... > Floats can store integer values exactly up to an upper limit (2^24

by raiph 11y ago

Fwiw I can't tell if you're being pedantic for fun or not. I'm going to stick with fun... > Floats can store integer values exactly up to an upper limit (2^24 IIRC) You're right, for relatively small integers of 8 digits or so. Here's a fun place to note that on the machine I just tried the Rakudo Perl 6 compiler will happily exactly store integers with hundreds of thousands of digits. > which is often useful. As in you've written such code in dozens of programs? > And [floats] can store binary fractions exactly up to a point. 0.1 is already "past" that point which is even less impressive than 8 digit integers. > No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly. Well duh. No computer can compute all computable things. Each can compute some things. My machine became unhappy when I asked it to store a number that would require a terabyte of RAM. Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3?

jjnoakes 11y ago
Floating point hardware storing integers is useful indeed. Look up JavaScript. A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point. 0.1 isn't past any "point" (whatever that means). It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10. Your post could do without 'duh' and the like as well.
- raiph 11y ago
  > A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point. I thought being able to store an up to 8 digit integer in a float was an interesting tidbit. I already knew it but others might not. However, it was also completely irrelevant to a discussion of why 0.1 + 0.2 equals 0.3 in Perl 6 and, imo, even to my (slight over) emphasis that a float is for (efficient) storage and processing of approximations, not exact numbers. > 0.1 isn't past any "point" (whatever that means). Precisely. I was directly responding to "And [floats] can store binary fractions exactly up to a point." What does that mean? "up to a point" is highly ambiguous. The fact that 0.1 isn't stored exactly is completely unambiguous. > It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10. So what? It is representable without recurrence in a pair of base 2 numbers, eg 1 (numerator) and 11 (denominator) for 1/3. > Your post could do without 'duh' OK. I considered that and thought it was OK, all things considered, given that it wasn't prominent and succinctly expressed my reaction. But I hear you that even such a gentle 'duh' is problematic and will be even more careful about how I express myself at HN in future. > and the like as well. Would you be willing to be specific? While I recognize the 'duh' is edgy, I've reread the rest of what I wrote and don't understand what you think I got wrong.
haberman 11y ago
> You're right, for relatively small integers of 8 digits or so. For doubles (more common than floats) it is up to 2^53, which is quite a usable range. > As in you've written such code in dozens of programs? As in every JavaScript program ever written that uses a for loop and integer indices does this. > 0.1 is already "past" that point which is even less impressive than 8 digit integers. 0.1 is not a binary fraction. A binary fraction can be expressed in the form a/2^b for some a and b. Decimal representations have the same limitation (can only express decimal fractions), it just seems more exact because we write numbers in decimal. > Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3? It's worth mentioning when you say untrue things like "Floats are, by definition, not relevant if one wants to store an exact number exactly." Double precision floating point has more exact integer range than int32.
- kbenson 11y ago
  I think you guys are arguing at cross-purposes. I'm not sure anyone is arguing that an integer is better than a double for integer representation, but that storing a pair of numeric values (whether they be integers or floating point of some type) allows for more natural expression of numeric values in a high level language, with more fidelity. > > Floats are, by definition, not relevant if one wants to store an exact number exactly. > Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point. If you have some knowledge about the number you are storing, such as that it is an integer, then you can use the fact that floats can represent integers exactly to large values. If you need a general purpose numeric type of which you can't assume it's an integer, and it needs to be stored exactly, then I think it's valid to say that floating point numbers are not relevant, at least not as the entirely of the underlying storage container. > No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly. Yes. So we are talking about storage mechanisms that allow for more fidelity than plain floats and doubles can achieve.
- raiph 11y ago
  If you search back to the comment that started this subthread you'll find it began: "Try 0.1 + 0.2 == 0.3 in some other language, then try it in Perl 6." Do you agree with all of the next sentence or not? Please start with a plain yes or no before getting in to details. The three individual literal decimal numbers shown above are not integers, they're not binary fractions, they're not floats, they are rational numbers, they are exact numbers, they are easily stored exactly on a computer, and whether or not they are stored exactly on a computer is a choice made by a programming language.

by raiph 11y ago

jjnoakes 11y ago

Floating point hardware storing integers is useful indeed. Look up JavaScript. A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point. 0.1 isn't past any "point" (whatever that means). It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10. Your post could do without 'duh' and the like as well.

raiph 11y ago
> A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point. I thought being able to store an up to 8 digit integer in a float was an interesting tidbit. I already knew it but others might not. However, it was also completely irrelevant to a discussion of why 0.1 + 0.2 equals 0.3 in Perl 6 and, imo, even to my (slight over) emphasis that a float is for (efficient) storage and processing of approximations, not exact numbers. > 0.1 isn't past any "point" (whatever that means). Precisely. I was directly responding to "And [floats] can store binary fractions exactly up to a point." What does that mean? "up to a point" is highly ambiguous. The fact that 0.1 isn't stored exactly is completely unambiguous. > It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10. So what? It is representable without recurrence in a pair of base 2 numbers, eg 1 (numerator) and 11 (denominator) for 1/3. > Your post could do without 'duh' OK. I considered that and thought it was OK, all things considered, given that it wasn't prominent and succinctly expressed my reaction. But I hear you that even such a gentle 'duh' is problematic and will be even more careful about how I express myself at HN in future. > and the like as well. Would you be willing to be specific? While I recognize the 'duh' is edgy, I've reread the rest of what I wrote and don't understand what you think I got wrong.

haberman 11y ago

> You're right, for relatively small integers of 8 digits or so. For doubles (more common than floats) it is up to 2^53, which is quite a usable range. > As in you've written such code in dozens of programs? As in every JavaScript program ever written that uses a for loop and integer indices does this. > 0.1 is already "past" that point which is even less impressive than 8 digit integers. 0.1 is not a binary fraction. A binary fraction can be expressed in the form a/2^b for some a and b. Decimal representations have the same limitation (can only express decimal fractions), it just seems more exact because we write numbers in decimal. > Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3? It's worth mentioning when you say untrue things like "Floats are, by definition, not relevant if one wants to store an exact number exactly." Double precision floating point has more exact integer range than int32.

kbenson 11y ago
I think you guys are arguing at cross-purposes. I'm not sure anyone is arguing that an integer is better than a double for integer representation, but that storing a pair of numeric values (whether they be integers or floating point of some type) allows for more natural expression of numeric values in a high level language, with more fidelity. > > Floats are, by definition, not relevant if one wants to store an exact number exactly. > Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point. If you have some knowledge about the number you are storing, such as that it is an integer, then you can use the fact that floats can represent integers exactly to large values. If you need a general purpose numeric type of which you can't assume it's an integer, and it needs to be stored exactly, then I think it's valid to say that floating point numbers are not relevant, at least not as the entirely of the underlying storage container. > No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly. Yes. So we are talking about storage mechanisms that allow for more fidelity than plain floats and doubles can achieve.
raiph 11y ago
If you search back to the comment that started this subthread you'll find it began: "Try 0.1 + 0.2 == 0.3 in some other language, then try it in Perl 6." Do you agree with all of the next sentence or not? Please start with a plain yes or no before getting in to details. The three individual literal decimal numbers shown above are not integers, they're not binary fractions, they're not floats, they are rational numbers, they are exact numbers, they are easily stored exactly on a computer, and whether or not they are stored exactly on a computer is a choice made by a programming language.