6 ms·

> Floats are defined by the hardware essentially, not the language. Floats are storage formats for approximations of numbers. Floats are, by definition, not r

by raiph 11y ago

> Floats are defined by the hardware essentially, not the language. Floats are storage formats for approximations of numbers. Floats are, by definition, not relevant if one wants to store an exact number exactly. > 0.1 can't be represented exactly as binary. 1 can be represented exactly as binary. And so can 10. And thus 1 (numerator) divided by 10 (denominator) can be represented by two (binary -- or any-other-ary-for-that-matter) numbers. This isn't about (just) decimals. The same thing applies to non-decimal fractions like 1/3 or 56,123 / 7329. Some languages prefer to store exact representations of rational numbers. Perl 6 is by no means the first.

haberman 11y ago
> Floats are storage formats for approximations of numbers. 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. No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
- 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.

by raiph 11y ago

haberman 11y ago

> Floats are storage formats for approximations of numbers. 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. No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.

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.