Re: [sage-support] Re: Whats wrong with my function syntax?

[martin . vgagern]

On Thu, Apr 2, 2015 at 7:02 AM, kcrisman > 
wrote: 

> Interesting idea, though what if it was intended in something, such as a 
> plot legend? 
>
 
Perhaps we could run such substitutions at a time where strings have been 
removed from the code during preparse. The preparser works by stripping 
strings and comments, then transforming the code, then putting them back 
in. So while strings and comments can contain arbitrarily ugly stuff, the 
rest should be reasonably sane, and any of the dashes U+2010 through U+2015 
could be turned into minus, while ×, ∙ and U+2062 (invisible times, often 
used in MathML) could become times. Unless you want × as cross_product, or 
something like that…

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Re: Blank result from animate().show() in notebook

[martin . vgagern]

I'm the author of http://trac.sagemath.org/ticket/16533. The way I see it, 
in the past the animate call probably relied on the fact that the notebook 
will pick up an image generated in the current directory which is a 
temporary directory just for this single cell. So saving the image was 
enough. But apparently something changed somewhere, since now files are 
generated in a temporary file which is not in the current directory, so it 
won't get picked up any more. Graphics.show() does things differently, and 
I have code to make the same work for Animation.show(). But at the moment 
my code is mixed up with other improvements, and it seems noone is willing 
yet to review thge whole bunch at once, so I'll probably try to separate 
stuff again. Until then, a command like a.save("anim1.gif") will save to 
the current directory and therefore show the animation.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] segmentation fault computing discriminants

[martin . vgagern]

On Wednesday, March 26, 2014 1:32:13 PM UTC+1, John Cremona wrote:
>
> You should definitely open a trac ticket.

 
I just opened #16014 for this. And would make this a link to 
http://trac.sagemath.org/ticket/16014 if the Google Groups editor weren't 
too broken to let me do so…

Don't expect that if you 
> post some code as text on a ticket that someone else will magically do 
> the right thing though!  If you have not before contributed to Sage 
> you can make this your chance to learn how that works, and people will 
> help. 
>

I've submitted a couple of patches, e.g. for 
#13608and#14239,
 
and the one for #14403  which even 
got 
committed
.

But I'll take that opportunity to come to grips with the new git-based 
workflow. After pulling recent changes into my existing git checkout, I'm 
currently running “./sage --upgrade”, and hope that after that and a 
“./sage -b” I have an up-to-date snapshot of the current sage master which 
I can then use as the basis for this contribution. If I should rather start 
from a released version, and avoid updating prior to contribution, please 
tell me so and also let me know why that's preferred.
 

> I would separate out two things here: one is a generic computation of 
> discriminants of univariate polynomials of degree d, the result being 
> a polynomial in d+1 variables (the generic coefficients) over ZZ (that 
> is correct -- there's a unique map from ZZ to any other ring).  This 
> should be part of the current invariant_theory module, though when I 
> just looked at that it only appeared to implement invariants for 
> binary forms of degrees 2 and 4 (not 3) as well as some ternary stuff.
>

Uh… I had never seen that 
modulebefore.
 But the way I see it, one would have to encode the degree of the 
polynomial into the name of some identifier, which would be possible if I 
did some case distinction as you indicated, but which feels weird 
nevertheless.
 

>  As a stop-gap, a global function generic_univariate_discriminant(deg) 
> whose output is a polynomial in ZZ[a0,a1,...,ad] and which caches its 
> results would do.


Sounds more reasonable to me. Would you suggest that global to be in 
invariant_theorynevertheless,
 or rather in 
polynomial_element.pyxwhere
 it is used?
 

> Then your function should be a method for the class which is already 
> computing your discriminants, namely 
> sage.rings.polynomial.polynomial_element.Polynomial_generic_dense 
> but as there is already a discriminant function there you don't need a 
> new function, just special case code to catch small degrees (up to 3 
> or 4 at least) which gets the generic expression and substitutes 
> coefficients.

 
I wonder whether doing the case distinction on degree is really the right 
thing to do. On the one hand, if the computation already takes ages for 
degree 3, it will be even worse for higher degrees. On the other hand, this 
computation is only bad due to the fact that the determinant computation on 
big polynomials is so expensive. If the base ring were just some finite 
field or some such, then I doubt we'd have to worry. So I wonder whether it 
might make more sense to do the case distinction based on the underlying 
ring. And in that case, I'm far from sure which cases should be handled 
which way. I guess I'd start by only detecting polynomial rings, and wait 
for other use cases to report problems. I don't know the most appropriate 
way to check whether a ring is a polynomial ring. Is some form of 
isinstancecheck the right way to do this, or should I combine checks 
is_PolynomialRing and is_MPolynomialRing?

Perhaps I could also add an argument “algorithm” to the discriminant 
method. It would default to None (meaning auto-selection) but could be used 
to force either direct computation or substitution. So possible values 
might be “direct” and “substitution”, perhaps others later on as well. That 
way, users could try alternatives to work out when a given method is faster 
than a different one, and could file bug reports requesting a change of 
default for certain cases.

This would be as simple as 
>
> if f.degree()<5: 
> return generic_univariate_discriminant(f.list()) 
>
> As for the generic function, something like
>
> def generic_univariate_discriminant(d): 
>R = PolynomialRing(ZZ,d,names='a') 
>a = R.gens() 
>if d==1: return 1 
>   if d==2: return a[1]^2 - 4*a[0]*a[2] 
>
>if d==3: return a[1]**2*a[2]**2 - 4*a[0]

Re: [sage-support] segmentation fault computing discriminants

[martin . vgagern]

On Wednesday, March 26, 2014 10:34:35 AM UTC+1, John Cremona wrote:
>
> Looking at the code used, it uses the resultant formula which in turn 
> evaluates a determinant.  I agree with you that for small degrees it 
> would be better (almost certainly in a lot of cases) be better to 
> substitute into the generic formula.
>

Here is some code which does that:

def generic_discriminant(p):
"""
Compute discriminant of univariate polynomial.

The discriminant is computed in two steps. First all non-zero
coefficients of the polynomial are replaced with variables, and
the discriminant is computed using these variables. Then the
original coefficients are substituted into the result of this
computation. This should be faster in many cases, particularly
with big coefficients like complicated polynomials. In those
cases, the matrix computation on simple generators is a lot
faster, and the final substitution is cheaper than carrying all
that information along at all times.
"""
pr = p.parent()
if not pr.ngens() == 1:
raise ValueError("Must be univariate")
ex = p.exponents()
pr1 = PolynomialRing(ZZ, "x", len(ex))
pr2. = pr1[]
py = sum(v*y^e for v, e in zip(pr1.gens(), ex))
d = py.discriminant()
return d(p.coefficients()) 

Should I file a trac ticket for this? If so, should I try to determine the 
cases when to use it, or should I simply get the function in there and ask 
someone else to take care of the required connections to existing code?

What is the correct ring to choose here? I thought about using 
pr.base_ring() instead of ZZ, but that would mean that in the case of 
stacked polynomial rings, I'd be doing the computation in a more difficult 
setup than needed. It seems that sage will automatically coerce things 
correctly: if the input is a polynomial over a polynomial ring over QQ or 
GF(p), then so is the output. But I'm not sure whether that will always be 
the case, or whether there might be cases where conversion from ZZ to 
something else fails to do the right thing.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] segmentation fault computing discriminants

[martin . vgagern]

The following sage code dies on me, after computing for quite some time:

┌┐
│ Sage Version 6.1.1, Release Date: 2014-02-04   │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
sage: PR. = QQ[]
sage: PR2. = PR[]
sage: E1 = diagonal_matrix(PR, [1, b^2, -b^2])
sage: RotScale = matrix(PR, [[1, -t1, 0], [t1, 1, 0], [0, 0, 1]])
sage: E2 = diagonal_matrix(PR, [1, 1, 
1+t1^2])*RotScale.transpose()*E1*RotScale
sage: Transl = matrix(PR, [[1, 0, -x1], [0, 1, -y1], [0, 0, 1]])
sage: E3 = Transl.transpose()*E2*Transl
sage: E4 = E3.subs(t1=t2, x1=x2, y1=y2)
sage: Transl = matrix(PR, [[1, 0, 0], [0, 1, 1+b], [0, 0, 1]])
sage: E2 = Transl.transpose()*diagonal_matrix(PR, [b^2, 1, -b^2])*Transl
sage: eqs = [det(mu*Ei + Ej).discriminant() for Ei, Ej in
:[(E1, E3), (E1, E4), (E2, E3), (E3, E4)]]
Segmentation fault

Attaching a debugger, I got thousands of stack frames from within the 
python interpreter:
symtable_visit_expr from Python-2.7.6/Python/symtable.c:1191 seems to be 
calling itself till the call stack overflows.

The above is from Sage on Gentoo, but the Sage 6.1.1 official release for 
Mac segfaults as well.

I'm a bit surprised both at the segfault and at the fact that this takes so 
long. After all, I'm just computing the discriminant of a bunch of cubic 
polynomials. Wikipedia has a formula for this, and using that formula, 
things complete in no time at all. Should discriminants for polynomials of 
small degree be special-cased to avoid such issues? Or perhaps the 
discriminant should be computed first for a generic polynomial (i.e. one 
variable for every non-zero coefficient of the input), and the actual 
coefficients of the input substituted into that in a second step.

I guess I'll be using that hardcoded formula for cubic discriminants for 
now, but it would be nice if such things could work out of the box.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Polynomial division without remainder

[martin . vgagern]

Working in a stack of multivariate polynomial rings, how can I compute the 
quotient of two polynomials in those cases where I know the remainder to be 
zero?

Reading the docs I found two likely approaches, but neither seems to work 
as I'd have hoped. See below for error messages.

Example:

sage: PR1.=QQ[]
sage: PR2.=PR1[]
sage: n=(x-y)*(x+3*y)
sage: d=(x-y)
sage: n/d
(x^2 + 2*x*y + (-3)*y^2)/(x - y)
sage: PR2(n/d)
---
TypeError Traceback (most recent call last)
 in ()
> 1 PR2(n/d)

…/sage/rings/polynomial/multi_polynomial_ring.pyc in __call__(self, x, 
check)
449 return x.numerator()
450 else:
--> 451 raise TypeError, "unable to coerce since the 
denominator is not 1"
452 
453 elif is_SingularElement(x) and self._has_singular:

TypeError: unable to coerce since the denominator is not 1
sage: n.quo_rem(d)
---
TypeError Traceback (most recent call last)
 in ()
> 1 n.quo_rem(d)

…/sage/structure/element.so in 
sage.structure.element.NamedBinopMethod.__call__ 
(sage/structure/element.c:24924)()

…/sage/rings/polynomial/multi_polynomial_element.pyc in quo_rem(self, right)
   1730 return self.quo_rem(right)  # this looks like 
recursion, but, in fact, it may be that self, right are a totally new 
composite type
   1731 R = self.parent()
-> 1732 R._singular_().set_ring()
   1733 X = self._singular_().division(right._singular_())
   1734 return R(X[1][1,1]), R(X[2][1])

…/sage/rings/polynomial/polynomial_singular_interface.pyc in 
_singular_(self, singular)
213 return R
214 except (AttributeError, ValueError):
--> 215 return self._singular_init_(singular)
216 
217 def _singular_init_(self, singular=singular_default):

…/sage/rings/polynomial/polynomial_singular_interface.pyc in 
_singular_init_(self, singular)
229 """
230 if not can_convert_to_singular(self):
--> 231 raise TypeError, "no conversion of this ring to a 
Singular ring defined"
232 
233 if self.ngens()==1:

TypeError: no conversion of this ring to a Singular ring defined

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] Readonly access to ask.sagemath.org

[martin . vgagern]

On Tuesday, March 18, 2014 2:30:53 PM UTC+1, William wrote:
>
> Would you be interested in taking the full existing data and getting it to 
> work in a clean ubuntu 12.04 VM? 
> I think the main thing this would require is patience and django knowledge.
>

Sorry, I lack the django knowledge. I'm optimistic that I could reconfigure 
Apache to redirect the login page, but migrating stuff will take more time 
than I have at the moment. But it's good to know what the requirements are, 
perhaps someone else wants to help out. And I'll keep this in mind as well, 
if I ever find some spare time for this I'll let you know. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] Readonly access to ask.sagemath.org

[martin . vgagern]

On Monday, March 17, 2014 5:37:23 PM UTC+1, William wrote:
>
> Sure if somebody will volunteer to configure this!
>

Would you grant the required privileges to a person you don't know? I don't 
know what the current config looks like, but this doesn't sound too 
difficult. So if you want to (and are privileged to), you can install my 
SSH pubkey (e.g. from https://launchpad.net/~gagern/+sshkeys) and I'll have 
a look. As long as that doesn't make me responsible for unrelated requests 
as well, that is.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Readonly access to ask.sagemath.org

[martin . vgagern]

Is it possible to restore at least read-only service to ask.sagemath.org? A 
lot of questions seem to have answers there, according to the excerpts 
which pop up in Google searches, but the answers themselves are unavailable 
due to the down-time. And I fear that with time, if the site remains 
unavailable, Google might drop these hits, which would mean loosing all 
that valuable content.

So perhaps you can simply disable the login page, placing a useful notice 
there, but provide anonymous read-only access to everything else?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] sage.libs.pari.gen.PariError: ZZ_123...1[y]/(y^2 + ...) is not a field in FpX_ffintersect

[martin . vgagern]

Reported as http://trac.sagemath.org/ticket/15886

Thanks for listening.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-support] sage.libs.pari.gen.PariError: ZZ_123...1[y]/(y^2 + ...) is not a field in FpX_ffintersect

[martin . vgagern]

On Monday, March 3, 2014 5:31:18 PM UTC+1, martin@gmx.net wrote:

> Nevertheless, here is a minimal example:
>
> https://gist.githubusercontent.com/gagern/9320350/raw/d1896f7a5a05b24075098941c9c3ff156ca6c139/MinimalReprodcing6.sage
>
> It is minimal in the following sense: For the whole expression, the 
> minpoly call fails with the claimed error message. For each operand, 
> however, it succeeds. If I recreate each operand from its minimal 
> polynomial, the call succeeds as well. So it must be not only the value 
> stored in the first operand, but also the way it is encoded, represented, 
> references other things and so on. The whole thing is far from minimal in 
> terms of code length, but as I said, I can't make the expression any easier 
> and still reproduce the issue. In terms of number of commands, it should be 
> fairly close to minimal, but the command defining the expression is huge.
>

Using pdb, I've managed to look at the stack trace where the exception was 
raised, and obtain the polynomial which gets passed to pari. At 
https://gist.github.com/gagern/9320350#file-minimalreproducing8-sage I've 
used this to create yet another minimal reproducing example, 
MinimalReproducing8.sage, which is a lot shorter than my previous attempt. 
It seems that this particular polynomial cannot be handled, for some 
reason. I guess now is a good time for the bug report, even though the huge 
numbers involved still make this example longer than I'd whish for.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-support] sage.libs.pari.gen.PariError: ZZ_123...1[y]/(y^2 + ...) is not a field in FpX_ffintersect

[martin . vgagern]

On Monday, March 3, 2014 11:30:50 AM UTC+1, Jeroen Demeyer wrote:
>
> > I have no clue what that error message means, and more importantly, how 
> to avoid it. 
> The concrete problem (I guess) is that 123633238138850861 is not a prime 
> number. But now the question becomes: where does this number come from?
>

I must confess that I also don't see why a computation involving algebraic 
numbers should involve operations over some finite field. But since I know 
only little about the implementation details of algebraic numbers, I'll 
accept any statement that there is a good reason for doing this. 
Nevertheless, knowing that reason might help figuring out what goes wrong 
here.
 

> > I've pasted my code from my norebook worksheet to 
> https://gist.github.com/gagern/9320350. 
> Can you please reduce the example code you posted? If you think this is 
> a bug in Sage, try to post the minimal amount of code that will 
> reproduce the bug. 
>

I realize that reproducing this beast is pretty difficult: the first time I 
encounter one of these errors, it's this pari error about FpX_ffintersect, 
but if I execute exactly the same command a second time, I get the 
AttributeError for PolynomialTracker instead:

AttributeError: 'AlgebraicPolynomialTracker' object has no attribute '_gen'


This makes debugging the beast a lot harder, since I have to redo many 
computations for every step.

Nevertheless, here is a minimal example:
https://gist.githubusercontent.com/gagern/9320350/raw/d1896f7a5a05b24075098941c9c3ff156ca6c139/MinimalReprodcing6.sage

It is minimal in the following sense: For the whole expression, the minpoly 
call fails with the claimed error message. For each operand, however, it 
succeeds. If I recreate each operand from its minimal polynomial, the call 
succeeds as well. So it must be not only the value stored in the first 
operand, but also the way it is encoded, represented, references other 
things and so on. The whole thing is far from minimal in terms of code 
length, but as I said, I can't make the expression any easier and still 
reproduce the issue. In terms of number of commands, it should be fairly 
close to minimal, but the command defining the expression is huge.

On Monday, March 3, 2014 11:36:03 AM UTC+1, Jeroen Demeyer wrote:On 
2014-03-03 09:11, martin@gmx.net wrote: 

> I think as a general rule, you should try to avoid symbolic computations 
> for any serious work. Try to convert your problem to use a polynomial ring 
> instead.
>

I have to take square roots and even cubic roots along the way, which I 
can't do in a polynomial ring. At least not easily, not without defining a 
new field every time I need another square root. Or is there a simple way?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-support] sage.libs.pari.gen.PariError: ZZ_123...1[y]/(y^2 + ...) is not a field in FpX_ffintersect

[martin . vgagern]

I'm trying to find a formula concerned with some computation about the relative 
position of two ellipses. But some result along the way looks strange when 
evaluated with RDF numbers, and trying to plug in algebaric numbers instead, I 
encounter the following error message:

sage.libs.pari.gen.PariError: ZZ_123633238138850861[y]/(y^2 + 
114948053005503479*y + 71680486823734693) is not a field in FpX_ffintersect

I have no clue what that error message means, and more importantly, how to 
avoid it. I've pasted my code from my norebook worksheet to 
https://gist.github.com/gagern/9320350. I tried to convert all the sage console 
output style back to sage input notation, with output as comments. Hope I 
didn't miss anything.

As you can see in that file, I've encountered quite a number of places where 
the current behavior of sage surprised or even annoyed me. The question I'm 
posting about now is question 6 from the comments in that file. But if anyone 
can contribute some insight to some of the other questions as well, that would 
be highly appreciated. If not, I might end up posting more mails about these as 
well. But right now, my most immediate problem is that about how to perform a 
proper algebraic computation on these expressions.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.