in reply to Re: Math::Base - arithmetics with baseX integers
in thread Math::Base - arithmetics with baseX integers (updated)

What I did is to mimic the behavior of sprintf and hex in encode(), i.e. roll over: 

    $num = (~abs($num))+1 if $num < 0;

[download]

And the return line now reads:

       return join( '', reverse @ret) || 0;

[download]

I've updated the op with the new version. Thanks for your hints!

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^3: Math::Base - arithmetics with baseX integers (OP updated)
by no_slogan (Deacon) on Aug 23, 2017 at 18:08 UTC
    $num = int $num;
    $num = (~abs($num))+1 if $num < 0;

    You can get the same effect with $num |= 0; ...but... why? Why would you want two's complement behavior in other bases?

    Truncating at $n bits is mathematically equivalent to:

    $num %= 2 ** $n;

    That's only meaningful for base-2. You can truncate at $n base-$b digits using this:

    $num %= $b ** $n;

    So -1 becomes 999999 in base-10 or 666666 in base-7. If you want, you can pick a big number of digits that still fits in a double-precision float like this:

    $num %= $base ** int(36.73/log($base));
[reply]
      That's only meaningful for base-2.

      Well, that's how computers work, don't they... since the whole business of this convoluted module is only yielding the string representation of a value $n to base $b via a charset @c, while all calculations are carried out on the number/integer slots of its objects - it doesn't really calculate in base $b (no such machine except $base == 2) - the only thing is to find a good stringified representation of the underlying numbers, whilst not limiting the native number range.

      So I guess the best way to go here is outlawing '-' from the valid chars array and using that as a prefix for negative numbers. That would reduce the maxbase to 90, which I deem not to be a big loss. Would that be a good way to go?

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
        I feel like the signed representation makes the most sense, but whatev. If the object is to represent high bases in an inscrutable fashion, there are plenty of Unicode characters out there. If it's to map every printable ASCII string to an integer value, you could use a mixed radix approach where the first digit is (at most) base-94 and the rest are base-95. (There are 95 printable ASCII characters, you missed these: {|}~)
[reply]
      ...but... why? Why would you want two's complement behavior in other bases?

      I think that you are both over- and under-thinking this. (We've clashed before on the benefits or otherwise of 'machine representation', so you may chose to simply ignore this.)

      On computers (popular, common, generic), numbers are stored and manipulated internally as binary. Whether we choose to view those numbers as signed or unsigned, integers or floats, decimal or hexadecimal or octal or (indeed) binary; internally they are held and maintained in binary form.

      Even your favored (Python) infinite precision numbers are stored and manipulated using a binary representation. And that means that it had to deal with exactly the same problems as shmem's code, and solved them in essentially the same way as you are now critiquing.

      For the full skinny, read PEP-0237.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]
        Do you seriously think I don't already know that? But I'm not worried about the implementation. I just can't imagine that someone would want to get the result 1-2=18446744073709551615. That's ridiculous C behavior that we've all gotten used to, and it might even be useful in a few situations, but it's not good behavior that anyone should be trying to emulate in a high-level language.
[reply]

In Section Cool Uses for Perl