[sage-combinat-devel] Sage(-Combinat) tutorial during EJCIM 2014?

2014-01-22 Thread Nicolas M. Thiery
Dear French Sage-combinat devs,

(this is about an upcoming Spring school for French PhD students at
the frontier of maths and computer science; if you are not based in
France, you may safely ignore this thread).

Sylvain Peyronnet m'a contacté pour savoir si nous souhaitions
intervenir comme les années précédentes lors de l'École Jeunes
Chercheurs 2014. Est-ce que certains d'entre vous seraient intéressés
pour participer resp. prendre cela en main?

Bonne journée!
Nicolas

- Forwarded message from Sylvain Peyronnet sylvain.peyron...@lri.fr -
Date: Tue, 21 Jan 2014 20:56:02 +0100
From: Sylvain Peyronnet sylvain.peyron...@lri.fr
To: gdr...@gdr-im.fr
Subject: [gdr-im] EJCIM 2014 !

MERCI DE DIFFUSER LARGEMENT

Annonce pour l'EJC-IM 2014 :

Ecole Jeunes Chercheurs en Informatique Mathématique (EJC-IM) 2014
31 mars au 4 avril 2014 à Caen

https://ejcim2014.greyc.fr/

Bonjour à toutes et tous.

Le GDR Informatique Mathématique propose chaque année une école pour
les jeunes chercheurs. L'édition 2014 de ces EJC-IM est organisée par
l'équipe AMACC du GREYC, laboratoire de recherche en informatique de
l'Université de Caen Basse-Normandie (UCBN).

Elle aura lieu sur le campus 3 de l'UCBN, du lundi 30 mars au vendredi
4 avril 2014.
Des pré-inscriptions sont obligatoires et ouvertes à partir 24 janvier
et jusqu'au 28 février.

Nous invitons les jeunes chercheurs participants potentiels à se
pré-inscrire sur le site web dès le 24 janvier.

Les grands thèmes du GDR IM sont l'algorithmique, la combinatoire, le
calcul formel, l'arithmétique, la protection de l'information, la
géométrie, la logique et la complexité. L'une des vocations de ces
EJC-IM est de promouvoir l'ouverture des jeunes chercheurs à ces
thématiques et de renforcer la cohésion scientifique de la communauté
Informatique Mathématique. Le public de ces écoles est prioritairement
celui des doctorants et jeunes docteurs du GDR IM, mais aussi des
étudiants de Master ou des chercheurs d'autres GDR.

Cette année, l'école permettra d'aborder les thèmes suivants.

* Automates Cellulaires
* Algorithmique du web
* Exemples d'analyse d'algorithmes en arithmétique et en théorie de
l'Information
* Complexité de communication
* Cryptographie

Les jeunes chercheurs sont aussi invités à exposer leurs travaux, sous
la forme de présentations orales ou de posters, et ont ainsi
l'occasion d'interagir avec la communauté. Les cours qui représentent
15 à 20h de formation sont validés par la plupart des écoles
doctorales (attestation fournie sur demande).

Les frais d'hébergement du dimanche soir au vendredi midi et la
demi-pension (matin et midi) sont pris en charge par
l'organisation. Les frais de transport sont à la charge des
participants, ainsi que les frais d'inscription de 75 euros. Les
modalités de paiement seront communiquées dans les prochaines
semaines.

Le comité scientifique est composé de :

– Valérie Berthé (LIAFA, Paris)
– Philippe Langlois (LIRMM, Perpignan)
– Jean-Michel Muller (ENS Lyon)
– Sylvain Peyronnet (GREYC, Caen)
– Natacha Portier (LIP, ENS Lyon)
– Brigitte Vallée (GREYC, Caen)

Le comité d'organisation est composé de :

– Ali Akhavi (GREYC, Caen)
– Nicolas Bacquey (GREYC, Caen)
– Thomas Largillier (GREYC, Caen)
– Sylvain Peyronnet (GREYC, Caen)
– Natacha Portier (LIP, ENS Lyon)
– Gaëtan Richard (GREYC, Caen)
– Brigitte Vallée (GREYC, Caen)

Pour plus de détails, n'hésitez pas à consulter la page web de l'école
ou à contacter Sylvain Peyronnet (sylvain.peyron...@unicaen.fr).


- End forwarded message -
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

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


Re: [sage-combinat-devel] Sage(-Combinat) tutorial during EJCIM 2014?

2014-01-22 Thread Matthieu Deneufchatel
Je veux bien donner un coup de main si c'est dans mes cordes.
Cordialement,
Matthieu





Le Mercredi 22 janvier 2014 9h38, Nicolas M. Thiery nicolas.thi...@u-psud.fr 
a écrit :
 
    Dear French Sage-combinat devs,

(this is about an upcoming Spring school for French PhD students at
the frontier of maths and computer science; if you are not based in
France, you may safely ignore this thread).

Sylvain Peyronnet m'a contacté pour savoir si nous souhaitions
intervenir comme les années précédentes lors de l'École Jeunes
Chercheurs 2014. Est-ce que certains d'entre vous seraient intéressés
pour participer resp. prendre cela en main?

Bonne journée!
                Nicolas

- Forwarded message from Sylvain Peyronnet sylvain.peyron...@lri.fr -
Date: Tue, 21 Jan 2014 20:56:02 +0100
From: Sylvain Peyronnet sylvain.peyron...@lri.fr
To: gdr...@gdr-im.fr
Subject: [gdr-im] EJCIM 2014 !

MERCI DE DIFFUSER LARGEMENT

Annonce pour l'EJC-IM 2014 :

Ecole Jeunes Chercheurs en Informatique Mathématique (EJC-IM) 2014
31 mars au 4 avril 2014 à Caen

https://ejcim2014.greyc.fr/

Bonjour à toutes et tous.

Le GDR Informatique Mathématique propose chaque année une école pour
les jeunes chercheurs. L'édition 2014 de ces EJC-IM est organisée par
l'équipe AMACC du GREYC, laboratoire de recherche en informatique de
l'Université de Caen Basse-Normandie (UCBN).

Elle aura lieu sur le campus 3 de l'UCBN, du lundi 30 mars au vendredi
4 avril 2014.
Des pré-inscriptions sont obligatoires et ouvertes à partir 24 janvier
et jusqu'au 28 février.

Nous invitons les jeunes chercheurs participants potentiels à se
pré-inscrire sur le site web dès le 24 janvier.

Les grands thèmes du GDR IM sont l'algorithmique, la combinatoire, le
calcul formel, l'arithmétique, la protection de l'information, la
géométrie, la logique et la complexité. L'une des vocations de ces
EJC-IM est de promouvoir l'ouverture des jeunes chercheurs à ces
thématiques et de renforcer la cohésion scientifique de la communauté
Informatique Mathématique. Le public de ces écoles est prioritairement
celui des doctorants et jeunes docteurs du GDR IM, mais aussi des
étudiants de Master ou des chercheurs d'autres GDR.

Cette année, l'école permettra d'aborder les thèmes suivants.

* Automates Cellulaires
* Algorithmique du web
* Exemples d'analyse d'algorithmes en arithmétique et en théorie de
l'Information
* Complexité de communication
* Cryptographie

Les jeunes chercheurs sont aussi invités à exposer leurs travaux, sous
la forme de présentations orales ou de posters, et ont ainsi
l'occasion d'interagir avec la communauté. Les cours qui représentent
15 à 20h de formation sont validés par la plupart des écoles
doctorales (attestation fournie sur demande).

Les frais d'hébergement du dimanche soir au vendredi midi et la
demi-pension (matin et midi) sont pris en charge par
l'organisation. Les frais de transport sont à la charge des
participants, ainsi que les frais d'inscription de 75 euros. Les
modalités de paiement seront communiquées dans les prochaines
semaines.

Le comité scientifique est composé de :

– Valérie Berthé (LIAFA, Paris)
– Philippe Langlois (LIRMM, Perpignan)
– Jean-Michel Muller (ENS Lyon)
– Sylvain Peyronnet (GREYC, Caen)
– Natacha Portier (LIP, ENS Lyon)
– Brigitte Vallée (GREYC, Caen)

Le comité d'organisation est composé de :

– Ali Akhavi (GREYC, Caen)
– Nicolas Bacquey (GREYC, Caen)
– Thomas Largillier (GREYC, Caen)
– Sylvain Peyronnet (GREYC, Caen)
– Natacha Portier (LIP, ENS Lyon)
– Gaëtan Richard (GREYC, Caen)
– Brigitte Vallée (GREYC, Caen)

Pour plus de détails, n'hésitez pas à consulter la page web de l'école
ou à contacter Sylvain Peyronnet (sylvain.peyron...@unicaen.fr).


- End forwarded message -
                Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

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

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


[sage-devel] Re: upcoming Sage Days

2014-01-22 Thread mmarco

I am not sure about my abilities to solve bugs, but i would sure like to 
try. My problem is that i need a long paperwork to go to USA, so i cannot 
attend on short notice.

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


Re: [sage-devel] Please review #15699: Glibc scanf workaround for ATLAS

2014-01-22 Thread Erik Massop
On Mon, 20 Jan 2014 08:10:03 -0800 (PST)
Volker Braun vbraun.n...@gmail.com wrote:

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

Since I'm currently unable to login to trac, I'll respond here:

Since it is unlikely that scanf will succeed after having failed once
(since it is then stuck somewhere in the middle of 0e+00) the
code in the current patch will just fill the rest of the array with the
last number that succeeded, disregarding anything remaining in the
file. I think we can do better than that. Please find attached a patch
on 540db9e211 (u/vbraun/glibc_scanf_workaround_for_atlas) that uses a
different approach, namely replacing scanf by strtod.

The patch is a bit more complicated than necessary, as checking
end ! = buf instead of errno == 0  end ! = buf  *end == '\n'
is probably sufficient for this usecase.


Regards,

Erik Massop

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
From 3a7a922a8012857628d90c2f2625f08210d0c9dc Mon Sep 17 00:00:00 2001
From: Erik Massop e.mas...@hccnet.nl
Date: Wed, 22 Jan 2014 11:47:06 +0100
Subject: [PATCH] Avoid scanf instead of just ignoring rest of file

---
 .../atlas/patches/glibc_scanf_workaround.patch | 25 +++---
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/build/pkgs/atlas/patches/glibc_scanf_workaround.patch b/build/pkgs/atlas/patches/glibc_scanf_workaround.patch
index f52eccd..9118aac 100644
--- a/build/pkgs/atlas/patches/glibc_scanf_workaround.patch
+++ b/build/pkgs/atlas/patches/glibc_scanf_workaround.patch
@@ -1,20 +1,29 @@
 Bug in glibc-2.18: https://sourceware.org/bugzilla/show_bug.cgi?id=15917
-Patch taken from openSUSE 13.1
 
 
 --- a/tune/sysinfo/masrch.c
 +++ b/tune/sysinfo/masrch.c
-@@ -113,7 +113,12 @@ double matime
+@@ -1,6 +1,7 @@
+ #include stdio.h
+ #include stdlib.h
+ #include assert.h
++#include errno.h
+ 
+ #ifndef NTIM
+#define NTIM 3
+@@ -113,7 +114,14 @@
 j = 0;
 for (i=0; i != NTIM; i++)
 {
 -  assert( fscanf(fp, %lf, mflop[i]) );
-+  if(fscanf(fp, %lf, mflop[i])==0) {
-+ if (i0)
-+mflop[i]=mflop[i-1];
-+ else
-+assert(0);
-+  }
++  /* FIXME: This assumes one float per line immediately followed by \n. */
++  char buf[100]; /* enough to read a double */
++  char *end;
++
++  assert(fgets(buf, sizeof buf, fp));
++  errno = 0;
++  mflop[i] = strtod(buf, end);
++  assert(errno == 0  end != buf  *end == '\n');
 }
 fclose(fp);
  /*
-- 
1.8.5.2



[sage-devel] polynomials are power series?

2014-01-22 Thread Ralf Stephan
While the ring type hierarchy does not reflect that polynomials are power 
series, you can have a power series without bigoh which is pratically a 
polynomial but, being a power series, has much less member functions 
available.

I think Sage shouldn't allow a zero bigoh term in power series. It should 
avoid unexpected behaviour, eg. users complaining that a polynomial isn't 
what it seems.

But I'm writing here to ask for your opinion before I think about patching, 
because I'm only beginning to understand Sage, and I'm not even a 
mathematician!

Regards,
Ralf Stephan

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


Re: [sage-devel] Re: Precision problems in taking determinant?

2014-01-22 Thread Dima Pasechnik
Is the default choice of the algorithm the right one?
One can see that 
sage: A.determinant(algorithm=hessenberg)
16801.7979988558
is quite good...

On Monday, 20 January 2014 18:10:43 UTC, Peter Bruin wrote:

 Would it be proper to autoconvert matrices over RR to RDF in case of the 
 default precision, so that the more stable numerical algorithms from RDF 
 can be used? I had proposed one such change in #13660 ( 
 http://trac.sagemath.org/13660 ) in case of eigenvalue/eigenvector 
 computations. 


 Well, it should also be fixed for a RealField of higher precision.  An 
 easy solution for that is to use PARI, which uses a numerically more stable 
 algorithm (Gaussian elimination, choosing pivots of maximal absolute value; 
 I don't know about proven error bounds).  Example:

 sage: A._pari_().matdet()
 16801.7979988279  # same as when doing the computation over QQ

 Sage's determinant() already uses PARI over Z/nZ for n less than the 
 machine word size; it would be trivial to adapt it to work also over the 
 reals.

 Peter



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


[sage-devel] Re: polynomials are power series?

2014-01-22 Thread Martin Raum
Thank you, Ralf, for considering ideas how to improve Sage.

I can't, however, agree with this particular idea. Think of coercion. You 
have a polynomial, coerce it into the power series ring, and then? Choose 
the precision = degree + 1? How could that be a ring homomorpism. You would 
sacrifice structure for the idea what looks the same should be the same. 
I don't think the latter is important enough to justify the former.

Martin

Am Mittwoch, 22. Januar 2014 12:49:01 UTC+1 schrieb Ralf Stephan:

 While the ring type hierarchy does not reflect that polynomials are power 
 series, you can have a power series without bigoh which is pratically a 
 polynomial but, being a power series, has much less member functions 
 available.

 I think Sage shouldn't allow a zero bigoh term in power series. It should 
 avoid unexpected behaviour, eg. users complaining that a polynomial isn't 
 what it seems.

 But I'm writing here to ask for your opinion before I think about 
 patching, because I'm only beginning to understand Sage, and I'm not even a 
 mathematician!

 Regards,
 Ralf Stephan


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


[sage-devel] Re: Cannot login to trac webinterface

2014-01-22 Thread Volker Braun
I'll take care of it


On Wednesday, January 22, 2014 10:22:45 AM UTC, Erik Massop wrote:

 Dear list, 


 Getting a 401 Authorization Required at http://trac.sagemath.org/login 
 I punch in my username (emassop) and password (from the latest 
 password-reset e-mail). This does not let me in. Can someone 
 help me with this? Do other people have the same problem? Maybe 
 only after having reset their password? 


 Regards, 

 Erik Massop 


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


Re: [sage-devel] polynomials are power series?

2014-01-22 Thread John Cremona
Surely all Ralf meant was that R[X] is a subring of R[[X]], i.e. some
elements of R[[X]] are exact, just as some decimal numbers like 0.25
are exact (in binary), and just as we might want to define a real
number as having *exactly* the value 0.25 and not just 0.25 +
O(10^-1000) one might want to consider 1+X as an exact power series
and not just 1+X+O(X^1000).

Of course I amy have misunderstood Ralf (or you)!

John

On 22 January 2014 11:49, Ralf Stephan gtrw...@gmail.com wrote:
 While the ring type hierarchy does not reflect that polynomials are power
 series, you can have a power series without bigoh which is pratically a
 polynomial but, being a power series, has much less member functions
 available.

 I think Sage shouldn't allow a zero bigoh term in power series. It should
 avoid unexpected behaviour, eg. users complaining that a polynomial isn't
 what it seems.

 But I'm writing here to ask for your opinion before I think about patching,
 because I'm only beginning to understand Sage, and I'm not even a
 mathematician!

 Regards,
 Ralf Stephan

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

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


Re: [sage-devel] polynomials are power series?

2014-01-22 Thread Ralf Stephan
I understand precision as being independent from element properties (as it
is in Pari). Note also that R.random_element() always has O(x^20) so a
fixed precision is already implemented.

​John is right that I see polynomials as a subring to power series. I would
not be able to give references to that however.​

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


[sage-devel] Re: polynomials are power series?

2014-01-22 Thread Nils Bruin
On Wednesday, January 22, 2014 3:49:01 AM UTC-8, Ralf Stephan wrote:

 While the ring type hierarchy does not reflect that polynomials are power 
 series, you can have a power series without bigoh which is pratically a 
 polynomial but, being a power series, has much less member functions 
 available.

As a power series, it has *different* methods available. For instance, the 
(formal) power series 1-x has a multiplicative inverse (formal) power series
1+x+x^2+x^3+...
but the polynomial 1-x does not have a multiplicative inverse polynomial.

The big-Oh term is giving you useful information: it is telling you that 1 
- x + O(x^10) is considered a power series. You also see why, even if this 
is the power series representation of the polynomial 1-x and not of a power 
series 1-x+x^11+x^13+..., it is still essential to have some precision 
associated to the object: once you take the inverse of a power series, you 
need a precision to represent it in a finite way (ignoring lazy 
approaches for now).

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


Re: [sage-devel] Re: polynomials are power series?

2014-01-22 Thread Ralf Stephan
If polynomials were a subring of power series then 1-x would have an
inverse. Who says it has not?

(Do not misunderstand me please, I simply don't know)


On Wed, Jan 22, 2014 at 4:57 PM, Nils Bruin nbr...@sfu.ca wrote:

 On Wednesday, January 22, 2014 3:49:01 AM UTC-8, Ralf Stephan wrote:

 While the ring type hierarchy does not reflect that polynomials are power
 series, you can have a power series without bigoh which is pratically a
 polynomial but, being a power series, has much less member functions
 available.

 As a power series, it has *different* methods available. For instance, the
 (formal) power series 1-x has a multiplicative inverse (formal) power series
 1+x+x^2+x^3+...
 but the polynomial 1-x does not have a multiplicative inverse polynomial.

 The big-Oh term is giving you useful information: it is telling you that
 1 - x + O(x^10) is considered a power series. You also see why, even if
 this is the power series representation of the polynomial 1-x and not of a
 power series 1-x+x^11+x^13+..., it is still essential to have some
 precision associated to the object: once you take the inverse of a power
 series, you need a precision to represent it in a finite way (ignoring
 lazy approaches for now).

 --
 You received this message because you are subscribed to a topic in the
 Google Groups sage-devel group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sage-devel/APnWIGYcq3M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/groups/opt_out.


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


[sage-devel] Re: polynomials are power series?

2014-01-22 Thread Ralf Stephan
I will abstain from the type hierarchy. I need to have a better grip on 
rings. Sorry for the time you wasted.

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


Re: [sage-devel] Re: polynomials are power series?

2014-01-22 Thread Travis Scrimshaw
It would not have it's inverse in the subring. You need an infinite number 
of terms to express (1 - x)^-1 = 1 + x + x^2 + x^3 + ... (by using 
multiplication as 1/(1 - x) is formally a rational function).

Currently we have the following behavior in sage:

sage: R.x = QQ[]
sage: f = 1 - x; f
-x + 1
sage: f.parent()
Univariate Polynomial Ring in x over Rational Field
sage: FPS.x = QQ[[]]
sage: FPS
Power Series Ring in x over Rational Field
sage: FPS(f)
1 - x
sage: _.parent()
Power Series Ring in x over Rational Field
sage: f + x
1
sage: FPS(f)^-1
1 + x + x^2 + x^3 + x^4 + x^5 + x^6 + x^7 + x^8 + x^9 + x^10 + x^11 + x^12 +x
^13 + x^14 + x^15 + x^16 + x^17 + x^18 + x^19 + O(x^20)
sage: f^-1
1/(-x + 1)
sage: _.parent() # This is the field of rational functions
Fraction Field of Univariate Polynomial Ring in x over Rational Field

so it looks like the 0*O(x^20) is just suppressed from the output in the 
(formal) power series ring.

Best,
Travis


On Wednesday, January 22, 2014 8:01:17 AM UTC-8, Ralf Stephan wrote:

 If polynomials were a subring of power series then 1-x would have an 
 inverse. Who says it has not?

 (Do not misunderstand me please, I simply don't know)


 On Wed, Jan 22, 2014 at 4:57 PM, Nils Bruin nbr...@sfu.ca 
 javascript:wrote:

 On Wednesday, January 22, 2014 3:49:01 AM UTC-8, Ralf Stephan wrote:

 While the ring type hierarchy does not reflect that polynomials are 
 power series, you can have a power series without bigoh which is pratically 
 a polynomial but, being a power series, has much less member functions 
 available.

 As a power series, it has *different* methods available. For instance, 
 the (formal) power series 1-x has a multiplicative inverse (formal) power 
 series
 1+x+x^2+x^3+...
 but the polynomial 1-x does not have a multiplicative inverse polynomial.

 The big-Oh term is giving you useful information: it is telling you that 
 1 - x + O(x^10) is considered a power series. You also see why, even if 
 this is the power series representation of the polynomial 1-x and not of a 
 power series 1-x+x^11+x^13+..., it is still essential to have some 
 precision associated to the object: once you take the inverse of a power 
 series, you need a precision to represent it in a finite way (ignoring 
 lazy approaches for now).
  
 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups sage-devel group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/sage-devel/APnWIGYcq3M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 sage-devel+...@googlegroups.com javascript:.
 To post to this group, send email to sage-...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




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


Re: [sage-devel] math software and China

2014-01-22 Thread Thierry Dumont

May be software piracy is not the problem (or there are other problems).
Consider for example scilab, which is a free replacement for Matlab (at
least partially): it has a huge success in China, even if it is very
easy to get non official versions of matlab for only some Yuans.
But Scilab is quite an official software in China, with software
contests for students!
Have a look at this:

http://www.scilab.org.cn/

Le 21/01/2014 15:06, John Cremona a écrit :
 I do know someone in Beiljing who does want to run a Sage Days --
 there was a posting to this list a few months ago.  He is Zhibin Liang
 and did a number theory PhD in Cambridge (UK) not long ago.
 
 If China has such huge resource then surely someone there could run a
 Sage notebook server.  Are they somehow asking for someone outside
 China to provide one which can be used from China?  Surely any open
 Sage server could be used from there?
 
 John
 
 On 21 January 2014 13:53, kcrisman kcris...@gmail.com wrote:
 Strange subject line, right?  But read this post from ask.sagemath:
 +++

 thank you very much!

 better a notebook servers to China,there are at least 600.000.000 people in
 internet.

 many kinds of Python books in China bookstore,but no many people deeply
 study it.

 in China,many people use mathematica,because mathematica 9.01 and maple 17
 is free download every where

 magma 2.15 free download in China.

 in China nobody and no college pay magma V2.20,if pay one times,magma V2.20
 will be free downloaded all China

 in China,95/100 windows OS are free downloaded,no pay a cent to Bill_gate

 +++

 Well, I guess the situation with respect to software piracy in China (and
 presumably elsewhere) is well-known.  I especially find the quote about
 Magma v2.20 interesting.

 Anyway, what are the implications of this for Sage - even the cloud?  I have
 no prediction, but it seems pretty important.  Certainly one issue this same
 poster has mentioned before is that the Great Firewall causes problems (see
 William and cjsh's brief conversation at
 http://ask.sagemath.org/question/3227/ ).

 So I think that this is worth discussing, especially if an entire huge
 country is essentially committed to proprietary software because it doesn't
 function in a proprietary way there; it makes some practical arguments for
 open source rather less compelling.  Are there any researchers thinking of
 planning a Sage Days in the PRC?  That would be really ground-breaking.

 - kcrisman

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

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

Re: [sage-devel] polynomials are power series?

2014-01-22 Thread Peter Bruin
Hi Ralf,

I understand precision as being independent from element properties (as it 
 is in Pari).


In Sage, there are two kinds of precision: the precision of an individual 
element and the default precision of the power series ring.  The same power 
series ring can contain elements that are represented using different 
precisions; for example, you can have a power series ring R with default 
precision 20, an element f in R with precision 10, and another element g in 
R with infinite precision.

An operation on power series (addition, inversion etc.) return the result 
in the highest precision to which it is defined; this depends on the 
precision of the elements, not on the default precision.  The exception is 
when the input has infinite precision and the output cannot be represented 
with infinite precision.  This is where the default precision comes in.  
For example, 1 - x has infinite precision, but 1/(1 - x) = 1 + x + x^2 + 
x^3 + ... cannot be represented exactly as a power series, so it is 
truncated to the default precision.

In PARI the situation is similar, except for two things: (1) there is no 
distinction between polynomials and power series of infinite precision 
that happen to be polynomials, and (2) the default precision is a global 
setting, not tied to any specific ring.  Both of these are simply because 
PARI has no (explicit) concept of polynomial rings and power series rings.

Peter

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


Re: [sage-devel] Re: polynomials are power series?

2014-01-22 Thread Peter Bruin
Hi Travis,

so it looks like the 0*O(x^20) is just suppressed from the output in the 
 (formal) power series ring.


If you mean that this is suppressed when printing FPS(f): no, actually 
FPS(f) has infinite precision, even though its parent FPS has a finite 
default precision.  Only when computing 1/f does the O(x^20) arise; the 
default precision is used here because the result cannot be expressed as a 
power series with infinite precision.

Peter

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


Re: [sage-devel] Re: Precision problems in taking determinant?

2014-01-22 Thread Peter Bruin
Hi Dima,

Is the default choice of the algorithm the right one?
 One can see that 
 sage: A.determinant(algorithm=hessenberg)
 16801.7979988558
 is quite good...  


The PARI documentation of the function charpoly() says: If flag=2, uses 
the Hessenberg form. Assumes that the base ring is a field.  Uses $O(n^3)$ 
scalar operations, but suffers from coefficient explosion unless the base 
field is finite or $\R$.  Since the determinant is just the constant term 
of the characteristic polynomial, this looks safe for the determinant as 
well.

I guess the question whether we should use Sage's built-in Hessenberg 
algorithm or PARI's matdet() comes down to which of the two is faster.

Peter

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


Re: [sage-devel] polynomials are power series?

2014-01-22 Thread Ralf Stephan
Thanks Travis, so there is coercion already. Now I think it natural to also
have coercion from the polynomial fractions to power series, or at least
have an expand() member function with a precision parameter and coercion in
case of addition with some bigoh, see
http://trac.sagemath.org/ticket/15698

And thanks to Peter for completely clarifying power series precision.



On Wed, Jan 22, 2014 at 5:36 PM, Peter Bruin pjbr...@gmail.com wrote:

 Hi Ralf,


 I understand precision as being independent from element properties (as it
 is in Pari).


 In Sage, there are two kinds of precision: the precision of an individual
 element and the default precision of the power series ring.  The same power
 series ring can contain elements that are represented using different
 precisions; for example, you can have a power series ring R with default
 precision 20, an element f in R with precision 10, and another element g in
 R with infinite precision.

 An operation on power series (addition, inversion etc.) return the result
 in the highest precision to which it is defined; this depends on the
 precision of the elements, not on the default precision.  The exception is
 when the input has infinite precision and the output cannot be represented
 with infinite precision.  This is where the default precision comes in.
 For example, 1 - x has infinite precision, but 1/(1 - x) = 1 + x + x^2 +
 x^3 + ... cannot be represented exactly as a power series, so it is
 truncated to the default precision.

 In PARI the situation is similar, except for two things: (1) there is no
 distinction between polynomials and power series of infinite precision
 that happen to be polynomials, and (2) the default precision is a global
 setting, not tied to any specific ring.  Both of these are simply because
 PARI has no (explicit) concept of polynomial rings and power series rings.

 Peter

  --
 You received this message because you are subscribed to a topic in the
 Google Groups sage-devel group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sage-devel/APnWIGYcq3M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/groups/opt_out.


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


Re: [sage-devel] Re: polynomials are power series?

2014-01-22 Thread Travis Scrimshaw
Ah, I see. Thanks for clarifying that for me Peter.

On Wednesday, January 22, 2014 8:41:24 AM UTC-8, Peter Bruin wrote:

 Hi Travis,

 so it looks like the 0*O(x^20) is just suppressed from the output in the 
 (formal) power series ring.


 If you mean that this is suppressed when printing FPS(f): no, actually 
 FPS(f) has infinite precision, even though its parent FPS has a finite 
 default precision.  Only when computing 1/f does the O(x^20) arise; the 
 default precision is used here because the result cannot be expressed as a 
 power series with infinite precision.

 Peter



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


[sage-devel] Re: Python class inheriting from MPolynomialRing_libsingular?

2014-01-22 Thread Nils Bruin
On Tuesday, January 21, 2014 1:47:47 PM UTC-8, Simon King wrote:

 I don't understand what is the problem with the Python class. Please 
 enlighten me!


I don't either, but I'll share some of my observations from the traceback. 
The libsingular init calls as a first thing 
MPolynomialRing_generic.__init__ which ends up triggering:
sage/categories/algebras.py:159
   154except AssertionError:
   155pass
   156return
   157
   158try:
  159one = self.one()

which looks like trouble to me, since the libsingular code only later sets 
self._one_element = one, where `one` is an explicitly 

Is it perhaps some type issue (where it explicitly tests for libsingular 
rings to avoid doing something) or the existence of a self.__dict__ that 
makes categories/algebras try to get the one element? In this order, you'll 
trigger the generic x=self(1) implementation of `one` which will wreak 
havoc: the underlying libsingular ring isn't even instantiated yet!

You might be able to make the code more robust by seeing if you can 
rearrange MPolynomial_libsingular.__init__ to only call the generic 
__init__ once the libsingular-specific attributes have been filled in. It 
may seem weird, but as you can see, apparently a part of the category-based 
initialization stuff expects to be passed fully functional rings during 
initialization, so that suggests tail calls in the __init__ hierarchy 
rather than head calls.

It would be good to identify why this isn't giving problems on a cdef 
class. The code that triggers the problem sits in 
sage.categories.algebras.Algebras.ParentMethods.__init_extra__ so the ease 
with which you can track down the problem will be a good test for how 
viable the category dynamic class stuff is in practice.


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


Re: [sage-devel] Re: Precision problems in taking determinant?

2014-01-22 Thread Dima Pasechnik
Hi Peter,

On Wednesday, 22 January 2014 16:53:43 UTC, Peter Bruin wrote:

 Is the default choice of the algorithm the right one?
 One can see that 
 sage: A.determinant(algorithm=hessenberg)
 16801.7979988558
 is quite good...  


 The PARI documentation of the function charpoly() says: If flag=2, uses 
 the Hessenberg form. Assumes that the base ring is a field.  Uses $O(n^3)$ 
 scalar operations, but suffers from coefficient explosion unless the base 
 field is finite or $\R$.  Since the determinant is just the constant term 
 of the characteristic polynomial, this looks safe for the determinant as 
 well.


Sage computes det() by computing charpoly(0), too... The division-free 
algorithm is obviously meant for more general setting of rings, not fields. 
I don't know why it was made default here, perhaps just an oversight.
 


 I guess the question whether we should use Sage's built-in Hessenberg 
 algorithm or PARI's matdet() comes down to which of the two is faster.


for charpoly(), that is.
 


 Peter



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


[sage-devel] Re: math software and China

2014-01-22 Thread Dima Pasechnik


On Tuesday, 21 January 2014 13:53:17 UTC, kcrisman wrote:

 Strange subject line, right?  But read this post from ask.sagemath:
 +++

 thank you very much!

 better a notebook servers to China,there are at least 600.000.000 people 
 in internet.

 many kinds of Python books in China bookstore,but no many people deeply 
 study it.

 in China,many people use mathematica,because mathematica 9.01 and maple 17 
 is free download every where

 magma 2.15 free download in China.

 in China nobody and no college pay magma V2.20,if pay one times,magma 
 V2.20 will be free downloaded all China

 in China,95/100 windows OS are free downloaded,no pay a cent to Bill_gate

 +++

 Well, I guess the situation with respect to software piracy in China (and 
 presumably elsewhere) is well-known.  I especially find the quote about 
 Magma v2.20 interesting.

Russia used to be quite similar in this respect - largely due to abundance 
of pirated wares things like Linux etc weren't too popular.

 

 Anyway, what are the implications of this for Sage - even the cloud?  I 
 have no prediction, but it seems pretty important.  Certainly one issue 
 this same poster has mentioned before is that the Great Firewall causes 
 problems (see William and cjsh's brief conversation at 
 http://ask.sagemath.org/question/3227/ ).

 So I think that this is worth discussing, especially if an entire huge 
 country is essentially committed to proprietary software because it doesn't 
 function in a proprietary way there; it makes some practical arguments for 
 open source rather less compelling.  Are there any researchers thinking of 
 planning a Sage Days in the PRC?  That would be really ground-breaking.

 - kcrisman


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


[sage-devel] Re: Python class inheriting from MPolynomialRing_libsingular?

2014-01-22 Thread Nils Bruin


On Wednesday, January 22, 2014 12:32:44 PM UTC-8, Nils Bruin wrote:

 It would be good to identify why this isn't giving problems on a cdef 
 class. The code that triggers the problem sits in 
 sage.categories.algebras.Algebras.ParentMethods.__init_extra__ so the ease 
 with which you can track down the problem will be a good test for how 
 viable the category dynamic class stuff is in practice.

 Here's some data. I have  Algebras.ParentMethods.__init_extra__ equipped 
with some print commands and I've adapted your example to use 
MPolynomialRing_generic instead, because that doesn't segfault. I get

sage: from sage.rings.polynomial.multi_polynomial_ring_generic import 
MPolynomialRing_generic
sage: R=MPolynomialRing_generic(QQ,3,['a','b','c'],lex)
sage: [C for C in type(R).mro() if __init_extra__ in C.__dict__]
[]
sage: R.__init_extra__
bound method JoinCategory.parent_class.__init_extra__ of Multivariate 
Polynomial Ring in a, b, c over Rational Field

whereas for a python subclass:

sage: class M(MPolynomialRing_generic): pass
sage: R=M(QQ,3,['a','b','c'],lex)
DEBUG: entering!
DEBUG: getting to dangerous part
DEBUG: exception has happened
sage: [C for C in type(R).mro() if __init_extra__ in C.__dict__]
[sage.categories.algebras.Algebras.parent_class,
 sage.categories.magmas.Magmas.parent_class,
 
sage.categories.commutative_additive_semigroups.CommutativeAdditiveSemigroups.parent_class,
 sage.categories.additive_magmas.AdditiveMagmas.parent_class]
sage: R.__init_extra__
bound method M_with_category.__init_extra__ of Multivariate Polynomial 
Ring in a, b, c over Rational Field

We see that for the python subclass the offending __init_extra__ does get 
executed, but for the original cdef class it doesn't (in fact the output 
also shows that the actual command try: one=self.one() fails for M as 
well, it just doesn't cause the segfault that happens for libsingular.

The reason for the difference is also clear once you know that the 
execution of `__init_extra__` is decided by seeing if it sits in some 
class.__dict__. For the python class, we see that there are several classes 
in the mro that indeed have that attribute, but for the cdef class there is 
not: also none of the dynamic classes sit in the cdef mro, whereas there 
are lots of dynamic classes in the mro of the type of the python subclass 
instance.

It surprises me that the MPolynomialRing_generic instance does have an 
__init_extra__ attribute. Where does that come from? does it get supplied 
by some custom get somewhere? Is it some workaround for the apparent fact 
that the whole dynamic class business doesn't work for cython classes? If 
so, then it does so in a way that's incompatible with the code that tries 
to decide to look up whether __init_extra__ needs to be run: Simon has just 
found a bug that has been lurking for ages, only because another bug 
prevented it from being triggered.

I must say this particular example increases my scepticism about the black 
magic the category framework tries to play. If even one of its designers 
gets stumped by it, do we really want to extend it even further?

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


[sage-devel] Re: math software and China

2014-01-22 Thread rjf

Implications?

Well, if you want to make Magma V2.20 free, just get a copy from China.
Or Mathematica.
etc.

The people who break the licensing code might also insert malware, so you
might not want to run it on an internet-connected computer. And you might
want to be secretive about your little criminal activity.

Eventually China might start respecting copyrights; after all there is
a Microsoft Research presence in Beijing. Someday.
RJF

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


[sage-devel] Re: Python class inheriting from MPolynomialRing_libsingular?

2014-01-22 Thread Nils Bruin
On Wednesday, January 22, 2014 8:43:36 PM UTC-8, Nils Bruin wrote:


 It surprises me that the MPolynomialRing_generic instance does have an 
 __init_extra__ attribute. Where does that come from? does it get supplied 
 by some custom get somewhere?


Yes, it does:

sage.structure.parent.Parent.__getattr__ claims to look on Parent and on 
self._category.parent_class for attributes. It tries to cache these things, 
though. Has it been tested that that is actually necessary? python is 
supposed to have an attribute lookup cache for types (I can't find a PEP 
but here's a Python Issue related to it 
http://bugs.python.org/issue1700288). This cache is pretty necessary for 
decent performance (its absence in cdef classes was for a while responsible 
for certain method calls being faster than straight attribute access on 
objects with long mro's, leading to the mistaken belief that cached no-arg 
methods were faster than straight attributes. Cython has luckily been fixed 
since)


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


[sage-devel] Re: Python class inheriting from MPolynomialRing_libsingular?

2014-01-22 Thread Nils Bruin
On Wednesday, January 22, 2014 11:10:24 PM UTC-8, Nils Bruin wrote:

 sage.structure.parent.Parent.__getattr__ claims to look on Parent and on 
 self._category.parent_class for attributes.

Moreover, it makes me wonder why we even bother with dynamic classes:

sage: [C.__getattribute__ for C in type(R).mro()]
[slot wrapper '__getattribute__' of 'sage.structure.parent.Parent' 
objects,
 slot wrapper '__getattribute__' of 'sage.structure.parent.Parent' 
objects,
...another 7 times ...
 slot wrapper '__getattribute__' of 'object' objects,
...very many times...]

If we're implementing inherited attribute lookup ourselves, why are we 
bothering doing it 9 times? And why are we adding all these parents to the 
mro that will not be visited any way for a useful reason, because the first 
`__getattr__` will already have taken care of the lookup?

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