4 ms·

The problem here isn’t integers at all, as 8.95 is not an integer but an integer (8) plus a fraction (0.95 or 95/100==19/20). That’s in decimal, but since compu

The problem here isn’t integers at all, as 8.95 is not an integer but an integer (8) plus a fraction (0.95 or 95/100==19/20). That’s in decimal, but since computers use binary, your decimal fraction must be converted to a binary fraction. This is what floating point is used for, although it’s important to know that floating point is an approximation of the real number line, and also that fractions that are rational in decimal may be irrational in binary, namely if the decimal denominator is not a power of two. Looks like that’s what’s going on with your example. Floating point approximation of an otherwise unrepresentable irrational binary which resulted in that repeating sequence when converted back to decimal again. I don’t know how BigDecimal works but I guess just by the name it is not floating point but rationals represented by arbitrary precision integer numerators and denominators. Definitely read up on how floating point representation works, with binary mantissas and exponents, normalization, and converting decimal fractions to binary fractions.

dragonwriter 7y ago
> That’s in decimal, but since computers use binary Well, if you tell them to, e.g., by using a binary floating point type instead of a decimal type.
- sixstringtheory 7y ago
  No, we aren’t using computers with logic gates that have 10 discrete states. Even if you’re programming to decimal, the underlying representation is still binary. But there are numerical differences between using decimals represented by rationals with binary integer numerators and denominators, vs floating point with binary mantissa and exponent.
  - dragonwriter 7y ago
    > No, we aren’t using computers with logic gates that have 10 discrete states. Even if you’re programming to decimal, the underlying representation is still binary. That is not the sense of "computers use binary" that justifies the conclusions in the sentence in which the phrase was used in the post being responded to, so while true on its own, in context it is an example of the fallacy of equivocation.
    - sixstringtheory 7y ago
      Could you help me understand where I’ve gone wrong here? I think there’s some miscommunication going on.
      - dllthomas 7y ago
        Are you familiar with binary coded decimal? Decimal format floats are in somewhat the same vein. See, for instance, https://en.m.wikipedia.org/wiki/Decimal32_floating-point_format https://en.m.wikipedia.org/wiki/Decimal32_floating-point_for...
        sixstringtheory 7y ago
        This is basically what I meant when I said "computers use binary"
        dllthomas 7y ago
        That sense is trivially true, but it doesn't follow that you have binary fractions.
        sixstringtheory 7y ago
        Sorry, but I'm not parsing this sentence: > it doesn't follow that you have binary fractions Is that in reference to something I said earlier, or are we just falling deeper down a rabbit hole of hair splitting? The point I was driving at is that a given number we think about in decimal like 12.3456 can be represented in binary in more than one way, one of which are rationals backed by integers for num/den, another is floating point with mantissa and exponent. Which way is chosen ultimately affects the outcomes of computations. I was trying to explain why OP was seeing unexpected results. I don't think I've been mistaken in the explanations...
        dllthomas 7y ago
        The issue is that you are missing the possibility of decimal floating point, which is also defined in IEEE 754 but which is typically not exposed as a primitive in programming languages. Imagine a BCD mantissa. That can encode 12.3456 exactly. So it's not "since computers use binary", but "since we use binary floating point". There are fair arguments that we made that choice because of efficiency concerns driven by the fact that "computers use binary", but I don't think that really helps the explanation. Note that the original objection was picking at a nit that I am not sure I would have picked at, I am just seeking to clarify.

dragonwriter 7y ago

> That’s in decimal, but since computers use binary Well, if you tell them to, e.g., by using a binary floating point type instead of a decimal type.

sixstringtheory 7y ago
No, we aren’t using computers with logic gates that have 10 discrete states. Even if you’re programming to decimal, the underlying representation is still binary. But there are numerical differences between using decimals represented by rationals with binary integer numerators and denominators, vs floating point with binary mantissa and exponent.
- dragonwriter 7y ago
  > No, we aren’t using computers with logic gates that have 10 discrete states. Even if you’re programming to decimal, the underlying representation is still binary. That is not the sense of "computers use binary" that justifies the conclusions in the sentence in which the phrase was used in the post being responded to, so while true on its own, in context it is an example of the fallacy of equivocation.
  - sixstringtheory 7y ago
    Could you help me understand where I’ve gone wrong here? I think there’s some miscommunication going on.
    - dllthomas 7y ago
      Are you familiar with binary coded decimal? Decimal format floats are in somewhat the same vein. See, for instance, https://en.m.wikipedia.org/wiki/Decimal32_floating-point_format https://en.m.wikipedia.org/wiki/Decimal32_floating-point_for...
      - sixstringtheory 7y ago
        This is basically what I meant when I said "computers use binary"
        dllthomas 7y ago
        That sense is trivially true, but it doesn't follow that you have binary fractions.
        sixstringtheory 7y ago
        Sorry, but I'm not parsing this sentence: > it doesn't follow that you have binary fractions Is that in reference to something I said earlier, or are we just falling deeper down a rabbit hole of hair splitting? The point I was driving at is that a given number we think about in decimal like 12.3456 can be represented in binary in more than one way, one of which are rationals backed by integers for num/den, another is floating point with mantissa and exponent. Which way is chosen ultimately affects the outcomes of computations. I was trying to explain why OP was seeing unexpected results. I don't think I've been mistaken in the explanations...
        dllthomas 7y ago
        The issue is that you are missing the possibility of decimal floating point, which is also defined in IEEE 754 but which is typically not exposed as a primitive in programming languages. Imagine a BCD mantissa. That can encode 12.3456 exactly. So it's not "since computers use binary", but "since we use binary floating point". There are fair arguments that we made that choice because of efficiency concerns driven by the fact that "computers use binary", but I don't think that really helps the explanation. Note that the original objection was picking at a nit that I am not sure I would have picked at, I am just seeking to clarify.