[sage-support] Re: Wrong NumberField.composite_field when embeddings are complex-conjugate roots of the same polynomial

2015-04-17 Thread Peter Bruin
This is now .

> Hello,
>
>> The NumberField containing both embeddings should be larger. The
>> morphisms also clearly show that something is going wrong:
>>
>> sage: nf = NumberField(x^8 - 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 +
>> 458*x^3 + 1875*x^2 + 4293*x + 3099, 'z', embedding=-1.18126721294295 +
>> 3.02858651117832j)
>> sage: nf2 = NumberField(x^8 - 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 +
>> 458*x^3 + 1875*x^2 + 4293*x + 3099, 'z', embedding=-1.18126721294295 -
>> 3.02858651117832j)
>> sage: nf.composite_fields(nf2,both_maps = True)
>> [(Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
>> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099,
>> Ring endomorphism of Number Field in z with defining polynomial x^8 -
>> 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
>> Defn: z |--> z,
>> Ring morphism:
>> From: Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
>> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
>> To: Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
>> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
>> Defn: z |--> z,
>>  +Infinity)]
>>
>> I couldn't find a bug on trac for it. I think there should be one filed.
>
> Indeed, this looks like a bug.  It might be because the polynomials do
> not have integral coefficients.  I will open a ticket.
>
> Peter

-- 
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: Wrong NumberField.composite_field when embeddings are complex-conjugate roots of the same polynomial

2015-04-17 Thread Peter Bruin
Hello,

> The NumberField containing both embeddings should be larger. The
> morphisms also clearly show that something is going wrong:
>
> sage: nf = NumberField(x^8 - 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 +
> 458*x^3 + 1875*x^2 + 4293*x + 3099, 'z', embedding=-1.18126721294295 +
> 3.02858651117832j)
> sage: nf2 = NumberField(x^8 - 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 +
> 458*x^3 + 1875*x^2 + 4293*x + 3099, 'z', embedding=-1.18126721294295 -
> 3.02858651117832j)
> sage: nf.composite_fields(nf2,both_maps = True)
> [(Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099,
> Ring endomorphism of Number Field in z with defining polynomial x^8 -
> 3*x^7 + 61/3*x^6 - 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
> Defn: z |--> z,
> Ring morphism:
> From: Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
> To: Number Field in z with defining polynomial x^8 - 3*x^7 + 61/3*x^6 -
> 9*x^5 + 298*x^4 + 458*x^3 + 1875*x^2 + 4293*x + 3099
> Defn: z |--> z,
>  +Infinity)]
>
> I couldn't find a bug on trac for it. I think there should be one filed.

Indeed, this looks like a bug.  It might be because the polynomials do
not have integral coefficients.  I will open a ticket.

Peter

-- 
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: What is right multiplication of vector spaces by matrices?

2015-01-31 Thread Peter Bruin
Hello,

>> The bug is caused by FreeModule_generic._mul_():
>
> Cool! You got the bug. Did you opened a ticket? If you do so, please cc'me.

This is now http://trac.sagemath.org/ticket/17705

Pete

-- 
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: What is right multiplication of vector spaces by matrices?

2015-01-30 Thread Peter Bruin
Hello,

The bug is caused by FreeModule_generic._mul_():

def _mul_(self, other, switch_sides=False):
if switch_sides:
return self.span([v * other for v in self.basis()])
return self.span([other * v for v in self.basis()])

It looks like the effect of the switch_sides flag is exactly the wrong
way around.

Peter


> Indeed
>
> sage: V.subspace([x*v]) == V.subspace([v])*x
> True
>
> Sage matrices are allow indifferently on vectors from left to right.
> But of course, the action is not the same but there is no row vectors
> vs column vectors.
>
> sage: v*x
> (1, 1)
> sage: x*v
> (1, 0)
>
> Your example shows that when acting on subspaces it is actually the
> left action which is used... which is silly, I definitely agree, since
> the action on subspaces is on right.
>
> Vincent
>
> 2015-01-30 15:51 UTC+01:00, Peter Mueller :
>> After hours of debugging some program code, I found out that right
>> multiplication of a row subspace of K^n by an element x from GL(n,K) does
>> *not* do what I expected!
>>
>> sage: V = GF(2)^2
>> sage: v = V((1,0))
>> sage: x = GL(2,2)(matrix([[1,1],[0,1]]))
>> sage: V.subspace([v*x]) == V.subspace([v])*x
>> False
>>
>> It seems that right multiplication by x actually multiplies by the
>> *transpose* of x? Is there any reason for that? That is even worse than the
>>
>> completely silly and error prone notation for permutation groups, where a
>> *right action* is written from the left, so g(h(x)) isn't (g*h)(x).
>>
>> -- Peter Mueller
>>
>>
>> --
>> 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.
>>

-- 
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] Failed to compute canonical height

2014-11-26 Thread Peter Bruin
It seems to be a precision issue; the error disappears when increasing the 
precision.

>From within Sage:

sage: point.height(precision=200)
242.47010035195076100129810400142304776375572634483556206582

Or directly in PARI:

gp > \p 100
   realprecision = 115 significant digits (100 digits displayed)
gp > ellheight(F, Q)
%7 = 
242.47010035195076100129810400142304776375572634483556206582073967312482167584

Peter

-- 
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] Failed to compute canonical height

2014-11-26 Thread Peter Bruin
I reported this bug to the PARI developers.

-- 
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: Failed to compute canonical height

2014-11-26 Thread Peter Bruin
Hello,

In the latest version of sage 6.4.1 the following code failed.
> I didn't have any problem with 6.2 version of sage.
>
> [...]
>
> Sage failed to compute the canonical height. 
> any ideas?
>

This computation is actually done by PARI; this was upgraded between 
versions 6.2 and 6.4.1.  The problem seems to lie in PARI:

gp > U = 
[-245369975623514803521420211420402474815373720177518420696215292670924086780233779586506792145074717/4069861969699146045958032034788970995470603578576,
 
-696053034387689435413673877713244121475782562610666903528251447608130654196417305610237634015759861/4069861969699146045958032034788970995470603578576,
 
-49356694805693369953216822105035107974083562942605713355717183776373331122267882948881129025418396548321363993080002121985116427859996985649385099335/4069861969699146045958032034788970995470603578576,
 
5996724761485351384753083917633373954904218466995628499407992841502416127074022935350022919212488198205525833829916828282709837728834438536000230267/1017465492424786511489508008697242748867650894644,
 
-1943033527672518505867347410801184866534773028979571976479290969993491996577167508758887358085512124817167326269402804641328588524702957475568608101932310746684310251168033629279636817525659690186705/4069861969699146045958032034788970995470603578576];
gp > E = ellinit(U);
gp > P = [283188771261789732541662405743402980051199109235, 
39175522019721182331498476245534716069785193060995];
gp > ellisoncurve(E, P)
%4 = 1
? ellheight(E, P)
  ***   at top-level: ellheight(E,P)
  *** ^--
  ***   at top-level: ellheight(E,P)
  *** ^--
  *** ellheight: unknown type 64.

The same with minimal models:

gp > F = ellminimalmodel(E, &urst);
gp > Q = ellchangepoint(P, urst);
gp > ellheight(F, Q)
  ***   at top-level: ellheight(F,Q)
  *** ^--
  ***   at top-level: ellheight(F,Q)
  *** ^--
  *** ellheight: unknown type 64.

Strangely, the error is slightly different (unknown type 0 instead of 64).

Peter

-- 
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: simple 'solve' error, possibly related to ecl and maxima installation

2014-11-21 Thread Peter Bruin
Op vrijdag 21 november 2014 04:34:44 UTC+1 schreef Nils Bruin:
>
> On Thursday, November 20, 2014 7:10:15 PM UTC-8, Bozh wrote:
>>
>> Are these warnings signs that maxima is still compiling itself every time 
>> I started?
>>
> It looks like Peter correctly identified the problem. According to his 
> assessment, Maxima compiles *some code* upon startup, but not all of maxima.
>  
>
>> Since these problems seem to be unique only on my mac (and the weird 
>> non-existence of CLT in Xcode), can I assume that the problem actually lies 
>> in my OSX or Xcode?
>>
> The fact that maxima tries to compile something is not unique to your mac. 
> The fact that the compilations failed was something relatively specific to 
> your mac, but not unique to it. Peter sketched a system where it didn't 
> work either.
>
> Hopefully, Peter will patch the maxima shipped with sage so that we avoid 
> the compilation. Then probably the next sage release will not have this 
> compilation issue anymore. In the longer run, hopefully the maxima people 
> find a way around compiling some code at init-time. Then we can remove our 
> patched behaviour we're going to need in the mean time.
>
 
I opened a ticket for this and am now testing a patch: 
http://trac.sagemath.org/ticket/17375

Peter

-- 
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: simple 'solve' error, possibly related to ecl and maxima installation

2014-11-20 Thread Peter Bruin
Op donderdag 20 november 2014 21:07:55 UTC+1 schreef Nils Bruin:
>
> On Thursday, November 20, 2014 4:36:52 AM UTC-8, Peter Bruin wrote:
>>
>> It could be caused by the following lines in the Maxima source code (in 
>> src/commac.lisp):
>>
>> (defparameter trailing-zeros-regex-f-0 (compile nil 
>> (maxima-nregex::regex-compile "^(.*\\.[0-9]*[1-9])00*$")))
>> (defparameter trailing-zeros-regex-f-1 (compile nil 
>> (maxima-nregex::regex-compile "^(.*\\.0)00*$")))
>> (defparameter trailing-zeros-regex-e-0 (compile nil 
>> (maxima-nregex::regex-compile "^(.*\\.[0-9]*[1-9])00*([^0-9][+-][0-9]*)$")))
>> (defparameter trailing-zeros-regex-e-1 (compile nil 
>> (maxima-nregex::regex-compile "^(.*\\.0)00*([^0-9][+-][0-9]*)$")))
>>
>> These are executed each time Maxima starts.  The call to compile 
>> apparently invokes the C compiler.
>>
> Indeed, a feature of ECL is that compile defers to the C compiler. It is 
> of course crazy this gets compiled every initialization of maxima. I don't 
> think this happened before either.  These definitions seem to have been 
> introduced between 5.33.0 and 5.34.1.
>

Yes, I noticed this while working on http://trac.sagemath.org/ticket/16908 
but didn't realise that this essentially made a C compiler a requirement 
for running Sage...

Peter

-- 
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: simple 'solve' error, possibly related to ecl and maxima installation

2014-11-20 Thread Peter Bruin
Op dinsdag 18 november 2014 04:07:56 UTC+1 schreef Nils Bruin:
>
> On Monday, November 17, 2014 5:49:14 PM UTC-8, Bozh wrote:
>>
>> ;;; (RUN-PROGRAM "gcc" ("-I." "-I/Applications/sage/local/lib/ecl/" 
>> "-I/Users/buildslave-sage/slave/sage_git/build/local/include" 
>> "-I/Users/buildslave-sage/slave/sage_git/build/local/include" "-g" "-O2" 
>> "-fPIC" "-fno-common" "-Ddarwin" "-O2" "-c" 
>> "/private/var/folders/gh/26025ywx7w128zfds279s_9rgn/T/ecl001IqKQ2b.c" 
>> "-o" 
>> "/private/var/folders/gh/26025ywx7w128zfds279s_9rgn/T/ecl001IqKQ2b.o"))
>>
>> Condition of type: UNBOUND-VARIABLE
>>
>> The variable C::GAZONK is unbound.
>>
> You probably downloaded a binary? By the looks of it, ecl has some paths 
> hard-baked into it: 
> "-I/Users/buildslave-sage/slave/sage_git/build/local/include". That path 
> probably doesn't exist on your computer, but it was present on the mac on 
> which the binary was built.
>
> Compilation would probably fail anyway, because you probably don't have a 
> gcc that is compatible with the rest of the build (I assume we're not 
> shipping gcc with our binary).
>
> The odd thing is that maxima deems it necessary to compile itself. Your 
> binary should have a precompiled maxima available already. Something must 
> have gotten damaged or the binary distribution from which you started is 
> broken/incompatible with your OSX. First thing to try might be to try and 
> install a fresh binary if you haven't done so already.
>

It could be caused by the following lines in the Maxima source code (in 
src/commac.lisp):

(defparameter trailing-zeros-regex-f-0 (compile nil 
(maxima-nregex::regex-compile "^(.*\\.[0-9]*[1-9])00*$")))
(defparameter trailing-zeros-regex-f-1 (compile nil 
(maxima-nregex::regex-compile "^(.*\\.0)00*$")))
(defparameter trailing-zeros-regex-e-0 (compile nil 
(maxima-nregex::regex-compile "^(.*\\.[0-9]*[1-9])00*([^0-9][+-][0-9]*)$")))
(defparameter trailing-zeros-regex-e-1 (compile nil 
(maxima-nregex::regex-compile "^(.*\\.0)00*([^0-9][+-][0-9]*)$")))

These are executed each time Maxima starts.  The call to compile apparently 
invokes the C compiler.  On a system I use, the /tmp directory is a tmpfs 
file system mounted with the noexec flag, and unless I set TMPDIR to 
something else than /tmp, the above lines cause the following error when 
starting Maxima:

;;; Loading #P"/home/bruinpj/src/sage/local/lib/ecl/cmp.fas"
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Internal error:
;;;   ** LOAD: Could not load file #P"/tmp/ecl001kpMN0E.fas" (Error: 
"/tmp/ecl001kpMN0E.fas: failed to map segment from shared object: Operation 
not permitted")
Condition of type: UNBOUND-VARIABLE
The variable C::GAZONK is unbound.

Peter

-- 
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: Bug in symbolic integral

2014-11-14 Thread Peter Bruin
Hello,

This appears to be a bug in the evaluation of the incomplete Gamma function 
in the older PARI version(s) used by Sage up to and including 6.3.  The 
computation is correct in the newly released Sage 6.4, which uses the 
recent stable PARI release 2.7.1.

(See also http://trac.sagemath.org/ticket/17328 for a PARI example showing 
very different incomplete Gamma function outputs in the two different PARI 
versions.)

Peter


Op woensdag 12 november 2014 22:14:29 UTC+1 schreef kcrisman:
>
> Hmm, I can't reproduce this problem. I am working w/ Maxima 5.34.1. 
>>
>>   (%i1) display2d : false $ 
>>   (%i2) foo : 1/log(x)^2 $ 
>>   (%i3) integrate (foo, x, 2, 3); 
>>   (%o3) gamma_incomplete(-1,-log(3))-gamma_incomplete(-1,-log(2)) 
>>   (%i4) %, numer; 
>>   (%o4) 1.273097216447114 
>>   (%i5) integrate (foo, x); 
>>   (%o5) gamma_incomplete(-1,-log(x)) 
>>   (%i6) ev (%, x=3) - ev (%, x=2); 
>>   (%o6) gamma_incomplete(-1,-log(3))-gamma_incomplete(-1,-log(2)) 
>>   (%i7) %, numer; 
>>   (%o7) 1.273097216447114 
>>
>
>
>  
>
>>   
>> Looks like Maxima handles the definite and indefinite integrals as 
>> expected. Or perhaps I have misunderstood the problem? 
>>
>>
> Nope, you've just confirmed that the way Sage handles incomplete gamma 
> evaluation is broken somehow.  I've opened 
> http://trac.sagemath.org/ticket/17328 for this.
>
>  
>

-- 
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: simplifying an expression involving complex domain

2014-10-03 Thread Peter Bruin
Hello,

> Somebody just complained about this on gitter 
>> > (https://gitter.im/sagemath/cloud): 
>> > 
>> > The simplify command is completely ignoring that the variable is 
>> > supposed to be complex: 
>> > ``` 
>> > t = var('t', domain='complex') 
>> > (conjugate(t)*t).simplify() 
>> > ``` 
>> > outputs `t^2`. This seems like a bug. 
>>
>> sage: t = var('t', domain='complex') 
>> sage: maxima(conjugate(t)), maxima(t) 
>>
>> outputs (_SAGE_VAR_t, _SAGE_VAR_t) 
>>
>> so basically conjugate(t) gets converted all wrong to maxima, or at 
>> least that t is complex is instantly forgotten.  Hmm. 
>>
>>
> This must be longstanding, because in Sage 4.4.4,
>
> sage:  t = var('t', domain='complex') 
> sage: maxima(conjugate(t)), maxima(t) 
> (t, t)
>
> Assuredly we aren't converting it properly. 
>

Maxima has to be told that t is complex:

Maxima 5.34.1 http://maxima.sourceforge.net
using Lisp ECL 12.12.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) display2d: false$ domain: complex$
(%i3) conjugate(x);
(%o3) x
(%i4) declare(x, complex)$
(%i5) conjugate(x);
(%o5) conjugate(x)

We should make sure that "declare(_SAGE_VAR_t, complex)" is called when the 
Sage variable t is first seen by Maxima.

Peter

-- 
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: var() definition in finite fields

2014-09-30 Thread Peter Bruin
Hello,

I want to do some symbolic operations (matrix/vector) in the GF(2).
>

Here is an alternative approach (assuming all your expressions are 
polynomials in m1, m2, m3 and m4):

sage: R. = PolynomialRing(GF(2))
sage: q = Matrix(R, [[m1, m2], [m3, m4]])
sage: q
[m1 m2]
[m3 m4]
sage: q*q
[ m1^2 + m2*m3 m1*m2 + m2*m4]
[m1*m3 + m3*m4  m2*m3 + m4^2]

Note that the coefficients are elements of R = GF(2)[m1, m2, m3, m4], not 
of GF(2); cf. the other answers where they are in SR.

Peter

-- 
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: apparent numerical integration bug in sage

2014-08-29 Thread Peter Bruin
Hello Robert,

Hmm, what method does PARI/GP use? The documentation for intnum 
> doesn't seem to mention any algorithms. ... I just looked at the 
> source code (intnum.c) and I can't tell what's going on. There is 
> some code for Romberg's method (intnumromb) but it's not called from 
> intnum


>From the PARI user's manual, chapter 3: "Starting with version 2.2.9 the 
``double exponential'' univariate integration method is implemented in 
intnum and its variants. Romberg integration is still available under the 
name intnumromb, but superseded."

Peter

-- 
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: Question About Finite Field propertie in polynomial ring

2014-08-29 Thread Peter Bruin
Hello,

Let be the field
> q = 2
> K. = GF(q^n)
> and the Polynomial Ring
> PR = PolynomialRing(K,"X")
> Let be a random monomial of PR for example
> P = t*X^(q^a).
> Is there any method in sage to reduce X degree of polynomial P, such that 
> equivalent polynomial is t*X^(q^b) where b = mod(P.degree(X)-1,n)
>

Does the following do what you want?

sage: n = 5; q = 2^n
sage: K. = FiniteField(q)
sage: PR. = PolynomialRing(K)
sage: Q. = PR.quotient(X^q - X)
sage: t*Xbar^(2*q)
t*Xbar^2

Peter

-- 
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: PARI Group Notation

2014-08-15 Thread Peter Bruin
Hi Steve,

The documentation of PARI's group labelling/naming conventions is here 
(there are an "old" and a "new" convention, and Sage uses the new one):

http://pari.math.u-bordeaux.fr/dochtml/html.stable/Functions_related_to_general_number_fields.html#polgalois

I don't see 2^n S_n mentioned here; I guess that is taken from the string 
returned as the last component by polgalois(), and the documentation agrees 
with Dima that this is the name of the group in GAP.

Peter


Op vrijdag 15 augustus 2014 06:35:22 UTC+1 schreef s meagher:
>
> Apologies if this is answered elsewhere in this group or in the 
> documentation, but I have not found the answer.
>
> When computing a galois group in sage using type='pari' Sage gives the 
> group a name.  I have not been able to find a guide for the nomenclature 
> used.
>
> For example, names like S_3 and D(4) are fairly clear.  But what is 2^3 
> S_3 and 2^4 S_4 - I presume they are the wreath products (\Z/2)^n . S_n.  
>
> Is there a reference?  And am I right about 2^n S_n
>
> Thanks
>
> Steve
>

-- 
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: Quotient ring over Finite Field 2^n

2014-08-12 Thread Peter Bruin
Hello,

It seems like quotient_ring doesn't have '__call__'. Does it a bug or a 
> feature?
>
> sage: K = GF(2^8,'a')
> sage: P = PolynomialRing(K,'x')
> sage: Q = P.quotient_ring(P("x^256+x"),'y')
> sage: f = Q.random_element()
> sage: f.subs(y=K.random_element()) # random
> (a^7 + a^6 + a^3 + a)*y^255 + (a^7 + a^4)*y^254 ...
> sage: Q
> Univariate Quotient Polynomial Ring in y over Finite Field in a of size 2^
> 8 with modulus x^256 + x
>
> I expect that the output will be in K. 
>

It would in principle not be hard to implement the functionality you are 
asking for, but I would recommend a solution like the following:

sage: K = GF(2^8, 'a')
sage: P. = PolynomialRing(K)
sage: Q. = P.quotient_ring(x^256 - x)
sage: a = K.random_element()
sage: ev_a = Q.hom([a])  # homomorphism "evaluation in a": Q -> K
sage: f = Q.random_element()
sage: b = ev_a(f)
sage: b  # random
a^7 + a^5 + a^3 + a^2 + a + 1
sage: b.parent() is K
True

In this way, the fact that ev_a is well-defined is checked during its 
construction, so it doesn't have to be checked when doing the actual 
evaluation.

Peter

-- 
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: Overflow creating finite field element

2014-08-12 Thread Peter Bruin
Hello,

I seem to have run across a potential bug on Sage:
>
> p = previous_prime(2^64)
>> F. = GF(p^2)
>> x * 2**63
>>
>>
> throws a "overflow in t_INT-->long assignment" exception creating the 
> element x * 2**63.
>

This is indeed a bug.  Sage calls the wrong PARI function for this 
conversion: it should convert to a 64-bit *unsigned* integer, but instead 
asks for a 64-bit *signed* integer, hence the overflow.  I opened a bug 
report at http://trac.sagemath.org/ticket/16807; a fix is coming soon.

Peter

-- 
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: ECL says: In function GCD, the value of the second argument is not of the expected type INTEGER

2014-06-03 Thread Peter Bruin
Hello,

This kind of problem has been reported before; see 
.

You could try the workaround

sage: sage.calculus.calculus.maxima('keepfloat: false')

although this seems to be very slow (but maybe you expect it to be).

Peter

 

> Hi,
> I'm having problem with the code below,
>
> var('x t'); k=1.38*(10**-23) ; e1=0 ; e2 =170*k ; na=6.02*(10**23)
> a=0.1 
> assume(x>a)
> u=1
> n=1 + floor(u)
>
> def DaRL(y,u): 
> return (1/gamma(n-u))*diff(integral(y/((x-t)**(u-n+1)),t,a,x),x,n)
>
> z=exp(-e1/(k*t)) + 3*exp(-e2/(k*t))
> f=-t*k*log(z)  
> s=-diff(f,t)
>
> somat=sum( (((t-a)**k)/factorial(k))*((derivative(s,t,k)).limit(t=a)) for 
> k in [0..(u-1)]) 
>
> Dcaputo=DaRL((s-somat),u) ; Dcaputo
>
> Which, in this case, is the same as
>
> var('x t'); k=1.38*(10**-23) ; e1=0 ; e2 =170*k ; na=6.02*(10**23)
>
> z=exp(-e1/(k*t)) + 3*exp(-e2/(k*t))
> f=-t*k*log(z)  
> s=-diff(f,t)
>
> Dcaputo=Diff(s,t) ; Dcaputo , changing the variable 't' to 'x'. If we put 
> s=sin(t);cos(t); t; 1; or any function with a known derivative it works.
>
> But it's not working the way it should and I don't understand. When I ask 
> Sage to do the code, Sage gives me this
>
> Traceback (most recent call last):def DaRL(y,u):
>   File "", line 1, in 
> 
>   File "/tmp/tmpQtIbpd/___code___.py", line 18, in 
> exec compile(u'Dcaputo=DaRL((s-somat),u) ; Dcaputo
>   File "", line 1, in 
> 
>   File "/tmp/tmpQtIbpd/___code___.py", line 10, in DaRL
> return (_sage_const_1 
> /gamma(n-u))*diff(integral(y/((x-t)**(u-n+_sage_const_1 )),t,a,x),x,n)
>   File 
> "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/misc/functional.py",
>  line 740, in integral
> return x.integral(*args, **kwds)
>   File "expression.pyx", line 9302, in 
> sage.symbolic.expression.Expression.integral 
> (sage/symbolic/expression.cpp:38413)
>   File 
> "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py",
>  line 688, in integrate
> return definite_integral(expression, v, a, b)
>   File "function.pyx", line 429, in sage.symbolic.function.Function.__call__ 
> (sage/symbolic/function.cpp:5064)
>   File 
> "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py",
>  line 173, in _eval_
> return integrator(*args)
>   File 
> "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/external.py",
>  line 21, in maxima_integrator
> result = maxima.sr_integral(expression, v, a, b)
>   File 
> "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py",
>  line 746, in sr_integral
> raise error
> RuntimeError: ECL says: In function GCD, the value of the second argument is
>   1.0
> which is not of the expected type INTEGER
>
> I don't know what this means. Can anyone give me a clue?
>
> Thanks.
>
>

-- 
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: incomplete gamma function: evaluation and taylor series

2014-05-03 Thread Peter Bruin
Correction: it is not exactly the same bug, but the two are certainly 
related.

-- 
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: incomplete gamma function: evaluation and taylor series

2014-05-03 Thread Peter Bruin
This is in fact a long-standing bug, reported here:

http://trac.sagemath.org/ticket/7099  (serious incomplete gamma function 
precision bugs)

-- 
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: incomplete gamma function: evaluation and taylor series

2014-05-03 Thread Peter Bruin
Hello,

> However, I seem to be having trouble with the incomplete gamma function. 
> > Here are two difficulties. First, in trying to evaluate the incomplete 
> > gamma function at a point where the result should be very small, I just 
> get 
> > zero even if I increase the precision arbitrarily. In particular 
> consider 
> > 
> > numerical_approx(gamma(9, 10^(-3))-gamma(9), digits=40) 
> > 
> > the value of this number is approximate -1.1 \times 10^(-28), but I just 
> > get 0.0 ...0 for the input above. 
>
> I think this is a bug in the Sage's interface to PARI's incomplete 
> gamma-function implementation. 
> The latter has a parameter 'precision' that actually allows you do 
> increase the precision of the computation here as much as you like.
>
 
>From looking at the source code, I suspect that the problem is in 
sage.functions.other.Function_gamma_inc, where the method _evalf_() does 
not use its argument "parent" (and hence does not know about the precision 
of that parent).

If you don't want to use PARI explicitly, you can also avoid the bug by 
typing

sage: C = ComplexField(400)
sage: C(9).gamma_inc(1/1000) - gamma(9)
-1.11011156551770881154239109830530085698810642670976295680548580836149189576782725366794514487711609262987622059881687164e-28

Peter

-- 
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] Re: How to define a homomorphism between two algebras

2014-04-26 Thread Peter Bruin
Hello,

In the future (hopefully soon; it is being worked on as I write this, see 
http://trac.sagemath.org/ticket/14990) Sage will have algebraic closures of 
finite fields; once we have those, you can use the subfield of the 
appropriate degree inside the algebraic closure instead of creating fields 
with the extension() method.

That aside, I agree with John that you can probably avoid some problems by 
first creating F_{p^12} and then constructing the other fields inside that.

Peter


Op vrijdag 25 april 2014 09:35:05 UTC+1 schreef John Cremona:
>
> On 25 April 2014 08:26, Irene > wrote: 
> > Yes, this is the example: 
> > 
> > p=371 
> > Fpr=GF(pow(p,2),'b') 
> > b=Fpr.gen() 
> > FFpr.=PolynomialRing(Fpr) 
> > EP= x^6 + (973912*b + 2535329)*x^5 + (416282*b + 3608920)*x^4 + 
> (686636*b + 
> > 908282)*x^3 + (2100014*b + 2063451)*x^2 + (2563113*b + 751714)*x + 
> 2687623*b 
> > + 1658379 
> > A1.=Fpr.extension(EP) 
> > Qx=x^6 + (1028017*b + 514009)*x^5 + 2*x^4 + (1028017*b + 514008)*x^3 + 
> 2*x^2 
> > + (1028017*b + 514009)*x + 1 
> > 
> > A2.=Fpr.extension(Qx) 
> > alpha=(1636197*b + 1129870)*z^5 + (1120295*b + 3059639)*z^4 + (2637744*b 
> + 
> > 3273090)*z^3 + (3564174*b + 890965)*z^2 + (3503957*b + 2631102)*z + 
> > 3343290*b + 146187 
> > f=A1.hom([alpha],A2) 
>
> This fails because Qx(alpha) is not 0.  You need to map theta to a 
> root of Qx in A2.  UNfortunately simple things like 
>
> sage: Qx.roots(A1, multiplicities=False) 
>
> sage: Qx.change_ring(A1).factor() 
>
> fail with a not-implemented error.  I think this is because A1 and A2 
> have not been constructed as fields, though both A1.is_field() and 
> A2.is_field() return True.  It might work to construct GF(p^12) 
> separately and define isomorphims from both A1 and A2 to it. 
>
> Unfortunately you are discovering that the ability of Sage to work 
> with relative extensions of finite fields is not as good as it should 
> be.  There has been fairly recent work on this, and maybe Peter Bruin 
> knows what stage that has reached. 
>
> John 
>
> > 
> > On Thursday, April 24, 2014 11:33:52 PM UTC+2, Peter Bruin wrote: 
> >> 
> >> Can you post a complete example?  The following (simple) example works 
> for 
> >> me (at least in 6.2.beta8): 
> >> 
> >> sage: F=GF(5).extension(2) 
> >> sage: A1.=F.extension(x^2+3) 
> >> sage: A2.=F.extension(x^2+3) 
> >> sage: A1.hom([z],A2) 
> >> Ring morphism: 
> >>   From: Univariate Quotient Polynomial Ring in y over Finite Field in a 
> of 
> >> size 5^2 with modulus y^2 + 3 
> >>   To:   Univariate Quotient Polynomial Ring in z over Finite Field in a 
> of 
> >> size 5^2 with modulus z^2 + 3 
> >>   Defn: y |--> z 
> >> 
> >> Peter 
> >> 
> >> 
> >> Op donderdag 24 april 2014 16:55:34 UTC+1 schreef Irene: 
> >>> 
> >>> I have defined two extensions A1 and A2 over a finite field Fp2 with 
> >>> generator b, 
> >>> 
> >>> A1.=Fp2.extension(Ep) 
> >>> A2.=Fp2.extension(Q) 
> >>> 
> >>> being Ep and Q polynomials. 
> >>> 
> >>> Now I want to define a homomorphism between those algebras. I have 
> >>> already computed alpha, that is the element in A2 where theta is 
> mapped, but 
> >>> Sage doesn't allow me to define it as: 
> >>> 
> >>> A1.hom([alpha], A2) 
> >>> 
> >>> Do you know how to do it? 
> >>> 
> >>> Irene 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To post to this group, send email to 
> > sage-s...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/sage-support. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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] Re: Computational geometry in the plane: in Sage?

2014-04-24 Thread Peter Bruin
A certain amount of work on adding functionality for hyperbolic geometry to 
Sage has been done in recent years, see here:

http://trac.sagemath.org/ticket/9439

There seem to be several different implementations by different authors; I 
am not sure about the status of all this work and how much of it is 
relevant to what you want to do.

Peter


Op donderdag 24 april 2014 18:54:32 UTC+1 schreef Ed Scheinerman:
>
> Glad to see this has gained some traction. Here is an illustration of the 
> immediate issue for which this would have been helpful. I wanted to produce 
> an illustration explaining lines in the hyperbolic plane using the Poincare 
> disk model. It's the arc of a circle whose end points are on a given circle 
> and the arc meets the given circle at right angles. (That's a lot to say 
> but a picture makes it so much easier.) 
>
> It took me a long time and a good deal of coding in Sage to get this how I 
> wanted. My "gut" tells me there's go to be a better way!
>
>
> On Thu, Apr 24, 2014 at 9:31 AM, Volker Braun 
> > wrote:
>
>> We do have convex hull and lines. What would be lacking for your 
>> application are discs and their intersection with polyhedra.
>>
>> sage: line = Polyhedron(vertices=[(0,-1)], lines=[(1,1)])
>> sage: (triangle & line).vertices()
>> (A vertex at (8/5, 3/5), A vertex at (3/2, 1/2))
>>
>>
>> On Thursday, April 24, 2014 7:02:21 AM UTC+1, Dominique Laurain wrote:
>>>
>>> I need same packages that Ed asked for.
>>> Nowadays I do geometry coding myself basic functions in SAGE worksheets 
>>> (to do intersection of lines etc).
>>> I do this using the "Rational Trigonometry philosophy" :-)..see 
>>> njwilderger youtube videos and book.
>>> Previously I played a little with Tex tools (pst-tricks and 
>>> pst-eucl)..check about pstricks too...at that time and until now, I
>>> was interested with tilings.
>>> In SAGE we have the basics tools (vectors,matplotlib...) but I feel 
>>> there are not the "intermediate" tools : convex hull, rules and compass 
>>> constructions, origami tools and so on.
>>> I can code some (for example, convex hull: I know an algorithm "paquet 
>>> cadeau" ...but everytime I feel to reinvent wheel.
>>> What is not enough with Tex is that all is static : for example, you 
>>> cannot have the generic solution of two lines AB and CD where A,B,C,D are 
>>> 2D points with variables coordinates...because it is no more static 
>>> geometry but symbolic computations (solving equations / inequations).
>>>

  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-support" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-support/Y0t4ShFLXJ4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> sage-support...@googlegroups.com .
>> To post to this group, send email to sage-s...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sage-support.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Ed Scheinerman (e...@scheinerman.net ) 
>

-- 
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: How to define a homomorphism between two algebras

2014-04-24 Thread Peter Bruin
Can you post a complete example?  The following (simple) example works for 
me (at least in 6.2.beta8):

sage: F=GF(5).extension(2)
sage: A1.=F.extension(x^2+3)
sage: A2.=F.extension(x^2+3)
sage: A1.hom([z],A2)
Ring morphism:
  From: Univariate Quotient Polynomial Ring in y over Finite Field in a of 
size 5^2 with modulus y^2 + 3
  To:   Univariate Quotient Polynomial Ring in z over Finite Field in a of 
size 5^2 with modulus z^2 + 3
  Defn: y |--> z

Peter


Op donderdag 24 april 2014 16:55:34 UTC+1 schreef Irene:
>
> I have defined two extensions A1 and A2 over a finite field Fp2 with 
> generator b,
>
> A1.=Fp2.extension(Ep)
> A2.=Fp2.extension(Q)
>
> being Ep and Q polynomials.
>
> Now I want to define a homomorphism between those algebras. I have already 
> computed alpha, that is the element in A2 where theta is mapped, but Sage 
> doesn't allow me to define it as:
>
> A1.hom([alpha], A2)
>
> Do you know how to do it?
>
> Irene
>

-- 
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] Change the field where a polynomial is considered

2014-04-17 Thread Peter Bruin
This works for me in Sage 5.13 (I don't have an older version installed), 
after replacing the definition of FFps by

FFps.=PolynomialRing(Fps)  # the . was missing

However, without the . the error I got was different from yours 
(TypeError: You must specify the names of the variables.)


Op donderdag 17 april 2014 17:05:20 UTC+1 schreef Irene:
>
> p=371
> Fp=GF(p)
> E=EllipticCurve([Fp(3),Fp(5)])
> j=E.j_invariant()
> l=13#Atkin prime
> n=((l-1)/2).round()
> r=2# Phi_13 factorize in factors of degree 2
> s=12#Psi_13 factorize in factors of degree 12
>
> #repsq(a,n) computes a^n
> def repsq(a,n):
> B = Integer(n).binary()
> C=list(B)
> k=len(B)-1
> bk=a
> i=1
> while i <= k:
> if C[i]=="1":
> bk=(bk^2)*a
> else:
> bk=bk^2
> i=i+1
> return bk
>
> d=E.division_polynomial(13)
> Fps=GF(repsq(p,s),'a')
> a=Fps.gen()
> Fpr=GF(repsq(p,r),'b')
> b=Fpr.gen()
> FFps=PolynomialRing(Fps)
> Fl=GF(l)
> c=GF(2)
> rts=d.roots(Fps,multiplicities=False)
> Px=rts[0]
> Py2=Px^3+3*Px+5
> c=Fl.multiplicative_generator()
>
> def produx(n,Qx):
> if is_odd(n):
> 
> pro=Qx-(E.division_polynomial(n-1,(Qx,1),two_torsion_multiplicity=1)*E.division_polynomial(n+1,(Qx,1),two_torsion_multiplicity=1)*
>  
> (Qx^3+3*Qx+5))/((E.division_polynomial(n,(Qx,1),two_torsion_multiplicity=1)^2))
> else:
> 
> pro=Qx-(E.division_polynomial(n-1,(Qx,1),two_torsion_multiplicity=1)*E.division_polynomial(n+1,(Qx,1),two_torsion_multiplicity=1))/((Qx^3+3*Qx+5)*E.division_polynomial(n,(Qx,1),two_torsion_multiplicity=1)^2)
> return pro
>
>
> Ep=(X-produx(2,Px))*(X-produx(4,Px))*(X-produx(8,Px))*(X-produx(3,Px))*(X-produx(6,Px))*(X-produx(12,Px))
>
> bb=b.minpoly().roots(Fps)[0][0]
> i=Fpr.hom([bb],Fps)
> j=i.section()
> PolynomialRing(Fpr,'x')([j(c) for c in Ep.coeffs()]) 
>
> That was the code, and the version is 5.11. Maybe the problem is because 
> the version is too old, but I was using another version and I got many 
> problems and right now I don't have another option.
>
> On Thursday, April 17, 2014 5:47:32 PM UTC+2, John Cremona wrote:
>>
>> On 17 April 2014 08:43, Irene  wrote: 
>> > I think that this is exactly what I need. Nevertheless I cannot use 
>> neither 
>> > i.section() nor i.inverse_image(). The second one because of the same 
>> reason 
>> > as you, and the first one when I try it is says "TypeError: 'NoneType' 
>> > object is not callable". 
>>
>> You'll have to post your actual code (and say which Sage version) for 
>> us to help debug that! 
>>
>> John 
>>
>> > 
>> > 
>> > On Thursday, April 17, 2014 12:07:18 PM UTC+2, John Cremona wrote: 
>> >> 
>> >> OK, that makes sense now.  It boils down to this: given an element of 
>> >> F12=GF(p^12) which happens to lie in F2 = GF(p^2), how to express it 
>> >> in terms of a generator of F2.  This is not quite as easy as it should 
>> >> be but this works (assuming that you have defined F12 with generator a 
>> >> and F2 with generator b): 
>> >> 
>> >> sage: bb = b.minpoly().roots(F12)[0][0] 
>> >> sage: i = F2.hom([bb],F12) 
>> >> sage: j = i.section() 
>> >> 
>> >> Here we have defined an embedding i of F2 into F12 by find a place to 
>> >> map b (called bb) and set j to be an inverse to i.  (I think we should 
>> >> be use i.inverse_image() but that gave me a NotImplementedError, which 
>> >> is a pity since I have used sort of construction easily in extensions 
>> >> of number fields). 
>> >> 
>> >> Now if f is your polynomial in F12[x] whose coefficients lie in F2 you 
>> can 
>> >> say 
>> >> 
>> >> sage: PolynomialRing(F2,'X')([j(c) for c in f.coeffs()]) 
>> >> 
>> >> to get what you want, I hope! 
>> >> 
>> >> John 
>> >> 
>> >> On 17 April 2014 02:52, Irene  wrote: 
>> >> > Sorry, I didn't write it correctly. I meant GF(p^12,'a') instead of 
>> >> > GF(p^13,'a'). As 2 divides 12, GF(p^12,'a') is an extension of 
>> >> > GF(p^2,'b'). 
>> >> > My question is the same now with the correct data. 
>> >> > 
>> >> > On Thursday, April 17, 2014 11:04:40 AM UTC+2, John Cremona wrote: 
>> >> >> 
>> >> >> On 17 April 2014 01:55, Irene  wrote: 
>> >> >> > Hello! 
>> >> >> > 
>> >> >> > I want to define a polynomial that I know lies in GF(p^2,'b')[x], 
>> >> >> > p=371. 
>> >> >> > The problem is that I have to define it as a product 
>> >> >> > E=(X-a_1)*(X-a_2)*(X-a_3)*(X-a_4)*(X-a_5)*(X-a_6), where every 
>> a_j is 
>> >> >> > in 
>> >> >> > GF(p^13,'a')[X]. 
>> >> >> > I tried to do GF(p^2,'b')[x](E), but then Sage just changes the 
>> >> >> > generator 
>> >> >> > 'a' and writes the same expression with the generator 'b'. 
>> >> >> > Any idea about how to do this? 
>> >> >> > Thank you!! 
>> >> >> 
>> >> >> Did you write that correctly?  GF(p^13) is not an extension of 
>> >> >> GF(p^2).  If a1 is in GF(p^13) then a1.minpoly() will give its min 
>> >> >> poly, in GF(p)[x]. 
>> >> >> 
>> >> >> John Cremona 
>> >> >> 
>> >> >> > 
>> >> >> > -- 
>> >> >> > You received this message be

[sage-support] Re: Change the field where a polynomial is considered

2014-04-17 Thread Peter Bruin
Hello,

I want to define a polynomial that I know lies in GF(p^2,'b')[x], 
> p=371. The problem is that I have to define it as a product 
> E=(X-a_1)*(X-a_2)*(X-a_3)*(X-a_4)*(X-a_5)*(X-a_6), where every a_j is in 
> GF(p^13,'a')[X].
> I tried to do GF(p^2,'b')[x](E), but then Sage just changes the generator 
> 'a' and writes the same expression with the generator 'b'.
> Any idea about how to do this?
>

There is a mathematical difficulty behind this: although the field of p^2 
elements is a subfield of the field of p^12 elements, it is not a subfield 
in a canonical way.  If you want automatic conversion between the two 
fields, you have to make sure that Sage recognises GF(p^2) as being a 
subfield of GF(p^12) in some well-defined way.  This can be done using 
Conway polynomials as defining polynomials for the two finite fields.  If 
(in Sage 5.13 or newer) you create the finite fields with

  sage: K = GF(p^2, 'a', conway=True, prefix='z')
  sage: L = GF(p^12, 'b', conway=True, prefix='z')

then it should be possible to automatically map field elements back and 
forth between the two fields.

  sage: R = K['x']
  sage: S = L['x']
  sage: x = S.gen()
  sage: f = (x - b) * (x - b^9); f
  x^2 + (2*b^3 + 2*b^2)*x + 2*b^3 + 2*b^2 + 1
  sage: R(f)
  x^2 + (a + 2)*x + a
  sage: S(R(f)) == f
  True

There was actually another bug (involving polynomial rings) that caused 
this not to work; it was fixed only 6 weeks ago, so you may have to wait 
for Sage 6.2 or to download the latest development version.  I just saw 
that John Cremona gave another solution, which does not rely on Conway 
polynomials and automatic conversion, so this may be easier to use 
(although you have to explicitly invoke the maps i and j).

Peter

-- 
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: Writing a particular Elliptic Curve

2014-04-10 Thread Peter Bruin
Dear Bhavin,

Thank you very much for your answer. It helps but still I do not know how 
> to see the answer to my exact problem.
> My exact problem is the see the graph of y^2=x(x+1)(2*x+1)/6. 
>

If you have constructed an elliptic curve (after scaling the variables), 
say E, then you can do

sage: E.plot()

Otherwise, you can try something like

sage: R.=RR[]
sage: f=y^2-x*(x+1)*(2*x+1)/6
sage: C=Curve(f)
sage: C.plot()

Peter

-- 
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: Writing a particular Elliptic Curve

2014-04-10 Thread Peter Bruin
Hello,

Sage only supports equations where the coefficients of y^2 and x^3 are 1; 
you first need to multiply the equation by A^2 and then put A*y = Y and A*x 
= X, so the equation becomes

Y^2 = X^3 + B*X^2 + A*C*X + A^2*D

You can construct this (assuming A, B, C, D are set to suitable values) 
using

sage: E = EllipticCurve([0, B, 0, A*C, A^2*D])

I hope this answers your question.

Peter


Op donderdag 10 april 2014 07:25:15 UTC+1 schreef Bhavin Moriya:
>
> How do I write the following elliptic curve in SAGE,
>
> y^2 = A*x^3 + B*x^2 + C*x + D?
>

-- 
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: Some GIT help

2014-04-10 Thread Peter Bruin
Hello,

I'm also a git beginner, so the experts should correct me if there is a 
better way, but what I normally do in such situations is

$ git stash
$ git pull git://trac.sagemath.org/sage.git develop
$ git stash pop

Since you say your change is just one line, this is probably the 
least-effort solution.  For larger changes (e.g. working on Trac tickets), 
it would probably be better to create a new branch forking off the 
development branch:

$ git checkout -b mybranch develop
... make changes and commit them in your branch ...

When you want to update to the last development branch,

$ git checkout develop
$ git pull git://trac.sagemath.org/sage.git develop

To go back to your branch,

$ git checkout mybranch

and then, if your branch starts to conflict with develop, resolve the 
conflicts using

$ git merge develop

Peter


Op donderdag 10 april 2014 14:02:05 UTC+1 schreef KnS:
>
> I am now trying to update SAGE to its newest development version via GIT:
>
> Apples-MacBook-Pro:sage apple$ git pull 
> git://trac.sagemath.org/sage.gitdevelop
>
> remote: Counting objects: 14241, done.
>
> remote: Compressing objects: 100% (5832/5832), done.
>
> remote: Total 12263 (delta 10270), reused 8154 (delta 6337)
>
> Receiving objects: 100% (12263/12263), 3.06 MiB | 7.00 KiB/s, done.
>
> Resolving deltas: 100% (10270/10270), completed with 1102 local objects.
>
> From git://trac.sagemath.org/sage
>
>  * branchdevelop-> FETCH_HEAD
>
> Updating 8be52e6..37c8a8c
>
> error: Your local changes to the following files would be overwritten by 
> merge:
>
> build/pkgs/singular/spkg-install
>
> Please, commit your changes or stash them before you can merge.
>
> Aborting
>
> So, the problem is that I have a line commented out from that file to get 
> 6.1.1 to build. So, how do I proceed now? Do I commit this change to my 
> local repository or not? Also, in any case, I would like to have the 
> changes I made to GAP packages folder remain on my local repository. 
>
> Something in me tells that I should ideally be creating a new branch or 
> sth. Being a  newbie that I am, I would be glad if somebody told me what is 
> the best way forward. 
>
> With Sincere Regards, 
> Kannappan. 
>

-- 
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: int() on real numbers broken?

2014-03-24 Thread Peter Bruin
Hello,

> I am working on a Z80 project and I needed 72 bits of precision for 64
> elements of the form log2(1+2^-i) (so log2(3/2), log2(5/4),...). I
> needed to convert these to hexadecimal, and it worked until I tried
> the following for i=56:
> int(256*log(1+2^-56,2))
>
> This returns 1, when in fact it should be 0. Actually, instead of
> multiplying by 256, multiplying by 65536, or 600, or many other
> numbers would also return the integer part as 1.
>
> As a note, I used RealField(80) as my precision.

Typing log(1 + 2^-56, 2) gives the result as a symbolic expression, not
as an element of a real field.  Applying int() to this internally uses a
RealIntervalField with 53 bits of precision, which is not enough in this
case.  Here is a way to get the desired precision:

sage: x = RealField(80)(256*log(1+2^-56,2))
sage: x
5.1254824061038682620123e-15
sage: int(x)
0

Peter

-- 
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: extension de corps

2014-03-24 Thread Peter Bruin
Bonjour,

Il est malheureusement un peu problématique de construire des tours
(extensions successives) de corps.  Sage sait bien vérifier que votre F6
est un corps, mais F6 est toujours représenté comme anneau quotient et
non comme corps fini ; c'est pourquoi certaines opérations naturelles ne
marchent pas.

Une solution possible est de commencer par construire F12 et de voir les
autres corps comme des sous-corps de F12.  Un calcul montre que le
polynôme minimal de l'élément primitif w de F12 est x^12 - 2x^6 + 2.  On
peut maintenant faire

sage: t=-(2^62 + 2^55 +1)
sage: p=36*t^4+36*t^3+24*t^2+6*t+1
sage: F=GF(p)
sage: R. = PolynomialRing(F)
sage: f = x^12 - 2*x^6 + 2
sage: F12. = FiniteField(p^12, modulus=f)
sage: v = w^2
sage: i = v^3 - 1
sage: i^2 == -1
True

En principe, il est possible de construire explicitement les sous-corps
et les plongements F2 -> F6 -> F12, mais il est sans doute plus facile
de faire tous les calculs directement dans F12.

Peter


> بتاريخ الأربعاء، 19 مارس، 2014 UTC+1 9:26:58 م، كتب ghamma...@gmail.com:
> > Bonsoir
> > SVP, j'ai besoin de definir sur Sage 3 extensions de corps, mais je
> > n'arrive pas. Je peux definir que deux extensions.

> When i find the test F6.is field() the answer is true,

> in this representation i have Fp^2, Fp^6 and Fp^12 are fields. But I
> need that Fp^2 be a field extension bacause I need to seperate his
> elements(a in Fp^2=a0+i*a1 and i need the value of a0=a[0] and
> a1=a[1])
> #t=2^62-2^54+2^44
> t=-(2^62 + 2^55 +1)
> #t=2^63-2^49
> p=36*t^4+36*t^3+24*t^2+6*t+1
> r=36*t^4+36*t^3+18*t^2+6*t+1
> tr=6*t^2+1
> #-- Fp--
> F=GF(p)
> #---
> b=2
> #--Fp^2--
> K2.=PolynomialRing(F)
> F2.=FiniteField(p^2,modulus=x^2+1)
> #
> #-Fp^6-
> K6.=PolynomialRing(F2)
> F6.=F2.extension(y^3-i-1)
> #-

> #---Fp^12---

> K12.=PolynomialRing(F6)
> F12.=F6.extension(z^2-v)
> F12.is_field=lambda:True
> #

-- 
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] Re: Possible Bug in Matrix Nullity Method

2014-03-06 Thread Peter Bruin
Hello John,

Surely not?   For the left nullity the vectors are row vectors on the 
> left, but the matrix is acting on the right (unless I got out of bed 
> on the wrong side this norming).
>

Yes, I now realise that I read the phrase in a "left-associative way", 
interpreting "kernel of this matrix acting on the right on row vectors" as 
being about the _kernel_ acting on row vectors.  I was also thinking of the 
fact that the kernel acts from the left via row operations on the matrix to 
its right.  After re-reading it I see that it makes more sense if you read 
it right-associatively.  (I could be somewhat left-right disoriented having 
just travelled from the UK to the continent.)

Anyway, given that this documentation will be read more closely by people 
who are less familiar with things like left kernels, I still find it a 
potentially confusing sentence.

Peter

-- 
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] Re: Possible Bug in Matrix Nullity Method

2014-03-06 Thread Peter Bruin
Hi Dima,

Is there something wrong in documentation regarding them?
>
 
Possibly: the documentation of m.nullity() says 

Return the (left) nullity of this matrix, which is the dimension of
the (left) kernel of this matrix acting from the right on row
vectors.

This should probably be "acting from the LEFT on row vectors"; I think it 
is even better (less confusing) to delete this part of the sentence.

Peter

-- 
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] Re: Possible Bug in Matrix Nullity Method

2014-03-06 Thread Peter Bruin
It is not a bug, but a consequence of a different convention.  In Sage, 
nullity means left nullity, i.e. the dimension of the left kernel.  In this 
example, m.nullity() + m.rank() = m.nrows().  For the more common right 
nullity (resp. kernel), use m.right_nullity() (resp. m.right_kernel()) 
instead.  Indeed, in the example m.right_nullity() returns 2.

Peter

Rank-nullity theorem states that the rank and the nullity of a matrix add 
> up to the number of columns of a matrix. In the following example, the 
> matrix defined over R has 5 columns but its rank and nullity add up to 4. 
> Is this a bug?
>
> sage: m = matrix(RR,[[1,-1,2,0,3],[2,-1,3,-1,2],[3,0,3,0,6],[6,0,6,-1,9]])
>
> sage: m.nullity()
>
> 1
>
> sage: m.ncols()
>
> 5
>
> sage: m.rank()
>
> 3
>

-- 
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] Re: Polynomial rings and homogenization

2014-03-05 Thread Peter Bruin
Hello Tristan,
 

> n = 100; d=3
> load DATA+'my_functions.py'
> coefficients = poly_expand(n,int(n**(1/d)),d)
> R. = ZZ[]
> f = 0
> for c in coefficients:
> f += c*t^d
> d -= 1
> g = f.homogenize('s')
>
> Running this returns "AttributeError: 'GlobalPolynomialRing' object has no 
> attribute '_first_ngens'".
>
Could it be that the elements of "coefficients" do not lie in ZZ but 
elsewhere (e.g. in the symbolic ring)?  Your example seems to work fine (at 
least with Sage 6.1.beta2) if "coefficients" is a vector of elements of ZZ.

Peter

-- 
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] Re: confused about primality of Ideal(1)

2014-01-27 Thread Peter Bruin
Hello,

> I'm a bit confused about Sage's answer if Ideal(1) is prime.
>
> R.= QQ[]
> I = Ideal(R(1))
> I.is_prime()
>
> Sage (5.11, not only) says yes,
> conflicting to the definition,
> http://en.wikipedia.org/wiki/Prime_ideal
> Has somebody an expanation of this behaviour?

The example Singular session below suggests that the problem lies in
Singular (I'm not too familiar with Singular, but I think the answers
should all be the same, and only primdecSY(J) seems to be correct).

Peter


$ sage -singular
 SINGULAR /  Development
 A Computer Algebra System for Polynomial Computations   /   version 3-1-5
   0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \   Jul 2012
FB Mathematik der Universitaet, D-67653 Kaiserslautern\
> LIB "primdec.lib"
(...)
> ring R = 0, (x, y), dp;
> ideal I = 1;
> primdecSY(I);
[1]:
   [1]:
  _[1]=1
   [2]:
  _[1]=1
> primdecGTZ(I);
[1]:
   [1]:
  _[1]=1
   [2]:
  _[1]=1
> ideal J = x, x + 1;
> primdecSY(J);
empty list
> primdecGTZ(J);
[1]:
   [1]:
  _[1]=1
   [2]:
  _[1]=1

-- 
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] Re: hyperbolic triangles using disc model

2014-01-17 Thread Peter Bruin
Hello,

I've been using Sage's hyperbolic_triangle function quite a lot to produce 
> a few pictures. I'm very happy with them, but I was also wondering whether 
> Sage could handle the "disc model" for hyperbolic triangles... Only the 
> "upper half-plane model" seems to be available, but I may be wrong.
>
> Anyone knows about this?
>
 
Quite a lot of work has been done on implementing various things related to 
hyperbolic geometry, but unfortunately there hasn't been a lot of activity 
recently (http://trac.sagemath.org/ticket/9439).  I have no idea how close 
this is to being finished...

Peter

-- 
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] Re: Calling gp.F(n) in a loop about 2^16 times raises exception

2013-11-22 Thread Peter Bruin


> To partially solve the above bug, we should make sure doubling of the 
> "sage" array works when an allocatemem() has to be done; this seems to be 
> broken, and I just opened a ticket for it (#15446).  It is only a partial 
> fix because doing GP calculations still leaks memory.
>

I also opened Trac ticket #15447 to implement evaluating PARI closures; e.g.

sage: T = pari('n -> n + 1')
sage: T(5)
6

Peter

-- 
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] Re: Calling gp.F(n) in a loop about 2^16 times raises exception

2013-11-22 Thread Peter Bruin


Op vrijdag 22 november 2013 18:48:27 UTC schreef Nils Bruin:
>
> On Friday, November 22, 2013 10:26:52 AM UTC-8, Peter Bruin wrote:
>>
>> The results of all GP command are stored in an array named 'sage' inside 
>> GP.  If you execute too many commands, this array apparently isn't enlarged 
>> anymore.  I suspect that this is because GP runs out of stack space and 
>> that Sage's GP interface does not notice this.
>>
>> I don't see a quick and easy solution.
>>
>  
> It might be worthwhile to add that the reason all those results are stored 
> in an array is because (at least at first) they correspond to a "gp" object 
> in sage, so we need a place to keep a reference to the value in gp. The 
> solution to this issue is freeing up the entries in gp when the result is 
> not needed any more, i.e., if the corresponding sage object gets 
> deallocated. Since you probably wouldn't want to do this via a "__delete__" 
> method, because that interferes with python's GC, you'd have to have a cdef 
> class on which you do the manipulation in gp in the __dealloc__.  (and then 
> probably make the entry in the array part of a "free-list"). The 
> __dealloc__ could run under quite adverse conditions, so I'm not sure that 
> driving a pexpect interface is a safe thing to do. One could queue the 
> re-use for the next allocation, though.
>

I agree that something like this would be the definitive fix.  To partially 
solve the above bug, we should make sure doubling of the "sage" array works 
when an allocatemem() has to be done; this seems to be broken, and I just 
opened a ticket for it (#15446).  It is only a partial fix because doing GP 
calculations still leaks memory.

Peter

-- 
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] Re: Calling gp.F(n) in a loop about 2^16 times raises exception

2013-11-22 Thread Peter Bruin
The results of all GP command are stored in an array named 'sage' inside 
GP.  If you execute too many commands, this array apparently isn't enlarged 
anymore.  I suspect that this is because GP runs out of stack space and 
that Sage's GP interface does not notice this.

I don't see a quick and easy solution.  You could try to divide your 
calculation in shorter pieces and starting with a fresh GP instance after 
each piece using the following command:

gp = Gp()

It would actually be better if the following could be made to work:

sage: T=pari("n->n+1")
sage: for n in [ 1 .. 2**20]:
a=T(n)
print n

This would use the PARI library rather than an interface to a PARI/GP 
program running outside Sage.  Unfortunately the above syntax isn't 
supported yet.

Peter


Op zondag 17 november 2013 08:31:43 UTC schreef Georgi Guninski:
>
> Is there something wrong or a workaround for this. 
> Simplified testcase: 
>
> sage: gp("{T(n)=n+1}") 
> sage: for n in [ 1 .. 2**20]: 
> a=gp.T(n) 
> print n 
>
> #wait some time.. 
> ... 
> 65535 
> 65536 
> --- 
>
> TypeError 
>
> TypeError: Error executing code in GP: 
> CODE: 
> sage[131074]=65537; 
> PARI/GP ERROR: 
>   ***   at top-level: sage[131074]=65537 
>   *** ^-- 
>   ***   array index (131074) out of allowed range [1-131073]. 
>
> after this trying: 
> sage: gp.T(1) 
>
> again raises exception. 
>
> The constants near 2^16 might indicate some wrong C/C++ type 
> (just a guess). 
>

-- 
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] Is it normal to get negative canonical height of a point on EC over NF ?

2013-11-22 Thread Peter Bruin
The problem is indeed fixed by applying #13951 (which still needs 
reviewing).

Peter

Op vrijdag 8 november 2013 17:35:01 UTC schreef John Cremona:
>
> On 8 November 2013 16:11, Georgi Guninski > 
> wrote: 
> > I am not an expert, but is it normal to get negative canonical 
> > height of a point on elliptic curve over number field? 
>
> No, this is certainly an error.  There is at least one outstanding 
> patch relating to heights over number fields (#13951) but also there 
> was a numerical instability problem fixed at #12509 which was not done 
> perfectly (I know, I did it) and that might be the issue here too. 
>
> Heights are supposed to be independent of the base field.  Your curve 
> and point are defined over Q where the height is computed as 
> 0.0324132522964454 -- this uses a completely different implementation 
> (in the pari library) which is more reliable, unfortunately. 
>
> John Cremona 
>
> > 
> > sage: Z1.=ZZ[];Nf.=NumberField(Z**16-2);E=EllipticCurve(Nf,[-87, 
> 504, -40320, 0, 0]);P=E(0,0) 
> > sage: P.height() #not very fast 
> > -0.150688795814905 
> > sage: P.height(precision=2000) 
> > -0.15068879581490624... 
> > 
> > Works on cloud.sagemath too. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To post to this group, send email to 
> > sage-s...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/sage-support. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>

-- 
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] Incorrect computations of Eisenstein series

2008-09-04 Thread Peter Bruin

Hi,

When computing Eisenstein series with a given character, Sage may
return some forms with a wrong character.  The following lines show an
example of this:

sage: G = DirichletGroup(7)
sage: E = EisensteinForms(G[4]).eisenstein_series()
sage: E[0].character() == G[4]
False

The problem appears to be caused by the condition

  if chi*psi == eps:

in the function __find_eisen_chars in modular/modform/eis_series.py.
According to Miyake, _Modular Forms_, Lemma 7.1.1 (cited in a comment
in this function), it should be

  if chi == eps*psi:

Another bug is that Sage uses an incorrect formula to compute q-
expansions of Eisenstein series.  Here the origin of the problem seems
to be formula (5.3.1) in Stein, _Modular Forms: A Computational
Approach_, where the psi(n) should be replaced by its complex
conjugate (cf. Miyake, _Modular Forms_, Theorem 4.7.1 and the first
three lines of page 271).  The method __compute_general_case of the
class EisensteinSeries in modular/modform/element.py reproduces this
formula in the form

  v.append(sum([psi(n)*chi(m/n)*n**(k-1) for n in rings.divisors(m)]))

Here psi should be ~psi.

Thanks,

Peter Bruin

--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@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-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---