Hacker News Reader

Comment by mehrdada | Hacker News Reader

"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.

View on HN

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

Here is the Decimal type which does not have this float problem.

Are you sure?

  >>> Decimal(0.1)
  Decimal('0.1000000000000000055511151231257827021181583404541015625')

use Decimal('0.1'), otherwise you will first generate a floating point number (with accuracy loss) and the convert it to a decimal.

It does not if you pass the string representation of the float you're working on. Like BigDecimal in Java.

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.

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.

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'.

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.

Right you are. One half is 0.5 in decimal or 0.1 in binary but 0.11111... in base 3

> 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.

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.

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.

Reply on news.ycombinator.com