[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
On Saturday 30 June 2007 07:11, Robert Bradshaw wrote: +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... David convinced me with the list-iteration argument, though even if I wasn't convinced it seems clear what most people want. I have uploaded a release candidate patch to http://www.sagemath.org:9002/sage_trac/ticket/397 Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
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) '1' sage: 16.str(8) '20' Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
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)
'1'
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
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)
'1'
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
After all, Intel has taken over Powerpc even in macs.. ;-) With that as a precedent, if SAGE goes little-endian, while Mathematica is big-endian, it could only mean that... Gonzalo On 6/29/07, David Roe [EMAIL PROTECTED] 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 --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
+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)
'1'
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/
-~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
On Jun 28, 2007, at 5:04 PM, Martin Albrecht wrote: 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. sage: e = ZZ(10231252).binary(); e (1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 0) sage: ZZ(e,2) 10231252 I know that this patch has some issues: * it breaks doctests which rely on strings (fix by replace ZZ.binary () with ZZ.str(2)) * it returns a tuple of Python ints should return tuple (?) of GF (2) elements but I didn't want to mess with imports yet * it can be done faster * you loose the minus sign: ZZ(-1).binary() is (1,), shall it raise an exception then? I am not out for micromanagement but I hesitate to just submit a polished patch as the Integers are such a central building block of SAGE. So, does anybody actually like the current behavior of ZZ.binary() which returns a (signed) string? Any other objections against making the above work? Hmmm I don't know if I like this. Well, I don't have any objections to such a method being available, but I prefer the name binary to have the current behaviour. It's more pythonic, like the hex function. BTW for the list format, I would prefer the least significant bit to be listed first. This is more like the list() function for polynomials, if you think of an integer as a polynomial in 2: eleven = 1*2^0 + 1*2^1 + 0*2^2 + 1*2^3 = [1, 1, 0, 1] 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
On 6/29/07, David Harvey [EMAIL PROTECTED] wrote: On Jun 28, 2007, at 5:04 PM, Martin Albrecht wrote: 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. sage: e = ZZ(10231252).binary(); e (1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 0) sage: ZZ(e,2) 10231252 I know that this patch has some issues: * it breaks doctests which rely on strings (fix by replace ZZ.binary () with ZZ.str(2)) * it returns a tuple of Python ints should return tuple (?) of GF (2) elements but I didn't want to mess with imports yet * it can be done faster * you loose the minus sign: ZZ(-1).binary() is (1,), shall it raise an exception then? I am not out for micromanagement but I hesitate to just submit a polished patch as the Integers are such a central building block of SAGE. So, does anybody actually like the current behavior of ZZ.binary() which returns a (signed) string? Any other objections against making the above work? Hmmm I don't know if I like this. Well, I don't have any objections to such a method being available, but I prefer the name binary to have the current behaviour. It's more pythonic, like the hex function. +1 for keeping the method and but changing the name. didier --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
Hmmm I don't know if I like this. Well, I don't have any objections to such a method being available, but I prefer the name binary to have the current behaviour. It's more pythonic, like the hex function. But there is no binary/bin function. I understand that __hex__ returns a string to obey Python conventions but binary() is our addition. Also, if you are after a binary representation of an integer in SAGE you probably want to do calculations with it, so a tuple/list/iterable of bits seems more natural to me. BTW for the list format, I would prefer the least significant bit to be listed first. This is more like the list() function for polynomials, if you think of an integer as a polynomial in 2: eleven = 1*2^0 + 1*2^1 + 0*2^2 + 1*2^3 = [1, 1, 0, 1] I think when it comes to endianess we will have to agree to disagree. In the multivariate world and in all the we-do-some-stuff-to-bits crypto big endianess (MSB is left) wins over little endianess. But it seem to me SAGE tends towards little endianess alltogether so I will return it in little endian order. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
On Jun 28, 2007, at 6:06 PM, Martin Albrecht wrote: Hmmm I don't know if I like this. Well, I don't have any objections to such a method being available, but I prefer the name binary to have the current behaviour. It's more pythonic, like the hex function. But there is no binary/bin function. I understand that __hex__ returns a string to obey Python conventions but binary() is our addition. Also, if you are after a binary representation of an integer in SAGE you probably want to do calculations with it, so a tuple/list/iterable of bits seems more natural to me. oct(34) '042' hex(34) '0x22' It just feels weird to me, even if we are adding binary() ourselves, to go against the grain here. Although, to make a point on your side, both the oct and hex functions return a representation which matches python's input syntax for octal and hex, and the binary string representation doesn't (and can't) do that. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO
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 --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
