[sage-devel] C library for SCSCP
Dear all, You may have heard about the protocol called "Symbolic Computation Software Composability Protocol", abbreviated SCSCP, developped under the SCIEnce project (http://www.symbolic-computation.org/). I have made a C library for SCSCP. The library aims to provide a simplest API to create client and server applications. This library is fully SCSCP 1.3-compliant. It is available for download from: http://www.imcce.fr/Equipes/ASD/trip/scscp/ Best regards, Mickael Gastineau gastin...@imcce.fr --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: accessors for FreeAlgebraElement
Hi Florent, I think the polynomial ring model should translate well to the non-commutative free algebras. In addition to access, specifying a (non-commutative) monomial ordering would be desirable. Generalizing these orderings is the only challenge in the generalization from free commutative algebras. For performance, one might want to use the same idea of a dictionary directly and have both free mononoids and free algebras use this. I think I strongly tied these two classes together, but this could be weakened while preserving the sharing of code. On the subject of orders, Sage, like Magma, allow one to specify the monomial ordering, but use the reverse ordering for printing: magma: P := PolynomialRing(QQ,2); magma: B := [ 1, x, x^2, y, x*y ]; magma: Sort(B); [ 1, y, x, x*y, x^2 ] magma: &+B; x^2 + x*y + x + y + 1 sage: P. = PolynomialRing(QQ,2) sage: B = [ 1, x, x^2, y, x*y ] sage: B.sort() sage: B [1, y, x, x*y, x^2] sage: sum(B) x^2 + x*y + x + y + 1 It would be desirable to be able to specify the printing order (whether 'reverse' or not). In the context of completions, a left-to-right printing is preferable: sage: P. = PolynomialRing(QQ) sage: S. = PowerSeriesRing(QQ) sage: f = x^7 + x + 1 sage: f x^7 + x + 1 sage: S(f) 1 + t + t^7 This could be controlled by a simple flag. Cheers, David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: accessors for FreeAlgebraElement
Dear William,
> > Or my student's :). That was my intention ! The obvious question is now the
> > naming convention. It seems to me that we should stick as close as possible
> > to
> > polynomials:
> >
> > sage: ring = ZZ['x1,x2']
> > sage: x1 = ring.gens()[0] # why x1 is not defined ???
>
> What do you mean by "why x1 is not defined?"There is inject_on(),
> but that only works with PolynomialRing:
>
> sage: inject_on()
> Redefining: FiniteField Frac FractionField FreeMonoid GF
> LaurentSeriesRing NumberField PolynomialRing quo quotient
Ok !!! In forgot about this mantra. Thanks for pointing this out.
> sage: PolynomialRing(ZZ, 'x1,x2')
> Defining x1, x2
> Multivariate Polynomial Ring in x1, x2 over Integer Ring
> sage: (x1+x2)^3
> x1^3 + 3*x1^2*x2 + 3*x1*x2^2 + x2^3
>
>
> It might be possible to fix ZZ['x1,x2'] to also work with inject_on -- not
> sure.
And I also thought after asking the debugger that the call
PolynomialRing(ZZ, 'x1,x2')
and
ZZ['x1,x2']
where strictly equivalent:
sage: trace("ZZ['x,y']")
> (1)()
ipdb> s
--Call--
> /usr/local/sage/sage-3.4.2/local/lib/python2.5/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py(41)PolynomialRing()
40
---> 41 def PolynomialRing(base_ring, arg1=None, arg2=None,
42sparse=False, order='degrevlex',
But inject_on seems to change the first one without telling the second one...
> > sage: truc = x1^8 + 2*x1^4 + 2
> > sage: truc
> > x1^8 + 2*x1^4 + 2
> > sage: type(truc)
> > > 'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular'>
> > sage: truc.dict()
> > {(0, 0): 2, (4, 0): 2, (8, 0): 1}
> > sage: truc.coefficients()
> > [1, 2, 2]
> > sage: truc.monomials()
> > [x1^8, x1^4, 1]
> >
> > Should we stick to this interface ?
> >
>
> I've cc'd David Kohel -- original author of FreeAlgebra, since he
> might have some thoughts.
Awaiting for comments...
Cheers,
Florent
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: accessors for FreeAlgebraElement
Dear David, > I think the polynomial ring model should translate well > to the non-commutative free algebras. In addition to > access, specifying a (non-commutative) monomial > ordering would be desirable. Generalizing these > orderings is the only challenge in the generalization > from free commutative algebras. > > For performance, one might want to use the same idea > of a dictionary directly and have both free mononoids > and free algebras use this. I think I strongly tied these > two classes together, but this could be weakened while > preserving the sharing of code. Sure ! But right now due to very few free time in personally have and the man-power I have with my student, I'll only focus on extending the interface... I'm sorry but I'll not have the time for any optimization or rewriting... Right now FreeAlgebraElements are stored by a dictionary. My feeling is that except for optimization, FreeAlgebra should be implemented as the GroupAlgebra of the Free monoid. There should be not that many specific code... Cheers, Florent --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: C library for SCSCP
On May 13, 1:42 am, Mickael Gastineau wrote: > Dear all, Hi Mickael, > You may have heard about the protocol called "Symbolic Computation > Software Composability Protocol", abbreviated SCSCP, developped under > the SCIEnce project (http://www.symbolic-computation.org/). > > I have made a C library for SCSCP. The library aims to provide a > simplest API to create client and server applications. This library is > fully SCSCP 1.3-compliant. > > It is available for download from: > > http://www.imcce.fr/Equipes/ASD/trip/scscp/ Interesting, but the code is under the CECILL-C license which according to http://fedoraproject.org/wiki/Licensing is not GPL compatible, neither V2 nor V3. Given that the CeCILL License v1.1 as well as CeCILL License v2 are what made you chose that license? > Best regards, > > Mickael Gastineau > gastin...@imcce.fr Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: C library for SCSCP
The fedora says that isn't compatible but the FSF says that it is compatible with GPL : see http://www.fsf.org/licensing/licenses/ (section CeCILL version 2) or http://www.gnu.org/licenses/license-list.html#SoftwareLicenses and the FAQ of the cecill says that the "CeCILL is nevertheless compatible with the GNU GPL: when a software under CeCILL is integrated with a software under the GPL, the resulting work can be distributed under the GNU GPL" So I consider that this license is compatible with the GPL license. Mickael, On May 13, 1:06 pm, mabshoff wrote: > On May 13, 1:42 am, Mickael Gastineau wrote: > > > Dear all, > > Hi Mickael, > > > You may have heard about the protocol called "Symbolic Computation > > Software Composability Protocol", abbreviated SCSCP, developped under > > the SCIEnce project (http://www.symbolic-computation.org/). > > > I have made a C library for SCSCP. The library aims to provide a > > simplest API to create client and server applications. This library is > > fully SCSCP 1.3-compliant. > > > It is available for download from: > > >http://www.imcce.fr/Equipes/ASD/trip/scscp/ > > Interesting, but the code is under the CECILL-C license which > according to > > http://fedoraproject.org/wiki/Licensing > > is not GPL compatible, neither V2 nor V3. Given that the CeCILL > License v1.1 as well as CeCILL License v2 are what made you chose that > license? > > > Best regards, > > > Mickael Gastineau > > gastin...@imcce.fr > > Cheers, > > Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: C library for SCSCP
On May 13, 5:25 am, Mickael Gastineau wrote: Hi Mickael, > The fedora says that isn't compatible but the FSF says that it is > compatible with GPL : > seehttp://www.fsf.org/licensing/licenses/ (section CeCILL version > 2) > orhttp://www.gnu.org/licenses/license-list.html#SoftwareLicenses No, it is not. That entry is specifically about "CeCILL version 2". > and the FAQ of the cecill says that the "CeCILL is nevertheless > compatible with the GNU GPL: when a software under CeCILL is > integrated with a software under the GPL, the resulting work can be > distributed under the GNU GPL" > > So I consider that this license is compatible with the GPL license. Well, the FSF speaks specifically about the "CeCILL version 2". If you check the link I posted to the Fedora wiki you will see that they agree with that assessment, but neither "CECILL-C" nor "CECILL-B" are considered GPL compatible by the Fedora people. If you read the CECILL- C license I tend to agree that it is incompatible with the GPL. > Mickael, Cheers, Mcihael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] strange behavour of sum()
Is there any reason why this line: print sum([1,2,3],10) in a .pyx file should not compile? I get the error "Call with wrong number of arguments (expected 3, got 2)" with an arrow pointing to the work "sum". This is driving me mad -- a very similar line in another .pyx file was fine! John --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: notebook and sage in path
>> The build bits do not exist in ipython, but I think ipython should >> have some good web notebook. > > Sure, competition is good for business. I just don't think this code > is currently a priority for them and judging from the current > discussion about getting 0.10 out the door I don't see anyone > interested *and* having the time to work on this. This is a pretty accurate assessment of the IPython notebook work. Our (IPython's) focus right now is on refactoring the core of IPython and parallel computing. I too am using spd/sagelite/Sage for notebooky things. Cheers, Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: notebook and sage in path
> Well, I think what we should do is merge as much of SPD into Sage as > possible to lessen the maintainance burden. One thing I could see here > is to define SAGE_EXECUTABLE and you would just set it to spd in your > code. I think this is a good idea. I think if SPD is kept separate, it will end up being a lot of work for all of us. One case in point: I am about to submit some bug reports related to Sage and SPD. The bugs affect both and it seems silly to do double work and track/fix these issues in both places. But this brings up a question: Currently spd creates its own .spd directory for notebooks. Sage creates a .sage dir for its notebooks. We should probably keep these 2 separate (but also configurable) as the 2 get combined. Cheers, Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using --enable-framework on Mac OS X?
I just pinged the pythonmac-sig group about why and when a framework build is actually needed. A while back I created an spkg for qt/pyqt and I remember that I needed to do a framework build to get it to work. My recollection is that if you want Python to be able to do anything with the native Mac GUI, it needs to be a framework build. If this is indeed the case, I think it would be a great idea to have the Sage python be a framework build and I have an older spkg around somewhere that does this without any bugs (that I know of ;-)). I know that in SPD, we would like to be able to have an spkgs for matplotlib that includes real GUI support. Plus I know that some folks are obviously linterested in VTK, Mayavi stuff as well. I will dig up my framework python spkg and get back after I hear from the pythonmac-sig folks. Cheers, Brian On Sun, May 10, 2009 at 10:48 AM, mabshoff wrote: > > On May 10, 10:36 am, Prabhu Ramachandran > wrote: >> On 05/10/09 21:58, mabshoff wrote: > > Hi Prabhu, > > > >> Well, I have seen this when I got the error first time (google is our >> friend) but didn't believe the answer would work for the simple reason >> that VTK is really well tested. I didn't want to mess with compilation >> arguments before testing other options. Regardless, I did try a manual >> link with -Wl,-single_module and it didn't work -- I got different >> errors. I could try -fno-common but that would have to be done for the >> Python build and not the VTK build. It appears that the problem is not >> with VTK but the Python build since the linking fails for the Python >> library. The VTK libraries are linked to each other quite nicely. > > Ok. I would still consider this strange, but IIRC most python builds > on OSX are Framework builds. Adding some custom flags like -fno-common > and/or -fPIC wouldn't be a problem for Sage IMHO. > > I am aware of some other problems with for example dyanmic python > libraries with modern toolchains on Linux since they do require -fPIC. > This problem seems to be unresolved in Python 2.5, but I think > something has been done about this in Python 2.6. > >> >> I guess I could retry with a non-framework build but it really takes a >> >> while to build on my machine and all previous attempts failed. >> >> > Sure. Let me know if the above works. >> >> I've tried the above and a few other things too. I'm still all ears >> though, so keep the suggestions coming. > > Well, I would need to play around with VTK, but I don't really have > the time to do that now :(. > > > >> > Well, it doesn't matter for builds from source too much, the real >> > problem is when a user runs -upgrade for Sage. >> >> Sorry for being dense. You mean when the user runs -upgrade with a >> non-framework install? Suppose a user has a fresh install, would the >> framework build cause problems when this user does a -upgrade? >> IOW, is this only a problem for those with older non-framework builds? > > Sorry, I wasn't quite correct - at least I wanted to write something > else: When you build python as framework without ever having build it > as non-framework there are some problems. They are fixable, but so far > I have not been convinced that building the Python in Sage as a > framework solves more problems that it causes. > >> Thanks. >> >> cheers, >> prabhu > > Cheers, > > Michael > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Clarification of Sage and GPL
> I apologize for the way I presented this. No offense was intended for > anybody. I won't follow up in sage-flame, because it was never my > intention to start a flame (I don't think this discussion has turned > into a flame yet, neither by me or others, but I can see it has the > potential to become one). I think licensing issues, although painful, > are quite important and don't qualify as flames. > > BTW, I use latin words not to sound fancy, but because I think they > may convey a message I want to share. Note that as english is not my > native language, I've got some handicap wrt finding the correct > english words for some things I want to say. You may want to factor > that in when reading my posts (I mean, when I actually use english). > OTOH, there are many latin expressions which are very commonly used in > english (more commonly than in spanish, I'd say). > > I hope that this will be, as per William's request, my last post in this > thread. Gonzalo, To respect William's request, I will follow up with you offlist. To everyone, I apologize for the inflammatory tone of my final remarks. I agree with Gonzalo that license discussions are important - I learned a lot from this one, which was my goal. Cheers, Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Complex interval fields
I recently noticed that complex interval fields have a very different notion of equality than real interval fields. For RIF, a != b if a is *definitely* not equal to b, but CIF just compares endpoints. I think we should change CIF's behavior to be more like RIF, does anyone have any objections? - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: strange behavour of sum()
On May 13, 2009, at 8:53 AM, John Cremona wrote: > Is there any reason why this line: > > print sum([1,2,3],10) > > in a .pyx file should not compile? I get the error "Call with wrong > number of arguments (expected 3, got 2)" with an arrow pointing to the > work "sum". > > This is driving me mad -- a very similar line in another .pyx file > was fine! No idea, did you re-define sum somewhere earlier? - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Complex interval fields
On Wed, May 13, 2009 at 11:02 AM, Robert Bradshaw wrote: > > I recently noticed that complex interval fields have a very different > notion of equality than real interval fields. For RIF, a != b if a is > *definitely* not equal to b, but CIF just compares endpoints. I think > we should change CIF's behavior to be more like RIF, does anyone have > any objections? No objection from me. (Sorry, this is surely my fault; I don't remember what I was thinking at the time.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: [Cython] Paper about Cython
This is a nicely written paper by some scientific computing person about using Cython. See below. Also, this link is better than the one given by the author below, since he messed up the file name. http://sage.math.washington.edu/home/wstein/tmp/simula_pdf_file.pdf -- Forwarded message -- From: Ilmar Wilbers Date: Wed, May 13, 2009 at 10:44 AM Subject: [Cython] Paper about Cython To: cython-...@codespeak.net Hi list, I wanted to make you aware of a paper[1] that we have written at Simula Research Laboratory in Oslo, Norway. The paper will be presented at MekIT 09 - Conference on Computational Mechanics in Trondheim in a couple of weeks. In this paper we compare Cython with similar packages with regard to execution time. It must be noted that the time for the arithmetic mean for Cython has decreased since the paper was accepted, as Dag Sverre pointed me to the additional argument 'mode' for the arrays. This reduces the time for Cython from 1.6 to 1.3 compared to the pure Fortran implementation. I apologize for any mistakes concerning Cython in the paper, as I'm sure the developers have some comments about stuff I've missed. We will be following the development of Cython further (in particular the Fortran integration) thanks for an excellent package so far! Ilmar Wilbers Simula Research Laboratory [1]: http://simula.no/research/scientific/publications/Simula.SC.578/simula_pdf_file ___ Cython-dev mailing list cython-...@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Complex interval fields
On May 13, 2009, at 11:23 AM, Carl Witty wrote: > On Wed, May 13, 2009 at 11:02 AM, Robert Bradshaw > wrote: >> >> I recently noticed that complex interval fields have a very different >> notion of equality than real interval fields. For RIF, a != b if a is >> *definitely* not equal to b, but CIF just compares endpoints. I think >> we should change CIF's behavior to be more like RIF, does anyone have >> any objections? > > No objection from me. (Sorry, this is surely my fault; I don't > remember what I was thinking at the time.) Excellent. Yours was the main opinion I was looking for. I'll be fixing this as part of the new symbolics. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: strange behavour of sum()
2009/5/13 Robert Bradshaw : > > On May 13, 2009, at 8:53 AM, John Cremona wrote: > >> Is there any reason why this line: >> >> print sum([1,2,3],10) >> >> in a .pyx file should not compile? I get the error "Call with wrong >> number of arguments (expected 3, got 2)" with an arrow pointing to the >> work "sum". >> >> This is driving me mad -- a very similar line in another .pyx file >> was fine! > > No idea, did you re-define sum somewhere earlier? No. I'll try to post something reproducible tomorrow. John > > - Robert > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 3.4.2 64 bit MacIntel 10.5 binary with only *one* doctest failure
On May 12, 3:27 am, mabshoff wrote: > I have build a 3.4.2 binary with various fixes and posted it at > http://sage.math.washington.edu/home/mabshoff/OSX64/ > Please give it a spin if you care about 64 bit OSX. Seems to work OK on my Mac Pro, although I hardly put it to the test. Are there any specific commands that you would want me to try or that I might expect to run faster on the 64 bit version? Perhaps some operations with large matrices? I notice the following when I check the precision of double: sage: RDF.prec() 53 This is the same result I get when I execute this command on my 32 bit version. I expected this, since I've noticed the same behavior in 64 bit Mathematica, Matlab, and C, but it makes me wonder why we should be excited about 64 bit systems. Mark McClure --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Perhaps a bug in polynomial()
Hi,
I traced this bug, and found that
sage: B=QQ[x]
sage: print B({0:1,1:2})
sage: print B({(0,):1,(1,):2})
2*x + 1
2*x + 1
sage: B=GF(5)[x]
sage: print B({0:1,1:2})
sage: print B({(0,):1,(1,):2})
2*x + 1
Traceback (most recent call last):
File "", line 1, in
File "/home/kwankyu/.sage/sage_notebook/worksheets/admin/0/code/
29.py", line 9, in
exec compile(ur'print B({(_sage_const_0 ,):_sage_const_1 ,
(_sage_const_1 ,):_sage_const_2 })' + '\n', '', 'single')
File "/usr/local/sage/local/lib/python2.5/site-packages/
SQLAlchemy-0.4.6-py2.5.egg/", line 1, in
File "parent.pyx", line 288, in
sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4320)
File "coerce_maps.pyx", line 81, in
sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/
structure/coerce_maps.c:3164)
File "coerce_maps.pyx", line 76, in
sage.structure.coerce_maps._call_ (sage/structure/coerce_maps.c:3039)
File "/usr/local/sage/local/lib/python2.5/site-packages/sage/rings/
polynomial/polynomial_ring.py", line 312, in _element_constructor_
return C(self, x, check, is_gen, construct=construct, **kwds)
File "polynomial_zmod_flint.pyx", line 72, in
sage.rings.polynomial.polynomial_zmod_flint.Polynomial_zmod_flint.__init__
(sage/rings/polynomial/polynomial_zmod_flint.c:11609)
File "polynomial_template.pxi", line 119, in
sage.rings.polynomial.polynomial_zmod_flint.Polynomial_template.__init__
(sage/rings/polynomial/polynomial_zmod_flint.c:5246)
TypeError: 'tuple' object cannot be interpreted as an index
I think the second form is not acceptable. Then the function
remove_from_tuple() in sage.rings.polynomial.multi_polynomial.pyx
should be revised as it output (1,) from (1,2) for example.
Kwankyu
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Perhaps a bug in polynomial()
Hi, I created a ticket #6036 for this bug. Kwankyu --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] 1-pixel errors in placement of lines and dots
In 2d plots, dots and oblique lines are nicely antialiased
but seem to be consistently misplaced by about 1 pixel.
Is this a problem with sage, matplotlib, aag, ...?
See the example below, where the dots are about 1 pixel to the left of
where they should be,
and the diagonal lines are likewise off by about 1 pixel.
http://orange.math.buffalo.edu/temp/1pixeloff_magnified.png
http://orange.math.buffalo.edu/temp/1pixeloff.png
g=0
bars = []
bars.append( line( [ ( 0,0 ), ( 2,2 ) ] , rgbcolor=(1,g,g),
zorder=0) )
bars.append( line( [ ( 0,2 ), ( 2,0 ) ] , rgbcolor=(1,g,g),
zorder=0) )
bars.append( line( [ ( 0,1 ), ( 2,1 ) ] , rgbcolor=(g,g,g),
zorder=0) )
bars.append( line( [ ( 1,0 ), ( 1,2 ) ] , rgbcolor=(g,g,g),
zorder=0) )
bars.append( line( [ ( 0,2 ), ( 2,2 ) ] , rgbcolor=(g,g,g),
zorder=0) )
bars.append( line( [ ( 2,2 ), ( 2,0 ) ] , rgbcolor=(g,g,g),
zorder=0) )
data = [ (0,0), (1,1), (2,2), (0,2), (2,0)]
p = points(data ,rgbcolor=(0,0,1),pointsize=10,zorder=1 ) + sum
( bars )
p.save('1pixeloff.png',aspect_ratio=1)
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: 3.4.2 64 bit MacIntel 10.5 binary with only *one* doctest failure
On May 13, 2:37 pm, mark mcclure wrote: > On May 12, 3:27 am, mabshoff wrote: Hi, > > I have build a 3.4.2 binary with various fixes and posted it at > > http://sage.math.washington.edu/home/mabshoff/OSX64/ > > Please give it a spin if you care about 64 bit OSX. > > Seems to work OK on my Mac Pro, although I hardly put it to > the test. Are there any specific commands that you would want > me to try or that I might expect to run faster on the 64 bit > version? Perhaps some operations with large matrices? It depends, some benchmarks are faster (things depending on MPIR), some are slower, i.e. certain operations with LinBox IIRC. > I notice the following when I check the precision of double: > sage: RDF.prec() > 53 > > This is the same result I get when I execute this command on > my 32 bit version. I expected this, since I've noticed the same > behavior in 64 bit Mathematica, Matlab, and C, but it makes me > wonder why we should be excited about 64 bit systems. Doubles are the same everywhere. The main issue is that you now can address more than 2 or 4GB RAM and given that you can get a mac with loads of RAM theses days it seems prudent to go 64 bit. Just like on Windows an aweful lot of software is still 32 bit even on 64 bit systems. Exceptions are mostly things like databases and scientific applications, i.e. those who need the extra RAM. As usual the port uncovered a number of bugs in Sage, so this is a good thing that it now works. > Mark McClure Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using --enable-framework on Mac OS X?
On May 13, 9:46 am, Brian Granger wrote: Hi Brian, > I just pinged the pythonmac-sig group about why and when a framework > build is actually needed. A while back I created an spkg for qt/pyqt > and I remember that I needed to do a framework build to get it to > work. My recollection is that if you want Python to be able to do > anything with the native Mac GUI, it needs to be a framework build. Ok. > If this is indeed the case, I think it would be a great idea to have > the Sage python be a framework build and I have an older spkg around > somewhere that does this without any bugs (that I know of ;-)). As is Sage doesn't even build if you do a straight up framework build. This can and will be fixed, but if I have learned one thing about FrameWorks on OSX is to avoid them whenever possible, i.e that absolute crap issue with the IOKit and libpng has scared me for life ;) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [ANN] sage-mode-0.6
On Tue, May 12, 2009 at 05:40:46PM -0700, Nick Alexander wrote:
> > - C-C C-j seems to get confused by tabs in the input, and triggers
> > automatic completion:
>
> As far as I'm concerned, tabs in input are always wrong. Python even
> has an error (TabError) for this, no? This is wontfix for me.
I am using C-c C-j also on external files of mine, where tabs would be
acceptable, but that's fair enough
> > - >* `next-error' now jumps between top-level errors, avoiding
> > lower
> >> level source files. Lower level source files are still hyperlinked.
> >
> > It might be jumping a bit too much. It detects no error in the test
> > result in PS.
>
> This I can't explain. The regexp is
>
> (defvar sage-test-regexp-alist
>'(("File \"\\(.*?\\)\", line \\([0-9]+\\):"
> 1 2)
> ("File \"\\(.*?\\)\", line \\([0-9]+\\),"
> 1 2 nil 0)
> )) ;; a `compilation-error-regexp-alist' for sage doctest errors
>
> And your examples should hit the first one. Is it consistently wrong?
I don't have my example under hand anymore, but with the example
below, it is consistently wrong. That is C-c t followed by C-x ` when
the tests are finished yields a Moved past last error message.
Let me know if there are things I should try to pinpoint the error.
Best,
Nicolas
-*- mode: sage-test; default-directory:
"/opt/sage-3.4.2/devel/sage-combinat/sage/schemes/elliptic_curves/" -*-
sage-test started at Wed May 13 22:48:08
sage -b >/dev/null && sage -tp 4
/opt/sage-3.4.2/devel/sage-combinat/sage/schemes/elliptic_curves/ell_torsion.py
real0m2.863s
user0m2.404s
sys 0m0.392s
Global iterations: 1
File iterations: 1
Using cached timings to run longest doctests first.
Doctesting 1 files doing 4 jobs in parallel
sage -t ell_torsion.py
**
File
"/opt/sage-3.4.2/devel/sage-combinat/sage/schemes/elliptic_curves/ell_torsion.py",
line 113:
sage: type(T)
Expected:
Got:
**
File
"/opt/sage-3.4.2/devel/sage-combinat/sage/schemes/elliptic_curves/ell_torsion.py",
line 151:
sage: type(T)
Expected:
Got:
**
2 items had failures:
1 of 30 in __main__.example_1
1 of 9 in __main__.example_2
***Test Failed*** 2 failures.
For whitespace errors, see the file /opt/sage-3.4.2/tmp/.doctest_ell_torsion.py
[5.5 s]
--
The following tests failed:
sage -t
devel/sage-combinat/sage/schemes/elliptic_curves/ell_torsion.py # 2 doctests
failed
--
Total time for all tests: 5.5 seconds
sage-test finished with failing tests at Wed May 13 22:48:16
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: [ANN] sage-mode-0.6
On 13-May-09, at 10:53 PM, Nicolas M. Thiery wrote: > > On Tue, May 12, 2009 at 05:40:46PM -0700, Nick Alexander wrote: >>> - C-C C-j seems to get confused by tabs in the input, and triggers >>> automatic completion: >> >> As far as I'm concerned, tabs in input are always wrong. Python even >> has an error (TabError) for this, no? This is wontfix for me. > > I am using C-c C-j also on external files of mine, where tabs would be > acceptable, but that's fair enough Hmm, I hadn't thought of this. There is an emacs command untabify that I will insert at the appropriate place; the only tricky thing is making sure the tab-width's agree. I think this is trivial and I will try to make it work, even though I still think it is wrong :) (PS. If there's no good reason to use tabs, you'll be a better netizen if you don't use them.) >> And your examples should hit the first one. Is it consistently >> wrong? > > I don't have my example under hand anymore, but with the example > below, it is consistently wrong. That is C-c t followed by C-x ` when > the tests are finished yields a Moved past last error message. Ah, I hit this myself and didn't think much of it. Can you verify that the errors are hyperlinked? What's strange is if you click the first, then `next-error' works. I will investigate. Thanks for the reports! Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
