in reply to Re^3: Behaviour of int() unexpected
in thread Behaviour of int() unexpected

Okay, so if 1/3 gives us a problem, why didn't they introduce another variable such as r which would count the repeating digits at the end?

So, a number like 23.676767676767 might be represented as m = 2367 e = -2 r = 2 where r tells us to repeat the last two digits to infinity. Or 1/3 would be stored as m = 3 e = -1 r = 1

In a 64-bit variable, it would be 4 bits for r, 10 bits for e, and 48 bits for m. Then there would be one bit for mantissa's sign and another bit for exponent's sign. Total 64 bits.

Mantissa would go from -281474976710656 to +281474976710656
Exp would go from -1024 to +1024
Rep would go from 0 to 15

Replies are listed 'Best First'.
Re^5: Behaviour of int() unexpected
by LanX (Saint) on Mar 11, 2025 at 03:59 UTC
    IIRC do some languages offer a data type for fractions.

    So 4/6 is stored as a tuple (2,3)

    I think Raku is one of them.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

[reply]
      Yes, Raku is one such language.
      Perl also provides this through the Math::BigRat module, and also the bigrat pragma: 
      > >perl -Mbigrat -le "$x = 4; print $x/6;"
2/3

      [download]
      Math::GMPq is another module that provides for rational arithmetic.

      Cheers,
      Rob
[reply]
[d/l]
      > data type for fractions.

      I should have mentioned that any periodic number can be represented loss free as fraction, and vice versa.

      (I already covered this in school in 7th or 8th grade but curriculums may vary.)

      So, within the boundaries of integer precision you can have loss free calculations.

      But with some overhead for normalization. (I suppose they can't be delayed ...🤔 ;)

      This could be sufficient for financial applications, though I'd rather prefer to calculate with the smallest unit in integer. ( Like cent, or deci-cent or whatever depending on legal specifications)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
Re^5: Behaviour of int() unexpected
by ikegami (Patriarch) on Mar 11, 2025 at 03:25 UTC

    It would be very expensive to perform math operations on a number stored that way, it at all possible.

    Assuming it's possible, even straight up comparisons would be super expensive. If you multiply m = 3 e = -1 r = 1 by three, you get m = 9 e = -1 r = 1. But that's equal to m = 1 e = 0 r = 0. Should every math operation perform this expensive normalization? Should comparison? Neither are appealing.

    And to what end? To avoid rounding? You'll need to do that anyway when r != 0, and you usually want to do that regardless. To make int work better? int will still give the wrong result in the example above (m = 9 e = -1 r = 1) without normalization.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom