+1 for little endian-ness. As well as consistency, I think big endian  
only makes sense for fixed size words. Otherwise you have to know how  
large the number is to know what each digit represents, and it seems  
odd to me to, say, subtract and have the result of the 5th and 7th  
digits be placed in the 2nd digit because of cancelation...

On Jun 29, 2007, at 2:14 PM, David Roe wrote:

> 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/
-~----------~----~----~----~------~----~------~--~---

Reply via email to