5 ms·

"Computers can only natively store integers, so they need some way of representing decimal numbers" Technically, [digital] computers only natively "store" high

"Computers can only natively store integers, so they need some way of representing decimal numbers" Technically, [digital] computers only natively "store" high and low voltages. The interpretation of a sequence of those signals as "integers" is entirely up to you. In all seriousness, representing integers is not a given either (e.g. two's complement vs one's complement, BCD, bignum, sparse integers, etc.). If you are going down in abstraction levels to describe floating point representation, you should not just call integers "native" blindly. Furthermore, floating point is not the only way to represent computation involving real values. It is indeed possible to represent computation on real values symbolically in many cases and lazily compute arbitrary precision results for output-printing purposes.

illumen 11y ago
Technically, much storage does not need voltage being high or low either. Pits burned with lasers, and magnetic changes are also common ways to store stuff that don't involve voltage in the stored state. Here you can see python has a fractions.Fraction type which can be used for rational number arithmetic. >>> from fractions import Fraction >>> Fraction("0.1") + Fraction("0.2") Fraction(3, 10) >>> repr(float(Fraction("0.1") + Fraction("0.2"))) '0.3' Here we see the floating point behaviour. >>> 0.1 + 0.2 0.30000000000000004 Here we see that python has a nice behaviour for when printing floats. >>> print(0.1 + 0.2) 0.3 Here is a common error where people feed the input of Fraction (and Decimal) with a float. Even though you use the Fraction here it still carries the floating point error through. >>> Fraction(0.1) + Fraction(0.2) Fraction(10808639105689191, 36028797018963968) >>> float(Fraction(0.1) + Fraction(0.2)) 0.30000000000000004 Here is the Decimal type which does not have this float problem. Some people have argued (including myself) that Decimal should be used by python instead of float. Since this is much friendlier to people doing things like adding these numbers together. >>> from decimal import Decimal >>> Decimal("0.1") + Decimal("0.2") Decimal('0.3') >>> float(Decimal("0.1") + Decimal("0.2")) 0.3
- jessaustin 11y ago
  Here is the Decimal type which does not have this float problem. Are you sure? >>> Decimal(0.1) Decimal('0.1000000000000000055511151231257827021181583404541015625')
  - karl42 11y ago
    use Decimal('0.1'), otherwise you will first generate a floating point number (with accuracy loss) and the convert it to a decimal.
  - flaie 11y ago
    It does not if you pass the string representation of the float you're working on. Like BigDecimal in Java.
- anon4 11y ago
  This is a good case for macros in Python, actually. Fraction('0.1') is usually what you want, so Fraction(0.1) should mean just that and if you do want the current behaviour, Fraction(float(0.1)) would do it. Same for Fraction(17/3) for example.
linker3000 11y ago
> Technically, [digital] computers only natively "store" high and low voltages. The interpretation of a sequence of those signals as "integers" is entirely up to you. And then there's MLC NAND flash which stores bit sequences as different voltage levels within the same cell.
kqr 11y ago
I think the words we're really looking for are "discrete" vs "continuous". Any discrete values will be bounded by some sort of precision limit.
- jacquesm 11y ago
  That depends on the number you want to represent. Some values can be represented exactly, others with varying degrees of precision because of the difference between what is actually stored and what you wanted to store. This will collapse a number of values into the same precision 'bucket'.
  - pnt12 11y ago
    What is continuous or precise depends on the base you use. I can't think of any example in base 2, but I believe in base 3 you could represent numbers that have infinite digits in base 10. If I'm not mistaken, 0.3333... would be 0.1 and 0.6666... would be 0.2. It probably gets nasty for a lot of simple base 10 numbers, so it isn't a good solution.
    - umanwizard 11y ago
      Right you are. One half is 0.5 in decimal or 0.1 in binary but 0.11111... in base 3
erikwiffin 11y ago
That's valid, but I was going for an ELI5 style explanation of a concept that surprised and confused me at the time. If you want to provide a better one, I'm happy to merge any pull requests.
- oldmanjay 11y ago
  when you aim for reddit style stuff like "ELI5", don't be surprised if HN tears you up. reddit likes things to be cool and cliquey. we like things to be correct. also we don't have 5 year olds.

illumen 11y ago

Technically, much storage does not need voltage being high or low either. Pits burned with lasers, and magnetic changes are also common ways to store stuff that don't involve voltage in the stored state. Here you can see python has a fractions.Fraction type which can be used for rational number arithmetic. >>> from fractions import Fraction >>> Fraction("0.1") + Fraction("0.2") Fraction(3, 10) >>> repr(float(Fraction("0.1") + Fraction("0.2"))) '0.3' Here we see the floating point behaviour. >>> 0.1 + 0.2 0.30000000000000004 Here we see that python has a nice behaviour for when printing floats. >>> print(0.1 + 0.2) 0.3 Here is a common error where people feed the input of Fraction (and Decimal) with a float. Even though you use the Fraction here it still carries the floating point error through. >>> Fraction(0.1) + Fraction(0.2) Fraction(10808639105689191, 36028797018963968) >>> float(Fraction(0.1) + Fraction(0.2)) 0.30000000000000004 Here is the Decimal type which does not have this float problem. Some people have argued (including myself) that Decimal should be used by python instead of float. Since this is much friendlier to people doing things like adding these numbers together. >>> from decimal import Decimal >>> Decimal("0.1") + Decimal("0.2") Decimal('0.3') >>> float(Decimal("0.1") + Decimal("0.2")) 0.3

jessaustin 11y ago
Here is the Decimal type which does not have this float problem. Are you sure? >>> Decimal(0.1) Decimal('0.1000000000000000055511151231257827021181583404541015625')
- karl42 11y ago
  use Decimal('0.1'), otherwise you will first generate a floating point number (with accuracy loss) and the convert it to a decimal.
- flaie 11y ago
  It does not if you pass the string representation of the float you're working on. Like BigDecimal in Java.
anon4 11y ago
This is a good case for macros in Python, actually. Fraction('0.1') is usually what you want, so Fraction(0.1) should mean just that and if you do want the current behaviour, Fraction(float(0.1)) would do it. Same for Fraction(17/3) for example.

linker3000 11y ago

> Technically, [digital] computers only natively "store" high and low voltages. The interpretation of a sequence of those signals as "integers" is entirely up to you. And then there's MLC NAND flash which stores bit sequences as different voltage levels within the same cell.

kqr 11y ago

I think the words we're really looking for are "discrete" vs "continuous". Any discrete values will be bounded by some sort of precision limit.

jacquesm 11y ago
That depends on the number you want to represent. Some values can be represented exactly, others with varying degrees of precision because of the difference between what is actually stored and what you wanted to store. This will collapse a number of values into the same precision 'bucket'.
- pnt12 11y ago
  What is continuous or precise depends on the base you use. I can't think of any example in base 2, but I believe in base 3 you could represent numbers that have infinite digits in base 10. If I'm not mistaken, 0.3333... would be 0.1 and 0.6666... would be 0.2. It probably gets nasty for a lot of simple base 10 numbers, so it isn't a good solution.
  - umanwizard 11y ago
    Right you are. One half is 0.5 in decimal or 0.1 in binary but 0.11111... in base 3

erikwiffin 11y ago

That's valid, but I was going for an ELI5 style explanation of a concept that surprised and confused me at the time. If you want to provide a better one, I'm happy to merge any pull requests.

oldmanjay 11y ago
when you aim for reddit style stuff like "ELI5", don't be surprised if HN tears you up. reddit likes things to be cool and cliquey. we like things to be correct. also we don't have 5 year olds.