behaviour of reduce ?
Pierre
this is going to be even worse than my recent bug report in terms of
reproducing the error. I guess i'll start with describing what
happens, and then if someone tells me that it's a bug and not a
feature, then i'll try to get a minimal example.
So I've got a polynomial ring with a few dozens variables, over a
cyclotomic field, and i've got an ideal J with hundreds of generators.
J contains at least y9 + y12. Then i got something like:
sage: J.reduce(y9 - y12)
2*y9 #which is fine
sage: J.reduce(y13*y15)
y13*y15 #why not
sage: J.reduce(y13*y15 + y9 - y12)
y13*y15 + y9 - y12
Now what's up with that ? shouldn't it be y13*y15 + 2*y9 ? that's what
i expect from the term 'reduction' anyway. Is this normal or is it a
bug ? if it's a bug, could it influence the equivalence x in J iff
J.reduce(x) == 0 ?
So if this is a bug i'll give you more details.
thanks!
Pierre
Martin Albrecht
reduce is defined as:
Reduce an element modulo the reduced Groebner basis for this
ideal. This returns 0 if and only if the element is in this
ideal. In any case, this reduction is unique up to monomial
orders.
See J.reduce?
> So if this is a bug i'll give you more details.
From what you've provided it is hard to tell. Could you provide a small
reproducible example? I know you said its hard to do but without it, it will
be difficult to help you.
Here are my attempts:
sage: P.<y9,y12,y13,y15> = PolynomialRing(CyclotomicField(3))
sage: J.reduce(y13 + y9 - y12)
(-2)*y12 + y13
sage: J.reduce(y13*y15 + y9 - y12)
y13*y15 + (-2)*y12
sage: J.reduce(y9 - y12)
(-2)*y12
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Pierre
bug (sorry for not trying earlier, i thought i did try and there was
no bug... must have changed a little something):
sage: k= CyclotomicField(3, "w")
sage: A= PolynomialRing(k, ["y9", "y12", "y13", "y15"])
sage: y9, y12, y13, y15= A.gens()
sage: J= [ y9 + y12]*A; J.groebner_basis()
sage: J.reduce(y9 - y12)
-2*y12
sage: J.reduce(y13*y15)
y13*y15
Which is odd. I had read J.reduce?, it seems to indicate that the
function returns what i would also call the reduction, but that is
linear. So I think this is a bug.
On Sep 16, 12:33 pm, Martin Albrecht <m...@informatik.uni-bremen.de>
wrote:
Martin Albrecht
> What did you put in J ? in fact, the following already produces the
> bug (sorry for not trying earlier, i thought i did try and there was
> no bug... must have changed a little something):
>
> sage: k= CyclotomicField(3, "w")
> sage: A= PolynomialRing(k, ["y9", "y12", "y13", "y15"])
> sage: y9, y12, y13, y15= A.gens()
> sage: J= [ y9 + y12]*A; J.groebner_basis()
> sage: J.reduce(y9 - y12)
> -2*y12
> sage: J.reduce(y13*y15)
> y13*y15
> sage: J.reduce(y13*y15 + y9 - y12)
> y13*y15 + y9 - y12
>
> Which is odd. I had read J.reduce?, it seems to indicate that the
> function returns what i would also call the reduction, but that is
> linear. So I think this is a bug.
Luckily (because we can fix it)/ unfortunately (because I'm probably to blame)
it seems like a bug in our pexpect interface to Singular.
First, this is vanilla 3.1.2.rc2:
sage: k.<w> = CyclotomicField(3)
sage: A= PolynomialRing(k, ["y9", "y12", "y13", "y15"])
sage: A.inject_variables()
sage: J= [ y9 + y12]*A
sage: J.groebner_basis()
sage: J.reduce(y13*y15 + y9 - y12)
y13*y15 + y9 - y12
This is 3.1.2.rc2 with
http://trac.sagemath.org/sage_trac/ticket/686
http://trac.sagemath.org/sage_trac/ticket/4022
http://trac.sagemath.org/sage_trac/ticket/4021
applied:
sage: k.<w> = CyclotomicField(3)
sage: A= PolynomialRing(k, ["y9", "y12", "y13", "y15"])
sage: A.inject_variables()
sage: J= [ y9 + y12]*A
sage: J.groebner_basis()
sage: J.reduce(y13*y15 + y9 - y12)
y13*y15 - 2*y12
so quite obviously we fail to tell Singular via pexpect to perform tail
reduction while in the libSingular wrapper we do tail reduction.
I'll look into it. Btw. reduction to zero should still work, since that
doesn't require tail reduction.
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Pierre
On Sep 16, 6:42 pm, Martin Albrecht <m...@informatik.uni-bremen.de>
wrote:
> applied:
>
> sage: k.<w> = CyclotomicField(3)
> sage: A= PolynomialRing(k, ["y9", "y12", "y13", "y15"])
> sage: A.inject_variables()
> sage: J= [ y9 + y12]*A
> sage: J.groebner_basis()
> sage: J.reduce(y13*y15 + y9 - y12)
> y13*y15 - 2*y12
>
> so quite obviously we fail to tell Singular via pexpect to perform tail
> reduction while in the libSingular wrapper we do tail reduction.
>
> I'll look into it. Btw. reduction to zero should still work, since that
> doesn't require tail reduction.
>
> Cheers,
> Martin
>
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _www:http://www.informatik.uni-bremen.de/~malb
Martin Albrecht
> cool, thanks a lot !
The solution to this problem is _really_ simple, if we tell Singular "don't do
tail reduction" then it won't tail reduce. Patch coming up.
Alternatively, the forementioned patches might be interesting to you since
they speed up multivariate polynomial arithmetic over absolute number fields
dramatically. All they need are reviews ... hint, hint ;-)
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Pierre
> Alternatively, the forementioned patches might be interesting to you since
> they speed up multivariate polynomial arithmetic over absolute number fields
> dramatically. All they need are reviews ... hint, hint ;-)
sage or that Mercurial thing. And believe me i would like to
contribute (or at least when i don't have to teach and... term starts
on monday). This was my one suggestion in the survey: improve the
documentation on "how to contribute", for real SVN-dummies like me.
(There was once a mercurial tutorial on the sage mirror i use, now
even this seems to be gone.) Note that i know how to program
reasonably well (C++ and Python), i'm just stuck with men's singles.
No clue about playing in a team.
If you have any pointers, they'll be welcome. In fact i'm toying with
the idea of applying for a "teaching-free year", like they grant you
every few years in France, in order to be more involved with sage.
Martin Albrecht
> > Alternatively, the forementioned patches might be interesting to you
> > since they speed up multivariate polynomial arithmetic over absolute
> > number fields dramatically. All they need are reviews ... hint, hint ;-)
>
> i know absolutely nothing about patches, reviewing, contributing to
> sage or that Mercurial thing. And believe me i would like to
> contribute (or at least when i don't have to teach and... term starts
> on monday).
Hi there,
the 'hint, hint' was more aimed at other Sage developers who bugged me for
this functionality for months :-)
> This was my one suggestion in the survey: improve the
> documentation on "how to contribute", for real SVN-dummies like me.
> (There was once a mercurial tutorial on the sage mirror i use, now
> even this seems to be gone.) Note that i know how to program
> reasonably well (C++ and Python), i'm just stuck with men's singles.
> No clue about playing in a team.
We started working on the Developer's guide again, which should eventually
address all those issues.
> If you have any pointers, they'll be welcome. In fact i'm toying with
> the idea of applying for a "teaching-free year", like they grant you
> every few years in France, in order to be more involved with sage.
You can have a look at the current stage here:
http://sage.math.washington.edu/home/mhansen/doc-sphinx/developer/.build/html/
(which is Mike Hansens copy for conversion from LaTeX to ReST/Sphinx)
We'd be very happy to hear what is unclear, missing, etc. Some parts are not
done yet (e.g. coercion) though.
Cheers,