On Jun 29, 2007, at 5:51 AM, Martin Albrecht wrote:
>
> On Friday 29 June 2007 02:48, Nick Alexander wrote:
>> Martin Albrecht <[EMAIL PROTECTED]> writes:
>>> Hi there,
>>>
>>> I often come across the situation where I have to construct an
>>> integer
>>> from its binary representation and vice versa. So far you do it
>>> in SAGE
>>> using strings. I have attached a preliminary patch which allows the
>>> following code to work, i.e. I _replaced_ the binary() method (which
>>> returned a string) with a method that returns a tuple of Python
>>> ints.
>>
>> I won't take about the method name, but it would be very nice to have
>> a method that returns the base b digits of an integer for arbitrary
>> b. Could this be made an optional argument, perhaps with a fast path
>> for b = 2?
>>
>> Nick
>
> Sounds good, will do. Actually, I have to bring up the endianess
> again. Right
> now the string is big endian and I would prefer the list/tuple/
> vector match
> the endianess of the string rather than the endianess of polynomials.
>
> sage: 16.str(2)
> '10000'
> sage: 16.str(8)
> '20'
>
> Thoughts?
I still don't like it, basically because I've never seen a computer
algebra system that represents integers *internally* in big-endian
format. (The main exception is PARI, which actually *reverses* the
representation on every single operation, because it uses GMP for the
arithmetic, and GMP represents things internally in little-endian
format!)
Strings are always big-endian because that's the way people read
numbers off a page. That's just a historical thing. It has more to do
with the left-right reading direction than representation in memory.
I guess when you start from the left, if you see how long the number
is, then the first digits (i.e. the most significant digits) give you
immediately more information about the overall magnitude. If you
start from the right, you only get information interesting to a
number theorist :-)
I guess the main reason it feels more natural to me to go little
endian is then digits are always aligned automatically for arithmetic
purposes. Like if you want to add two vectors, you just start
looping, you don't have to fiddle with indexing. If the value
overflows, you just append digits at the end, you don't have to go
shifting everything around.
On the other hand, you have mathematica as a precedent:
IntegerDigits[13, 2]
{1, 1, 0, 1}
But honestly I don't really care which way it goes. If you don't buy
my argument, doesn't bother me at all. I'll just call reverse()
whenever I use your function :-)
david
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
