[sage-devel] Re: Coercion trouble

[David Roe]

The code for residue field is currently not correct.  In converting a number
field element, it expresses it in terms of a power basis for the number
field and then casts the coefficients to Z/pZ.  But the coefficients can
have denominators divisible by p in general.  That's probably what's causing
your problem.

William and I have been talking about rewriting it so that residue field
computes a p-maximal order and then does things appropriately, but it hasn't
gotten done yet.
David

On Nov 15, 2007 8:57 PM, mabshoff <
[EMAIL PROTECTED]> wrote:

>
>
>
> On Nov 16, 1:30 am, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
> > Hi folks,
>
> Hello Ifti,
>
> >
> > I run into some coercion trouble when I reduce a fourier coefficient
> > of a cusp form modulo a prime ideal. (See below.)
> >
> > Any idea how I can avoid this?
> >
>
> No clue for now, but that looks like a bug to me. Please file a bug
> report.
>
> Cheers,
>
> Michael
>
> > Regards,
> > Ifti
> > ===
> >
> > sage: M = ModularSymbols(77, 2)
> >
> > sage: s = M.cuspidal_subspace().new_subspace()
> >
> > sage: N = s.decomposition()
> >
> > sage: f = N[3].q_eigenform()
> >
> > sage: R = f.base_ring()
> >
> > sage: K = R.number_field()
> >
> > sage: O = K.ring_of_integers()
> >
> > sage: I = O.ideal(7)
> >
> > sage: F = O.residue_field(I)
> >
> > sage: F(f[2])
> >
> ---
> >  Traceback (most recent call
> > last)
> >
> > /home/burhanud/tau_nov14_07/ in ()
> >
> > /home/burhanud/tau_nov14_07/residue_field.pyx in
> > sage.rings.residue_field.ResidueFiniteField_givaro.__call__()
> >
> > /home/burhanud/tau_nov14_07/finite_field_givaro.pyx in
> > sage.rings.finite_field_givaro.FiniteField_givaro.__call__()
> >
> > : unable to coerce
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion trouble

[David Roe]

I lost internet connection and then lost the traceback when my machine
restarted, so if you could open a ticket on the __rpath issue, I would
apprectiate it.

The residue field problem is ticket 1183.
David

On Nov 15, 2007 9:29 PM, David Roe <[EMAIL PROTECTED]> wrote:

> I lost internet connection and then lost the traceback when my machine
> restarted, so if you could open a ticket on the __rpath issue, I would
> apprectiate it.
>
> I'll open a ticket on the residue field issue though. Or check to see if
> one exists already.
> David
>
>
> On Nov 15, 2007 9:13 PM, mabshoff <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> >
> > On Nov 16, 3:05 am, "David Roe" <[EMAIL PROTECTED]> wrote:
> > > The code for residue field is currently not correct.  In converting a
> > number
> > > field element, it expresses it in terms of a power basis for the
> > number
> > > field and then casts the coefficients to Z/pZ.  But the coefficients
> > can
> > > have denominators divisible by p in general.  That's probably what's
> > causing
> > > your problem.
> > >
> > > William and I have been talking about rewriting it so that residue
> > field
> > > computes a p-maximal order and then does things appropriately, but it
> > hasn't
> > > gotten done yet.
> > > David
> >
> > David,
> >
> > could you please open a ticket then. I was also wondering if you ever
> > opened a ticket about the --rpath issue that caused compilation
> > failure on OSX when moving the install. I can't find it, so if you
> > don't want to open that one let me know and I will do.
> >
> > Cheers,
> >
> > Michael
> >
> > >
> > > On Nov 15, 2007 8:57 PM, mabshoff <
> > >
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > On Nov 16, 1:30 am, Iftikhar Burhanuddin < [EMAIL PROTECTED]> wrote:
> > > > > Hi folks,
> > >
> > > > Hello Ifti,
> > >
> > > > > I run into some coercion trouble when I reduce a fourier
> > coefficient
> > > > > of a cusp form modulo a prime ideal. (See below.)
> > >
> > > > > Any idea how I can avoid this?
> > >
> > > > No clue for now, but that looks like a bug to me. Please file a bug
> > > > report.
> > >
> > > > Cheers,
> > >
> > > > Michael
> > >
> > > > > Regards,
> > > > > Ifti
> > > > > ===
> > >
> > > > > sage: M = ModularSymbols(77, 2)
> > >
> > > > > sage: s = M.cuspidal_subspace().new_subspace()
> > >
> > > > > sage: N = s.decomposition()
> > >
> > > > > sage: f = N[3].q_eigenform()
> > >
> > > > > sage: R = f.base_ring()
> > >
> > > > > sage: K = R.number_field()
> > >
> > > > > sage: O = K.ring_of_integers()
> > >
> > > > > sage: I = O.ideal(7)
> > >
> > > > > sage: F = O.residue_field(I)
> > >
> > > > > sage: F(f[2])
> > >
> > > >
> > ---
> > > > >  Traceback (most recent
> > call
> > > > > last)
> > >
> > > > > /home/burhanud/tau_nov14_07/ in ()
> > >
> > > > > /home/burhanud/tau_nov14_07/residue_field.pyx in
> > > > > sage.rings.residue_field.ResidueFiniteField_givaro.__call__()
> > >
> > > > > /home/burhanud/tau_nov14_07/finite_field_givaro.pyx in
> > > > > sage.rings.finite_field_givaro.FiniteField_givaro.__call__()
> > >
> > > > > : unable to coerce
> > > >
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Power series rings

[David Roe]

Hey all,
At some point in the near future I may try to bring the implementation of
power series rings more into line with the p-adics.  The single variable
case seems straightforward, but a something popped up for me when thinking
about the multivariable case.

What is the appropriate analogue of laurent series?  Is the key point for
laurent series that we allow bounded negative exponents?   Or that it's a
field?  Because allowing bounded negative exponents is not enough to always
have inverses: x + y has no inverse if we require the exponents of x and y
to be bounded away from negative infinity.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: writing a new class

[David Roe]

This is one of the things I'd been planning on adding to the new programming
guide.

Your issue is that you're creating a new directory.  When you do that, you
have to add that directory to the list of packages at the bottom of
setup.pyin sage-root/devel/sage-branch/
You should also put an __init__.py file in your new directory, and probably
also an all.py file that controls the imports of that directory for the sage
namespace.

Things get more complicated if you want to add cython files, but you're not
doing that at the moment.
David

On Nov 20, 2007 7:03 AM, Jason Grout <[EMAIL PROTECTED]> wrote:

>
> Hi everyone,
>
> I have a simple question: I'm trying to write a new class in a new file.
>  How do I get that file to show up in Sage?  In this case, I'm trying
> to write a menu.py file under the sage/server/notebook/widgets directory
> (a  new directory).  But when starting up SAGE with sage -br, it doesn't
> ever say anything about my file and I can't import my file like a normal
> Sage object (i.e., from sage.server.notebook.widgets import menu).
>
> Thanks,
>
> Jason
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: ArithmeticError

[David Roe]

It's fixed (patch posted to trac).  As suspected, it was a bug introduced in
the ell_rational_field refactoring.
David


On Nov 21, 2007 12:25 PM, William Stein <[EMAIL PROTECTED]> wrote:

>
> On Nov 20, 2007 1:40 PM, Paul Zimmermann <[EMAIL PROTECTED]> wrote:
> >William,
> >
> > sage told me to report you, thus I do:
> [... see below]
>
> For the particular curve you're considering mwrank (via sage's rank
> command)
> can compute the rank -- which is what you want -- in 0.5 seconds, so maybe
> you can use .rank() instead?
>
> {{{id=24|
> e = EllipticCurve([0, 33076156654533652066609946884, 0,
> 347897536144342179642120321790729023127716119338758604800,
> 114112815436927429551902303280680424778815462104985764887003237028585178\
> 135281664])
> }}}
>
> {{{id=27|
> time e.rank()
> ///
> 1
> CPU time: 0.00 s,  Wall time: 0.46 s
> }}}
>
> That said, the fact that  e.torsion_order() fails is certainly a bug:
>
> {{{id=29|
> e.torsion_order()
> ///
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/Users/was/sage_notebook/worksheets/admin/23/code/91.py", line
> 4, in 
> ...
>self.__torsion_subgroup =
> rational_torsion.EllipticCurveTorsionSubgroup(self, flag)
>  File
> "/Users/was/s/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/rational_torsion.py",
> line 56, in __init__
>self.__E.__pari_double_prec()
> AttributeError: 'EllipticCurve_rational_field' object has no attribute
> '_EllipticCurveTorsionSubgroup__pari_double_prec'
> }}}
>
> This is now trac #1237
>   http://trac.sagemath.org/sage_trac/ticket/1237
> and it probably won't be too hard to fix.  I suspect it was caused perhaps
> by David Roe's recent refactoring of the code for elliptic curve over QQ,
> but I couldn't be completely wrong.
>
>
> > sage: d = 919681/88529281
> > sage: _ = magma.eval('K := Rationals()')
> > sage: _ = magma.eval('P:=ProjectiveSpace(K,2)')
> > sage: def rank(d):
> > :s='f := (x^2+y^2)*z^2-z^4-('
> > :s=''.join([s, repr(d), ')*x^2*y^2;'])
> > :magma.eval(s)
> > :magma.eval('C:=Curve(P,f);')
> > :E = magma('EllipticCurve(C,C![0,1,1])')
> > :l = E.aInvariants()
> > :EE = EllipticCurve(map(Integer,l))
> > :return EE.simon_two_descent()[0]
> > :
> > sage: rank(d)
> >
> ---
> > Traceback (most recent call
> last)
> >
> > /home/zimmerma/ in ()
> >
> > /home/zimmerma/ in rank(d)
> >
> > /usr/local/sage-2.8.12/sage/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py
> in simon_two_descent(self, verbose, lim1, lim3, limtriv, maxprob,
> limbigprime)
> > 858 (8, 8)
> > 859 """
> > --> 860 if self.torsion_order() % 2 == 0:
> > 861 raise ArithmeticError, "curve must not have rational
> 2-torsion\nThe *only* reason for this is that I haven't finished
> implementing the wrapper\nin this case.  It wouldn't be too
> difficult.\nPerhaps you could do it?!  Email me ([EMAIL PROTECTED])."
> > 862 F = self.integral_weierstrass_model()
> >
> > /usr/local/sage-2.8.12/sage/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py
> in torsion_order(self)
> >1743 return self.__torsion_order
> >1744 except AttributeError:
> > -> 1745 self.__torsion_order = self.torsion_subgroup
> ().order()
> >1746 return self.__torsion_order
> >1747
> >
> > /usr/local/sage-2.8.12/sage/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py
> in torsion_subgroup(self, flag)
> >1781 return self.__torsion_subgroup
> >1782 except AttributeError:
> > -> 1783 self.__torsion_subgroup =
> rational_torsion.EllipticCurveTorsionSubgroup(self, flag)
> >1784 return self.__torsion_subgroup
> >1785
> >
> > /usr/local/sage-2.8.12/sage/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/rational_torsion.py
> in __init__(self, E, flag)
> >  54 G = self.__E.pari_curve().elltors(flag)
> >  55 except RuntimeError:
> > ---> 56 self.__E.__pari_double_prec()
> >  57 if G is None:
> >  58 raise RuntimeError, "Could not compute torsion
> subgroup"
> >
> > : 'EllipticCurve_rational_field'
> object has no attribute '_EllipticCurveTorsionSubgroup__pari_double_prec'
> >
> > Paul
> >
>
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~-

[sage-devel] Re: Talk about SAGE at Les Trophees du Libre 2007 competition

[David Roe]

I have to agree.  The slide where you list p-adic numbers, p-adic
L-functions and p-adic height pairings kinda jumped out at me.  While I'm
obviously interested in that kind of stuff, it won't appeal as much to a
non-specialist audience.

One might argue that as things implemented natively in Sage, these will
count toward the innovation category.  Perhaps, but then you should
emphasize that aspect, and tone down the words that the judges will have
never heard before (ie p-adics).  And I think Philippe does have a point
that Sage does a lot in the innovation category that is more widely
applicable.
David

On Nov 25, 2007 2:35 PM, Philippe Saade <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> don't you think you should add examples closer to "applied math" as
> Discreet Fourier transform, financial math, Finite Element Method, etc
> ?
>
> Some explanations :
> I am a french teacher and if the Jury is not aware of the importance
> of p-adic stuff or Elliptic Curve story, it will all appear quiet a
> mystery. A lot of research labs, university or schools could be happy
> with sage. And i think your presentation should insist on the fact
> that SAGE can be used by a huge amount of people and not only
> specialists (mathematicians...). It's true that SAGE is great for
> professional mathematicians, but it can also do a great job in
> education...
>
> More images might help the jury to be convinced of it...
>
> Hope my remarks will help (and let me say your work is very good
> already...)
>
> Best regards,
> philippe Saadé
>
> On Nov 25, 2007 4:14 PM, Martin Albrecht <[EMAIL PROTECTED]>
> wrote:
> >
> > Hi there,
> >
> > Sage is among the finalists of this year's Les Trophees du Libre
> competition
> > in Paris, France.
> >
> > http://www.tropheesdulibre.org/+Finalists-projects?lang=en
> >
> > I am going to represent Sage at the finals (each project has to give a
> 30
> > minute presentation) and thus prepared some slides available at:
> >
> >
> http://sage.math.washington.edu/home/malb/20071129%20-%20SAGE%20-%20Paris/
> >
> > cetril.pdf is the presentation, SAGE_Demo.sws the demo worksheet, and
> > SAGE_Demo.pdf the PDF version of that demo. The target audience is a
> group of
> > people who want to promote open-source but probably are not into
> mathematics
> > at all. So presenting that we have a very sophisticated model for p-adic
> > arithmetic and comparing Sage with Magma might not do the trick. (but
> Sage is
> > in the 'scientific software' section, so it is okay to talk a little
> about
> > mathematics ;-))
> >
> > The rules for the competition also indicate what the judges are going to
> be
> > looking for:
> >
> > """
> > All the software will be tested and evaluated according to the criteria
> set
> > out below:
> > - Innovation (coefficient of 3)
> > - Functionality (coefficient of 3)
> > - Quality/stability (coefficient of 3)
> > - Durability (coefficient of 3)
> > - Utility (coefficient of 4)
> > - Documentation (coefficient of 3)
> > - Ease of installation (coefficient of 1)
> > - General renown (coefficient of -15)
> > """
> >
> > I believe I've addressed these points implicitly (and I prefer to
> address them
> > implicitly) but I'd appreciate feedback on the talk and demo. Also, what
> else
> > could go into a demo for non-mathematicians? Is your name missing in the
> list
> > of contributes (I generated that from the hg logs)?
> >
> > Cheers,
> > Martin
> >
> > --
> > name: Martin Albrecht
> > _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> > _www: 
> > http://www.informatik.uni-bremen.de/~malb
> > _jab: [EMAIL PROTECTED]
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: patch for SymPy <--> SAGE conversion, please review

[David Roe]

Addition not commuting there bothers me.  I can see why it's happening: a
SymPy object doesn't call into the coercion system.  One possible solution
is to have coercion map sage objects into sympy, so both s+o and o+s (in
line 134 and 135 of test_sympy.py) would be SymPy objects.  Is SymPy and the
SymbolicRing canonically isomorphic?  Can every SymbolicRing element be cast
into SymPy?
David

On Nov 25, 2007 9:13 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> I fixed my bad patch, now it passes all tests in 2.8.14:
>
> http://sagetrac.org/sage_trac/ticket/1189
>
> the main patch (also linked from the ticket) in text form browsable over
> web:
>
> http://sagetrac.org/sage_trac/attachment/ticket/1189/sympy2.patch
>
> Could someone familiar with coerce.pyx review it please? It's actually
> a very simple patch, but it could possibly cause troubles later
> (mabshoff knows:).
>
> Thanks a lot,
> Ondrej
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: patch for SymPy <--> SAGE conversion, please review

[David Roe]

> I don't think so, since probably sage/maxima have special functions
> sympy doesn't.  And even if it could be, the functions provided by
> SymPy are different
> than the ones provided by SymbolicRing.
>
> If sympy('x') + x and x + sympy('x') are totally different in Sage I
> will be unhappy about
> that.Either the result has to always be in SymPy or always in Sage
> or we have to get
> an error and request that the user explicitly do a coercion.
>
> We have to decide on a canonical map in exactly one direction, and I
> prefer
>
>SymPy ---> SymbolicRing,
>
> just because SymbolicRing is more native in Sage, and probably could be
> improved
> so it would support any SymPy expression (yes -- I know this isn't
> true now, unfortunately).


I would prefer that direction too.  In order to make that happen, the SymPy
__add__ function has to recognize a sage element and call its __add__ method
instead.  This sounds like it should be doable.


> Now that I read through #1189 patch, I'm uncomfortable with
>
>   return _verify_canonical_coercion_c(x,y)
>
> The function _verify_canonical_coercion_c is supposed to be like
>
>   assert(parent(x) is parent(y))
>
> it's *never* supposed to be called when the parents are different -- if it
> is,
> that means there is a bug.  However, you're using it to test whether the
> parents are different, and if so do some other behavior (i.e., eventually
> raise
> a TypeError).   So that makes me nervous.  It would be better to just
> directly do a call to the have_same_parent function, like in the
> implementation
> of _verify_canonical_coercion_c in coerce.pxi.



Agreed.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage equivalents for Maple number theory functions

[David Roe]

Excellent list!  Maybe I should take a break from p-adics and do some of
these.  Some of the gaps should be quite easy to fill in.
David

On Nov 30, 2007 12:45 PM, Stephen Forrest <[EMAIL PROTECTED]> wrote:

>
> Hello all,
>
> I've lurked on this list for a time, commenting little because I am
> not yet familiar with Sage.  Some time ago on this list, there was
> some discussion of what number-theoretic functionality Maple
> has that Sage still lacks.
>
> Since I have a substantial background in Maple, as a exercise in
> learning Sage I have compiled a list of number-theoretic
> Maple functions along with any Sage equivalent that is available.  The
> results are available here:
>
> http://wandership.ca/projects/sage/numtheory-SAGE.html
>
> Any questions, corrections, or other comments are welcome.
>
> regards,
>
> Steve
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Sparse SVD

[David Roe]

My housemates have been writing a Python wrapper for SVDLIBC (a C library
that does SVDs for sparse and dense matrices over the reals) using Swig.  I
suggested that they use Cython instead and thought that this might make a
good spkg.  I've asked a few people about sparse SVDs, and I think Sage
currently has no mechanism to do this.  Thoughts?  At some point I'll
probably ask for help on IRC in making an spkg since I've only been involved
in writing library code and not at all on the spkg side of things.

The website for SVDLIBC:
http://tedlab.mit.edu/~dr/SVDLIBC/

David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factor ideals at NF

[David Roe]

The issue is that since Sage uses pari to do everything in the background,
one needs to create the pari data structures, which means that you currently
call nfinit on the number field, which computes the class group and unit
group.  This should change eventually, but right now...
David

On Dec 29, 2007 2:10 PM, Enrique Gonzalez-Jimenez <
[EMAIL PROTECTED]> wrote:

>
> As John Cremona said at the sage.forum: "But why would Sage be
> computing the class group in order to factor 2 in K?"
>
>
> For me that is strange too. Since it would be easier to compute the
> factorization of an ideal generate by a prime.
>
> For example: Using the Proposition that asserts that if K is a number
> field and the ring of integers is of the form O_K=Z[alpha] (where f(t)
> is the minimal polynomial over Z of alpha) then to compute the
> factorization of the ideal O_K where p is a rational prime is
> enough to factorize f(t)mod p. That is, if
> f(t)=f_1(t)^r_1...f_s(t)^r_s (mod p) then the factorization on prime
> ideal is of the form
>
> O_K=^r_1...^r_s.
>
> Enrique
>
> On 29 dic, 21:42, Bill Hart <[EMAIL PROTECTED]> wrote:
> > It presumably can't compute the class group, because of the proof=true
> > thing. Basically if you want a proven result, it is going to take
> > forever and will need more primes than Pari has precomputed.
> >
> > It's not clear to me if SAGE is actually catching the error message,
> > or if it is just raising an exception because Pari did something it
> > wasn't expecting (i.e. print an error message).
> >
> > Bill.
> >
> > On 29 Dec, 20:27, mabshoff <[EMAIL PROTECTED]
> >
> > dortmund.de> wrote:
> > > On Dec 29, 9:17 pm, [EMAIL PROTECTED] wrote:
> >
> > > > Hello:
> >
> > > > I am working at my Number Theory lectures and I have found a bug
> (?). This is
> > > > the output:
> >
> > > > ///   SAGE 2.9.1   ///
> > > > sage: K.=CyclotomicField(23)
> > > > sage: O=K.maximal_order()
> > > > sage: (2*O).factor()
> > > >   ***   Warning: large Minkowski bound: certification will be VERY
> long.
> > > > Traceback (most recent call last):
> > > >   File "", line 1, in 
> > > >   File "/home/notebook/sage_notebook/worksheets/admin/3/code/13.py",
> > > > line 4, in 
> > > > exec compile(ur'(Integer(2)*O).factor()' + '\n', '', 'single')
> > > >   File
> > > > "/usr/local/sage/local/lib/python2.5/site-packages/sympy/plotting/",
> > > > line 1, in 
> >
> > > >   File "sage_object.pyx", line 92, in
> > > > sage.structure.sage_object.SageObject.__repr__
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/structure/factor\
> > > > ization.py", line 187, in _repr_
> > > > t = str(self[i][0])
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field_ideal.py", line 218, in __repr__
> > > > return "Fractional ideal %s"%self._repr_short()
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field_ideal.py", line 235, in _repr_short
> > > > return '(%s)'%(', '.join([str(x) for x in self.gens_reduced()]))
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field_ideal.py", line 553, in gens_reduced
> > > > dummy = self.is_principal(proof)
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field_ideal.py", line 714, in is_principal
> > > > bnf = self.number_field().pari_bnf(proof)
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field.py", line 1464, in pari_bnf
> > > > self.pari_bnf_certify()
> > > >   File
> > > >
> "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/number_fie\
> > > > ld/number_field.py", line 1497, in pari_bnf_certify
> > > > if self.pari_bnf(certify=False, units=True).bnfcertify() != 1:
> > > >   File "gen.pyx", line 6474, in sage.libs.pari.gen._pari_trap
> > > > sage.libs.pari.gen.PariError: not enough precomputed primes, need
> > > > primelimit ~  (35)
> >
> > > Hi Enrique,
> >
> > > this looks like a bug to me. I have seen this issue discussed before,
> > > but I cannot find any ticket in our bug tracker that relates to it. So
> > > I am hoping for somebody more familiar with the pari interface to
> > > voice an opinion.
> >
> > > Cheers.
> >
> > > Michael
> >
> > > > But if you type the following lines using gp interface, it works:
> >
> > > > sage: K=gp.bnfinit(cyclotomic_polynomial(23))
> > > > sage: gp.idealfactor(K,2)
> >
> > > > [[2, [1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > > 0]~, 1, 11, [1, 1, 0, 0, 0, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
> 0, 0,
> > > > 0, 0]~], 1; [2, [1, 1, 0, 0, 0, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0,
> 0,
> > > > 0, 0, 0, 0]~, 1, 11, [1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0,
> 0, 0,
> > > > 0, 0, 0, 0, 0]~], 1]
> >

[sage-devel] Re: anyone with osx 10.4 intel please test this for dvd

[David Roe]

It worked for me.
David

On Jan 6, 2008 1:08 AM, Joshua Kantor <[EMAIL PROTECTED]> wrote:

>
> Hello. for the dvd we are including a dmg file. There was some
> problems with the initial version of this. I believe the following is
> working,
> but if anyone else could test that following the instructions works
> fine on their system that would be appreciated. Again this is osx 10.4
> intel
>
>
> http://sage.math.washington.edu/home/jkantor/sage-2.9.2-osx10.4-intel-i386-Darwin.dmg
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] [sage-deve] anyone with osx 10.4 intel please test this for dvd

[David Roe]

> > David, can you test the md5sum of the downloaded .dmg file.
> > At the terminal
> > md5 
>
> FWIW, I get:
>
> MD5 (/SandBox/DownLoads/sage-2.9.2-osx10.4-intel-i386-Darwin.dmg) =
> 7bdaf64293d8136aa0d59c89b894ca79
>

I get the same:

MD5 (sage-2.9.2-osx10.4-intel-i386-Darwin.dmg) =
7bdaf64293d8136aa0d59c89b894ca79

For reference I used the finder to move the sage folder to Applications
rather than the command line.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: loading integer or float data from file into a matrix

[David Roe]

One way to do it is to use the Python functions on strings.  For example, if
you want to use the real double field (RDF) and matrix_data is your string,
the following should do what you want:
M = matrix(RDF, [b.split() for b in matrix_data.split('\n')])

The split method of a string creates a list of substrings that are separated
by a given separator, and the default separator is whitespace.
See the documentation on RDF to see if you want to use that, or RR or
something else.
David

On Jan 10, 2008 11:42 AM, myFalc <[EMAIL PROTECTED]> wrote:

>
> Hello!
> I'm new to sage and I already searched for a solution on the web, but
> couldn't find any.
> At the moment I'm trying to load a file into sage and put its data
> into a matrix. The file spans a matrix of thousands of float values.
> columns separated by whitespaces and rows separated by newlines.
> I was able to load the data into a string(or list) but i couldn't find
> out how to put the data into a matrix.
> e.g. M = Matrix(10,2,(string)) is not working.
> anyone with ideas or solutions?
>
> i used octave before, and it worked really easy there. unfortunately i
> can't use the octave load commands in sage since there are semicolons
> needed for the command which result in a syntax error.
>
> greetings
> markus
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: hodge number calculator

[David Roe]

That looks quite cool.

spkg's are generally for non-Python files.  The way to put a Python file
into sage is to convert your .sage file to a .py file (for example, changing
"^" to "**" throughout) and then putting it somewhere with the sage library
files (for example, in $SAGE_ROOT/devel/sage-main/sage/schemes/generic/)
Then you could, from the command line do from
sage.schemes.generic.hodge_numbers_ci import * and have access to all of
your functionality.  Once you do so, get an account on sage_trac (e-mail
William), post this as a ticket to include in Sage, get someone to review it
and you're all set.

At some point we need to get around to improving the documentation for
people in exactly your situation: just starting to contribute to the sage
library.  It was a project started at Sage Days 6, but hasn't gone very far
since then.

I like making a CompleteIntersection class eventually.
David

On Jan 14, 2008 8:38 AM, D. Benjamin Antieau <[EMAIL PROTECTED]>
wrote:

> To all,
>
> I've created a sage file to calculate, among other things, the Hodge
> numbers of an arbitrary complete intersection. Attached is the .sage file. I
> also attempted to create a .spkg file, but it does not seem to work. Mine
> contains simply a .py file that the install script puts it
> $SAGE_ROOT/local/bin. But, I cannot seem to use it from within sage. Any
> help on that front would be appreciated. On the other hand, loading the
> .sage file works fine.
>
> The file itself is well-documented. I would love suggestions for further
> methods to add. For instance, at some point I will add the ability to
> compute the degrees of the top Chern classes of a threefold.
>
> I don't see putting this in sage at the moment, but it does lead to the
> question: should there be a CompleteIntersection class, which would inherit
> from AlgebraicScheme_subscheme_projective. If so, then I could put this code
> in that class in the characteristic zero case.
>
> Ben Antieau
>
> Example:
>
> The Hodge numbers of a crazy fourfold. The list of integers is the list of
> degrees of the complete intersection.
>sage: hodge_numbers_ci([2,4,6,3,6,4,3,2,9,5],4)
>[  1   0   0   0  2658146543]
>[  0   1   0 22238665343   0]
>[  0   0 42452753184   0   0]
>[  0 22238665343   0   1   0]
>[ 2658146543   0   0   0   1]
>
> The file provides the following functions:
> chiy_characteristic_ci(degrees,index,yprecision,zprecision)
> hodge_numbers_ci(degrees,dimension)
> betti_numbers_ci(degrees,dimension)
> euler_characteristic_ci(degrees,dimension)
> topological_euler_characteristic_ci(degrees,dimension)
> arithmetic_genus_ci(degrees,dimension)
> geometric_genus_ci(degrees,dimension) [==arithmetic_genus_ci]
> K_squared_surface_ci(degrees,dimension) [computes the degree of K^2 of a
> complete intersection surface]
> c2_surface_ci(degrees,dimension) [computes the degree of the second Chern
> class of a complete intersection surface]
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Doc Day 1 announcement: January 17th, 2008, 9am-5pm PST

[David Roe]

Note that I just put up a ticket with patch (1795) that fixes sage-coverage
so that it checks cdef'd and cpdef'd functions and classes.
David

On Jan 16, 2008 12:00 PM, Martin Albrecht <[EMAIL PROTECTED]>
wrote:

>
> On Wednesday 16 January 2008, mabshoff wrote:
> > Hello folks,
> >
> > after doing 8 Bug Days the time has come to spend some more time on
> > the documentation, which also needs a lot of work. So after some
> > discussion in IRC we decided to get together in IRC at the above date
> > and time and work on the documentation. Since we have never done a doc
> > day it isn't 100% clear to me how the whole thing will go down, but I
> > assume we will just go with the flow.
> >
> > Thoughts? Suggestions?
>
> Suggestion: each participant goes through a file of his/her own choice and
> makes sure it has 100% doctest coverage. Reading the source of the
> possibly
> unfamiliar file is also encouraged.
>
> Martin
>
>
> --
> name: Martin Albrecht
> _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _www: 
> http://www.informatik.uni-bremen.de/~malb
> _jab: [EMAIL PROTECTED]
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Doc Day 1 announcement: January 17th, 2008, 9am-5pm PST

[David Roe]

My modification to sage-coverage checks to see that doctests are present in
the docstring of a cdef'd function but doesn't check that the function name
is there (because it usually won't be).
David

On Jan 16, 2008 2:24 PM, Nick Alexander <[EMAIL PROTECTED]> wrote:

>
>
> On 16-Jan-08, at 11:17 AM, Robert Bradshaw wrote:
>
> >
> > Sounds like a good idea--I'll be able to participate in the morning
> > at least. Do we want to require all cdef functions to have doctests?
> > Also, how to test them?
>
> I vote to require.  Presumably all cdef functions are exercised by
> some part of the python accessible code (otherwise, why are they
> present?).  Doctests in cdef docstrings are found by the doctesting
> architecture and executed.  So they will be tested, just not in the
> most straightforward way :)
>
> Nick
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Doc Day 1 announcement: January 17th, 2008, 9am-5pm PST

[David Roe]

> Of course, it'd be nice if every function had ample documentation,
> but I'd rather have 100% coverage on all user-accessible functions in
> two files, than 100% coverage in one file for def/cpdef and cdef
> functions. Also, often the "inderect" tests for cdef functions seem
> to be redundant with the doctests exposed functions.


The indirect doctests are sometimes reduntant.  But sometimes they are
things like _add_c_impl, which won't necessarily get doctested elsewhere.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Doc Day 1 announcement: January 17th, 2008, 9am-5pm PST

[David Roe]

With the modifications, our overall coverage is at 33.1%.
David

On Jan 16, 2008 2:56 PM, mabshoff <
[EMAIL PROTECTED]> wrote:

>
>
>
> On Jan 16, 8:51 pm, "David Roe" <[EMAIL PROTECTED]> wrote:
> > > Of course, it'd be nice if every function had ample documentation,
> > > but I'd rather have 100% coverage on all user-accessible functions in
> > > two files, than 100% coverage in one file for def/cpdef and cdef
> > > functions. Also, often the "inderect" tests for cdef functions seem
> > > to be redundant with the doctests exposed functions.
> >
> > The indirect doctests are sometimes reduntant.  But sometimes they are
> > things like _add_c_impl, which won't necessarily get doctested
> elsewhere.
> > David
>
> I think it can't hurt to test those. When I need to debug some odd
> crash on an experimental platforms with very abstract, high level code
> it would greatly help to narrow down the issue if those functions
> would also be doctested and exposed when I run -testall on the build.
> While it certainly is a lot of effort it would still be worth it. The
> only negative impact I would see is that our percentage of -
> coverageall would probably do drop quite a bit.
>
> Cheers,
>
> Michael
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: infinity

[David Roe]

The reason I put it in is that if you have signed infinities then you might
as well preserve the sign when you invert them, which means that you should
have a divider.  Yes, that means you sometimes get elements where you don't
know if it's positive or negative.  I think that's okay, but then I'm the
one that originally made the design decision, so
David



On Jan 17, 2008 9:52 AM, David Harvey <[EMAIL PROTECTED]> wrote:

>
> Hi folks (especially william + robert + david roe),
>
> I showed up for Doc Days 1 and started looking at the infinity and
> extended integer ring stuff.
>
> Question: why does the "unsigned infinity ring" not have a zero
> element, whereas the "(signed) infinity ring" has a zero?
>
> This is okay:
>
> sage: 0 / Infinity
> Zero
>
> But this is way confusing:
>
> sage: oo = UnsignedInfinityRing(Infinity)
> sage: 0 / oo
> A number less than infinity
>
> I totally expected the last output to be Zero. But it can't be,
> because the UnsignedInfinityRing doesn't have a zero element.
>
> On the other hand, if there's a zero element, then you start having
> issues with things like
>
> sage: UnsignedInfinityRing(2) - UnsignedInfinityRing(3)
>
> because you can't tell if it's zero or not.
>
> Thoughts?
>
> david
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: infinity

[David Roe]

So perhaps the solution to your problem is the extended integers (or
extended rationals).  This needs some work (both in terms of speed and with
having multiple types for elements of the same parent), but it does have the
benefit of returning 1 as the answer to 1 + 0/infinity.  Perhaps the default
sage infinity should be the infinity of the extended integers, and there's a
coercion map from the extended integers to the extended rationals to the
signed infinity ring to the unsigned infinity ring, as well as coercions
from the integers to the extended integers and the rationals to the extended
rationals.
David

On Jan 24, 2008 12:48 PM, Burcin Erocal <[EMAIL PROTECTED]> wrote:

>
> Hello,
>
> Today I witnessed a mathematica user struggling with Sage because of
> the way Sage handles infinity. On trac #1915 you can see an example.
>
> On Thu, 17 Jan 2008 09:52:32 -0500
> David Harvey <[EMAIL PROTECTED]> wrote:
>
> > Question: why does the "unsigned infinity ring" not have a zero
> > element, whereas the "(signed) infinity ring" has a zero?
> >
> > This is okay:
> >
> > sage: 0 / Infinity
> > Zero
>
> I don't think this is okay. In this case we get
>
> sage: 1 + 0/Infinity
> A positive finite number
>
> If 0/Infinity is 0, the result of this should be 1.
>
> > But this is way confusing:
> >
> > sage: oo = UnsignedInfinityRing(Infinity)
> > sage: 0 / oo
> > A number less than infinity
> >
> > I totally expected the last output to be Zero. But it can't be,
> > because the UnsignedInfinityRing doesn't have a zero element.
>
> I would also expect the output to be zero. Moreover, there should be a
> way of returning a numeric zero from these operations. Otherwise the
> coercion model gets confused, and everything ends up being coerced into
> "The Infinity Ring".
>
> sage: Infinity.parent()
> The Infinity Ring
>
>
> Thoughts?
>
> Burcin
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: differential forms

[David Roe]

What kinds of geometric objects do your forms live on?  Algebraic curves and
varieties?  Manifolds?  Manifolds with boundary?
David

On Feb 1, 2008 8:00 AM, Peter Storm <[EMAIL PROTECTED]> wrote:

>
> Hello,
>
> I would like to either develop or find a method for computing with
> differential forms in sage.  More specifically, the level of
> generality I'm looking for is the ability to manipulate differential
> forms with values in a Lie algebra.  I'd like to define the usual
> operations on forms (+, scaling, d, wedge) plus Riemannian operations
> which take into account a metric (Hodge star, a connection, the
> adjoint of d).  Such a tool would be useful to me for studying
> deformations of geometric structures on a manifold.
>
> Years ago, Steve Kerckhoff hacked together some Mathematica code for
> this purpose.  However, Mathematica's inability easily to define and
> manipulate objects makes it an unnatural choice.  I would like the
> data structures to be as close to the mathematical objects as
> possible.
>
> If anybody is working on something similar, please let me know.  For a
> warm-up, I'm already working on a toy 2d version of the above.
>
> Best,
> Pete Storm
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Add new structures to Sage: Parent and Element

[David Roe]

So, these kinds of issues were the subject of the coercion project at SD7.
Robert Bradshaw, Mike Hansen, Bobby Moretti and I are currently in the
process of changing a lot of the infrastructure behind parents, elements,
etc.  If you want to help (or want to see our current progress) see the
sprint page at http://wiki.sagemath.org/days7/coercion or contact one of us
via e-mail.

Given that, I'll answer your questions, both as Sage exists now and as we
see it existing in a few months.

I'm wondering if there is some documentation or a howto somewhere that
> describes the process of adding new structures to Sage.


We're working on this.  See the wiki page I referenced above for the current
progress.


> For example,
> we want to add poset functionality to Sage---Peter Jipsen and I began
> working on this at Sage Days 7. So we created a Poset class that
> inherits from ParentWithBase (because inheriting from Parent isn't
> support if I want to have elements---something that should be fixed, I
> guess),


Yup.  This will be one of the changes that we're making.  ParentWithBase and
ParentWithGens are both disappearing, and both generator and base
functionality is getting pushed up to CategoryObject (a superclass of
parent) so that you can have objects with generators and bases but without
elements.

For now you should probably inherit from ParentWithBase and have base =
self.


> and a PosetElement class that inherits from the Element class.


Yes, you should still be inheriting from Element.

If this is not correct, then someone should tell me now, and the
> better way to do this.
>
> Also, I have some technical questions.
>
> 1. Can someone describe to me how ParentWithBase works? Does each
> instance of Element store the parent poset? I imagine this is not the
> case as it would mean several copies of the Parent will be stored in
> memory. So it's some kind of identifier for the poset?


This is the case, because elements need to know their parent.  Since Python
objects are stored as pointers, this isn't a huge memory overhead.  But you
can just treat it as storing the parent, and get access to it by calling
self.parent().


> 2. My PosetElement class accepts two arguments: the Parent poset P and
> a label for the poset element. The problem I am having here is that I
> can create an instance of PosetElement with Parent poset P, but this
> element won't belong to P (and it shouldn't). But then the parent
> function returns P on this new element. Here is a psuedo-example:
>
> sage: P = FinitePoset([0,1,2])
> sage: y = PosetElement(P,3)
> sage: parent(y) == P
> True
> sage: y in P
> False


Your __init__ method on the element should check to see if the input it gets
generates a valid element of the parent.  If it doesn't, raise a ValueError.

One generally doesn't expose the element class directly to the user.
Instead, the better behavior is to use the __call__ method on Parent and the
write P(3).

I'm probably messing something up with my class definitions. (I'm new
> to OOProgramming and Sage.) I'm including a very basic implementation
> of the classes below. Any suggestions?
>
> Take care,
> Franco
>
> --
>
> from sage.structure.element import Element
>
> class FinitePoset(ParentWithBase):
>def __init__(self,data=None):
>Parent.__init__(self)
>self.elements=[]
>if not data is None:
>for x in data:
>self.elements.append(PosetElement(self,x))


You can write "data is not None" if you want: Python has an "is not"
operator.

   def __contains__(self,x):
>return x in self.elements
>
>def list(self):
>return self.elements
>
> class PosetElement(Element):
>def __init__(self,poset,label):
>Element.__init__(self,poset)


This __init__ method should check that the label actually belongs to the
parent.  You can have a parameter check, by default True, which is able to
disable this checking.

Let me know if you have more questions.
And for those of you out there interested in coercion, I'll have my bundle
posted as soon as I get a chance to tie off some loose ends.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 2.10.2.alpha0 released!

[David Roe]

This is doctest where the result used to be
Traceback (most recent call
last):

...

TypeError: cannot create a p-adic out of 

but after the p-adics patch it started working and returning p.  I looked at
it briefly and couldn't figure out why it was doing so.
David

On Fri, Feb 15, 2008 at 3:16 PM, Jaap Spies <[EMAIL PROTECTED]> wrote:

>
> mabshoff wrote:
> > 
>
> >>  sage -t
>  devel/sage-main/sage/rings/polynomial/multi_polynomial.pyx
> >
> > That is a new one. Could you post the detailed failure?
> >
>
>
> [EMAIL PROTECTED] sage-2.10.2.alpha0]$ ./sage -t
>  devel/sage-main/sage/rings/polynomial/multi_polynomial.pyx
> sage -t
>  
> devel/sage-main/sage/rings/polynomial/multi_polynomial.pyx**
> File "multi_polynomial.pyx", line 256:
> sage: R(S.0)
> Expected:
> BROKEN -- FIX ME
> Got:
> p
> **
> 1 items had failures:
>1 of  14 in __main__.example_4
> ***Test Failed*** 1 failures.
> For whitespace errors, see the file .doctest_multi_polynomial.pyx
>  [2.0 s]
> exit code: 256
>
> Jaap
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 2.10.2.rc0 release!

[David Roe]

> Here are the pow_computer failures:
> sage -t  devel/sage-main/sage/rings/padics/pow_computer.pyx
> **
> File "pow_computer.pyx", line 160:
>sage: PC._pow_mpz_t_tmp_demo(6, 8)
> Expected:
>244140625
> Got:
>152587890625
> **
> 1 items had failures:
>   1 of   6 in __main__.example_5
> ***Test Failed*** 1 failures.
> For whitespace errors, see the file .doctest_pow_computer.pyx
> [5.3 s]
> sage -t
>  
> devel/sage-main/sage/rings/padics/pow_computer_ext.pyx**
> File "pow_computer_ext.pyx", line 613:
>sage: PC._pow_ZZ_tmp_demo(6, 8)
> Expected:
>244140625
> Got:
>152587890625
> **
> 1 items had failures:
>   1 of   6 in __main__.example_11
> ***Test Failed*** 1 failures.


These are due to function calls being made in a different order.  It's not a
problem: these functions are intended to demonstrate pitfalls of using
pow_mpz_t_tmp and pow_ZZ_tmp dangerously.  Patch posted at 2259.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: exact cover problem

[David Roe]

In this context I think that binary means all the entries are 1s and zeros.
But when you look for a set of rows that add up to [1,1,1,...], you don't
consider 1+1=0.  This makes sense when you want only one 1 to appear in each
column, which is a natural requirement, and makes the problem much harder.
In particular, you don't get to use linear algebra because your arithmetic
isn't taking place over a field.
David

On Fri, Feb 22, 2008 at 4:10 PM, John Cremona <[EMAIL PROTECTED]>
wrote:

>
> The original problem said "binary matrix" so surely that means mod 2?
> And I would expect mod 2 matrices to come up in the graph theory
> applications.  Not that I know about that...
>
> John
>
> On 22/02/2008, William Stein <[EMAIL PROTECTED]> wrote:
> >
> >  On Fri, Feb 22, 2008 at 12:50 PM, David Harvey
> >  <[EMAIL PROTECTED]> wrote:
> >  >
> >  >
> >  >  On Feb 22, 2008, at 3:49 PM, William Stein wrote:
> >  >
> >  >  >
> >  >  > On Fri, Feb 22, 2008 at 12:04 PM, Jason Grout
> >  >  > <[EMAIL PROTECTED]> wrote:
> >  >  >>
> >  >  >>  [EMAIL PROTECTED] wrote:
> >  >  >>> I've found a nice implementation of the DLX algorithm, which
> >  >  >>> "quickly" solves the NP-Complete exact cover problem.  For those
> >  >  >>> who aren't in Seattle and haven't heard me blathering on and on
> >  >  >>> and on and on about how awesome DLX is...
> >  >  >>>
> >  >  >>> Let M be a binary matrix.  An exact cover is a subset of the
> rows
> >  >  >>> of the matrix who sum (exactly) to the vector 1,1,...,1.
> >  >  >>>
> >  >  >
> >  >  > Isn't that exactly the same thing as solving
> >  >  >
> >  >  >M*x = [1,...,1],
> >  >  >
> >  >  > over GF(2)?
> >  >
> >  >  I think it's probably not mod 2.
> >  >
> >  >  david
> >
> >
> > Oh, that's a good point.  I guess things become a lot easier when 1+1 =
> 0.
> >
> >
> >  William
> >
> >
> >  >
> >
>
>
> --
> John Cremona
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: some more entries for sagemath.org/pub.html

[David Roe]

A friend of mine also pointed out the following, which uses Sage to compare
runtimes for different algorithms:
Dan Boneh, Craig Gentry, Michael Hamburg. http://crypto.stanford.edu/~dabo/pubs.html";>Space-efficient identity based
encryption without pairings (37 pages), Proceedings FOCS 2007.
David


On Sat, Feb 23, 2008 at 10:33 AM, Alex Ghitza <[EMAIL PROTECTED]> wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Patrick Ingram, http://arxiv.org/abs/0802.2651";>Multiples of
> integral points on elliptic curves (29 pages), 2008.
>
> Nicholas J. Cavenagh, Carlo Hamalainen, Adrian M. Nelson,  href="http://arxiv.org/abs/0712.0233";>On completing three cyclic
> transversals to a latin square (13 pages), 2007.
>
> Chris A. Kurth, Ling Long,  href="http://arxiv.org/abs/0710.1835";>Computations with finite index
> subgroups of $PSL_2(\mathbb Z)$ using Farey symbols (16 pages), 2007.
>
> David Harvey, http://arxiv.org/abs/0708.3404";>Efficient
> computation of p-adic heights (18 pages), 2007.
>
> David Harvey, http://arxiv.org/abs/math/0610973";>Kedlaya's
> algorithm in larger characteristic (21 pages), 2006.
>
> John Voight, http://arxiv.org/abs/0802.0194";>Enumeration of
> totally real number fields of bounded root discriminant (14 pages),
> 2008.
>
> David Loeffler, http://arxiv.org/abs/0801.3176";>Explicit
> calculations of automorphic forms for definite unitary groups (19
> pages), 2008.
>
> Jonathan Sondow, Kyle Schalm,  href="http://arxiv.org/abs/0709.0671";>Which partial sums of the Taylor
> series for $e$ are convergents to $e$? (and a link to the primes 2, 5,
> 13, 37, 463) (13 pages), 2007.
>
>
>
>
>
>
> - --
> Alexandru Ghitza
> Assistant Professor
> Department of Mathematics
> Colby College
> Waterville, ME 04901
> http://bayes.colby.edu/~ghitza/ 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHwDzDdZTaNFFPILgRAiwRAJwMEsSvRhefdgjalS11nyekdvsvnQCfUJ4X
> YxBcJDwX8ACy30T8kP5fV+k=
> =2BrF
> -END PGP SIGNATURE-
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: set_si & set_str in Integer

[David Roe]

I think they should still exist, but should be cdef'd.  This means I can
interface between C longs and sage Integers without having to reach in and
grab n.value, but one can't use them to make Integers mutable in Python.  A
function get_si() would also be useful if it did bounds checking so that I
don't have to worry about the mpz_t not fitting in a long.
David

On Mon, Mar 3, 2008 at 8:02 AM, Joel B. Mohler <[EMAIL PROTECTED]>
wrote:

>
> Hi,
>
> These methods set_si & set_str violate immutability:
> sage: n=300
> sage: n.set_si(12)
> sage: n
> 12
>
> Shouldn't they be called _set_unsafe_xx?  Better yet, shouldn't they be
> deleted altogether since I can't find anywhere they are used in code aside
> from doc-tests?  Or, was that the point -- to doc-test something?
>
> The Rational object also has these methods.
>
> --
> Joel
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: set_si & set_str in Integer

[David Roe]

I was not suggesting eliminating the ability to directly access .value from
Cython.  Rather, I see set_si() and get_si() as convenience functions so
that if the only thing you're doing is converting back and forth between
sage integer and long, one can use object oriented notation (and so that you
don't have to rewrite the overflow checking each time: I've done that over
and over).
David

On Mon, Mar 3, 2008 at 10:34 AM, Carl Witty <[EMAIL PROTECTED]> wrote:

>
> On Mar 3, 5:42 am, "David Roe" <[EMAIL PROTECTED]> wrote:
> > I think they should still exist, but should be cdef'd.  This means I can
> > interface between C longs and sage Integers without having to reach in
> and
> > grab n.value, but one can't use them to make Integers mutable in Python.
>  A
> > function get_si() would also be useful if it did bounds checking so that
> I
> > don't have to worry about the mpz_t not fitting in a long.
> > David
>
> I disagree.  I think we should either allow the use of .value in
> Cython code or ensure that the WHOLE of the GMP API is available
> through methods on Integer.  Since the latter is a huge chunk of work
> for no benefit, I think the former is the way to go.
>
> So +1 for deleting the methods.
>
> Carl
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: set_si & set_str in Integer

[David Roe]

Fixing the ubiquitous accessing of .value would be far more work that it's
worth.  The main functionality that I would like is a get_si() with bounds
checking.  Given that, I think having a set_si as well is reasonable.
David

On Mon, Mar 3, 2008 at 9:36 AM, Joel B. Mohler <[EMAIL PROTECTED]>
wrote:

>
> On Monday 03 March 2008 08:42:53 am David Roe wrote:
> > I think they should still exist, but should be cdef'd.  This means I can
> > interface between C longs and sage Integers without having to reach in
> and
> > grab n.value, but one can't use them to make Integers mutable in Python.
>  A
> > function get_si() would also be useful if it did bounds checking so that
> I
> > don't have to worry about the mpz_t not fitting in a long.
> > David
>
> That would be fine with me.  Although, we already violate the information
> hiding aspect quite a bit -- that is, we already access n.value quite
> freely
> from matrix and vector code (for instance).  So, I'm not sure that that is
> worth talking about -- although maybe your point was that we should
> respect
> the private-ness of value and fix all that?
>
> In any case, the real point is that this should be removed from tab
> completion
> list and cdef'ing them would do that.
>
> --
> Joel
>
> >
> > On Mon, Mar 3, 2008 at 8:02 AM, Joel B. Mohler <[EMAIL PROTECTED]>
> >
> > wrote:
> > > Hi,
> > >
> > > These methods set_si & set_str violate immutability:
> > > sage: n=300
> > > sage: n.set_si(12)
> > > sage: n
> > > 12
> > >
> > > Shouldn't they be called _set_unsafe_xx?  Better yet, shouldn't they
> be
> > > deleted altogether since I can't find anywhere they are used in code
> > > aside from doc-tests?  Or, was that the point -- to doc-test
> something?
> > >
> > > The Rational object also has these methods.
> > >
> > > --
> > > Joel
> >
> >
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: repr or input_form or some way of getting the code to create an object

[David Roe]

I agree with the choice of _sage_init_.  By default this can return
self._repr_(), but should be overridden in cases like matrix.
David

On Wed, Mar 5, 2008 at 1:32 AM, Robert Bradshaw <
[EMAIL PROTECTED]> wrote:

>
> _sage_init_ sounds like the right solution. The problem is that for
> many objects, printing all the information that would make them
> reproducible is really ugly. For example, if I have
>
> [1 2]
> [3 4]
>
> Is this over the integers, or the rationals, or the integers mod 17?
> Or perhaps it's a symbolic matrix, or over a polynomial ring of a
> finite field of a particular modulus. Of course, this could be
> incorporated into the representation, but one doesn't usually want to
> see it unless it is explicitly asked for.
>
> For this reason, most of the focus has been on having good pickling/
> unpicking support.
>
> - Robert
>
>
> On Mar 4, 2008, at 10:59 AM, Jason Grout wrote:
>
> > This morning I tried to copy a matrix output, edit it, and create a
> > new
> > matrix.  It was frustrating because there seemed to be no way to
> > easily
> > cut and paste output into input.  This afternoon a person I was
> > showing
> > Sage to also had the same concern.
> >
> > There has been discussion before on the python convention of str
> > versus
> > repr, especially in light of the python docs:
> >
> > "repr(object)
> >  Return a string containing a printable representation of an
> > object.
> > This is the same value yielded by conversions (reverse quotes). It is
> > sometimes useful to be able to access this operation as an ordinary
> > function. For many types, this function makes an attempt to return a
> > string that would yield an object with the same value when passed to
> > eval()."
> >
> > For matrices, repr() and str() yield the same output which is pretty
> > much useless to try to cut and paste back into input.
> >
> > Please let me know if
> >
> >   * I should not implement repr for matrices and graphs in
> > accordance to
> > the python docs.
> >
> >   * There is another function, like the input_form that mabshoff
> > suggested on 2386, which could give a code-like representation of an
> > object if possible?
> >
> >
> > Thanks,
> >
> > Jason
> >
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: linear algebra in Cython

[David Roe]

There are tons of examples of things in the sage library: just look for .pyx
files.  In particular, many of the matrix files are written in cython: look
in sage.matrix.

For loops, use the syntax:
cdef Py_ssize_t i
cdef long n = 17
for i from 0 <= i < n:
do_stuff()

Hope this helps.
David

On Fri, Mar 7, 2008 at 9:52 PM, Vincent <[EMAIL PROTECTED]> wrote:

>
> I would like to implement some Bayesian routines using Cython. I have
> looked at some of the Cython examples but they don't really provide
> enough information for a newbie like me. As a starting point i'd like
> to implement bootstrapping of OLS parameter standard errors. That
> would give me an idea of how to implement (1) linear algebra in
> Cython, i assume by calling routines from Numpy in some way, (2)
> random number generators for sampling, and (3) running loops.
>
> I anyone has any (simple) examples of how to do something like this in
> Cython i'd love to see them. Also, if there are better ways to do this
> than through Cython i'd luv to hear your suggestions.
>
> Thanks,
>
> Vincent
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Bring back the XOR

[David Roe]

Note that the function that is called by "^" is __xor__.  So you can already
do a.__xor__(b).  If you want to write the function that David describes,
calling a.__xor__(b) is better than using eval.
David

On Mon, Mar 10, 2008 at 6:34 AM, David Joyner <[EMAIL PROTECTED]> wrote:

>
> Another solution (avoiding the preparer) is to simply define
>
> sage: def xor(a,b):  return eval("%s^%s"%(a,b))
> :
> sage: xor(1,0)
> 1
> sage: xor(1,1)
> 0
>
> which mimics the native Python behavior:
>
> Python 2.5.1 (r251:54863, Oct  5 2007, 13:50:07)
> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> 1^0
> 1
> >>> 1^1
> 0
>
>
> On Mon, Mar 10, 2008 at 5:30 AM, vgermrk <[EMAIL PROTECTED]> wrote:
> >
> >  Since the preparser replaces "^" with "**"  (which is good!),
> >  i want a way to access the python-buildin-XOR again.
> >
> >  I suggested in IRC that the preparser should also replace "xor" with
> >  "^",
> >  so that one can do   "5 xor 3".
> >  But since i did not convince everybody (on IRC), let's discuss here
> >  about it.
> >
> >  So what do you think?
> >
> >  -vgermrk-
> >  >
> >
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Multivariable LaurentSeries Ring?

[David Roe]

It's in progress.  See http://trac.sagemath.org/sage_trac/ticket/2291
David

On Thu, Mar 27, 2008 at 9:28 AM, bump <[EMAIL PROTECTED]> wrote:
>
>  On Feb 19, 1:27 pm, "David Roe" <[EMAIL PROTECTED]> wrote:
>
>  > This should be pretty easy (though multivariable Laurent series rings have
>  > all kinds of issues associated with them).  I don't have time to implement
>  > it right now, but if nobody has done it before the weekend poke me and I 
> can
>  > probably throw something together.
>  > David
>
>  Did anything ever come of this? Multivariable Laurent polynomials
>  would
>  be extremely useful.
>
>  Daniel Bump
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Summing up a list only *linear*?

[David Roe]

Splitting it like this still yields a linear algorithm.  If f(n) is
the time to add a list of length n, then you have
f(n) = 2*f(n/2), so f(n) is linear.
David

On Mon, Mar 31, 2008 at 1:04 AM, Simon King <[EMAIL PROTECTED]> wrote:
>
>  Dear Sage team,
>
>  i made a few timings with the "sum" function:
>
>  sage: L2=range(100)
>  sage: L3=range(1000)
>  sage: L4=range(1)
>  sage: L5=range(10)
>  sage: L6=range(100)
>  sage: timeit('a=sum(L2,0)')
>  625 loops, best of 3: 299 µs per loop
>  sage: timeit('a=sum(L3,0)')
>  125 loops, best of 3: 1.35 ms per loop
>  sage: timeit('a=sum(L4,0)')
>  25 loops, best of 3: 13.6 ms per loop
>  sage: timeit('a=sum(L5,0)')
>  5 loops, best of 3: 138 ms per loop
>  sage: timeit('a=sum(L6,0)')
>  5 loops, best of 3: 1.37 s per loop
>
>  So, it seems that the time grows about linearly in the length of the
>  list. Shouldn't it be possible to have it growing logarithmically?
>  Namely when sum(L) splits L into two sub-lists L0,L1 of about the same
>  size and returns sum(L0)+sum(L1)? Or would this introduce a huge
>  overhead?
>
>  I am not a computer scientist, so perhaps i am mistaken. Where is the
>  source code of the sum function?
>
>  Yours
>Simon
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Output Form versus Internal Structure

[David Roe]

Separate from the coercion model, I have some ideas for changing where
printing code lives (see the section on printers at the bottom of
http://www.sagemath.org:9001/days7/coercion).  I agree that it should
be easy to implement output into other formats, and I'll keep that in
mind when I actually sit down to implement printer objects.
David

On Tue, Apr 1, 2008 at 2:33 PM, root <[EMAIL PROTECTED]> wrote:
>
>  Robert,
>
>  I briefly looked over your coercion model.
>
>  _repr_ This is the easiest way to define how your object prints
>It should take a string representing your object
>I takes one argument, do_latex
>
>
>  I might comment that Axiom uses an output domain that exports functions
>  for constructing the print representation of its objects. This design
>  has made it possible for an object to print itself in various ways.
>
>  Over time Axiom has implemented many different output forms, such as
>  script (an IBM internal scripting language), algebra (the default 2D
>  ascii output), LaTeX, FORTRAN, and most recently MathML, used in the
>  new Firefox front end.
>
>  You might consider a design that allows the end user the option of
>  specifying the desired output form as decoupled from the object
>  structure.
>
>  Tim Daly
>  Axiom
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Output Form versus Internal Structure

[David Roe]

That's the plan.  Though I'll have to ask around to figure out how to
determine if _repr_ is being called from the notebook or iPython.
David

On Tue, Apr 1, 2008 at 7:01 PM, Dan Drake <[EMAIL PROTECTED]> wrote:
> Robert Bradshaw wrote:
>  > Thanks for your input. We are considering a more advanced model
>  > (David Roe has lots of ideas on this front), but this falls outside
>  > of the central focus coercion scheme. (This is one reason to use
>  > _repr_ rather than the Python __repr__ so that the base object's
>  > __repr__ can do more sophisticated things (although now it just calls
>  > _repr_).
>
>  I would really like something like this. For example, take Young
>  tableaux: when working in the Sage interpreter, I might want a tableau
>  to print out like this:
>
>7532
>642
>632
>1
>
>  but in the notebook interface, or for including into a LaTeX document, I
>  might want the tableau to print out a TikZ picture environment:
>
>   \begin{tikzpicture}
> \draw ...
>   \end{tikzpicture}
>
>  Also, Francophones will want those same things printed upside down. :)
>  So more flexibility, and multiple printed representations, would be very
>  nice.
>
>  Dan
>
>  --
>  ---  Dan Drake <[EMAIL PROTECTED]>
>  -  KAIST Department of Mathematical Sciences
>  ---  http://math.kaist.ac.kr/~drake
>
> -BEGIN PGP SIGNATURE-
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFH8ujrr4V8SljC5LoRAv81AJ0YtScjIEi9FCAQ9uk12ZcIJcCTJwCeK1Nc
>  fs73ezUTiHz0Dj+6Cf2F2f0=
>  =hS/w
>  -END PGP SIGNATURE-
>
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adic crash error

[David Roe]

I'm back from my three week trip to the west coast and will take a look at this.
David

On Mon, Apr 7, 2008 at 11:16 AM, Kiran Kedlaya <[EMAIL PROTECTED]> wrote:
>
>  Jen Balakrishnan spent time with some of the usual suspects during the
>  Arizona Winter School tracking down bugs in the p-adics, but more
>  remain. We've isolated a code snippet that makes sage 2.11 go boom on
>  multiple platforms:
>  {{{
>  sage: R. = QQ[]
>  sage: K = Qp(11,10)
>  sage: J. = K.extension(x^30-11)
>  sage: M. = PowerSeriesRing(J)
>  sage: S. = QQ[]
>  sage: xr = O(a^152)*t + (8*a^2 + 10*a^32 + 7*a^62 + 10*a^92 + 7*a^122
>  + O(a^152))*t^2 + O(a^154)*t^3 + (2*a^4 + 10*a^64 + 2*a^124 +
>  O(a^154))*t^4 + O(a^156)*t^5 + (5*a^6 + 2*a^96 + a^126 + O(a^156))*t^6
>  + O(a^158)*t^7 + (7*a^8 + 6*a^38 + 8*a^68 + 2*a^98 + 5*a^128 +
>  O(a^158))*t^8 + O(a^160)*t^9 + (8*a^10 + 10*a^40 + a^70 + 5*a^130 +
>  O(a^160))*t^10 + O(a^162)*t^11 + (9*a^12 + 7*a^42 + 8*a^72 + 6*a^102 +
>  9*a^132 + O(a^162))*t^12 + O(a^164)*t^13 + (2*a^14 + 5*a^44 + 3*a^74 +
>  a^104 + 4*a^134 + O(a^164))*t^14 + O(a^166)*t^15 + (2*a^16 + 5*a^46 +
>  8*a^76 + 5*a^106 + 7*a^136 + O(a^166))*t^16 + O(a^168)*t^17 + (7*a^18
>  + 3*a^48 + 6*a^78 + 9*a^138 + O(a^168))*t^18 + O(a^172)*t^19 + (7*a^50
>  + 3*a^80 + 5*a^110 + 5*a^140 + 7*a^170 + O(a^172))*t^20 +
>  O(a^172)*t^21 + (a^22 + a^52 + 3*a^82 + 3*a^112 + 2*a^142 +
>  O(a^172))*t^22 + O(a^174)*t^23 + (4*a^24 + 7*a^54 + 9*a^84 + 4*a^114 +
>  7*a^144 + O(a^174))*t^24 + O(a^176)*t^25 + (3*a^26 + 8*a^56 + 8*a^116
>  + 5*a^146 + O(a^176))*t^26 + O(a^178)*t^27 + (2*a^28 + 2*a^58 + 6*a^88
>  + a^118 + 10*a^148 + O(a^178))*t^28 + O(a^180)*t^29 + (8*a^30 + 5*a^60
>  + 8*a^90 + 5*a^120 + 6*a^150 + O(a^180))*t^30 + O(a^184)*t^31 +
>  (7*a^62 + 9*a^92 + 2*a^182 + O(a^184))*t^32
>  sage: yr = xr^2
>  sage: dtr = xr.derivative()
>  sage: f_dtr = yr*dtr # boom
>  FFTRep: inconsistent use
>  (and then sage exits uncleanly)
>  }}}
>  I wasn't able to find a shorter value of xr that reproduces this
>  (removing the t^32 term alleviates the error).
>
>  We've opened ticket #2843 for this.
>
>  Kiran
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: trouble running n() on matrices

[David Roe]

If you take a look at the source code for n(), you'll see that the
first thing that it does is to try calling numerical_approx(prec) on
the object, and then tries coercing to real or complex fields.  So the
solution is to write a method numerical_approx(prec) in the matrix
base class that tries to numerically approximate the entries and make
a new matrix out of them.

This is now ticket 2857.
David

On Tue, Apr 8, 2008 at 2:32 AM, Dan Drake <[EMAIL PROTECTED]> wrote:
> Hello all,
>
>  I'm running into problems with coercing to complexes or reals in
>  matrices:
>
>   sage: d = matrix([[3, 0],[0,sqrt(2)]])
>   sage: b = matrix([[1, -1], [2, 2]])
>   sage: e = b * d * b.inverse(); e
>
>   [1/sqrt(2) + 3/2 3/4 - 1/(2*sqrt(2))]
>   [3 - sqrt(2) 1/sqrt(2) + 3/2]
>
>  and when I try to run n() on the matrix e, I get:
>
>   sage: e.n()  # or n(e)
>   [snip]
>   : unable to coerce to a ComplexNumber
>
>  but I can run n() on all the entries of e:
>
>   sage: n(e[0,0])
>   2.20710678118655
>   sage: n(e[1,0])
>   1.58578643762690
>   sage: n(e[1,1])
>   2.20710678118655
>   sage: n(e[0,1])
>   0.396446609406726
>
>  Also, I can't run .n() on the matrix b, even though it's an integer
>  matrix!
>
>   sage: parent(b)
>   Full MatrixSpace of 2 by 2 dense matrices over Integer Ring
>   sage: b.n()
>   [same as before]
>   : unable to coerce to a ComplexNumber
>
>  Yikes! It can't coerce integers into complexes! But in other situations,
>  there's no trouble:
>
>   sage: n(5)
>   5.00
>   sage: parent(sqrt(2))
>   Symbolic Ring
>   sage: n(sqrt(2))
>   1.41421356237310
>
>  It seems clear that when I have a matrix with expressions like
>  "1/sqrt(2) + 3/2" and I run n() on it, I want the obvious floating point
>  approximations.
>
>  Am I going about this wrong? Is this not a correct use of matrices? Or
>  is it a coercion bug? Any help is much appreciated.
>
>  Dan
>
>  --
>  ---  Dan Drake <[EMAIL PROTECTED]>
>  -  KAIST Department of Mathematical Sciences
>  ---  http://math.kaist.ac.kr/~drake
>
> -BEGIN PGP SIGNATURE-
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFH+xGBr4V8SljC5LoRAmTfAJ9+otZSqPbrD3UjUYsnu6eB5I7rRQCeOnWl
>  g/ob45B+hjZ6mNjKC0a1T9I=
>  =tjOf
>  -END PGP SIGNATURE-
>
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adic crash error

[David Roe]

I think Willem fixed this bug.  I've made the same change a few other
places and added a doctest.
David

On Mon, Apr 7, 2008 at 11:16 AM, Kiran Kedlaya <[EMAIL PROTECTED]> wrote:
>
>  Jen Balakrishnan spent time with some of the usual suspects during the
>  Arizona Winter School tracking down bugs in the p-adics, but more
>  remain. We've isolated a code snippet that makes sage 2.11 go boom on
>  multiple platforms:
>  {{{
>  sage: R. = QQ[]
>  sage: K = Qp(11,10)
>  sage: J. = K.extension(x^30-11)
>  sage: M. = PowerSeriesRing(J)
>  sage: S. = QQ[]
>  sage: xr = O(a^152)*t + (8*a^2 + 10*a^32 + 7*a^62 + 10*a^92 + 7*a^122
>  + O(a^152))*t^2 + O(a^154)*t^3 + (2*a^4 + 10*a^64 + 2*a^124 +
>  O(a^154))*t^4 + O(a^156)*t^5 + (5*a^6 + 2*a^96 + a^126 + O(a^156))*t^6
>  + O(a^158)*t^7 + (7*a^8 + 6*a^38 + 8*a^68 + 2*a^98 + 5*a^128 +
>  O(a^158))*t^8 + O(a^160)*t^9 + (8*a^10 + 10*a^40 + a^70 + 5*a^130 +
>  O(a^160))*t^10 + O(a^162)*t^11 + (9*a^12 + 7*a^42 + 8*a^72 + 6*a^102 +
>  9*a^132 + O(a^162))*t^12 + O(a^164)*t^13 + (2*a^14 + 5*a^44 + 3*a^74 +
>  a^104 + 4*a^134 + O(a^164))*t^14 + O(a^166)*t^15 + (2*a^16 + 5*a^46 +
>  8*a^76 + 5*a^106 + 7*a^136 + O(a^166))*t^16 + O(a^168)*t^17 + (7*a^18
>  + 3*a^48 + 6*a^78 + 9*a^138 + O(a^168))*t^18 + O(a^172)*t^19 + (7*a^50
>  + 3*a^80 + 5*a^110 + 5*a^140 + 7*a^170 + O(a^172))*t^20 +
>  O(a^172)*t^21 + (a^22 + a^52 + 3*a^82 + 3*a^112 + 2*a^142 +
>  O(a^172))*t^22 + O(a^174)*t^23 + (4*a^24 + 7*a^54 + 9*a^84 + 4*a^114 +
>  7*a^144 + O(a^174))*t^24 + O(a^176)*t^25 + (3*a^26 + 8*a^56 + 8*a^116
>  + 5*a^146 + O(a^176))*t^26 + O(a^178)*t^27 + (2*a^28 + 2*a^58 + 6*a^88
>  + a^118 + 10*a^148 + O(a^178))*t^28 + O(a^180)*t^29 + (8*a^30 + 5*a^60
>  + 8*a^90 + 5*a^120 + 6*a^150 + O(a^180))*t^30 + O(a^184)*t^31 +
>  (7*a^62 + 9*a^92 + 2*a^182 + O(a^184))*t^32
>  sage: yr = xr^2
>  sage: dtr = xr.derivative()
>  sage: f_dtr = yr*dtr # boom
>  FFTRep: inconsistent use
>  (and then sage exits uncleanly)
>  }}}
>  I wasn't able to find a shorter value of xr that reproduces this
>  (removing the t^32 term alleviates the error).
>
>  We've opened ticket #2843 for this.
>
>  Kiran
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adic crash error

[David Roe]

No, I forgot to change it back.  Use the patch I posted instead, which
changes all the eis_shift_a's back to eis_shift.  The p-adics folder
passes sage -t now.
David

On Thu, Apr 10, 2008 at 8:53 PM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
>  On Apr 11, 12:35 am, "David Roe" <[EMAIL PROTECTED]> wrote:
>  > I think Willem fixed this bug.  I've made the same change a few other
>  > places and added a doctest.
>  > David
>
>  Hi David,
>
>  I posted a one line patch to make you patch compile. It is attached to
>  #2843. Can you have a look? craigcitro just said in IRC that you
>  intend to remove the extra "_a"
>
>  Cheers,
>
>  Michael
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: integers beginning with zero

[David Roe]

On the other hand, using a leading zero to indicate octal is a fairly
standard convention in computer science.  And it's nice to minimize
these kinds of differences between Python ints and Sage Integers.
David

On Sun, Apr 13, 2008 at 3:36 PM, Harald Schilly
<[EMAIL PROTECTED]> wrote:
>
>  On Apr 13, 9:08 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>  > the other option -- changing
>  > Python -- is not an option.
>  >
>
>  I know, but my "picture" is a high-school teacher explaining that
>  leading zeros don't matter, and when someone tries it in sage, it
>  suddenly matters. So, imho, there is something not ok with that. The
>  preparser could filter this, also depending its behaviour based on the
>  current mode. And the inconsistency should be fixed, too.
>
>  Harald
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Noncanonical coercion (finite fields)

[David Roe]

On Mon, Apr 14, 2008 at 12:23 PM, Craig Citro <[EMAIL PROTECTED]> wrote:
>
>  Actually, Conway polynomials don't cut it in general, in the sense
>  that one can't actually generate them for sufficiently large finite
>  fields. Even Magma doesn't know them in the sizes that Willem is
>  talking about:
>
>  > ConwayPolynomial(3,100);
>^
>  Runtime error in 'ConwayPolynomial': A conway polynomial for GF(3^100) is not
>  known
>
>  David Roe and I (and probably some other people) talked about this way
>  back at SD3, and ultimately decided that we had no idea what Magma was
>  doing. ;) David (and/or others) may have discovered more by now. Magma
>  definitely has a way on deciding on a default choice, in the sense
>  that if you create the finite fields in the same order, the same
>  polynomial is generated between different Magma runs. It's interesting
>  that it changes when you change the order you created the fields with
>  -- I don't recall us discovering this way back when. I also find this
>  somewhat interesting -- though it's probably just the fact that it's
>  checking something for consistency:
>
>  [EMAIL PROTECTED] ~]  $ magma
>  Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513]
>  Type ? for help.  Type -D to quit.
>  > time F := FiniteField(3^100);
>  Time: 0.050
>  > time K := FiniteField(3^200);
>  Time: 3.470
>  >
>
>  Total time: 4.190 seconds, Total memory usage: 8.39MB
>  [EMAIL PROTECTED] ~]  $ magma
>  Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938]
>  Type ? for help.  Type -D to quit.
>  > time K := FiniteField(3^200);
>  Time: 0.420
>  > time F := FiniteField(3^100);
>  Time: 0.050
>  >
>
>  That paper is particularly frustrating -- if you're trying to figure
>  out exactly this, you end up getting referred around the paper a few
>  times, only to discover a paragraph where they say "and in the case
>  that the Conway polynomial can't be found, we make another default
>  choice." Wow, thanks. :)
>
>  -cc
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Noncanonical coercion (finite fields)

[David Roe]

Grrr... I clicked reply, and then tried to click on the text field to
begin typing, and it scrolled down at exactly the wrong moment and the
right amount so that I clicked send insteady.  Sorry about that.

>  David Roe and I (and probably some other people) talked about this way
>  back at SD3, and ultimately decided that we had no idea what Magma was
>  doing. ;) David (and/or others) may have discovered more by now. Magma
>  definitely has a way on deciding on a default choice, in the sense
>  that if you create the finite fields in the same order, the same
>  polynomial is generated between different Magma runs. It's interesting
>  that it changes when you change the order you created the fields with
>  -- I don't recall us discovering this way back when. I also find this
>  somewhat interesting -- though it's probably just the fact that it's
>  checking something for consistency:

I haven't worked on this much, aside from keeping it in mind when
designing the coercion system.  Once we have the coercion branch
merged back in, we should have the appropriate framework for writing
all this and making it happen in an appropriately automatic fashion.

As for timeline, the conclusion that Robert and Michael came to sounds
reasonable to me.  I'll try to finish the work we want to do before
the 3.0 release so that once 3.0 comes out we can just merge.

When the coercion release comes (which sounds like 3.1), Robert and I
will write about how YOU can help.  :-)  Basically, we're trying to
make the global changes that need to happen all at once across all of
Sage, but there will be a lot of places where we've left intermediate
solutions in place: keeping the current functionality of Sage
operational while transforming the structure to make improvement
possible on a local scale.  As a result, there will be lots of little
things that you can do, in your favorite part of Sage, to take
advantage of the new framework.  We'll give you more details in a few
weeks.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage -n?

[David Roe]

I would prefer sage -n, because -b suggests build to me, so sage -nb
would be rebuild and then start the notebook.
David

On Tue, Apr 15, 2008 at 1:29 PM, didier deshommes <[EMAIL PROTECTED]> wrote:
>
>  On Tue, Apr 15, 2008 at 1:11 PM, Kiran Kedlaya <[EMAIL PROTECTED]> wrote:
>  >
>  >  Currently the command-line option to start sage directly in (secure)
>  >  notebook mode is -notebook. What do people think of adding a shorter
>  >  alternative, such as sage -n? If people are wary about assigning
>  >  single-letter options, then sage -nb is another possibility.
>
>  I would prefer sage -nb
>
>  didier
>
>
>
>  >
>  >  Kiran
>  >
>  >  >
>  >
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: possible package for inclusion in Sage

[David Roe]

+1 from me as well.  There have been a few times recently when I've
wished Sage included a component for solving linear programming or
integer programming optimization problems.
David

On Sun, Apr 20, 2008 at 11:20 AM, Harald Schilly
<[EMAIL PROTECTED]> wrote:
>
>  On Apr 20, 4:42 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>  > OpenOpt
>
>  +1
>
>  I've already requested it some time ago I think. Since I've a strong
>  background in numerical optimization and computation, i know about the
>  difficulties involved. Inclusion would help to expose OpenOpt to a
>  larger userbase and forces him to release higher quality releases
>  (doctests and so on). Also very useful for education and
>  experimentation.
>  The only thing not compatible with Sage is the interactive plotter -
>  this is a graphic pop window showing a realtime view of how the
>  optimization process currently works, but that's just a trivial
>  problem. Another difficulty could be cross platform availability of
>  included solvers, but that's pluggable anyway.
>
>
>
>  h
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: Project

[David Roe]

On Sun, Apr 20, 2008 at 5:13 PM, TimDaly <[EMAIL PROTECTED]> wrote:
>
>  > I'm surprised by how convinced you are that using a specific
>  > technology/language -- literate programming -- can be a silver
>  > bullet to solve such a difficult problem.  I think peer review,
>  > and many many other things, are steps in the right direction,
>  > but *not* solutions to the problem.  I think it's just a difficult
>  > problem, with no easy solutions.
>
>  Actually, I don't think that literate programming is a silver bullet.
>  But I do think that it exposes the real work that is needed to make
>  something like Sage live (see my power-of-3 screed a while back).
>
>  If Gary is going to figure out "the way up the mountain face"
>  wouldn't it make sense to write it down so others can read it?
>  Or is it better to let the next person figure it out (badly) from
>  reading the code and inferring the path?

Yes, it would be great if Gary could write that down, write a book
about it and let us know how it went.  But Gary has only finite time,
and lots of things he wants to do with it.  He has to choose what the
best use of his time is.  And there's a lot of work that goes into
making a book that has little to do with a direct explanation of what
this line/section of code does.

There's a distinction between the style of "literate programming" and
writing documentation within your code so that others can understand
what it's doing.  I understand the argument that you want the writing
to be "explanation-centric" rather than "code-centric."  But writing
documentation in other ways can serve to explain what you're doing to
future readers as well.  For me, I'm happy when I write good comments:
I don't want to take the time to write a book surrounding my code.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Coercion

[David Roe]

Hey,
If you want to log onto sage-devel, I'm working on coercion and had a
few things to talk about.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Initial support for posets

[David Roe]

+1: Lattice as abelian group with inner product.
-1: Lattice as poset with meet and join

(of course I'm biased by number theory, though I admit that I have
heard of the second kind of lattice.  ;-)

That being said, I'm glad people are working on the poset kind of
lattice: I'd wanted to do so for a while, but too many other projects
intervened.  I'll try to chip in a bit.

David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Initial support for posets

[David Roe]

One thing that Python has going for it here is that it's object
oriented.  So f.differentiate() is disambiguated because f has a type.

The time when this doesn't help is object creation (thus the issue for
Lattices).  It's worth having this discussion, and I agree that names
matter, but the problem isn't quite as extensive as might be feared.
:-)
David

On Thu, Apr 24, 2008 at 4:00 PM, root <[EMAIL PROTECTED]> wrote:
>
>  >Sage just uses the mainstream language Python; we are
>  >not in the language design business.  It's an interesting
>  >exercise to think through how each of the ideas you generously
>  >explained above is expressed using Python.
>
>  This is a general purpose python idea, actually. If there was
>  a python function that looked at the namespace available for
>  each .py file then it could decide that there are two lattice
>  functions. This could issue an "import lattice from poset"
>  to disambiguate the lattice question automatically. (I have no
>  idea how you might look at a .py file and get its namespace).
>
>  This is not a new issue because Sage already has several different
>  polynomials available to it at any given time. The user has to
>  specify which one to call by naming the spkg tool explicitly.
>  Thus the various spkgs split the namespace at the moment.
>
>  As more functionality migrates from the external packages into
>  "Sage-native python" this issue will grow worse. Which package
>  gets to own the name "differentiate"? Axiom shows 25 different
>  functions of that name, e.g. polynomials vs power series.
>
>  Suppose the user wants to use the "same name" in the "same sentence"
>  (e.g. differentiate(poly)*differentiate(powerseries)). How is
>  this resolved? Does the user have to do special imports? How
>  will the user know that there are 50 differentiates from 7
>  different spkgs (25 from Axiom alone) and 6 from python packages?
>
>  It is an explicit design decision of the user interface to decide
>  whether there is an automatic resolution or a user-specified
>  resolution. It would be worthwhile to have a discussion of this
>  design decision before it gets "encoded by default" as a result
>  of the lattice discussion.
>
>  I don't think that Axiom's solution can work for Sage because
>  Axiom is a strongly typed language. But it does highlight at
>  least one other point in the space of design decisions.
>
>  Names matter.
>
>  Tim
>
>
>
>
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: A Sage Enhancement Proposal: Lattice Modules

[David Roe]

I am in fact planning on reimplementing finitely generated abelian
groups soon, so my vote would be to have the quotient of lattices L/L'
(with L' a full sublattice or not) be an abelian group A with a
canonical map L -> A.
David

On Mon, Apr 28, 2008 at 2:33 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
>  On Mon, Apr 28, 2008 at 11:29 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>  >
>  >  David, I don't think you understood my suggestion.   We are talking
>  >  about groups A which are finitely-generated and torsion-free, so
>  >  abstractly isomorphic to Z^n, together with a suitable blinear
>  >  function on AxA taking values in Z or Q, and I wish to include R
>  >  -valued forms.
>
>  John see below.
>
>
>  >
>  >  2008/4/28 David Joyner <[EMAIL PROTECTED]>:
>  >
>
>
> >  >  >  3. Implement a LatticeQuotient class (for now, just full sublattices,
>  >  >  >  i.e., finite quotients).
>  >  >  >   -- Inherit from FreeModule_ZZ_quotient?
>  >  >  >   -- Inherit from AbelianGroup?
>  >  >
>  >  >  -1 is my vote on this. Infinite AbelianGroup instances are not
>  >  >  completely implemented.
>
>  I think David is -1'ing *only* having LatticeQuotient inherit from 
> AbelianGroup,
>  not the entire proposal.  His reasoning is that AbelianGroup is not
>  implemented sufficiently well in Sage, and perhaps he feels some 
> responsibility
>  related to this since he did the current AbelianGroup implementation in Sage.
>
>  I disagree with David -- if AbelianGroup is the right thing to derive
>  form (I'm not saying it is!),
>  but AbelianGroups aren't "good enough", the right thing to do is fix them.
>  Don't underestimate the boundless energy and capabilities of the students
>  working on this project.  Either Robert Miller or David Roe could
>  likely do in a day or
>  two whatever needs to be done with the AbelianGroup class to make it
>  substantially
>  better for the purposes of the above proposal.
>
>   -- William
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.2 merge cycle opened

[David Roe]

I'm not going to be able to work much more on coercion until next
week, and I don't get the impression that Robert has much time this
week either.  It's probably best to put coercion off until after
3.0.2.
David

On Mon, May 5, 2008 at 11:44 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>  Hello folks,
>
>  as you might have notices 3.0.1 is finally out. We currently have
>  nearly fifty patches in trac, i.e.
>
>  http://trac.sagemath.org/sage_trac/report/13
>
>  Feel free to review patches and obviously also upload more fixes.
>  3.0.2 is also supposed to be another bug fix release with few deep
>  changes. It would be interesting to see the status of the coercion
>  rewrite to get an idea how to plan the rest of the release cycle.
>
>  Other than that we have Bug Day 12 this Saturday, so this should be
>  work that mostly flows into 3.0.2 [provided we didn't screw up and do
>  not need a quick fix release].
>
>  Cheers,
>
>  Michael
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: infinity

[David Roe]

So, I think I was the one to rework infinity most recently.  I don't
really have time today to expand at length on the issues you brought
up, but I agree with them to some extent.  I will note that a coercion
is "a natural map into the object," which is why your first example
failed, but the __call__ in the second example asks to "create an
element of the infinity ring if at all possible", which is why the
second does work.

It is possible to have an algebraic infinity in the case of an
arbitrary field k by looking defining P^1(k), though of course this
isn't an ordered field (it's actually not even a field at all!).

Anyway, I'd be happy to help think about ways to make infinity in Sage
more mathematically rigorous while keeping it useful.  But this
evening I have a take home final to finish.  :-)
David

On Tue, May 13, 2008 at 3:23 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>
>  I've been looking at some of the trac tickets.  Two of them caught my
>  eye, and I'm curious about them:
>
>  http://trac.sagemath.org/sage_trac/ticket/2515
>
>  http://trac.sagemath.org/sage_trac/ticket/1915
>
>  Both of them deal with Infinity. In the first one, someone suggests
>  doing away with ExtendedRationalField and ExtendedIntegerRing, because
>  Infinity should be handled by the code in sage.rings/infinity.py.  In
>  the second one, it is pointed out that evaluating 1/Infinity yields
>  "Zero" in the "infinity ring", whereas maybe it should yield the
>  element 0 in some "numeric domain".
>
>  The documentation in infinity.py says that in the infinity ring
>
>  > The rules for arithmetic are that the unsigned infinity ring does not 
> canonically
>  > coerce to any other ring, and all other rings canonically coerce to
>  > the unsigned infinity ring, sending all elements to the single element
>  > ``a number less than infinity'' of the unsigned infinity ring.
>
>  I have two issues with this: first, things don't quite behave as
>  expected:
>
>  sage: a=GF(2)(1)
>  sage: a/Infinity   # expect this to give Zero, or maybe "A number less
>  than infinity"
>  Traceback (click to the left for traceback)
>  ...
>  TypeError: unsupported operand parent(s) for '/': 'Finite Field of
>  size
>  2' and 'The Infinity Ring'
>
>  However, this does work:
>
>  sage: UnsignedInfinityRing(a)
>  A number less than infinity
>
>  Second, I disagree with the mathematics described in the documentation
>  (and I agree more or less with the first aspect above of Sage's
>  behavior): I don't think there is any good notion of infinity
>  associated to, say, a finite field.  I object to elements of a finite
>  field being coerced to something *less* than infinity, since there is
>  no intrinsic ordering on them.  I also object to elements of, say, a
>  finite field of order 4, or a polynomial ring, being coerced to
>  something called "a number".  Thus I'm happy with a/Infinity being
>  undefined if a is an element of GF(2).
>
>  I don't know anything about coercion, so I don't know if this makes
>  sense, but it seems to me that any ring R could have a method
>  R.has_infinity() (or R.is_extended() or something like that), which is
>  True if there is a good notion of infinity associated to that ring,
>  False otherwise.  Then if R.has_infinity() is True and if
>  r is an element of R, evaluating r / Infinity would yield the zero
>  element of R.  Other arithmetic, like r * Infinity, would coerce to
>  Infinity in the unsigned infinity ring.  You could also have
>  R.has_signed_infinity().
>  For example, if R is the complex numbers, then R.has_infinity() would
>  be True but R.has_signed_infinity() would be false, while if R is the
>  integers, then R.has_signed_infinity() would be True.  Having this in
>  place would let you replace some of the coercion code for the
>  InfinityRing_class, say converting
>
> elif isinstance(x, (sage.rings.integer.Integer,
>  sage.rings.rational.Rational,
>  sage.rings.real_double.RealDoubleElement,
>  sage.rings.real_mpfr.RealNumber)) or isinstance(x, (int,long,float))
>
>  into something like
>
>  elif x.parent().has_signed_infinity() or isinstance(x,
>  (int,long,float)):
>
>  Among my many questions about this:
>
>  1. Does this make any sense?
>  1a. If so, is it feasible to implement?
>
>  2. Why does Sage behave the way it does with
>  a=GF(2)(1); a/Infinity
>
>  I guess the issue is that Infinity is an element of InfinityRing, not
>  UnsignedInfinityRing, and there is no coercion taking place.  Doing 'a/
>  UnsignedInfinityRing(Infinity)' returns 'A number less than infinity',
>  though.
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Change the default base_ring for matrices from ZZ to QQ

[David Roe]

I agree with Nick here.  If we want to change the default behavior of
some functions so that they work the same as over the fraction field,
that's fine.  But don't add a call to fraction field to the
constructor.  ZZ is the initial object in the category of rings.
That's a good reason for it to be the default base ring.
David

On Thu, May 15, 2008 at 2:48 PM, Nils Bruin <[EMAIL PROTECTED]> wrote:
>
> -1. While I agree that defaulting to matrices over QQ rather than over
> ZZ would lead to more expected behaviour for most users, I don't see
> how the rule for changing the base ring can be made both consistent
> and cheap.
>
> Imagine R1 = QQ[x,y]/(x^2+y^2-1). Then FieldOfFractions(R1) is well-
> defined, so one would expect that
> matrix([x]) would be over the field of fractions.
>
> If R2=Q[x,y]/( x^2-y^2), FieldOfFractions(R2) does not exist. Deciding
> whether FieldOfFractions(Ri) exists is a fairly expensive operation in
> these cases.
>
> I think special-casing matrix([ZZ(1)]) etc. is a bad idea. You would
> need a method R.has_an_obvious_field_of_fractions() on rings to both
> deal with ZZ and avoid expensive operations for R1 and R2 above.
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Adding functions to Sage

[David Roe]

Yeah, I arrive in Seattle on June 9.
David

On Tue, May 27, 2008 at 1:20 AM, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
>
> On 26-May-08, at 9:40 PM, David Roe wrote:
>>
>> I've gotten distracted by trying to do work that my advisor gave me.
>> I suspect it's mostly a matter of Robert and I having other time
>> demands.
>
> I assumed as much, and understand completely :)  Will you both be at
> Dev Days?  That sounds like the opportune time.
>
> Nick
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage Days

[David Roe]

Algebraic topology.
David

On Tue, May 27, 2008 at 2:32 AM, mhampton <[EMAIL PROTECTED]> wrote:
>
> Dynamical systems - I think this now might be Sage's weakest area of
> mathematics.  Getting AUTO/pydstool and other more specialized code in
> Sage is necessary if its going to have any appeal to that community.
>
> -M. Hampton
>
> On May 26, 3:14 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
>> Two more crazy ideas:
>>
>> 1. error-correcting codes
>> 2. any topic but located in the same place as the next ECCAD.
>>
>> On Mon, May 26, 2008 at 3:41 PM, William Stein <[EMAIL PROTECTED]> wrote:
>>
>> > Hi,
>>
>> > I would greatly appreciate it if people would in this thread throw out
>> > some random
>> > brainstorming ideas for topics for future sage days.   Since I have
>> > partial funding for
>> > three per year for the next 5 years, we should start planning a
>> > general program.
>>
>> > To get started, I'll throw out some wild and crazy ideas.  Note that a
>> > particular Sage
>> > days can have multiple themes.
>>
>> >   * Statistical computation  (I think we're already putting together
>> > an IPAM proposal for this)
>>
>> >   * Quantitative finance -- extend the range of applicability of Sage
>> > to include economics
>>
>> > Thanks!
>>
>> > --
>> > William Stein
>> > Associate Professor of Mathematics
>> > University of Washington
>> >http://wstein.org
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Pickling functions

[David Roe]

One way to get around this limitation in python is to use callable
classes instead of functions.
David

On Sat, Jun 14, 2008 at 10:42 AM, David Harvey
<[EMAIL PROTECTED]> wrote:
>
> On Jun 14, 2008, at 1:25 PM, Daniel Bump wrote:
>
>
> Some code that has been proposed by Nicolas Thiery
> for sage/combinat/families.py would create classes
> that have as attributes dictionaries of functions.
> However dumps(s) will raise an exception if s is
> such a class instance.
> Example: the simple reflections in a Weyl group. See:
> http://groups.google.com/group/sage-combinat-devel/msg/8b987cd471db3493?hl=en
> What it boils down to is this. The following is
> fine in native Python:
>
> import pickle
> def f(x): return x+1
>
> ...
>
> pickle.dumps(f)
>
> 'c__main__\nf\np0\n.'
>
> pickle.dumps({1:f})
>
> '(dp0\nI1\nc__main__\nf\np1\ns.'
> But if you try to run this from within Sage,
> both calls to dumps() will raise exceptions.
> Is this a bug in Sage?
>
> I actually thought you couldn't really pickle functions, even in plain
> python.
> http://docs.python.org/lib/node317.html
> "Note that functions (built-in and user-defined) are pickled by ``fully
> qualified'' name reference, not by value. This means that only the function
> name is pickled, along with the name of module the function is defined in.
> Neither the function's code, nor any of its function attributes are pickled.
> Thus the defining module must be importable in the unpickling environment,
> and the module must contain the named object, otherwise an exception will be
> raised."
> david
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage.math

[David Roe]

sage.math seems to be back up.  At least, I'm logged in to it.  ;-)
David

On Thu, Jun 19, 2008 at 12:47 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> sage.math is down and I don't have physical access to the machine right now.
> Reminder: a backup from yesterday of everybody's file is available here:
>   http://modular.math.washington.edu/home/
>
> I hope to reboot sage.math within an hour, but given the summer break
> I'm not sure I can.
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[David Roe]

> BTW, I have also modified giac source, it should now compile with gcc
> 4.3.1.

Excellent!

> As I said earlier, I'm ready to invest time for that, but I can't do
> it alone, there must be someone on the python side who has time and
> interest to do it with my help.

I've seen a lot of acrimonious threads recently about Sage's
relationship with software such as Maxima, Axiom and giac.  I think
some of it may result from a misunderstanding about the priorities of
the Sage developers.

Many of us are interested in Sage primarily for computational number
theory, and of those that aren't, only a few are really interested in
working on the kind of symbolic manipulations required for the classic
computer algebra applications of calculus, solving equations, etc.
that are the forte of Maxima and SymPy for example.  But when someone
comes along and volunteers to work on making symbolics in Sage better,
we don't tell them no.  We let them loose and see what happens.  But
there's not a huge developer base within sage working on improving
"symbolics."  Currently, it seems to be mostly Gary.

So, where does this leave giac?  You're probably no going to find
someone currently involved with Sage who wants to work on it with you.
 If you want to further its incorporation into Sage, here's what you
can do. The first step would be making giac an experimental spkg.
Personally, I know very little about the process for doing so: I've
tended to work mostly within the Sage library of Python and Cython
code.  But if you log on to the #sage-devel IRC channel you will
likely find someone who can answer questions as they come up.  In
particular, I don't think an experimental spkg requires any Python
code.

The second step is to take a look at how Sage interfaces with outside
software.  Look through the files in sage.interfaces for examples of
using pexpect to communicate with running instances of other programs
(this is how sage communicates with maxima).  Since giac is written in
C++, you can also link to it dynamically and make the functionality
available through Cython.  This tends to be significantly more work
than just writing a pexpect interface.  Take a look at the wrappers in
sage/libs and the C and C++ code in c_lib for some examples of Sage
using other programs as libraries (eg pari, ntl, mwrank, flint...).

Next, one would make the experimental spkg into an optional one by
making sure that it builds on the platforms Sage supports.  You would
also open a trac ticket to incorporate your interface code into the
Sage library.  As long as the library code you want to add is well
written and documented, I think we will always welcome the ability to
use more math software from Sage.  One of Sage's strength's is the way
it combines many systems, and adding new interfaces always helps with
this.  By getting to the optional package stage, you give any user of
Sage the ability to install giac as an optional package and then have
a Python interface to it from Sage.

The final hurdle, getting a package incorporated as standard in Sage,
requires more than just code and effort required of an optional
package.  It requires that the proposed package satisfies a number of
requirements, namely (from
http://groups.google.com/group/sage-devel/browse_thread/thread/1c42fb1e4ca32230/7cec80383bd54573?lnk=gst&q=standard+spkg#7cec80383bd54573)
GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE

1. GPL version 2 compatible license.   (This rule
will be reconsidered in December 2008.  I.e., we
might allow GPL v3 only code.)

2. The package must build on our supported architectures:
   * Linux x86, x86_64, itanium, ppc
   * OS X ppc, intel
   * Solaris sparc, x86_64
   * MS Windows (or at least a reasonable plan for building in
 the near future)

3. Quality: The package should be "better" than anything else (that
passes criteria 1 and 2) and an argument should be made for this. The
comparison should be made to both Python and other software. Criteria
in passing the quality test include:
* Speed
* Documentation
* Usability
* Memory leaks
* Maintainable
* Build time
* Size
* Dependencies

4. Interest and Demand:
* JSAGE vote (majority)
* A majority vote on sage-devel.


At every stage of this process, you should be able to find help in
answering questions that come up.  Whether you can find someone else
to chip in and contribute to the work depends on who else is excited
about getting giac into Sage.  But you should feel free to go ahead
and go through the steps of making giac an optional spkg even if
nobody currently involved in Sage development is enthusiastic enough
to help out.  If it's important enough to you to put in the work, go
for it!
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-deve

[sage-devel] Re: Help fixing pari shared library across all platforms

[David Roe]

I'm running OS X 10.4 and the warning about DT_TEXTREL doesn't appear
in my install log.

Good luck!
David

On Sun, Jul 13, 2008 at 3:51 AM, François Bissey
<[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Recently David Kirkby tried to compile sage on
> solaris express and it blew up on pari. Turns out
> the pari shared library is build without any PIC
> flag and that caused his linker to just give up.
> Turns out that the problem is in fact widespread
> across a number of archs where the linker emits
> a warning about DT_TEXTREL (usually) but still
> return a shared object. I know it affects me on
> linux-x86.
>
> After inspecting the patches shipped with pari
> on sage it turns out that the problem is in a
> file called get_dlcflags and that someone from
> sage fixed the problem on linux-ppc but left it
> open for a number of platforms.
>
> So I would like feedback from install on various
> archs to see which one needs to be fixed.
> Here is a summary of what I think I know:
> -Working (presumably):
>  *linux-ppc
>  *ia64 (itanium)
>  *x86_64/amd64 (possibly)
> -not working:
>  *linux-x86
> -unsure:
>  *OSX (darwin) - all flavors.
>  *linux-ppc64
>
> Example of what to look for in install.log:
> gcc  -o
> libpari-gmp.so.2.3.3 -shared  -O3 -Wall -fno-strict-aliasing 
> -fomit-frame-pointer -Wl,-shared,-soname=libpari-gmp.so.2
> mp.o mpinl.o Flx.o Qfb.o RgX.o alglin1.o alglin2.o arith1.o arith2.o base1.o
> base2.o base3.o base4.o base5.o bibli1.o bibli2.o buch1.o buch2.o buch3.o
> buch4.o galconj.o gen1.o gen2.o gen3.o ifactor1.o perm.o polarit1.o
> polarit2.o polarit3.o rootpol.o subcyclo.o subgroup.o trans1.o trans2.o
> trans3.o anal.o compat.o default.o errmsg.o es.o init.o intnum.o members.o
> sumiter.o aprcl.o elldata.o elliptic.o galois.o groupid.o kummer.o mpqs.o
> nffactor.o part.o stark.o subfield.o
> thue.o -lc -ldl -lm -L/home/francois/Work/SAGE/local/lib -lgmp
> /usr/lib/gcc/i686-pc-linux-gnu/4.2.4/../../../../i686-pc-linux-gnu/bin/ld:
> warning: creating a DT_TEXTREL in object.
> ^^
>
> Thanks for your assistance.
>
> Francois
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Lazy Infinite Power Series

[David Roe]

Great!  This has been on my list of things I'd like to have
implemented for a while.

Presumably, much of this code will be incorporated into the Sage
library.  So it's not really a "package" per se.  Instead, you should
make a ticket on trac (http://trac.sagemath.org/sage_trac), for which
you need an account.  Then you should post Mercurial patches there,
that include both the changes to existing files and the new files that
you've created (there's a Mercurial tutorial at
http://sagemath.org/doc/prog/index.html if you need it).  Then you
should have someone review the code, at which point it can be merged
into the current Sage release.
David

On Wed, Oct 29, 2008 at 4:11 PM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I developed a package to work with infinite power series.
> You can work with the power series mostly like with functions, the
> actual value of a coefficient is computed when requested.
> For example (the working title is PowerSeriesRingI, "I" like
> infinite):
>
>sage: PQ = PowerSeriesRingI(QQ)
>sage: #Predefined
> PowerSeries
>sage: expps = PQ.exp
>sage: expps.poly(10,x)
>1/362880*x^9 + 1/40320*x^8 + 1/5040*x^7 + 1/720*x^6 +
> 1/120*x^5 + 1/24*x^4 + 1/6*x^3 + 1/2*x^2 + x + 1
>sage: expps
>[1, 1, 1/2, 1/6, 1/24, 1/120, 1/720, 1/5040, 1/40320,
> 1/362880, 1/3628800, ...]
>sage: PQ.zero
>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: PQ.one
>[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: PQ.id
>[0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: #finite
> powerseries
>sage: p = PQ([1,2,3,4])
>sage: p.poly(10,x)
>4*x^3 + 3*x^2 + 2*x + 1
>sage: p
>[1, 2, 3, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: one = PQ([1])
>sage: id = PQ([0,1])
>
>sage: #power series are just functions that map the index to
> the coefficient
>sage: expps[30]
>1/26525285981219105863630848000
>
>sage: #power series
> operations
>sage: p+p
>[2, 4, 6, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: p-p
>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: p*p
>[1, 4, 10, 20, 25, 24, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, ...]
>sage: one/p
>[1, -2, 1, 0, 5, -14, 13, -4, 25, -90, 121, -72, 141, -550,
> 965, -844, 993, ...]
>sage: p.rcp()/p*p*p
>[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: p**2
>[1, 4, 10, 20, 25, 24, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, ...]
>sage: #composition only works for coefficient 0 being 0 in the
> second operand
>sage: dexp = expps - one
>sage: expps.o(dexp)
>[1, 1, 1, 5/6, 5/8, 13/30, 203/720, 877/5040, 23/224,
> 1007/17280, ...]
>
> Beneath composition it can also perform (fractional) iteration
>sage: #we come into interesting
> regions ...
>sage: dexp.o(dexp)
>[0, 1, 1, 5/6, 5/8, 13/30, 203/720, 877/5040, 23/224,
> 1007/17280, ...]
>sage: dexp.nit(2)
>[0, 1, 1, 5/6, 5/8, 13/30, 203/720, 877/5040, 23/224,
> 1007/17280, ...]
>sage: dexp.it(-1)
>[0, 1, -1/2, 1/3, -1/4, 1/5, -1/6, 1/7, -1/8, 1/9, -1/10,
> 1/11, -1/12, ...]
>sage: dexp.it(-1).o(dexp)
>[0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>sage: hdexp = dexp.it(1/2)
>sage: hdexp
>[0, 1, 1/4, 1/48, 0, 1/3840, -7/92160, 1/645120, 53/3440640,
> -281/30965760, ...]
>sage: #verifying that shoudl be
> Zero
>sage: hdexp.it(2) - dexp
>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, ...]
>
> My question is about making this a standard SAGE package.
> Is there any guideline how to do so and what are the criteria and
> requirements?
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] p-adics

[David Roe]

Hey all,
Genya and I have code for p-adic ring and field classes and are
currently debugging and writing documentation.  If you're interested
I've posted the four files at
sage.math.washington.edu/home/roed/padics07

I've been running into some trouble figuring out how to change
everything I need to so that imports work correctly.  I've gotten it so
that sage starts after building, but am now having problems getting all
the classes I've defined into the namespaces for the other modules.  In
particular, if I start SAGE and run dir(), it shows pAdicRingGeneric,
etc. But if I run dir(sage.rings) it doesn't show any of the padic
packages.  What do I need to edit besides sage/rings/all.py in order to
make things work?  And how should I import things at the top of my
source files?

Thanks,
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adics

[David Roe]

They implement a somewhat modified version of the interfaces in the
folder.  The folder also includes other classes that we haven't written
yet.
David

On Jan 25, 4:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Jan 2007 13:03:39 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> > Hey all,
> > Genya and I have code for p-adic ring and field classes and are
> > currently debugging and writing documentation.  If you're interested
> > I've posted the four files at
> > sage.math.washington.edu/home/roed/padics07What is the relation between the 
> > four files in that directory and the
> files in the SAGE_ROOT/devel/sage/sage/rings/padics directory that is
> currently included with SAGE (but not used)?
> 
> William


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adics

[David Roe]

I didn't know that the code in SAGE_ROOT/devel/sage/sage/rings/padics
was actually working.  I'll take a look at it and see if I can just
incorporate actual source into that framework.
David

On Jan 25, 5:22 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Jan 2007 14:15:07 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> > They implement a somewhat modified version of the interfaces in the
> > folder.  The folder also includes other classes that we haven't written
> > yet.Did you start with the code in SAGE_ROOT/devel/sage/sage/rings/padics
> then modify it, etc.?  I put maybe 2 hours into getting that code
> to import, and I want to know if you started again on that.  If so,
> shouldn't you be making it available to use as an hg patch?  It's
> extremely confusing to try to develop code without a source control
> system in place, which makes me scared of
>   sage.math.washington.edu/home/roed/padics07
> In short, I would prefer to have code that I can apply to a clone
> of my SAGE repository.  Then if I sit here for an hour, make some
> changes so imports work for you, i can just send you back a patch, etc.
>
>
>
> > On Jan 25, 4:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> >> On Thu, 25 Jan 2007 13:03:39 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> >> > Hey all,
> >> > Genya and I have code for p-adic ring and field classes and are
> >> > currently debugging and writing documentation.  If you're interested
> >> > I've posted the four files at
> >> > sage.math.washington.edu/home/roed/padics07What is the relation between 
> >> > the four files in that directory and the
> >> files in the SAGE_ROOT/devel/sage/sage/rings/padics directory that is
> >> currently included with SAGE (but not used)?
> 
> >> William


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: p-adics

[David Roe]

It looks like you fixed the import statements at the top of padic_ring
and padic_ring_element.  If that's the case, I can change the source
code in those files and things will be okay, correct?  Once the
padic_ring code is generally working I can try to add padic field code.
David

On Jan 25, 5:59 pm, "David Roe" <[EMAIL PROTECTED]> wrote:
> I didn't know that the code in SAGE_ROOT/devel/sage/sage/rings/padics
> was actually working.  I'll take a look at it and see if I can just
> incorporate actual source into that framework.
> David
>
> On Jan 25, 5:22 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 25 Jan 2007 14:15:07 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> > > They implement a somewhat modified version of the interfaces in the
> > > folder.  The folder also includes other classes that we haven't written
> > > yet.Did you start with the code in SAGE_ROOT/devel/sage/sage/rings/padics
> > then modify it, etc.?  I put maybe 2 hours into getting that code
> > to import, and I want to know if you started again on that.  If so,
> > shouldn't you be making it available to use as an hg patch?  It's
> > extremely confusing to try to develop code without a source control
> > system in place, which makes me scared of
> >   sage.math.washington.edu/home/roed/padics07
> > In short, I would prefer to have code that I can apply to a clone
> > of my SAGE repository.  Then if I sit here for an hour, make some
> > changes so imports work for you, i can just send you back a patch, etc.
>
> > > On Jan 25, 4:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > >> On Thu, 25 Jan 2007 13:03:39 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> > >> > Hey all,
> > >> > Genya and I have code for p-adic ring and field classes and are
> > >> > currently debugging and writing documentation.  If you're interested
> > >> > I've posted the four files at
> > >> > sage.math.washington.edu/home/roed/padics07What is the relation 
> > >> > between the four files in that directory and the
> > >> files in the SAGE_ROOT/devel/sage/sage/rings/padics directory that is
> > >> currently included with SAGE (but not used)?
> 
> > >> William


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: design question: interval arithmetic comparisons

[David Roe]

I'm actually working on a slightly different type of interval compare
for the p-adics.  Lazy p-adics will return an interval as their
valuation if they're currently indistinguishable from 0: it will be of
the form [a, infinity] or [a, a].  If you compare such intervals, they
shrink themselves until either they can separate themselves from the
other interval you're comparing with, they both become single points
and are equal, or they give up after some amount of trying and raise
an error (to stop the comparison from running forever in the case that
both values are secretly zero).  You can then do arithmetic with such
intervals (when multiplying, they can shrink themselves away from
multiplying zero by infinity, etc).  This is all being a real pain to
implement, but if people are interested in these types of objects in
more generality than just as the valuations of lazy p-adics and power
series, you should let me know so I can take your application into
account in the design.
David

On Feb 12, 2:38 am, "Michel" <[EMAIL PROTECTED]> wrote:
> I am wondering what Sage's strategy is with regard to coercions.
> It thought that it would be reasonable that an element of a
> RealIntervalField
> should be coercable into a RealField but this does not seem to be the
> case.
>
> sage: r=RealIntervalField(16)((1,2))
> sage: RealField(16)(r)
>
> : Unable to convert x
> (='[1.0...2.0]') to real number.
>
> Is this a design decision?
>
> Regards,
> Michel


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] slices

[David Roe]

If one types a[4:8:2] in Python, Python creates a slice object (call
it s) with s.start = 4, s.stop = 8 and s.step = 2.  It then passes
this slice object to a's __getitem__ method.  If one of the arguments
is left out, it is filled with None: so the slice [:8:2] would have
start None.  However, if you don't have the second colon, instead of
filling it with None, it fills start with a Python int 0 and stop with
a Python int 2147483647 (which some of you may recognize as maxint).
So a[:4] would call __getslice__(0, 4), or if that's not defined,
__getitem__(slice(0, 4)).  Similarly, if I write a[-2:8] it calls
__getitem__(slice(a.__len__() - 2, 8, None)).  Is there any way that I
can distinguish between a[0:4] and a[:4] in writing __getitem__?   Or
more generally, get Python to construct a new style slice object when
called with just two arguments?  I want to overload the slice operator
for p-adic fields and this is stymieing me (yes, that is how you spell
stymieing: I just looked it up).
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Random elements

[David Roe]

I've been thinking about random elements a bit for p-adics.  There are lots
of good and reasonable ways to generate random elements of things.  For
example, in addition to Robert's suggestion, we could have a Gaussian
distribution with a specified mean, or a Poisson distribution...  It seems
like a reasonable way to do it would be to have an algorithm = {uniform,
gaussian,...} argument to the random element function and thus have lots
available (ie however many we decide to write).  Then if someone wants to
know what kind of random distributions they can generate, they can just
check the docstring for the function.  Of course, this still leaves the
question of which is the default...

Anyway, I'm planning on doing this for p-adics.  Thought I might throw the
idea in for integers too.
David


>It's always bugged me that the default distribution for integers (and
>rationals) is just a uniform distribution over some small range. What
>if instead we chose the distribution ZZ.random_element() = floor(1/r)
>where r is uniformly distributed in (-1,1). Then P(n) = 1 / (2 |n| (|
>n| + 1)) for all n in Z-{0}. This gives mostly small numbers with the
>occasional large ones thrown in at ever decreasing probabilities.
>
>A random rational could then be the ratio of two such integers.
>
>- Robert

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: First remarks on new padics model

[David Roe]

I tried sending a response a while ago, but it didn't seem to get
through.

I'm including a response to David Kohel's e-mail at the bottom of
this.

> Congratulations on the new p-adic model. This really looks very
> promising and extensible.

Thanks.

>  - It should be possible to create elements with a given precision,
> without the overhead of first creating the elements to the entire
> "cap": If you don't know the precision you'll need yet, you would
> probably create a ring with a huge cap and just create all your
> elements with way lower precision (having a huge cap floating around
> should not be very costly). You can just lift your elements to higher
> precision when it turns out you need more.

I'm working on this now.  It should be done tonight.

>  - Currently trying to create an element in a "lazy" ring leads to a
> Exception (click to the left for traceback):
> File "integer.pyx", line 669, in integer.Integer.__pow__
> TypeError: exponent (=lazy) must be an integer
> Coerce your numbers to real or complex numbers first.
> (that's the pyrex "**" thing I guess)

What code did you run to try to create the lazy element?

>  - We're going to need a "lifttoprecision" method that returns an
> element with a changed precision. For lowering the precision you
> already have add_bigoh, but one needs to be able to obtain a lift of
> an element too (for instance, if you want to increase precision using
> newton iteration, you need to create the room first)

Agreed.  That will go on the TODO list.

>  - I assume the ringextension is just a rough first draft? The
> following was rather disconcerting:
>
> sage: Zp=pAdicRing(3)
> sage: ZpX.=Zp[]
> sage: R=pAdicRingExtension(X^2-3)
> sage: R.uniformiser();
> 3 + O(3^21)

Yes, padic_ring_extension.py was an initial attempt that we abandoned
halfway through to implement unramified_ring_extension directly.
Ramified extensions are not currently implemented.

> In general, the ramified extensions cannot completely be implemented
> via polynomial quotient rings.

Why not?  Can't we just use an Eisenstein polynomial f(x) and have x
be the uniformizer?  If the user wants to use a different polynomial,
we convert between x and the user defined variables...

> You'll find relating precisions in
> the extensions with precisions in the base ring to be a general
> headache.

I haven't yet thought about it much, but I believe you.

> Another thing:
>
> R.=pAdicRingExtension(X^2-3)
>
> throws an error at the moment (we cannot name the new generator!)

See the comment above.

> Uniqueness of rings:
>
> in the future, I'm sure we'll be able to ask for:
>
> K.=NumberField(x^2+1)
> Q5a,KtoQ5a=Completion(K,Place(2+i))
> Q5b,KtoQ5b=Completion(K,Place(2-i))
>
> Are Q5a, Q5b going to be the same ring with all the difference
> relegated to the embedding maps of K?
> Are Q5a, Q5b going to have coersions from K?
> Are Q5a, Q5b going to be wrapper classes around the same pAdicField(5)
> to distinguish their relation to K?

We haven't yet decided how to do this.  Generally, we're trying to
have fields be uniquely determined by the parameters that define
them.  We could have no automatic coercion from the number field to
the localization and have the user have to use __call__ instead.
Maybe syntax like def __call__(self, x, absprec = None, place = None)
where place determines the embedding of K into Q5?  Feel free to share
any thoughts you have on this.

And now, David Kohel's request...
> Another feature that I find extremely useful are the quotient rings
> (currently not implemented).
> This allows one to work in a well-defined ring, and control precision
> precisely.

What do you mean by quotient rings?  Are you talking about finite
extensions of Z/p^nZ?
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: First remarks on new padics model

[David Roe]

> My mistake, but the errors let me think it was sage's fault. I typed
> pAdicRing(3,prec="lazy")
> which gets accepted. Doing anything with the ring afterwards leads to
> the
> above error. You should probably validate all construction parameters
> at construction time.

Sounds like a good idea.  We'll put some in.

> On second thought, yes, possibly you can. Your Valuation(polyquoelt)
> would be min([n*valuation(polyquoelt[i])+i for i in 0..n-1])
> and similar for precision.
> The problems will arise when you start working with precisions that
> are not
> a nice multiple of the extension degree n, i.e., what if you want to
> find the unit part
> of pi+3+O(pi^3)
> where pi=sqrt(3) in Z_3?

Yeah.  Precision there bears more thinking on.  I was actually even
considering
having precisions and valuations normalized so that valuation(p) = 1,
and then only
integral precisions would be allowed.  I'm not sure whether I like
this idea though...

> > We haven't yet decided how to do this.  Generally, we're trying to
> > have fields be uniquely determined by the parameters that define
> > them.  We could have no automatic coercion from the number field to
> > the localization and have the user have to use __call__ instead.
> > Maybe syntax like def __call__(self, x, absprec = None, place = None)
> > where place determines the embedding of K into Q5?  Feel free to share
> > any thoughts you have on this.
>
> The place can't be a parameter on the receiving end. (imagine places
> of higher degrees?)
> I wouldn't mind a field homomorphism K -> K_p that you have to call
> explicitly.

Sure.

I added lift_to_precision, specifying precision at creation time for p-
adic elements
and polynomials with p-adic coefficients, xgcds of polynomials with
coefficients in
Qq last night.  Generally, I'm going to have two .hg files available
for download for
anyone who's interested.  sage.math.washington.edu/home/padicgroup/
semistable-version.hg
will have a version that passes all doctests.  That means I'm sending
it off to William, but
if you want it faster you can get it from there.  And
sage.math.washington.edu/home/padicgroup/development-version.hg
has the most recent version.  I'll only update that when the code
builds, but I don't guarantee anything about doctests.

David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.4-rc3

[David Roe]

Build (for rc3) went  fine on my machine (32 bit MacBook Pro, OS X
10.4.9)
real61m23.087s
user38m43.449s
sys 15m50.664s
Make test:
All tests passed!
Total time for all tests: 1732.5 seconds
David

On Mar 25, 5:52 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> Can you send the part of SAGE_ROOT/test.log that describes
> the failures for
>
> > sage -t  devel/sage-main/sage/graphs/graph.py
> > sage -t  devel/sage-main/sage/graphs/graph_isom.py
> > sage -t  devel/sage-main/sage/groups/perm_gps/permgroup.py
>
> The dft.py is just a rounding randomness.  But I don't know what
> would have caused the above three failures.
>
> On 3/25/07, Hamptonio <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I installed 2.4-rc3 on a powerpc g4 powerbook.  I had 4 tests fail,
> > but it looked like that was because I didn't install the gap
> > packages.  The four failures were:
>
> > sage -t  devel/sage-main/sage/graphs/graph.py
> > sage -t  devel/sage-main/sage/graphs/graph_isom.py
> > sage -t  devel/sage-main/sage/groups/perm_gps/permgroup.py
> > sage -t  devel/sage-main/sage/gsl/dft.py
>
> > I'll try to install gap and check again.
>
> > -Marshall Hampton
>
> > On Mar 25, 11:53 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> > > Thanks for all your feedback.  It looks like a release of sage-2.4 is 
> > > imminent!
>
> > > On 3/25/07, David Joyner <[EMAIL PROTECTED]> wrote:
>
> > > > All tests passed on suse 10.2 amd 64 bit.
>
> > > > Jaap Spies wrote:
> > > > > Jaap Spies wrote:
>
> > > > >> There were no problems what so ever with sage-2.4.rc3 on FC5:
> > > > >> --
> > > > >> All tests passed!
> > > > >> Total time for all tests: 1093.9 seconds
> > > > >> [EMAIL PROTECTED] sage-2.4.rc3]$
>
> > > > > The same for Fedora Core 6.
>
> > > > > Jaap
>
> > > --
> > > William Stein
> > > Associate Professor of Mathematics
> > > University of Washingtonhttp://www.williamstein.org
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://www.williamstein.org


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: integer-shiting + mpfr reals

[David Roe]

Two things.  First, order of operations is not what I would expect:
your first code is equivalent to
sage: 1 << (3 + 1.2).
Note that
sage: (1 << 3) + 1.2
9.20
works.

Secondly, the reason the second example works is that you can shift by
an integer n, and
it just multiplies by 2^n (before 2.4 I think it had to be a positive
integer).  If you want to be able
to shift by arbitrary real values then change the code for __lshift__
and __rshift__ for the reals.
David

On Mar 25, 11:24 pm, "didier  deshommes" <[EMAIL PROTECTED]> wrote:
> This is strange: SAGE crashes on input that mixes shifting and mpfr
> reals
> {{{
> sage: # mpz, mpfr
> sage: 1<<3 +1.2
> Segmentation fault
>
> }}}
>
> But note that this is fine:
> {{{
> # mpfr, mpz
> sage: 2.0 + 1<<3
>  24.0
>
> }}}
>
> Anyone knows what's happening?


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Coercion in multivariable polynomial rings

[David Roe]

I sent this a little while ago but it didn't seem to go through...
sorry if it appears twice.

What do people think of having a canonical map between multivariate
polynomial rings when one's variables are a subset of the other's?
What about a subset in the same order?  What about an initial subset
in the same order?
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion in multivariable polynomial rings

[David Roe]

Why lexicographically?  How about the following:
(1) there is a canonical coercion map from K to L
(2) the variables of R are a subset of the variables of S, and
(3) The map from variables of R to variables of S is order
preserving.

Also, I defined base_extend for multivariable polynomial rings, which
means that now
sage: R. = ZZ[]
sage: f = (x + y) / 3
sage: f.parent()
Polynomial Ring in x, y over Rational Field
Rather than
sage: f.parent()
Fraction Field of Polynomial Ring in x, y over Integer Ring

Is this a problem?

On Mar 29, 10:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 3/29/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> > I sent this a little while ago but it didn't seem to go through...
> > sorry if it appears twice.
>
> > What do people think of having a canonical map between multivariate
> > polynomial rings when one's variables are a subset of the other's?
> > What about a subset in the same order?  What about an initial subset
> > in the same order?
>
> Suppose R and S are multivariate polynomial rings over base rings K and L.
> I think a reasonable convention would be to have a canonical coercion map
> R --> S if the following conditions hold:
> (1) there is a canonical coercion map from K to L
> (2) the variables of R are a subset of the variables of S, and
> (3) if the variables of R equal the variables of S, then when
> ordered lexicographically the variables of R are <=
> the variables of S.
>
> William


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion in multivariable polynomial rings

[David Roe]

I guess I'm not totally sure what you meant by (3).  Do you mean
(3) If (2) is satisfied, then for all v variables of R and w
variables of S that are not in R, v < w?

> Actually, whatever we do, we should make sure and require that
> the term orders on the two rings are compatible.
What is the condition for compatibility?
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] File location for polynomials and matrices

[David Roe]

So, I'm planning on writing new classes for matrices and polynomials
over p-adics.  Eventually there will probably be 8 new classes for
each of matrices and polynomials.  Should these go in rings/padics?
rings/padics/polynomial and rings/padics/matrix?  In rings/ and
matrix/? Move polynomial_element_generic, etc to rings/polynomial and
put the polynomial code in there?  Put the matrices in matrix/padic?

I don't want to pollute the file space too much by creating lots of
files, so...
David


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: File location for polynomials and matrices

[David Roe]

I can try writing the matrices using SageX...
Then working with 1x1 matrices might be faster than working with
padics...
;-)
David

On Mar 29, 11:59 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 3/29/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> > So, I'm planning on writing new classes for matrices and polynomials
> > over p-adics.  Eventually there will probably be 8 new classes for
> > each of matrices and polynomials.  Should these go in rings/padics?
> > rings/padics/polynomial and rings/padics/matrix?  In rings/ and
> > matrix/?
> > Move polynomial_element_generic, etc to rings/polynomial and
> > put the polynomial code in there?
>
> Yes, that would be very sensible.   Thanks.  Then make a directory
>   rings/polynomial/padic
>
> > Put the matrices in matrix/padic?
>
> The p-adic matrices definitely go in
>
> sage/matrix/**something**,
>
> where I see no real problem with having files like
>
>sage/matrix/padic/matrix_lazy_dense
>
> Make certain to name the matrix files following the conventions used
> in that directory, which work very well.
>
> There are currently no non-SageX matrices, and I think it's probably
> not even possible to create non-SageX matrix classes.  This could
> be an issue, unless you want to write the matrices using SageX.
> Robert B, do you have any thoughts about this?
>
> William


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: File location for polynomials and matrices

[David Roe]

The data of a p-adic matrix will consist of three things
1) An matrix representing the values of the entries.  In the capped relative
and lazy cases, this will be an integer matrix.  In the capped absolute and
fixed mod cases, this will be a mod_n matrix where n = p^precision_cap.
2) A list of precisions of elements.
3) A common valuation

Many algorithms will then call the anologous algorithm on the value matrix
and figure out the precision information separately.  This is faster because
you can now use fast algorithms on the integer part and custom design
algorithms to find precision information separately (which is easier than
actually doing a determinant, for example, of a matrix of p-adic entries and
treating precisions correctly).  Currently, we have such algorithms for
maxtrix multiply, determinant, charpoly as well as easier things like matrix
add, matrix-vector multiply, etc, where the algorithm for integer matrices
is just the naive algorithm.
David

On 3/30/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> On Mar 29, 2007, at 10:15 PM, William Stein wrote:
>
> > On 3/29/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> >> I think one would have to extend/re-implement matrix_generic_dense/
> >> sparse to do it in python. If I remember right, these store their
> >> entries as a (python) list.
> >
> > You're right.   That would make sense; perhaps even just deriving
> > from matrix_generic_dense/sparse would work.
> >
> >>  Unless padic matrices have special
> >> functionality, there won't be much gain over just using that class
> >> directly with the padic ring(s). Really, the main motivation for
> >> matrix classes is to have special, faster algorithms and much more
> >> efficient data storage/manipulation.
> >
> > I think based on our (you, me, and David) conversations in Tucson
> > that in fact p-adic matrices will have special algorithms.  It seemed
> > like there are numerous situation in which naive arithmetic leads
> > to very serious precision issues, so one wants to overload the default
> > algorithms with algorithms that behave more sensible.
> >
> > Also, it's entirely possible that David Roe has in mind, at least
> > in some
> > cases, actually implementing the matrix arithmetic directly using the
> > GMP C library. (??) That could be very fast.
>
> Good point. Yes, eventually I think these should be implemented via
> GMP, though if elements have widely varying precisions this would
> probably be very different than the (simple) matrix_integer_dense.
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: File location for polynomials and matrices

[David Roe]

So, I think I might want to use the __new__ function of Matrix_integer_dense
directly, but I don't really know what I'm doing (thus contradicting the
warning in the docstring for that function).  So I thought I would check
with the list.

A p-adic matrix will include an integer matrix of values.  Since I'm
allocating memory, I need to do this during the __new__ phase of creating my
p-adic matrix.  So I want to call Matrix_integer_dense's __new__ method
then.  Here's the beginnings of the code I'm thinking about:

def __new__(self, parent, entries, copy, coerce):
matrix_dense.Matrix_dense.__init__(self, parent)
self._nrows = parent.nrows()
self._ncols = parent.ncols()
self._value_matrix_parent = MatrixSpace(ZZ, self._nrows,
self._ncols)
self._value_matrix =
Matrix_integer_dense.__new__(Matrix_integer_dense,
self._value_matrix_parent, 0, 0, 0)
_sig_on
self._relprecs = sage_malloc(size_of(uint) * (self._nrows *
self._ncols))
_sig_off
if self._relprecs == NULL:
raise MemoryError, "out of matrix allocating precisions"

def __dealloc__(self):
self._value_matrix.__dealloc__()
if self._initialized:
sage_free(self._relprecs) #shouldn't this part always be done,
even if self is not initialized?

def __init__(self, parent, entries, copy, coerce):
## Call self._value_matrix.__init__(self._value_matrix_parent,
modified_entries, copy=copy, coerce=coerce) sometime in here.

Am I missing something?
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Help with SageX

[David Roe]

So, I'm trying to learn how to write Pyrex code.  So far, I've been able to
fit some functions into existing files, but creating new files and modules
to Sage has been difficult...

I'm moving polynomials to sage.rings.polynomial because there are getting to
be a fair number of files for polynomials.  I'm then creating a padics
folder inside there.
I'm also creating a padics folder in sage/matrix.

In addition to moving some files around, I'm writing new matrix and
polynomial classes.  The polynomial class is pure Python, and I think I have
it mostly working.   The matrix class however...

Does anyone know where I can find some tips on writing .pxd files?  What do
I need to include, import, cimport, from blah cimport, cdef, cdef extern,
etc.

Also, I'm trying to add a function to the Matrix_integer_dense class and
getting an error embedding the pyrex code.  I've included the .pxd file
below (I moved the arrow to where it actually points to for those of us
without fixed-width fonts).  If anybody could point out what I'm doing
wrong, I'd appreciate it.
David


include "../ext/cdefs.pxi"

cimport matrix_dense
cimport sage.rings.integer
from sage.rings.integer cimport Integer

cdef extern from "../ext/multi_modular.h":
ctypedef unsigned long mod_int

cdef class Matrix_integer_dense(matrix_dense.Matrix_dense):
cdef char _initialized
cdef mpz_t *_entries
cdef mpz_t **_matrix
cdef object _pivots
cdef int mpz_height(self, mpz_t height) except -1
cdef _mod_int_c(self, mod_int modulus)

cdef _zero_out_matrix(self)
cdef _new_unitialized_matrix(self, Py_ssize_t nrows, Py_ssize_t ncols)
cdef _pickle_version0(self)
cdef _unpickle_version0(self, data)

cdef _init_linbox(self)
cdef void reduce_entry_unsafe(self, Py_ssize_t i, Py_ssize_t j, Integer
modulus^):



/Users/roed/Math/sage/devel/sage-padics/sage/matrix/matrix_integer_dense.pxd:24:84:
C function definition not allowed here

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Random Reals

[David Roe]

Hey,
I've been looking into changing RR.random_element and RDF.random_element to
do something more sensible than create a random integer in the range -2 to 2
and coerce it into the reals. The reasonable thing to do for RDF seems to be
to use GSL, create a RealDistribution and then return a random element from
that.  Two issues arise:
1) This doesn't work for RR, since GSL's distributions (as far as I can
tell) only support doubles.  Does anyone know how to get various
distributions in mpfr?  Also, where can I find documentation on the
interface to mpfr?  Their website suggests there are multiple ones
2) If you create a lot of RealDistributions quickly, their initial values
seem to agree fairly often.  For example,
sage: L = [RealDistribution('gaussian', RDF(1)).get_random_element() for _
in range(50)]
sage: Ldict = {}
sage: for m in L:
   ...: if Ldict.has_key(m):
   ...: Ldict[m] = Ldict[m] + 1
   ...: else:
   ...: Ldict[m] = 1
   ...:
sage: Ldict

{-1.97183627646 : 1,
 -1.38176904179: 4,
 -1.1574992194: 2,
 -0.885770378312: 2,
 -0.771164851336: 2,
 -0.757752144086: 1,
 -0.746099959575: 4,
 -0.693091109446: 1,
 -0.685217028642: 5,
 -0.38901172123: 1,
 - 0.315558170546: 2,
 -0.264326023715: 2,
 -0.183537311896: 2,
 -0.153138950133: 3,
 0.0996438605326: 1,
 0.30639951233: 1,
 0.338001249663: 1,
 0.393989493557: 3,
 0.51919088944: 2,
 0.6674486868 : 2,
 0.818610064197: 1,
 0.822495637678: 1,
 0.996828351594: 2,
 2.06664604023: 4}

Naively, this seems like the wrong behavior: they should all be distinct.
Now, maybe I just need to set the seed manually.  It seems like we could set
the seed by default with some other source of randomness though...
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: is_zero

[David Roe]

On 4/12/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> I just took a look at the Python 3000 PEP.  A couple of points where
> things due to be phased out are commonly used in SAGE:
>   -- raise ValueError, "That number shouldn't be zero" -- now illegal
>   -- raise ValueError("That number shouldn't be zero") -- instead
>
>   -- print "hello world" -- will become
>   -- print("hello world") -- instead
>
> imports will be absolute by default.
>
> no more longs.  Yay!
>
> Classic classes will be gone.  I'm not sure what effect this will have,
> but I know that both classic and new classes exist in SAGE.
>
> dict.has_key method is disappearing.
>
> Defining __cmp__ will no longer make <, ==, > etc work: you have to define
> __richcmp__.
>
> Just some things to keep in mind while you're writing new code so that
> it's easier to make Python 3000 compliant.
> If you want to read the PEP it's at
> http://www.python.org/dev/peps/pep-3100/
> David
>
>
> On 4/12/07, William Stein <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 4/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Hi there,
> > > > many classes in SAGE implement and test for is_zero. I think these
> > methods
> > > > should be replaced with __nonzero__ methods, as this is the standard
> > way
> > > > of
> > > > doing such a test in Python. For example,  int doesn't have a
> > is_zero(),
> > > > such
> > > > that one would have to test for a type (of a return value) first.
> > >
> > > +1, and document this in structure.element.
> >
> > Comment 1:
> > My first comment is that __nonzero__ is going to be removed from Python
> > in Python 3000, so you should read the thread here about it being
> > removed:
> >
> >
> > http://mail.python.org/pipermail/python-3000/2006-November/004524.html
> >
> > (Python 3000 being the Python in SAGE is probably not as far off as you
> > might think...  I realized this at the scipy talk that Guido gave on
> > Python 3000.)
> >
> > So in the future, __nonzero__ will be replaced by __bool__; currently
> > the point of __nonzero__ is to implement bool(x) for x an object.
> >
> > Comment 2:
> > One of the most important and used functions in MAGMA is "IsZero".
> > MAGMA doesn't have an "IsNonzero".
> > Likewise, in sage it appears in search_src('is_zero') over 200 times.
> > This all suggests that for mathematics programming, conceptually
> > "is zero" is the function one wants, and that moreover in writing
> > code it is very natural to use a function called "is zero".   Getting
> > rid of is_zero and replacing it by __nonzero__ is thus not natural,
> > since it's the opposite.   I really don't like code like this:
> >
> >if my_complicated_number:
> >  do blah
> >
> > when my_complicated_number is some sort of complicated mathematical
> > object.  I
> > much prefer
> >
> >if not my_complicated_number.is_zero():
> >   do blah
> >
> > or even
> >
> >if my_complicated_number.is_nonzero():
> >   do blah
> >
> > I think it's easier to read and more explicit.
> >
> > Comment 3:
> > Definitely __nonzero__ (or later __bool__) should be defined whenever
> > possible, so code like this behaves sensibly:
> >if x:
> > do blah
> >
> > Conclusions:
> >   (1) Do not eliminate the is_zero method.   I.e., it should still be
> > possible to write
> >x.is_zero() for x an element.
> >   (2) Do implement __nonzero__, and redefine is_zero in the base to be
> >   def is_zero(self):
> >return self.__nonzero__()
> >   (3) Make sure no derived classes define is_zero; they should instead
> > always
> > define __nonzero__.
> >   (4) I wish there were code to certify that derived classes don't
> > define things they
> > shouldn't define...
> >
> > William
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: A patch for rational and integers (Re: sage-2.4.2)

[David Roe]

I also have a patch for RDF.random_element.  I've pasted it in below for
comparison to ideas other people have.  The interface is still incomplete (I
wrote it in 5 minutes): I want to eventually provide an interface to all of
the probability distributions that GSL offers.

def random_element(self, distribution = 'gaussian', parameters = [],
mean = None, sigma = None, min = None, max = None):

"""

Return a random element of this real double field in the interval
[min,
max].




EXAMPLES:

sage: RDF.random_element()

-0.657233364114

sage: RDF.random_element(min=100,
max=110)

106.592535785

"""
cdef float a, b
import sage.gsl.probability_distribution
# Eventually take mean and sigma into account if parameters ==
[]

if min is not None and max is not None:
a = min
b = max
return self._new_c((b-a)*random() + a)
else:
Dist =
sage.gsl.probability_distribution.RealDistribution(distribution,
parameters)
return Dist.get_random_element()

David

--~--~-~--~~~---~--~~
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Coercion and categories in SAGE

[David Roe]

In the course of thinking about coercion for p-adic rings, fields and
extensions, I've had some ideas about a different kind of coercion model to
use for SAGE.  It would fit into the existing coercion model, though I can
see it motivating changes to the existing model.

SAGE currently does quite well when coercing between different basic rings
(Integers to Rationals for example).  Each ring R implements a _coerce_impl
function that takes an element of another ring S and either returns an
element of R or raises an error if that element cannot be coerced into R.
When there is a canonical morphism from S to R, this is fine.  But if there
is no such canonical morphism from S to R, you have to either use the syntax
R(x), in which case it picks a default map (which may or may not be a ring
morphism), or you have to define a ring morphism f: S ---> R and apply it
explicitly.  This last option gets to be quite inconvenient when working
with towers of extensions, or even worse, with extensions that are not
explicitly defined as relative extensions of each other (currently SAGE
cannot automatically coerce from GF(19^2) to GF(19^4)).  Part of the issue
is existence of automorphisms.  Magma has a solution for finite fields that
I think we can extend to an automatic coercion system that works more
broadly (Bosma, Cannon and Steele.  Lattices of Compatibly Embedded Finite
Fields.  J. of Symbolic Comp.  Volume 24, Issue 3-4).

SAGE would define a commutative diagram class.  One could implement this as
an extension of a Graph, where vertices are labeled by Rings (or Groups,
Algebras, etc), and the edges are labelled by morphisms in the appropriate
category.  I think one should also allow sections of injections and
surjections.  In order to coerce between two rings that both lie in the
diagram, one just finds a path from one to the other, and applies the
morphisms in succession.

There are a couple of nice benefits of this approach.  First, one can apply
the methods of "Lattices of Compatibly Embedded Finite Fields" to
automatically grow a global coercion environment so that if a user does the
following:
sage: K. = GF(19^2)
sage: L. = GF(19^4)
sage: c = a + b
sage: c.parent()
Finite Field in b of size 19^4,
things work appropriately.

One might even allow adding elements where neither field embeds into the
other, but there is a default field containing both (when both are Galois
extensions of a third field, for example).
sage: K. = GF(19^6)
sage: L. = GF(19^4)
sage: c = a + b
sage: c.parent()
Finite Field in ? of size 19^12.

There are other benefits of such a coercion model: one can use Python's with
syntax to allow user defined coercion environments.
The user creates a bunch of rings.  Some are defined as extensions or
subfields of others, yielding some a priori injections and sections of
injections.  The user can then define some morphisms between them, and
package all of this data into a "coercion environment" (a layer on top of a
commutative diagram).  For example, one could do the following:
sage: S. = QQ[]
sage: R. = QQ[]
sage: f = S.hom([y^2], R)
sage: E = CoercionEnvironment([R, S], [f])
sage: with E:
...z = x + y
...w = z - x^2
...
sage: w
y + y^2 - y^4
sage: w.parent()
Univariate Polynomial Ring in y over Rational Field

A question remains with what to do with coercions from outside the coercion
environment to inside, or vice versa.  Obviously, the answer can differe
depending on which diagram's morphisms one uses.  One solution would be to
say that in these cases one uses the outer coercion environment (ie the
default global one and not E in the example above).  Yet there are times
when it's convenient to be able to use mixed environments: for example, when
coercing a constant polynomial over ZZ into a number field (or a constant
polynomial over one number field into another number field in a coercion
diagram).  Another idea I've had is the notion of an entry point.  If your
diagram has an initial object (S in the diagram above), then one first tries
to coerce in the outer environment.  If this fails, one tries to coerce to
the initial object in the outer environment, and from the initial object to
your desired ring.  One can similarly define the notion of exit points with
terminal objects.  I don't know what to do if there are multiple initial or
terminal objects (check them in an order given at creation time?).

Should CoercionEnvironments be mutable or immutable? (I'm leaning toward
immutable, but if someone has a good reason otherwise...)

Another unresolved issue for me is how __call__ and _coerce_ should behave
differently in a coercion environment.  Should __call__ only exist at the
top, global level of coercion, possibly using _coerce_ from user defined
coercion environments to fill in gaps?  Should the default choices of
embeddings for finite fields and unramified p-adic extensions use call or
coerce syntax?

How can we make all of this fast and memory-friendly?  I think

[sage-devel] Re: Coercion and categories in SAGE

[David Roe]

[completions at places of number fields]
So, one thing that SAGE should support is completing a number field at a
place.  The resulting object will be either RR, CC, Qp, or a p-adic
extension field.  I think that it should also include the data of which
completion it is.  This allows one to automatically coerce elements from the
number field to the completion.  This is one of the motivations for the
notion of entry point I mentioned in the previous e-mail, though thinking
about it now I realize that the description I gave needs to be modified for
this case.

Because of this need for different completions to store their places, there
is no longer a unique real field.  Perhaps the best way to do this is to
have a RealCompletionField that extends RealField.  It would store a number
field K and a real place v of K; it would then have an automatic coercion
from K.  One would have to manually cast an element of a RealCompletionField
into RR.  Similarly for ComplexCompletionField (I suppose I choose one of
the conjugate embeddings arbitrarily) and pAdicCompletionField.
David

On 4/26/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> In the course of thinking about coercion for p-adic rings, fields and
> extensions, I've had some ideas about a different kind of coercion model to
> use for SAGE.  It would fit into the existing coercion model, though I can
> see it motivating changes to the existing model.
>
> SAGE currently does quite well when coercing between different basic rings
> (Integers to Rationals for example).  Each ring R implements a _coerce_impl
> function that takes an element of another ring S and either returns an
> element of R or raises an error if that element cannot be coerced into R.
> When there is a canonical morphism from S to R, this is fine.  But if there
> is no such canonical morphism from S to R, you have to either use the syntax
> R(x), in which case it picks a default map (which may or may not be a ring
> morphism), or you have to define a ring morphism f: S ---> R and apply it
> explicitly.  This last option gets to be quite inconvenient when working
> with towers of extensions, or even worse, with extensions that are not
> explicitly defined as relative extensions of each other (currently SAGE
> cannot automatically coerce from GF(19^2) to GF(19^4)).  Part of the issue
> is existence of automorphisms.  Magma has a solution for finite fields that
> I think we can extend to an automatic coercion system that works more
> broadly (Bosma, Cannon and Steele.  Lattices of Compatibly Embedded Finite
> Fields.  J. of Symbolic Comp.  Volume 24, Issue 3-4).
>
> SAGE would define a commutative diagram class.  One could implement this
> as an extension of a Graph, where vertices are labeled by Rings (or Groups,
> Algebras, etc), and the edges are labelled by morphisms in the appropriate
> category.  I think one should also allow sections of injections and
> surjections.  In order to coerce between two rings that both lie in the
> diagram, one just finds a path from one to the other, and applies the
> morphisms in succession.
>
> There are a couple of nice benefits of this approach.  First, one can
> apply the methods of "Lattices of Compatibly Embedded Finite Fields" to
> automatically grow a global coercion environment so that if a user does the
> following:
> sage: K. = GF(19^2)
> sage: L. = GF(19^4)
> sage: c = a + b
> sage: c.parent()
> Finite Field in b of size 19^4,
> things work appropriately.
>
> One might even allow adding elements where neither field embeds into the
> other, but there is a default field containing both (when both are Galois
> extensions of a third field, for example).
> sage: K. = GF(19^6)
> sage: L. = GF(19^4)
> sage: c = a + b
> sage: c.parent()
> Finite Field in ? of size 19^12.
>
> There are other benefits of such a coercion model: one can use Python's
> with syntax to allow user defined coercion environments.
> The user creates a bunch of rings.  Some are defined as extensions or
> subfields of others, yielding some a priori injections and sections of
> injections.  The user can then define some morphisms between them, and
> package all of this data into a "coercion environment" (a layer on top of a
> commutative diagram).  For example, one could do the following:
> sage: S. = QQ[]
> sage: R. = QQ[]
> sage: f = S.hom([y^2], R)
> sage: E = CoercionEnvironment([R, S], [f])
> sage: with E:
> ...z = x + y
> ...w = z - x^2
> ...
> sage: w
> y + y^2 - y^4
> sage: w.parent()
> Univariate Polynomial Ring in y over Rational Field
>
> A question remains with what to do with coercions from outside the
> coercion environment to inside, or vice versa.  Obviously, the answer can
> differe dep

[sage-devel] Re: Coercion and categories in SAGE

[David Roe]

[cohomology and algebraic topology]
Thinking about commutative diagrams made me want to implement chain
complexes, homology and cohomology in SAGE.  This led me to wonder how easy
it would be to provide useful functionality to algebraic topologists out
there.  For example, it would not be very hard right now to implement a
cohomology functor that operates on chain complexes in some abelian
category.  One could then go on to define various types of cohomology and
homology by creating a chain complex out of something and applying the
generic cohomology functor to it.

We would want the notion of a graded commutative ring, which shouldn't be so
hard.  One hard part would be figuring out a good representation of
topological spaces.  Finite CW complexes only?  It seems like we should be
able to support ring spectra...

Does anyone know what kind of software out there exists for algebraic
topology?  I hear that Singular has a library for doing ext and tor, etc (I
think it's called homolog_lib).
David

On 4/26/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> In the course of thinking about coercion for p-adic rings, fields and
> extensions, I've had some ideas about a different kind of coercion model to
> use for SAGE.  It would fit into the existing coercion model, though I can
> see it motivating changes to the existing model.
>
> SAGE currently does quite well when coercing between different basic rings
> (Integers to Rationals for example).  Each ring R implements a _coerce_impl
> function that takes an element of another ring S and either returns an
> element of R or raises an error if that element cannot be coerced into R.
> When there is a canonical morphism from S to R, this is fine.  But if there
> is no such canonical morphism from S to R, you have to either use the syntax
> R(x), in which case it picks a default map (which may or may not be a ring
> morphism), or you have to define a ring morphism f: S ---> R and apply it
> explicitly.  This last option gets to be quite inconvenient when working
> with towers of extensions, or even worse, with extensions that are not
> explicitly defined as relative extensions of each other (currently SAGE
> cannot automatically coerce from GF(19^2) to GF(19^4)).  Part of the issue
> is existence of automorphisms.  Magma has a solution for finite fields that
> I think we can extend to an automatic coercion system that works more
> broadly (Bosma, Cannon and Steele.  Lattices of Compatibly Embedded Finite
> Fields.  J. of Symbolic Comp.  Volume 24, Issue 3-4).
>
> SAGE would define a commutative diagram class.  One could implement this
> as an extension of a Graph, where vertices are labeled by Rings (or Groups,
> Algebras, etc), and the edges are labelled by morphisms in the appropriate
> category.  I think one should also allow sections of injections and
> surjections.  In order to coerce between two rings that both lie in the
> diagram, one just finds a path from one to the other, and applies the
> morphisms in succession.
>
> There are a couple of nice benefits of this approach.  First, one can
> apply the methods of "Lattices of Compatibly Embedded Finite Fields" to
> automatically grow a global coercion environment so that if a user does the
> following:
> sage: K. = GF(19^2)
> sage: L. = GF(19^4)
> sage: c = a + b
> sage: c.parent()
> Finite Field in b of size 19^4,
> things work appropriately.
>
> One might even allow adding elements where neither field embeds into the
> other, but there is a default field containing both (when both are Galois
> extensions of a third field, for example).
> sage: K. = GF(19^6)
> sage: L. = GF(19^4)
> sage: c = a + b
> sage: c.parent()
> Finite Field in ? of size 19^12.
>
> There are other benefits of such a coercion model: one can use Python's
> with syntax to allow user defined coercion environments.
> The user creates a bunch of rings.  Some are defined as extensions or
> subfields of others, yielding some a priori injections and sections of
> injections.  The user can then define some morphisms between them, and
> package all of this data into a "coercion environment" (a layer on top of a
> commutative diagram).  For example, one could do the following:
> sage: S. = QQ[]
> sage: R. = QQ[]
> sage: f = S.hom([y^2], R)
> sage: E = CoercionEnvironment([R, S], [f])
> sage: with E:
> ...z = x + y
> ...w = z - x^2
> ...
> sage: w
> y + y^2 - y^4
> sage: w.parent()
> Univariate Polynomial Ring in y over Rational Field
>
> A question remains with what to do with coercions from outside the
> coercion environment to inside, or vice versa.  Obviously, the answer can
> differe depending on which diagram's morphisms one uses.  One solution w

[sage-devel] Re: Coercion and categories in SAGE

[David Roe]

e_maps" so that we don't have to find coercion maps
more than once.
and a function find_coerce_map(R, S) that does the following:  (note that
the code below doesn't correctly handle cycles in diagrams)
def find_coerce_map(self, R, S):
"""
Returns a coercion morphism from R to S, or None if none exists in the
current environment.

Tests first to see if R and S are already cached in the dictionary of
known maps.
Next, checks to see if R and S both belong to one of the diagrams and
there's a path between them.  If this is true for only one of the diagrams,
returns that map.  If true for more than one, raises an error.
Next, checks to see if R belongs to a diagram with exit points and S to
a diagram with entry points.  If so, recursively tries to find a coercion
map from the codomain of an exit point of a diagram to which R belongs to
the domain of an entry point of a diagram to which S belongs.
Finally, checks to see if there is an enclosing environment, and if
there is a coercion map in the enclosing environment.
"""
if self.coerce_maps.has_key((R, S)):
return self.coerce_maps [(R, S)]
f = None
for cat in intersection(R._coercion_categories(),
S._coercion_categories):
if self.diagrams.has_key(cat) and R in self.diagrams[cat] and S in
self.diagrams[cat]:
path = self.diagrams[cat].path(R, S)
if path is not None:
if f is None:
f = path.compose()
else:
raise ValueError, "more than one coercion map found"
if f is None:
for diag1 in self.diagrams.values() if R in diag1:
for diag2 in self.diagrams.values() if S in diag2:
for g in diag1.exit_points() if g.domain() is not R:
 pathR = diag1.path(R, g.domain())
 if pathR is not None:
 for h in diag2.entry_points() if h.codomain() is
not S:
 pathS = diag2.path(h.codomain(), S)
 if pathS is not None:
 e = self.find_coerce_map(g.codomain(),
h.domain())
 if e is not None:
 if f is None:
 f = pathS.compose() * h * e * g *
pathR.compose()
 else:
 raise ValueError, "more than one
coercion map found"
if f is None and self.encl is not None:
f = self.encl.find_coerce_map(R, S)
self.coerce_maps[(R, S)] = f
return f

Suggestions are welcome (especially thoughts on the giant nested for loops).


As an example, in the default environment, the diagrams[Rings] diagram would
include the ring morphism from ZZ to QQ sending 1 to 1.  Whenever you create
a polynomial ring over a ring R it would add a morphism from R to the
polynomial ring embedding R as constant polynomials.  Whenever you create a
quotient ring it would add a morphism to the default diagram.  Etc.

When you create a finite field of prime order, diagrams[FiniteFields] will
add an entry point from ZZ to the prime field.  diagrams[FiniteFields] will
then build a lattice of compatibly embedded fields as you create new
extension fields of that prime field.  Note that the diagrams can be
disjoint unions of other diagrams (in practice one might use a list of
diagrams instead...).  I don't know yet how to make weakrefs work with this
whole scheme.

David


On 4/26/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> Interestingly enough, William and I were just talking about the
> coercion model today. The issue came up when deciding how to apply
> the sqrt() operator to, say, the rational number 2. Currently it
> returns a decimal approximation, and as of 2.5 it returns an element
> of the symbolic expressions ring. Both have serious drawbacks.
> Ideally one would get something in a number field, but then the issue
> comes up how to handle all the coercions.
>
> Essentially, what we came up with is that (extra) implicit coercion
> morphisms could be specified at ring (object) creation time, which
> would be extra data attached to that specific ring, and the coercion
> model would detect and use those. Also, one could implement a
> ambient_parent() method who would (if possible) return a new parent
> together with injections from each of the original rings. The lattice
> of number fields stuff would be used here.
>
> I like the idea of being able to use python contexts. I don't know
> how efficient one could make it though. I think the inner context
> would take precedence. I really like the idea of having a commutative
> diagram graph too. How would it get created? Would every ring, on
> creation time, try and update the commutative diagram to inc

[sage-devel] Re: elliptic curve height bounds

[David Roe]

I'd be happy to do it.  Having just read through the code, it looks like it
shouldn't be hard, with the following potential hangups:
Does SAGE have Tamagawa numbers, Kodaira symbols and minimal models for
elliptic curves?
I need to think a bit about the syntax for completions of number fields at
prime ideals in SAGE.  This is impacted be the ongoing discussion of
augmenting the coercion model.
David

On 4/27/07, William Stein <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> John Cremona has implemented a wide range of height bounds for
> elliptic curves in this magma program:
>
> http://www.maths.nott.ac.uk/personal/jec/ftp/progs/magma/nfhtbound.m
>
> Upon my request he GPL'd this program. Thus we can legally port it
> line-by-line to SAGE.  Would anybody like to volunteer to do this?
> I've listed this as trac ticket #360:
>http://www.sagemath.org:9002/sage_trac/ticket/360
>
> william
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://www.williamstein.org
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion and categories in SAGE

[David Roe]

>
> >> I think the square_root
> >> function should take a parameter to distinguish between the three
> >> types (with default 2? One can always do sqrt(2.0) or RR(sqrt(2)),
> >> etc. and I don't think causal users would be confused by \sqrt{2} as
> >> an answer). One could have actual functions for the types too. E.g.
> >> sqrt_approx, sqrt_extend, sqrt_exact(?).
> >
> > Yes.  That's almost exactly what I proposed above.  I prefer
> > different function names, since the return results are so
> > different, and since there are three options.  If it were just
> > one could have
> >def sqrt(self, exact=True, extend=True):
> >...
> >
> > but it gets complicated because if exact=False, you also need
> > to be able to pass in an optional precision parameter.  I think
> > I prefer three separate functions:
> >sqrt_approx, sqrt, sqrt_exact.
>
> Having a single function with parameters means one could pass the
> parameters on, e.g. in the sqrt function for power series, on needs
> to take the square root of the leading coefficient. This would let
> one write more generic code. Also, the "global" sqrt could take
> parameters too. Perhaps
>
> def sqrt(self, precision=None, extend=True):
>  
>
>
> I think this would be in addition to the named parameters.


As with William, I agree that this is a good idea.  We can have aliases
sqrt_exact and sqrt_approx when they make sense (for example, rationals
would have both, reals would have both, where sqrt_exact throws an error
given a negative real while sqrt_approx returns a complex, Z/NZ would only
have sqrt_exact and normal sqrt).

Another issue with square roots for general rings is the following:
what do we do when there is no commonly accepted choice of square root?
Worse, what do we do when there are more than two choices (sqrt(mod(17, 32))
could return 7, 9, 23 or 25)?  Pari's solution is to raise an error, GAP's
solution is to return a list of all of them, and I bet there's some system
out there that picks one.


> sqrt(2) could be an element of the number field K=Q[x]/(x^2-2)
> > *equipped* with an embedding map K --> SR that sends x to
> > the symbolic ring element sqrt(2).  We could also equip K with maps
> > to RR, CC, etc., by choosing a root to some precision (which would
> > choose a root to any bigger precision automatically).  More generally,
> > at creation time one could equip any ParentWithGens object with
> > a list of embedding morphisms that should be used by the coercion
> > system automatically.  This list is would be immutable.   So there
> > would be a new number field class NumberField_with_embedding(s).
>
> I think this should be an ability of any parent (with gens?), and one
> would not necessarily have to create a new class
> NumberField_with_embeddings.


This would be pretty easy to implement with a system like I described.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: buglet in maxima list

[David Roe]

To some extent I agree.  I think what pushed me to the other side is that if
you're having to use an index such an object in the first place, you already
have had to put the effort into learning that package.  And for those people
who know the package well and not SAGE well, preserving the native indexing
will make their lives easier.
David

On 5/6/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] writes:
>
> > +1 for consistency across the board.
>
> +1 from me too.  I'd like to learn Python and SAGE, not 50+ packages.
>
> Nick
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Fwd: [sage-devel] Re: Teach a man to fish

[David Roe]

> 1) I started moving desolvers.py into
SAGEHOME/devel/sage-main/build/sage/calculus/.  Is this the appropriate
place?
Seems like a good place to me.

> 2) You use "Integer(i)" instead of just "i", which seems unnecessary. I
changed all of these, but I am wondering why they were as they were.

The reason to use Integer(i) in general is that, in .py and .pyx files, if
you use just i, Python will use Python ints, which may or may not be what
you want (it's somewhat useful as loop variables, but otherwise you'd
probably rather be using an Integer).
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: a "press release"

[David Roe]

I have to agree with Martin here.  And I'm worried that if we get a
journalist involved, they won't be willing to include exactly what we want.
The general readership of a newspaper is not going to be very interested
that SAGE includes Python, GP/Pari, Maxima, Singular,

I also think that the tone in the press release is too confrontational.  In
particular, I think the statement that "The result has been software with
limited functionality at a very high price" is pretty ridiculous.  Despite
how much we would like Mathematica, Magma, Maple and Matlab to be free and
open source, I don't think one can really describe their functionality as
limited.  I don't think it's worth angering people who develop and use those
systems in order to interest people who have no idea what Mathematica is.
David

On 5/16/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
>
> 
>
> I think the press release lacks the mention of the free, open-source
> software
> we ship with SAGE. Despite the fact that SAGE wouldn't be possible without
> them as they are a crucial part it could seriously piss their authors off
> (and I couldn't blame them, to be honest) . They put years into making
> these
> fine software packages and SAGE claims all the credit.
>
> It might be true that controversies sell but are we seriously more
> interested
> in selling a story to a not-interested non-math audience than to "our
> fellow"
> mathematicians and developers? They might not take into account that this
> is "just" a press release.
>
> 
>
> Martin
>
> --
> name: Martin Albrecht
> _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _www: http://www.informatik.uni-bremen.de/~malb
> _jab: [EMAIL PROTECTED]
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] RFC: the subresultant algorithm

[David Roe]

I may be implementing something like this for p-adics soon.  It's one of the
options for doing gcds meaningfully.  If anyone else is interested in
working on this, get in touch with me.
David

On 5/17/07, Michel <[EMAIL PROTECTED]> wrote:
>
>
> It is rather frustrating that sage does not a have a gcd algorithm
> for
> multivariate polynomials over generic fields.
>
> There is such an algorithm. It is called the "subresultant" algorithm.
> It is for example described
> in Knuth's book "Semi-numerical algorithms" in section 4.6.1.
>
> Does anybody have experience with this algorithm? Does it perform
> acceptably? I think Magma
> uses it as a fallback if more specialized algorithms fail.
>
> Michel
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion bug

[David Roe]

These are all basically examples of sections of injective canonical maps
going the other direction.  There clearly shouldn't be a coerce method going
that direction because the objects are not isomorphic.  If we switch to a
data-driven, category theoretic coercion system, it should be possible to
recognize this kind of situation and handle it appropriately.  Personally,
I'd like to see what comes out of discussions at SD4 (or before too I
suppose) on the feasibility of such an extension to Sage's coercion model,
and how it would work.
David

On 5/22/07, Michel <[EMAIL PROTECTED]> wrote:
>
>
>
> > I'm concerned that your proposal, if I understand it correctly,
> > will make it difficult to avoid infinite loops.  Could you flesh
> > out your proposal more, and specifically address issues
> > involving infinite loops?
>
> I guess this was more of an idea than a proposal.  But given
> the rethinking of the coercion model it is perhaps appropriate
> to raise it.
>
> To address your concerrn wouldn't it be sufficient to specify that
>
> _noncanonical_into_
>
> should *not* call R(self). Or if it *really* wants to then it should
> do R._call_(self) (single underscore).
>
> In the examples I have in mind things are pretty simple.
> Constant diagonal matrices --> base ring.
> Fraction field element-> base ring (if the denominator is a unit)
> Constant polynomials -> base ring.
> Field extension -> base field (if applicable)
>
> etc...
>
> Michel
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: symbol number radian degree

[David Roe]

I hate significant figures.  Use real error propogation and standard
deviations instead.
David

On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> On Tue, 22 May 2007, David Harvey wrote:
>
> >> 1*meters + 2*meters*meters : NOT OK.
> >> 1*meters + 2*feet = ... in feet or meters?  (I say meters)
> >
> > I say metres.
>
> Not my fault you can't spell.  ;)
>
> William: I don't like the word "scalar".  That may be because much of my
> experience with PHP and PERL -- where there are scalars and arrays.  I'd
> like it to be called something like "unitless" or "value".  However, since I
> did a fair amount of tutoring for physics and engineering courses, being
> able to just throw away the units is deeply disturbing to me, for the
> following reason:
>
> > a = 5*meters
> > b = 2*feet
> > c = a*b; print c
> 10 feet*meters
> > d = a*meters(b)
> 25.4 meters^2
> > c == d
> True
> > print c.value()
> 10
> > print d.value()
> 25.4
>
> I would almost rather the user have to multiply by the inverse units.  I
> know almost nothing about chemistry... but last time I took a chemistry
> class, it was nearly trivial because I'd gotten so used to fiddling with
> units: if the units come out right, the answer is almost certainly correct.
>
> Since we're on this topic: anybody who cares about units probably cares
> about significant figures, too.  Should the units classes do book-keeping on
> significant figures?
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: GPL plotting/drawing options

[David Roe]

> Another big issue with asymptote is that I think it fundamentally depends
> on latex.  Latex doesn't come pre-installed in OS X or most Linux
> installs,
> though of course it is easy to install in Linux.   So far SAGE has got
> quite
> far with almost no dependencies -- latex is a pretty big dependency to
> add.
> Also, I'm concerned about the quality of 3d support in asymptote.
> We already have good 3d graphics, so the main reason to add asymptote
> would be for 3d graphics, where my impression is that it might not
> be that impressive after all.   That said, it's well worth investigating
> asymptote further, especially given that it is GPL'd.
>
> William


 Another reason to add asymptote is to be able to nicely print things like
commutative diagrams.  I'm not saying that it's as major, but it would be
cool to be able to do so.
David

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Sage Enhancement Proposal: Number Fields

[David Roe]

For those of you interested in improving number fields in Sage (especially
those of you who won't be at SD4), I've posted a SEP on the wiki.  As you
will be able to tell, I was rushed at the end.  But I would like to hear
peoples' comments.

http://www.sagemath.org:9001/days4/projects/numbertheory/number_fields

David Roe

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Matrix question

[David Roe]

Sorry I didn't reply earlier.

Implementing an is_symmetric function for matrices sounds like a good idea.
But I think it should go in the base class: something like

def is_symmetric(self):
if self.ncols != self.nrows:
return False
cdef int i, j:
for i from 1 <= i < self.nrows:
for j from 0 <= j < i:
if self[i][j] != self[j][i]:
return False
return True

One can override this in a subclass if desired: if there's some special,
faster way to test for symmetry.  I can't think of a better method in
general than this.
David

On 6/28/07, Justin C. Walker <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I ran into a glitch, using QuaternionAlgebraWithGramMatrix(field,
> matrix):
>- the code verifies that the second argument is a matrix
>  with "isinstance(Matrix)", which blows up because 'Matrix'
>  is not known.  A simple 'import' fixes that.
>- then the code blows up because "is_symmetric" is not an
>  attribute of the second arg.
>
> Fixing this is a bit more involved.  First, it appears that
> "is_symmetric" is supposed to be a boolean, presumably defined when
> the matrix is created.  There are other versions, scattered through
> the code, of a function, but nothing in the Matrix class itself.
>
> Seems to me that this should be a function, not a variable (matrices
> aren't immutable), and defined in the class.
>
> My question: is it reasonable to implement is_symmetric() in the
> class definition?
>
> Some more questions:
>
> The Matrix class is a pyrex module, and checking for equality is then
> probably best done by subclasses.  Is that correct?  Is it reasonable
> to have a generic "it can be done in Pyrex" version that must be
> overridden by a subclass if that assumption is false?
>
> Is there a better (i.e., faster) way than checking for a square
> matrix and making n(n-1)/2 comparisons?
>
> Is the Matrix class undergoing reconstruction, so the above are all
> irrelevant?  :-}
>
> Thanks!
>
> Justin
>
> --
> Justin C. Walker, Curmudgeon at Large
> Institute for the Absorption of Federal Funds
> ---
> If it weren't for carbon-14, I wouldn't date at all.
> ---
>
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: request for comments: ZZ(ZZ(FOO).binary(),2) == FOO

[David Roe]

I would agree on the little endian-ness.  The lists of digits coming from
p-adics (and printing in series mode) is little-endian.  It would be nice to
be consistent with this.  I also agree with David Harvey's arguments.
David

On 6/29/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jun 29, 2007, at 5:51 AM, Martin Albrecht wrote:
>
> >
> > On Friday 29 June 2007 02:48, Nick Alexander wrote:
> >> Martin Albrecht <[EMAIL PROTECTED]> writes:
> >>> Hi there,
> >>>
> >>> I often come across the situation where I have to construct an
> >>> integer
> >>> from its binary representation and vice versa. So far you do it
> >>> in SAGE
> >>> using strings. I have attached a preliminary patch which allows the
> >>> following code to work, i.e. I _replaced_ the binary() method (which
> >>> returned a string) with a method that returns a tuple of Python
> >>> ints.
> >>
> >> I won't take about the method name, but it would be very nice to have
> >> a method that returns the base b digits of an integer for arbitrary
> >> b.  Could this be made an optional argument, perhaps with a fast path
> >> for b = 2?
> >>
> >> Nick
> >
> > Sounds good, will do. Actually, I have to bring up the endianess
> > again. Right
> > now the string is big endian and I would prefer the list/tuple/
> > vector match
> > the endianess of the string rather than the endianess of polynomials.
> >
> > sage: 16.str(2)
> > '1'
> > sage: 16.str(8)
> > '20'
> >
> > Thoughts?
>
> I still don't like it, basically because I've never seen a computer
> algebra system that represents integers *internally* in big-endian
> format. (The main exception is PARI, which actually *reverses* the
> representation on every single operation, because it uses GMP for the
> arithmetic, and GMP represents things internally in little-endian
> format!)
>
> Strings are always big-endian because that's the way people read
> numbers off a page. That's just a historical thing. It has more to do
> with the left-right reading direction than representation in memory.
> I guess when you start from the left, if you see how long the number
> is, then the first digits (i.e. the most significant digits) give you
> immediately more information about the overall magnitude. If you
> start from the right, you only get information interesting to a
> number theorist :-)
>
> I guess the main reason it feels more natural to me to go little
> endian is then digits are always aligned automatically for arithmetic
> purposes. Like if you want to add two vectors, you just start
> looping, you don't have to fiddle with indexing. If the value
> overflows, you just append digits at the end, you don't have to go
> shifting everything around.
>
> On the other hand, you have mathematica as a precedent:
>
> IntegerDigits[13, 2]
>
> {1, 1, 0, 1}
>
> But honestly I don't really care which way it goes. If you don't buy
> my argument, doesn't bother me at all. I'll just call reverse()
> whenever I use your function :-)
>
> david
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Saving graphs to Postscript

[David Roe]

Hey all,
I ran into a problem saving a graph to postscript recently.  Here's what I
did:

plot.options['plot_division'] = 4
plot.options['plot_points'] = 2
P=plot(sin(5/(x)), x,0,1)
P.save('filename.eps', xmin = -.25, xmax = 1)

Attempting to open the resulting file on my MacBook Pro with either Preview
or ps2pdf leads to errors (I've pasted in the error from ps2pdf at the end
of this e-mail in case it's useful to anyone).
Similar problems arise with .ps, but .png appears to work fine.

David







Error: /invalidfont in -dict-
Operand stack:
   LucidaGrande   --dict:11/14(L)--   Font   LucidaGrande
--dict:11/14(L)--   LucidaGrande
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3
%oparray_pop   --nostringval--   1   3   %oparray_pop   1   3
%oparray_pop   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--   2   4
%oparray_pop   3   4   %oparray_pop   --nostringval--   --nostringval--
--nostringval--   7   5   %oparray_pop   --nostringval--   7   5
%oparray_pop
Dictionary stack:
   --dict:1120/1686(ro)(G)--   --dict:0/20(G)--   --dict:75/200(L)--
--dict:6/7(L)--   --dict:17/17(ro)(G)--
Current allocation mode is local
Last OS error: 2
Current file position is 4613603
AFPL Ghostscript 8.51: Unrecoverable error, exit code 1

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---