[sage-devel] Re: Major bug in GF(109)['x', 'y']
ok, it isn't normalize, but a very small function called npWrite
void npWrite (number a)
{
if ((long)a (npPrimeM 1)) StringAppend(-%d,(int)(npPrimeM-
((long)a)));
else StringAppend(%d,(int)((long)a));
}
This is set to the current ring
in numbers.cc
n-nWrite = npWrite;
It should just affect the output, so I think would be okay to change
it.
Michael
On 11 Sep., 01:35, Martin Albrecht [EMAIL PROTECTED]
wrote:
I can well understand why no-one wanted to write their own conversion
of a multi-variable poly to a string, but it would not be any harder
than for univars: just loop over the monomials...
John
:-) My main concern is not the writing part but making it fast, since ideally
one would convert each coefficient to the native Sage type and use its
string representation. This however is slow and the speed of the string
representation does matter for instance w.r.t. the conversion to Magma and
other pexpect'ed systems. If this is perceived as a major annoyance I'll just
write the code eventually.
Cheers,
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
I seem to have hit this by accident: http://trac.sagemath.org/sage_trac/ticket/4096. John 2008/9/10 mabshoff [EMAIL PROTECTED]: On Sep 9, 7:27 pm, Jason Grout [EMAIL PROTECTED] wrote: David Harvey wrote: On Sep 9, 2008, at 10:20 PM, mabshoff wrote: Could a ticket be opened? #4095 it is. You all know what this means. ooh, ooh...it's still open! /me thinks really hard for a bug :). I got like 10 on my personal to do list, but I don't want to take ticket 2^12 away from anybody :) Jason Cheers, Michael --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is undesired
that they print differently how come it is 'major'? What am I missing?
Martin
PS: The -10 comes from libSingular so changing this would mean to not use its
built-in printing code.
--
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
2008/9/10 Martin Albrecht [EMAIL PROTECTED]:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is undesired
that they print differently how come it is 'major'? What am I missing?
I agree with Martin. We use different engines for 1- and 2-variable
polynomial rings, and they have different normalizations for
representing residue classes. It is not such a big deal, is it?
though of course it would be nicer to be more consistent, if
libSingular had a way of changing its default once and for all which
we could call upon.
John
Martin
PS: The -10 comes from libSingular so changing this would mean to not use its
built-in printing code.
--
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
It's probably just a function pointer.
void(*nNormalize)(number a);
But I am not sure about side effects.
Michael
On 10 Sep., 15:54, John Cremona [EMAIL PROTECTED] wrote:
2008/9/10 Martin Albrecht [EMAIL PROTECTED]:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is undesired
that they print differently how come it is 'major'? What am I missing?
I agree with Martin. We use different engines for 1- and 2-variable
polynomial rings, and they have different normalizations for
representing residue classes. It is not such a big deal, is it?
though of course it would be nicer to be more consistent, if
libSingular had a way of changing its default once and for all which
we could call upon.
John
Martin
PS: The -10 comes from libSingular so changing this would mean to not use
its
built-in printing code.
--
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On 10-Sep-08, at 1:49 AM, Martin Albrecht wrote:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is
undesired
that they print differently how come it is 'major'?
Okay, maybe it is not major. For internal reasons, I am very
unsettled to get back different representations for the same thing.
Try:
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x', 'y'](-10).constant_coefficient()
99
}}}
I can't see how this won't bite someone in the ass sometime.
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
2008/9/10 Nick Alexander [EMAIL PROTECTED]:
On 10-Sep-08, at 1:49 AM, Martin Albrecht wrote:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is
undesired
that they print differently how come it is 'major'?
Okay, maybe it is not major. For internal reasons, I am very
unsettled to get back different representations for the same thing.
Try:
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x', 'y'](-10).constant_coefficient()
99
}}}
I can't see how this won't bite someone in the ass sometime.
Maybe. As far as I can see the _repr_() function on the (constant)
poly just gets a string from singular, so is relying on singular's
representation for integers mod 109. While the constant_coefficient()
function is returning a Sage object. There does not seem to be a
method for turning the singular form into a Sage polynomial.
John
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Wednesday 10 September 2008, John Cremona wrote:
2008/9/10 Nick Alexander [EMAIL PROTECTED]:
On 10-Sep-08, at 1:49 AM, Martin Albrecht wrote:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is
undesired
that they print differently how come it is 'major'?
Okay, maybe it is not major. For internal reasons, I am very
unsettled to get back different representations for the same thing.
Try:
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x', 'y'](-10).constant_coefficient()
99
}}}
I can't see how this won't bite someone in the ass sometime.
Maybe. As far as I can see the _repr_() function on the (constant)
poly just gets a string from singular, so is relying on singular's
representation for integers mod 109. While the constant_coefficient()
function is returning a Sage object. There does not seem to be a
method for turning the singular form into a Sage polynomial.
Of course, I *could* write our own _repr_ function instead of just using
whatever Singular returns back.
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
2008/9/10 Martin Albrecht [EMAIL PROTECTED]:
On Wednesday 10 September 2008, John Cremona wrote:
2008/9/10 Nick Alexander [EMAIL PROTECTED]:
On 10-Sep-08, at 1:49 AM, Martin Albrecht wrote:
On Wednesday 10 September 2008, mabshoff wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
I don't see the problem, since -10 == 99 mod GF(109).Even if it is
undesired
that they print differently how come it is 'major'?
Okay, maybe it is not major. For internal reasons, I am very
unsettled to get back different representations for the same thing.
Try:
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x', 'y'](-10).constant_coefficient()
99
}}}
I can't see how this won't bite someone in the ass sometime.
Maybe. As far as I can see the _repr_() function on the (constant)
poly just gets a string from singular, so is relying on singular's
representation for integers mod 109. While the constant_coefficient()
function is returning a Sage object. There does not seem to be a
method for turning the singular form into a Sage polynomial.
Of course, I *could* write our own _repr_ function instead of just using
whatever Singular returns back.
Wouldn't it be better to write a conversion from singular to a Sage
type? Or would that be impossibly complicated (I have no idea how
many Singular types there are, but all we need is a conversion from
MPolynomial_libsingular to start with).
John
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
2008/9/10 Martin Albrecht [EMAIL PROTECTED]: Of course, I *could* write our own _repr_ function instead of just using whatever Singular returns back. Wouldn't it be better to write a conversion from singular to a Sage type? Or would that be impossibly complicated (I have no idea how many Singular types there are, but all we need is a conversion from MPolynomial_libsingular to start with). I don't understand, MPolynomial_libsingular (libsingular + wrapper) is the Sage type, just like GMP integers + wrapper is the Sage type. Sorry I was talking nonsense. For univariate polys we have our own (Sage) function for turning into a string, which in particular converts the coefficients using str() which puts them in range(p). For multis, we use singular's own function p_String and do minimal post-processing (just changing the spacing), so we are the mercy of singular's way of representing the coefficients -- despite the fact that when you ask for a specific coefficient they are of Sage type sage.rings.integer_mod.IntegerMod_int. So for f a random poly in that ring we see sage: [f.monomial_coefficient(m) for m in f.monomials()] [55, 80, 39, 53, 69] but sage: sum([f.monomial_coefficient(m)*m for m in f.monomials()]) -54*x^2 - 29*x*y + 39*y^2 + 53*x - 40*y sage: sum([f.monomial_coefficient(m)*m for m in f.monomials()]) == f True I can well understand why no-one wanted to write their own conversion of a multi-variable poly to a string, but it would not be any harder than for univars: just loop over the monomials... John Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
I can well understand why no-one wanted to write their own conversion of a multi-variable poly to a string, but it would not be any harder than for univars: just loop over the monomials... John :-) My main concern is not the writing part but making it fast, since ideally one would convert each coefficient to the native Sage type and use its string representation. This however is slow and the speed of the string representation does matter for instance w.r.t. the conversion to Magma and other pexpect'ed systems. If this is perceived as a major annoyance I'll just write the code eventually. Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Sep 9, 7:13 pm, Nick Alexander [EMAIL PROTECTED] wrote:
This is double plus not good.
{{{
sage: GF(109)['x', 'y'](-10)
-10
sage: GF(109)['x'](-10)
99
}}}
Could a ticket be opened?
#4095 it is.
Nick
Cheers,
Michael
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Sep 9, 2008, at 10:20 PM, mabshoff wrote: Could a ticket be opened? #4095 it is. You all know what this means. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
David Harvey wrote: On Sep 9, 2008, at 10:20 PM, mabshoff wrote: Could a ticket be opened? #4095 it is. You all know what this means. ooh, ooh...it's still open! /me thinks really hard for a bug :). Jason --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Major bug in GF(109)['x', 'y']
On Sep 9, 7:27 pm, Jason Grout [EMAIL PROTECTED] wrote: David Harvey wrote: On Sep 9, 2008, at 10:20 PM, mabshoff wrote: Could a ticket be opened? #4095 it is. You all know what this means. ooh, ooh...it's still open! /me thinks really hard for a bug :). I got like 10 on my personal to do list, but I don't want to take ticket 2^12 away from anybody :) Jason Cheers, Michael --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
