I would agree on the little endian-ness. The lists of digits coming from
p-adics (and printing in series mode) is little-endian. It would be nice to
be consistent with this. I also agree with David Harvey's arguments.
David
On 6/29/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
>
> 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/
-~----------~----~----~----~------~----~------~--~---
