[sage-devel] Clifford + Sage
Hello,
I would like to make a relatively simple (but cumbersome) symbolic
calculation in exterior algebra (more precisely in \Lambda^{k}(R^
{n})).
One possibility would be to use the Clifford algebra Cl(R^{n}, Q=0).
Do you know if there is something in "Sage" appropriate to make this
kind of calculation?
Thanks in advance for any hint.
Cordially,
Luis
--~--~-~--~~~---~--~~
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: Clifford + Sage
Sage contains sympy and there is this:
http://wiki.sympy.org/wiki/Geometric_Algebra_Module
If that does what you want, you might want to ask about it on
the sympy list: http://groups.google.com/group/sympy?hl=en
since I not sure if the author subscribes to this list.
Sage contains Maxima and there is this:
http://maxima.sourceforge.net/docs/manual/en/maxima_29.html
Hope one of these helps.
On Sat, Jan 17, 2009 at 6:45 AM, luis wrote:
>
>
> Hello,
>
> I would like to make a relatively simple (but cumbersome) symbolic
> calculation in exterior algebra (more precisely in \Lambda^{k}(R^
> {n})).
> One possibility would be to use the Clifford algebra Cl(R^{n}, Q=0).
> Do you know if there is something in "Sage" appropriate to make this
> kind of calculation?
>
> Thanks in advance for any hint.
>
> Cordially,
>
> Luis
>
> >
>
--~--~-~--~~~---~--~~
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] Plan for shifting Pchpack functionality into Sage
Currently Phcpack is an optional package for sage. Its main purpose is to numerically compute isolated solutions of polynomial systems, although it has some other functionality as well (e.g. computing mixed volumes, witness sets for higher-dimensional solution components). I have wanted Phcpack to be standard in Sage for a while, but have been blocked by concerns about portability. Phcpack is written in Ada. Recently Jan Verschelde (the author of Phcpack) and his students have added some C and Python interfaces, which help integration efforts but don't solve the portability issue. I discussed this situation recently with Jan (who I am cc'ing on this email in case he has clarifications or corrections) and he seems willing to work with me on porting Phcpack into Sage as a native program. Although Phcpack is pretty fast, there are closed source programs that seem quite a bit faster at the moment (although its not a simple comparison, they different strengths and weaknesses). A Sage implementation could be quite a bit faster by taking advantage of Sage's linear algebra and other components. My plan for doing this is to move in the functionality piece by piece starting in late Febuary (earlier if I can magically find extra time). The first piece will be a parameter-homotopy path tracker, since I understand that part the best at the moment and its relatively straightforward. This would take as input a polynomial start system and a list of solutions to the start system, and a target system. The algorithm would deform the start system and its solutions into the target system and its corresponding solutions. There is quite a bit of literature on how to do this, and if Jan helps me understand how Phcpack does this I think it won't be hard to get something running. Optimizing it will probably take longer but I know there are some Sage developers out there who might find it fun to help. After the parameter homotopy, we would need: 1) A way to compute mixed volumes and the cells of a mixed subdivision. Jan ported a C implementation in Ada to do this, so he thinks it might be fairly easy for him to do this. 2) Create ways to generate start systems and their solutions. The main way is to use the mixed subdivision from (1), but there are some alternatives. 3) Routines for "endgames" - issues that arise at the end of homotopies, where solutions might be degenerate in various senses. 4) Techniques for higher-dimensional solution components. I imagine that Jan and I and our students will do most of this, but we will need some help and I am soliciting it in advance. One thing I need is a deeper knowledge of Cython, which will be crucial in getting our implementation competitive with closed source alternatives. -Marshall Hampton --~--~-~--~~~---~--~~ 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: Clifford + Sage
On Sat, Jan 17, 2009 at 6:45 AM, luis wrote:
>
>
> Hello,
>
> I would like to make a relatively simple (but cumbersome)
> symbolic calculation in exterior algebra (more precisely in
> \Lambda^{k}(R^{n})).
> One possibility would be to use the Clifford algebra
> Cl(R^{n}, Q=0).
> Do you know if there is something in "Sage" appropriate to
> make this kind of calculation?
>
Clifford algebra is available in the fricas-1.0.3.p0 add-on to Sage. E.g.
sage: LambdaK=axiom('CliffordAlgebra(4,Fraction Polynomial
Integer,quadraticForm diagonalMatrix [0,0,0,0])')
sage: e1=axiom('x*e(1)$%s'%(LambdaK.name()))
sage: e2=axiom('x*e(2)$%s'%(LambdaK.name()))
sage: e3=axiom('x*e(3)$%s'%(LambdaK.name()))
sage: e4=axiom('x*e(4)$%s'%(LambdaK.name()))
sage: a=3*e2*e1 + 4*e1
sage: b=4*e2*e1 + 3*e2
sage: a*b
2
12x e e
1 2
Is that of any help?
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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] Proposal for inclusion of lrs as a standard package in Sage
I would like a vote on including the lrs optional package as a standard package in Sage. lrs stands for linear reverse search, an algorithm for computing convex hulls which is quite different from that of cddlib (which is already in Sage). You can read about the algorithm and initial implementation here: http://sage.math.washington.edu/home/mhampton/Avis_lrs_99.pdf One advantage of lrs is that the memory it uses is linear in the size of the problem (roughly speaking, see the reference for more precise statements). It can also be much faster than cddlib for certain families of polytopes. Because of this, polymake includes cddlib and lrs as well as its own third convex hull algorithm (beneath-and- beyond, which someone should implement in Sage one day). lrs can also compute triangulations and volumes of polytopes. We currently don't have anything else that can do those things, as far as I am aware. TOPCOM does all sorts of triangulations but it is a big, complicated program that would be much more difficult to include. Much as with polymake, it seems that the best way forward at the moment is to include the key smaller libraries and build our own functionality on them. lrs has been extended by David Avis since 1999. Because Komei Fukuda was a co-creator of it, its files are compatible with those of cddlib, which makes incorporating it into polytope code that uses cddlib very easy. It is a mature package that has had many rounds of bugfixes for its core functionality. lrs is pretty small - the optional spkg is 120 kB, which unpacks to less than 1 MB. The executable is only 92 kB on my machine. It buils qiuckly and I have seen no reports of build problems (although I don't know how many people have tried the optional package). I am cc'ing David Avis on this announcement in case he has any clarifications or comments. The license is GPL v2. Overall I think this is almost a model candidate for the sort of code that should be in Sage. Marshall Hampton --~--~-~--~~~---~--~~ 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: Proposal for inclusion of lrs as a standard package in Sage
On Jan 17, 6:17 am, mhampton wrote: Hi, > I would like a vote on including the lrs optional package as a > standard package in Sage. > > lrs stands for linear reverse search, an algorithm for computing > convex hulls which is quite different from that of cddlib (which is > already in Sage). You can read about the algorithm and initial > implementation here: > > http://sage.math.washington.edu/home/mhampton/Avis_lrs_99.pdf > > One advantage of lrs is that the memory it uses is linear in the size > of the problem (roughly speaking, see the reference for more precise > statements). It can also be much faster than cddlib for certain > families of polytopes. Because of this, polymake includes cddlib and > lrs as well as its own third convex hull algorithm (beneath-and- > beyond, which someone should implement in Sage one day). > > lrs can also compute triangulations and volumes of polytopes. We > currently don't have anything else that can do those things, as far as > I am aware. TOPCOM does all sorts of triangulations but it is a big, > complicated program that would be much more difficult to include. > Much as with polymake, it seems that the best way forward at the > moment is to include the key smaller libraries and build our own > functionality on them. > > lrs has been extended by David Avis since 1999. Because Komei Fukuda > was a co-creator of it, its files are compatible with those of cddlib, > which makes incorporating it into polytope code that uses cddlib very > easy. It is a mature package that has had many rounds of bugfixes for > its core functionality. Ok. I have certainly seen it as components of various other packages. It certainly seems to be mature. > lrs is pretty small - the optional spkg is 120 kB, which unpacks to > less than 1 MB. The executable is only 92 kB on my machine. It buils > qiuckly and I have seen no reports of build problems (although I don't > know how many people have tried the optional package). It seems only to be tested on Linux, OSF and Cygwin. Poking around through the code it seems that there is an optional signal handler component which can easily be ported to native Windows. Since the code itself seems to have zero dependencies this ought to be an easy port. But the code certainly needs prettying up, i.e. I couldn't find a test suite, the files were all dumped in the same directory and on and on. If upstream is interested I could certainly make some suggestions. Do you want to use the code also in "library mode"? This certainly seems to be the goal in the end. > I am cc'ing David Avis on this announcement in case he has any > clarifications or comments. > > The license is GPL v2. It is GPL V2+ which is pretty important. > Overall I think this is almost a model candidate for the sort of code > that should be in Sage. Yes, I would vote +1 assuming some cleanup happens and someone actually takes the code for a spin with MSVC. Until then I am a 0 on this :) > Marshall Hampton 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] FW: [Sage Bug Report] or not?
-- Forwarded message -- From: Yann Laigle-Chapuy Date: Sat, Jan 17, 2009 at 4:06 AM Subject: [Sage Bug Report] or not? To: Michael Abshoff < SNIP > Hi, is the following a feature or a bug? sage: 0*log(0) ... ValueError: self must be positive ok, but sage: f=x*log(x) sage: f(0) 0 --~--~-~--~~~---~--~~ 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: Clifford + Sage
Luis,
I get:
sage: ...
sage: a=3*e2*e1 + 4*e1
sage: a
2
4x e - 3x e e
1 1 2
---
I notice you are using sage-3.1.4. That should be fine. In the example
above I am using 3.1.3 but it includes the patches done by Mike Hansen
http://trac.sagemath.org/sage_trac/ticket/4036
that are not yet in the Sage distribution (review needed). See also
http://trac.sagemath.org/sage_trac/ticket/4633
The error message you show seems typical of the problems that these
patches solve.
Regards,
Bill Page.
On Sat, Jan 17, 2009 at 9:47 AM, luis wrote:
>
> Hi Bill,
>
> Thanks for your answer. Yes, it seems to be a good answer
> to my question.
> I have however a problem. The error message is included
> below. Do you have some idea?
>
> Regards,
>
> Luis
>
> --
>
> sage: e1=axiom('x*e(1)$%s'%(LambdaK.name()))
> sage: e2=axiom('x*e(2)$%s'%(LambdaK.name()))
> sage: e3=axiom('x*e(3)$%s'%(LambdaK.name()))
> sage: e4=axiom('x*e(4)$%s'%(LambdaK.name()))
> sage: a=3*e2*e1 + 4*e1
> ---
> TypeError Traceback (most recent call
> last)
>
> /home/luis/sage-3.1.4-debian32-IntelXeon-x86-i686-Linux/ console> in ()
>
> /home/luis/sage-3.1.4-debian32-IntelXeon-x86-i686-Linux/local/lib/
> python2.5/site -packages/sage/structure/element.so in
> sage.structure.element.RingElement.__mul_ _ (sage/structure/element.c:
> 8187)()
>
> /home/luis/sage-3.1.4-debian32-IntelXeon-x86-i686-Linux/local/lib/
> python2.5/site -packages/sage/structure/coerce.so in
> sage.structure.coerce.CoercionModel_cache_ maps.bin_op (sage/structure/
> coerce.c:5559)()
>
> TypeError: unsupported operand parent(s) for '*': 'Integer Ring' and
> 'Axiom'
>
--~--~-~--~~~---~--~~
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: Clifford + Sage
Luis,
Now that I have had some coffee, let me also give you a slightly
better example :-)
sage: LambdaK=axiom('CliffordAlgebra(4,Fraction Polynomial
Integer,quadraticForm diagonalMatrix [0,0,0,0])')
sage: e1=axiom('e(1)$%s'%(LambdaK.name()))
sage: e2=axiom('e(2)$%s'%(LambdaK.name()))
sage: e3=axiom('e(3)$%s'%(LambdaK.name()))
sage: e4=axiom('e(4)$%s'%(LambdaK.name()))
sage: var('x,y,z')
(x, y, z)
sage: a=x*e1*e2
sage: b=x*e1*e3
sage: c=y*e4*e3
sage: a*b
0
sage: a*c
- x y e e e e
1 2 3 4
sage:
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: Clifford + Sage
On Sat, Jan 17, 2009 at 10:30 AM, luis wrote:
> Bill,
>
> Thanks again. Yes, this is exactly the kind of thing I want to
> do.
>
> A couple of questions:
>
> - Can you give me a small example in using axiom directely?
> (I mean without passing through sage).
Sure, no problem. Try something like this:
wsp...@virtual-debian:~/sage-3.1.3$ vi LambdaK.input
--
)set message autoload off
LambdaK:=CliffordAlgebra(4,Fraction Polynomial Integer,quadraticForm
diagonalMatrix [0,0,0,0])
e1:=e(1)$LambdaK
e2:=e(2)$LambdaK
e3:=e(3)$LambdaK
e4:=e(4)$LambdaK
a:=x*e1*e2
b:=x*e1*e3
c:=y*e4*e3
a*b
a*c
--
If you have FriCAS (or another fork of Axiom) installed you can just
run the above script directly, or you can start the FriCAS installed
in Sage like this
$ sage -axiom
or from within Sage like this:
sage: axiom.console()
viewman not present, disabling graphics
Checking for foreign routines
AXIOM="/home/wspage/sage-3.1.3/local/lib/fricas/target/i686-pc-linux"
spad-lib="/home/wspage/sage-3.1.3/local/lib/fricas/target/i686-pc-linux/lib/libspad.so"
foreign routines found
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 1.0.3
Timestamp: Monday October 20, 2008 at 10:14:54
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-
(1) -> )read LambdaK.input
)set message autoload off
LambdaK:=CliffordAlgebra(4,Fraction Polynomial Integer,quadraticForm
diagonalMatrix [0,0,0,0])
(1) CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
Type: Domain
e1:=e(1)$LambdaK
(2) e
1
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
e2:=e(2)$LambdaK
(3) e
2
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
e3:=e(3)$LambdaK
(4) e
3
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
e4:=e(4)$LambdaK
(5) e
4
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
a:=x*e1*e2
(6) x e e
1 2
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
b:=x*e1*e3
(7) x e e
1 3
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
c:=y*e4*e3
(8) - y e e
3 4
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
a*b
(9) 0
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
a*c
(10) - x y e e e e
1 2 3 4
Type: CliffordAlgebra(4,Fraction Polynomial Integer,MATRIX)
(11) -> )quit
sage:
> - I can see the patches in "trac", but I don't know how to apply them
> (I am just starting with sage). Is there some tool to apply them?
>
This thread might help:
http://groups.google.com/group/fricas-devel/browse_thread/thread/ce55dbdfbb0e65ff/28a682142f569ccf
If you still have questions, please ask... And also try to encourage
the Sage/FriCAS developers to review this ticket so that we can
finally get it into Sage! :-)
Regards,
Bill Page.
>
> On Jan 17, 4:10 pm, Bill Page wrote:
>> Luis,
>>
>> Now that I have had some coffee, let me also give you a slightly
>> better example :-)
>>
>> sage: LambdaK=axiom('CliffordAlgebra(4,Fraction Polynomial
>> Integer,quadraticForm diagonalMatrix [0,0,0,0])')
>> sage: e1=axiom('e(1)$%s'%(LambdaK.name()))
>> sage: e2=axiom('e(2)$%s'%(LambdaK.name()))
>> sage: e3=axiom('e(3)$%s'%(LambdaK.name()))
>> sage: e4=axiom('e(4)$%s'%(LambdaK.name()))
>> sage: var('x,y,z')
>> (x, y, z)
>> sage: a=x*e1*e2
>> sage: b=x*e1*e3
>> sage: c=y*e4*e3
>> sage: a*b
>> 0
>> sage: a*c
>>
>> - x y e e e e
>> 1 2 3 4
>> sage:
>>
>> Regards,
>> Bill Page.
>
--~--~-~--~~~---~--~~
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: Clifford + Sage
On Jan 17, 8:56 am, Bill Page wrote: > On Sat, Jan 17, 2009 at 10:30 AM, luis wrote: Hi Bill, > If you still have questions, please ask... And also try to encourage > the Sage/FriCAS developers to review this ticket so that we can > finally get it into Sage! :-) I don't want to point out the obvious, but since you have been using those patches and are also familiar with Axiom why don't you review them? > Regards, > Bill Page. 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: Clifford + Sage
Michael, In an email list usually it doesn't hurt much to point out the obvious ... :-) But I don't understand. Haven't I reviewed them many times here already? Perhaps I just don't understand the process... Overall there does not seem to be very much interest in the fricas package for Sage, so I haven't had much incentive to try to do more. Specifically: what can I do to help get these patches into Sage? Regards, Bill Page. On Sat, Jan 17, 2009 at 12:15 PM, mabshoff wrote: > > > > On Jan 17, 8:56 am, Bill Page wrote: >> On Sat, Jan 17, 2009 at 10:30 AM, luis wrote: > > > > Hi Bill, > >> If you still have questions, please ask... And also try to encourage >> the Sage/FriCAS developers to review this ticket so that we can >> finally get it into Sage! :-) > > I don't want to point out the obvious, but since you have been using > those patches and are also familiar with Axiom why don't you review > them? > >> Regards, >> Bill Page. > > 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: Clifford + Sage
I think roughly speaking what Michael is referring to is to ask you to: (a) apply the patches at http://trac.sagemath.org/sage_trac/ticket/4036 to the latest version of Sage (b) see if it applies cleanly, see if the tests pass, see if you find problems in the code or docstrings. Assume for simplicity there are no problems (this may be incorrect!). (c) issue a new patch with your changes which replaces all the other patches. (d) change the subject line from "needs rebase" to "positive review". If there are any questions, just ask on the trac ticket or on sage-devel. On Sat, Jan 17, 2009 at 12:28 PM, Bill Page wrote: > > Michael, > > In an email list usually it doesn't hurt much to point out the obvious > ... :-) But I don't understand. Haven't I reviewed them many times > here already? Perhaps I just don't understand the process... Overall > there does not seem to be very much interest in the fricas package for > Sage, so I haven't had much incentive to try to do more. Specifically: > what can I do to help get these patches into Sage? > > Regards, > Bill Page. > > On Sat, Jan 17, 2009 at 12:15 PM, mabshoff wrote: >> >> >> >> On Jan 17, 8:56 am, Bill Page wrote: >>> On Sat, Jan 17, 2009 at 10:30 AM, luis wrote: >> >> >> >> Hi Bill, >> >>> If you still have questions, please ask... And also try to encourage >>> the Sage/FriCAS developers to review this ticket so that we can >>> finally get it into Sage! :-) >> >> I don't want to point out the obvious, but since you have been using >> those patches and are also familiar with Axiom why don't you review >> them? >> >>> Regards, >>> Bill Page. >> >> 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: Clifford + Sage
Dear Bill, On 17 Jan., 18:28, Bill Page wrote: ... > ... :-) But I don't understand. Haven't I reviewed them many times > here already? Ticket #4633 is, as much as I see, your code. Therefore, someone else must review it (obviously, in a peer review system one can not be referee for one's own contribution). And in ticket #4036, I see no review of you. You say "Haven't I reviewed them many times *here*" - does 'here' mean 'on this list'? I guess this would not suffice, it only counts as a review if it appears on the ticket. But perhaps you can make a review for #4036 without much additional effort by copy-and-paste your posts? Yours Simon --~--~-~--~~~---~--~~ 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: Clifford + Sage
David, http://trac.sagemath.org/sage_trac/ticket/4036 Does not apply cleanly to recent source versions of Sage. It says: [...,needs rebase] How do I do that? It is not hard to manually fix the mismatches in the old patches, but what does it mean to "re-base"? The existing tests pass, but I am aware of some other issues - some of which I have posted to the list, including patches. And I have some additional code that I have added to trac. By item c) below, do you mean that I should accumulate all of my local changes plus Mike Hansen's original stuff and post the result to 4036? I could certainly give that a positive review since I am currently using it, but then isn't a review by some else also required? Actually like most people I expect, I have to admit that with my limited available time the rate at which Sage source code changes makes it hard for me to keep up. Since I want to accomplish other things with Sage and Axiom besides development work and no one has expressed much interest in the interface, this issue has just been pushed to the bottom of the pile until someone posts something that seems directly related. Regards, Bill Page. On Sat, Jan 17, 2009 at 12:52 PM, David Joyner wrote: > > I think roughly speaking what Michael is referring to is to ask you to: > > (a) apply the patches at http://trac.sagemath.org/sage_trac/ticket/4036 > to the latest version of Sage > (b) see if it applies cleanly, see if the tests pass, see if you find > problems in the code or docstrings. Assume for simplicity there > are no problems (this may be incorrect!). > (c) issue a new patch with your changes which replaces all the other > patches. > (d) change the subject line from "needs rebase" to > "positive review". > > If there are any questions, just ask on the trac ticket or on > sage-devel. > > > On Sat, Jan 17, 2009 at 12:28 PM, Bill Page > wrote: >> >> Michael, >> >> In an email list usually it doesn't hurt much to point out the obvious >> ... :-) But I don't understand. Haven't I reviewed them many times >> here already? Perhaps I just don't understand the process... Overall >> there does not seem to be very much interest in the fricas package for >> Sage, so I haven't had much incentive to try to do more. Specifically: >> what can I do to help get these patches into Sage? >> >> Regards, >> Bill Page. >> >> On Sat, Jan 17, 2009 at 12:15 PM, mabshoff wrote: >>> >>> >>> >>> On Jan 17, 8:56 am, Bill Page wrote: On Sat, Jan 17, 2009 at 10:30 AM, luis wrote: >>> >>> >>> >>> Hi Bill, >>> If you still have questions, please ask... And also try to encourage the Sage/FriCAS developers to review this ticket so that we can finally get it into Sage! :-) >>> >>> I don't want to point out the obvious, but since you have been using >>> those patches and are also familiar with Axiom why don't you review >>> them? >>> Regards, Bill Page. >>> >>> 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: Clifford + Sage
Given your time constraints and the problems you mentioned, what I would do is the following (though possibly Michael might recommend something else): (a) apply to a clone of the most recent version of Sage the changes you want (including those of M Hansen) "manually", (b) create a new "big" patch and attach it to 4036. (this is the rebase). Test this on as many platforms as you can. (c) Mention as a trac comment what you just said (you give everything a positive review, but you added some material ...), then replace "needs rebase" by "positive review, needs further review". (I can't find the "legal" strings for trac tickets on http://wiki.sagemath.org/TracGuidelines, but it's something like this.) (d) Email someone to ask for an immediate quick review. I can try myself or maybe Martin Rubey or Simon King can? On Sat, Jan 17, 2009 at 1:15 PM, Bill Page wrote: > > David, > > http://trac.sagemath.org/sage_trac/ticket/4036 > > Does not apply cleanly to recent source versions of Sage. It says: > > [...,needs rebase] > > How do I do that? It is not hard to manually fix the mismatches in the > old patches, but what does it mean to "re-base"? > > The existing tests pass, but I am aware of some other issues - some of > which I have posted to the list, including patches. And I have some > additional code that I have added to trac. By item c) below, do you > mean that I should accumulate all of my local changes plus Mike > Hansen's original stuff and post the result to 4036? I could certainly > give that a positive review since I am currently using it, but then > isn't a review by some else also required? > > Actually like most people I expect, I have to admit that with my > limited available time the rate at which Sage source code changes > makes it hard for me to keep up. Since I want to accomplish other > things with Sage and Axiom besides development work and no one has > expressed much interest in the interface, this issue has just been > pushed to the bottom of the pile until someone posts something that > seems directly related. > > Regards, > Bill Page. > > On Sat, Jan 17, 2009 at 12:52 PM, David Joyner wrote: >> >> I think roughly speaking what Michael is referring to is to ask you to: >> >> (a) apply the patches at http://trac.sagemath.org/sage_trac/ticket/4036 >> to the latest version of Sage >> (b) see if it applies cleanly, see if the tests pass, see if you find >> problems in the code or docstrings. Assume for simplicity there >> are no problems (this may be incorrect!). >> (c) issue a new patch with your changes which replaces all the other >> patches. >> (d) change the subject line from "needs rebase" to >> "positive review". >> >> If there are any questions, just ask on the trac ticket or on >> sage-devel. >> >> >> On Sat, Jan 17, 2009 at 12:28 PM, Bill Page >> wrote: >>> >>> Michael, >>> >>> In an email list usually it doesn't hurt much to point out the obvious >>> ... :-) But I don't understand. Haven't I reviewed them many times >>> here already? Perhaps I just don't understand the process... Overall >>> there does not seem to be very much interest in the fricas package for >>> Sage, so I haven't had much incentive to try to do more. Specifically: >>> what can I do to help get these patches into Sage? >>> >>> Regards, >>> Bill Page. >>> >>> On Sat, Jan 17, 2009 at 12:15 PM, mabshoff wrote: On Jan 17, 8:56 am, Bill Page wrote: > On Sat, Jan 17, 2009 at 10:30 AM, luis wrote: Hi Bill, > If you still have questions, please ask... And also try to encourage > the Sage/FriCAS developers to review this ticket so that we can > finally get it into Sage! :-) I don't want to point out the obvious, but since you have been using those patches and are also familiar with Axiom why don't you review them? > Regards, > Bill Page. 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: Clifford + Sage
On Jan 17, 10:31 am, David Joyner wrote: > Given your time constraints and the problems you mentioned, > what I would do is the following (though possibly Michael might > recommend something else): > > (a) apply to a clone of the most recent version of Sage the > changes you want (including those of M Hansen) > "manually", hg provides merge tools for that, i.e. k3diff is some people's preferred tool to do that on Linux. > (b) create a new "big" patch and attach it to 4036. (this is > the rebase). Test this on as many platforms as you can. This might or might not be a good idea since that screws with the credit situation. Ideally you would use Queues to rebase the patch series and fold together patches. In this situation I would just complain long enough until Mike posts a rebased patch. > (c) Mention as a trac comment what you just said (you give > everything a positive review, but you added some material ...), then > replace "needs rebase" by "positive review, needs further review". > (I can't find the "legal" strings for trac tickets > onhttp://wiki.sagemath.org/TracGuidelines, > but it's something like this.) Don't do that, just change the status to "needs review" and then explain on the ticket which additional patches need review. If you rebase things be also very specific what patches to apply in which order. Long and somewhat ambiguous ticket descriptions make the ticket get picked up by the wrong report and I will then rename it. > (d) Email someone to ask for an immediate quick review. I can try > myself or maybe Martin Rubey or Simon King can? 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: Plan for shifting Pchpack functionality into Sage
On Jan 17, 2009, at 5:45 AM, mhampton wrote: > Currently Phcpack is an optional package for sage. Its main purpose > is to numerically compute isolated solutions of polynomial systems, > although it has some other functionality as well (e.g. computing mixed > volumes, witness sets for higher-dimensional solution components). > > I have wanted Phcpack to be standard in Sage for a while, but have > been blocked by concerns about portability. Phcpack is written in > Ada. Recently Jan Verschelde (the author of Phcpack) and his students > have added some C and Python interfaces, which help integration > efforts but don't solve the portability issue. > > I discussed this situation recently with Jan (who I am cc'ing on this > email in case he has clarifications or corrections) and he seems > willing to work with me on porting Phcpack into Sage as a native > program. Although Phcpack is pretty fast, there are closed source > programs that seem quite a bit faster at the moment (although its not > a simple comparison, they different strengths and weaknesses). A Sage > implementation could be quite a bit faster by taking advantage of > Sage's linear algebra and other components. > > My plan for doing this is to move in the functionality piece by piece > starting in late Febuary (earlier if I can magically find extra > time). The first piece will be a parameter-homotopy path tracker, > since I understand that part the best at the moment and its relatively > straightforward. This would take as input a polynomial start system > and a list of solutions to the start system, and a target system. The > algorithm would deform the start system and its solutions into the > target system and its corresponding solutions. There is quite a bit > of literature on how to do this, and if Jan helps me understand how > Phcpack does this I think it won't be hard to get something running. > Optimizing it will probably take longer but I know there are some Sage > developers out there who might find it fun to help. > > After the parameter homotopy, we would need: > > 1) A way to compute mixed volumes and the cells of a mixed > subdivision. Jan ported a C implementation in Ada to do this, so he > thinks it might be fairly easy for him to do this. > > 2) Create ways to generate start systems and their solutions. The > main way is to use the mixed subdivision from (1), but there are some > alternatives. > > 3) Routines for "endgames" - issues that arise at the end of > homotopies, where solutions might be degenerate in various senses. > > 4) Techniques for higher-dimensional solution components. > > I imagine that Jan and I and our students will do most of this, but we > will need some help and I am soliciting it in advance. One thing I > need is a deeper knowledge of Cython, which will be crucial in getting > our implementation competitive with closed source alternatives. This sounds great. The math is (as far as I know) outside my field of expertise, but I'm always up for learning something new (subject to time constraints) and I do know quite a bit about Cython. At some point, this sounds like it would make a good coding sprint project at a Sage Days too. The site http://wiki.sagemath.org/SageDays has a listing but seems out of date. - 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: FW: [Sage Bug Report] or not?
On Jan 17, 2009, at 6:54 AM, mabshoff wrote: > -- Forwarded message -- > From: Yann Laigle-Chapuy > Date: Sat, Jan 17, 2009 at 4:06 AM > Subject: [Sage Bug Report] or not? > To: Michael Abshoff < SNIP > > > > Hi, > is the following a feature or a bug? > > sage: 0*log(0) > ... > ValueError: self must be positive > > ok, but > > sage: f=x*log(x) > sage: f(0) > 0 I would say that's a bug. Probably an overly-naive simplification. Also, note sage: f = x*log(x) sage: f(0) 0 sage: f.subs(x=0) Traceback (most recent call last): File "", line 1, in File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 3811, in subs return self.substitute(*args, **kwds) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 3808, in substitute return X._recursive_sub(kwds) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 4857, in _recursive_sub new_ops = [SR(op._recursive_sub(kwds)) for op in ops] File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 6275, in _recursive_sub return ops[0](ops[1]._recursive_sub(kwds)) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 6600, in __call__ return getattr(x, self._repr_())(*args) File "integer.pyx", line 1560, in sage.rings.integer.Integer.log (sage/rings/integer.c:11178) ValueError: self must be positive sage: f(x) = x*log(x) sage: f(0) Traceback (most recent call last): File "", line 1, in File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 5922, in __call__ return self._expr.substitute(dct) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 3808, in substitute return X._recursive_sub(kwds) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 4857, in _recursive_sub new_ops = [SR(op._recursive_sub(kwds)) for op in ops] File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 6275, in _recursive_sub return ops[0](ops[1]._recursive_sub(kwds)) File "/Users/robert/sage/current/local/lib/python2.5/site-packages/ sage/calculus/calculus.py", line 6600, in __call__ return getattr(x, self._repr_())(*args) File "integer.pyx", line 1560, in sage.rings.integer.Integer.log (sage/rings/integer.c:11178) ValueError: self must be positive --~--~-~--~~~---~--~~ 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] compilation
Hi, In compiling sage on a linux debian (stable) I have a problem with "flint-1.0.13.p0". Some lines of the install.log file are included hereafter. Thanks, Luis make[1]: Entering directory `/home/luis/Desktop/sage-3.2.1/spkg' sage-spkg flint-1.0.13.p0 2>&1 You must set the SAGE_ROOT environment variable or run this script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory. flint-1.0.13.p0 Machine: Linux urubamba 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux Deleting directories from past builds of previous/current versions of flint-1.0.13.p0 Extracting package /home/luis/Desktop/sage-3.2.1/spkg/standard/ flint-1.0.13.p0.spkg ... -rw-r--r-- 1 luis luis 496581 2008-11-27 07:28 /home/luis/Desktop/ sage-3.2.1/spkg/standard/flint-1.0.13.p0.spkg flint-1.0.13.p0/ flint-1.0.13.p0/.hg/ flint-1.0.13.p0/.hg/00changelog.i flint-1.0.13.p0/.hg/branch.cache flint-1.0.13.p0/.hg/dirstate flint-1.0.13.p0/.hg/requires ... ... OK ... flint-1.0.13.p0/src/ZmodF_poly-profile.c flint-1.0.13.p0/src/ZmodF_poly-test.c flint-1.0.13.p0/src/ZmodF_poly.c flint-1.0.13.p0/src/ZmodF_poly.h flint-1.0.13.p0/test_gcc_version.pl Finished extraction Host system uname -a: Linux urubamba 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux GCC Version gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/usr/local --enable-languages=c,c ++ --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.3.2 (GCC) Found gcc 4 or later Deleting old FLINT make[2]: Entering directory `/home/luis/Desktop/sage-3.2.1/spkg/build/ flint-1.0.13.p0/src' gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c mpn_extras.c -o mpn_extras.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c mpz_extras.c -o mpz_extras.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c memory-manager.c -o memory-manager.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c ZmodF.c -o ZmodF.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c ZmodF_mul.c -o ZmodF_mul.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c ZmodF_mul-tuning.c -o ZmodF_mul-tuning.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c fmpz.c -o fmpz.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c fmpz_poly.c -o fmpz_poly.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c mpz_poly-tuning.c -o mpz_poly-tuning.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c mpz_poly.c -o mpz_poly.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c ZmodF_poly.c -o ZmodF_poly.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c long_extras.c -o long_extras.o gcc -std=c99 -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/ luis/Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c zmod_poly.c -o zmod_poly.o g++ -I/home/luis/Desktop/sage-3.2.1/local/include/ -I/home/luis/ Desktop/sage-3.2.1/local/include -fPIC -funroll-loops -O3 -c NTL- interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.so mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o zmod_poly.o NTL-interface.o -L/ home/luis/Desktop/sage-3.2.1/local/lib/ -L/home/luis/Desktop/ sage-3.2.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ mpz_extras.o: In function `__strcspn_c1': mpz_extras.c:(.text+0x0): multiple definition of `__strcspn_c1' mpn_extras.o:mpn_extras.c:(.text+0x0): first defined here mpz_extras.o: In function `__strcspn_c2': mpz_extras.c:(.text+0x40): multiple definition of `__strcspn_c2' mpn_extras.o:mpn_extras.c:(.text+0x40): first defined here mpz_extras.o: In function `__strcspn_c3': ... ... ... memory-manager.c:(.text+0xec0): multiple definition
[sage-devel] Re: compilation
On Jan 17, 11:34 am, luis wrote: > Hi, > > In compiling sage on a linux debian (stable) I have a problem > with "flint-1.0.13.p0". > > Some lines of the install.log file are included hereafter. > > Thanks, > > Luis > Finished extraction > > Host system > uname -a: > Linux urubamba 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 > GNU/Linux > > > GCC Version > gcc -v > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ./configure --prefix=/usr/local --enable-languages=c,c > ++ --with-gmp=/usr/local --with-mpfr=/usr/local > Thread model: posix > gcc version 4.3.2 (GCC) > I doubt this gcc is the one shipped with the distribution. What is your env looking like? Setting CC, CXX, CFLAGS and so on does have side effects in Sage and there are plans to fix all those issues. What about $PATH and $LD_LIBRARY_PATH? 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: Clifford + Sage
David Joyner writes: > (d) Email someone to ask for an immediate quick review. I can try > myself or maybe Martin Rubey or Simon King can? I won't be able to do that, because I cannot build sage anymore. My computer has become too old for sage, sorry. Martin --~--~-~--~~~---~--~~ 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: compilation
On Sat, Jan 17, 2009 at 11:42 AM, mabshoff wrote: > > > > On Jan 17, 11:34 am, luis wrote: >> Hi, >> >> In compiling sage on a linux debian (stable) I have a problem >> with "flint-1.0.13.p0". >> >> Some lines of the install.log file are included hereafter. >> >> Thanks, >> >> Luis > > > >> Finished extraction >> >> Host system >> uname -a: >> Linux urubamba 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 >> GNU/Linux >> >> >> GCC Version >> gcc -v >> Using built-in specs. >> Target: i686-pc-linux-gnu >> Configured with: ./configure --prefix=/usr/local --enable-languages=c,c >> ++ --with-gmp=/usr/local --with-mpfr=/usr/local >> Thread model: posix >> gcc version 4.3.2 (GCC) >> > > I doubt this gcc is the one shipped with the distribution. I agree, especially given the /usr/local's above. Also, I just installed Debian stable a month ago and it ships the following: --- wst...@debian32:~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) --- The user may want to build sage using the gcc that comes with Debian. William --~--~-~--~~~---~--~~ 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: compilation
Mabshoff, William, Yes, enforcing the use of the original compiler (/usr/bin/gcc) the "flint" compilation problem disappears. Thanks, Luis On Jan 17, 9:41 pm, William Stein wrote: > On Sat, Jan 17, 2009 at 11:42 AM, mabshoff wrote: > > > On Jan 17, 11:34 am, luis wrote: > >> Hi, > > >> In compiling sage on a linux debian (stable) I have a problem > >> with "flint-1.0.13.p0". > > >> Some lines of the install.log file are included hereafter. > > >> Thanks, > > >> Luis > > > > > >> Finished extraction > >> > >> Host system > >> uname -a: > >> Linux urubamba 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 > >> GNU/Linux > >> > >> > >> GCC Version > >> gcc -v > >> Using built-in specs. > >> Target: i686-pc-linux-gnu > >> Configured with: ./configure --prefix=/usr/local --enable-languages=c,c > >> ++ --with-gmp=/usr/local --with-mpfr=/usr/local > >> Thread model: posix > >> gcc version 4.3.2 (GCC) > >> > > > I doubt this gcc is the one shipped with the distribution. > > I agree, especially given the /usr/local's above. Also, I just > installed Debian stable a month ago and it ships the following: > > --- > wst...@debian32:~$ gcc -v > Using built-in specs. > Target: i486-linux-gnu > Configured with: ../src/configure -v > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 > --enable-checking=release i486-linux-gnu > Thread model: posix > gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > --- > > The user may want to build sage using the gcc that comes with Debian. > > William --~--~-~--~~~---~--~~ 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: FW: [Sage Bug Report] or not?
On Sat, Jan 17, 2009 at 11:31 AM, Robert Bradshaw
wrote:
>
> On Jan 17, 2009, at 6:54 AM, mabshoff wrote:
>
>> -- Forwarded message --
>> From: Yann Laigle-Chapuy
>> Date: Sat, Jan 17, 2009 at 4:06 AM
>> Subject: [Sage Bug Report] or not?
>> To: Michael Abshoff < SNIP >
>>
>>
>> Hi,
>> is the following a feature or a bug?
>>
>> sage: 0*log(0)
>> ...
>> ValueError: self must be positive
>>
>> ok, but
>>
>> sage: f=x*log(x)
>> sage: f(0)
>> 0
>
> I would say that's a bug. Probably an overly-naive simplification.
> Also, note
It's a bug, but I think there is not much of a point in even reporting
it to trac, since it is already fixed in the new symbolics which
Burcin and I wrote 5 *months* ago, and which still aren't the default
in Sage.
sage: var('x',ns=1)
x
sage: f(x) = x*log(x)
sage: f(0)
...
ValueError: self must be positive
-- William
>
> sage: f = x*log(x)
> sage: f(0)
> 0
> sage: f.subs(x=0)
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 3811, in subs
> return self.substitute(*args, **kwds)
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 3808, in substitute
> return X._recursive_sub(kwds)
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 4857, in _recursive_sub
> new_ops = [SR(op._recursive_sub(kwds)) for op in ops]
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 6275, in _recursive_sub
> return ops[0](ops[1]._recursive_sub(kwds))
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 6600, in __call__
> return getattr(x, self._repr_())(*args)
> File "integer.pyx", line 1560, in sage.rings.integer.Integer.log
> (sage/rings/integer.c:11178)
> ValueError: self must be positive
>
> sage: f(x) = x*log(x)
> sage: f(0)
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 5922, in __call__
> return self._expr.substitute(dct)
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 3808, in substitute
> return X._recursive_sub(kwds)
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 4857, in _recursive_sub
> new_ops = [SR(op._recursive_sub(kwds)) for op in ops]
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 6275, in _recursive_sub
> return ops[0](ops[1]._recursive_sub(kwds))
> File "/Users/robert/sage/current/local/lib/python2.5/site-packages/
> sage/calculus/calculus.py", line 6600, in __call__
> return getattr(x, self._repr_())(*args)
> File "integer.pyx", line 1560, in sage.rings.integer.Integer.log
> (sage/rings/integer.c:11178)
> ValueError: self must be positive
>
>
> >
>
--
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: Proposal for inclusion of lrs as a standard package in Sage
On Jan 17, 8:36 am, mabshoff wrote: > But the code certainly needs prettying up, i.e. I couldn't find a test > suite, the files were all dumped in the same directory and on and on. > If upstream is interested I could certainly make some suggestions. I don't think for such a small program that the directory structure is terribly important; I tend to like a flat file structure. There are already some tests for it in the optional code in polyhedra.py, and I would be happy to add more. Then we would be testing it through sage. That seems like the easiest way to add tests, unless David Avis is interested in adding it upstream. -Marshall --~--~-~--~~~---~--~~ 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: FW: [Sage Bug Report] or not?
William Stein wrote: > On Sat, Jan 17, 2009 at 11:31 AM, Robert Bradshaw > wrote: >> On Jan 17, 2009, at 6:54 AM, mabshoff wrote: >> >>> -- Forwarded message -- >>> From: Yann Laigle-Chapuy >>> Date: Sat, Jan 17, 2009 at 4:06 AM >>> Subject: [Sage Bug Report] or not? >>> To: Michael Abshoff < SNIP > >>> >>> >>> Hi, >>> is the following a feature or a bug? >>> >>> sage: 0*log(0) >>> ... >>> ValueError: self must be positive >>> >>> ok, but >>> >>> sage: f=x*log(x) >>> sage: f(0) >>> 0 >> I would say that's a bug. Probably an overly-naive simplification. >> Also, note > > It's a bug, but I think there is not much of a point in even reporting > it to trac, since it is already fixed in the new symbolics which > Burcin and I wrote 5 *months* ago, and which still aren't the default > in Sage. > Well, depending on how long before the new symbolics is the default, I'd say it's worth reporting and fixing, especially if it's easy. Jason --~--~-~--~~~---~--~~ 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: Proposal for inclusion of lrs as a standard package in Sage
I would be glad to have standard functions for triangulations! Andrey --~--~-~--~~~---~--~~ 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: compilation
On Jan 17, 12:48 pm, luis wrote: > Mabshoff, William, Hi, > Yes, enforcing the use of the original compiler (/usr/bin/gcc) > the "flint" compilation problem disappears. Ok, but I am still curious why this fails for you with the other compiler. Having compiled Sage with self compiled gcc 4.3.2 on numerous platforms and never seen that bug I would guess your environment is somehow mixing up those two compilers, but I have no prove for this. Also please do not send off list replies to me unless I explicitly ask for them. My mailbox is stuffed to the top already and things Sage related not on [sage-devel] get easily lost. > Thanks, > > Luis 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: Proposal for inclusion of lrs as a standard package in Sage
On Jan 17, 12:56 pm, mhampton wrote: > On Jan 17, 8:36 am, mabshoff wrote: Hi, > > But the code certainly needs prettying up, i.e. I couldn't find a test > > suite, the files were all dumped in the same directory and on and on. > > If upstream is interested I could certainly make some suggestions. > > I don't think for such a small program that the directory structure is > terribly important; I tend to like a flat file structure. I disagree. Having src, include, test, doc, example make it instantly understandable what is what. > There are already some tests for it in the optional code in > polyhedra.py, and I would be happy to add more. Then we would be > testing it through sage. No, this is wrong. Stein's Axiom I: Everything not tested is broken. I want to be able to run "make check" on the code and not depend on anything else to verify that the code works. *Every* time we merge code this way and just assume that Sage's test suite will pick up all the issues I am the one who is getting screwed with the prime examples being Symmetrica and SYMPOW debugging on more exotic platforms. Writing tests for this code should be easy since you already have a command line mode. And since you can use it from Sage via pexpect it should be trivial to add a bunch of tests by logging the traffic. If you look at the Makefile of this code you should clearly see that it needs cleaning up and rewriting it from scratch in this case might be easier since only a couple files are involved. On problem right off the bat is that compiler as well as build flags are hard coded for each file. So if you do something about that and add tests someone might as well as put files into proper directories, etc. And lrs can be build as a library and probably will so be integrated in Sage in the future. Since there are issues with LLP64 this is not a fun thing to debug, i.e. anything that can go wrong will lead to a segfault which isn't fun to debug because it happens *in* Python or the Sage library, and I wouldn't want to do it via Sage. How things like this can get screwed up badly (and this is not even a LLP64 issue) is Symmetrica where we see segfaults on Solaris in 32 bit mode when running some examples. There is a test suite of about 400 examples (at least according to the documentation) and after numerous attempts to contact the author we still don't have the files. The author does not reply to emails or bug reports and because of that as well as the truly horribly nature of the code (worst abuse of the preprocessor I have *ever* seen) I have lobbied to get the code thrown it. Without the test suite it is unclear if Symmetrica even works reliably on all the platforms I am building Sage on. The same case about upstream who cannot be bothered to even reply to emails from a variety of Sage devs is the cddlib upstream. We have send a couple build system improvements to upstream and six months later we haven't even gotten an acknowledgment. I have gotten code put on the removal list, i.e. quaddouble, because it did not work cross platform. And I will make damn sure no other project like that where I have doubts about quality will get into Sage. lrs also has LLP64 issues which will become relevant if it is used as a library from Sage as mentioned above and that is a killer knock out punch for me right there. All of the above leads me to the following conclusion: If upstream is not willing to help out with doing fresh releases or making improvements we ask for the code in question is not meant to be in Sage. The maintenance in this situation often enough ends up in my lap and I am sick and tired of it. I am not saying that this is the case here, but if you want to see how communication about issues in code should look like I would recommend you look at recent conversations on the flint-devel mailing list I had with Bill Hart. The fact that lrs does not have a mailing list, did not have a release since 2006 and so on does not make me bullish. Having all said the above I am more than happy to help out fixing those issues in lrs, but my approval will only happen when I see that upstream is willing to pitch in. Obviously you might "win" this vote, but even then I will appeal to the JSage board and argue that the code quality of lrs is not up to the standard we want. And I am pretty sure the board members will listen to my arguments. > That seems like the easiest way to add > tests, unless David Avis is interested in adding it upstream. > > -Marshall 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: Proposal for inclusion of lrs as a standard package in Sage
On Sat, Jan 17, 2009 at 6:44 PM, mabshoff wrote: > > > > On Jan 17, 12:56 pm, mhampton wrote: >> On Jan 17, 8:36 am, mabshoff wrote: > > Hi, > >> > But the code certainly needs prettying up, i.e. I couldn't find a test >> > suite, the files were all dumped in the same directory and on and on. >> > If upstream is interested I could certainly make some suggestions. >> >> I don't think for such a small program that the directory structure is >> terribly important; I tend to like a flat file structure. > > I disagree. Having src, include, test, doc, example make it instantly > understandable what is what. This is a good measure of code quality, and certainly a good minimum thing to strive for in software engineering. > >> There are already some tests for it in the optional code in >> polyhedra.py, and I would be happy to add more. Then we would be >> testing it through sage. > > No, this is wrong. Stein's Axiom I: Everything not tested is broken. > > I want to be able to run "make check" on the code and not depend on > anything else to verify that the code works. *Every* time we merge > code this way and just assume that Sage's test suite will pick up all > the issues I am the one who is getting screwed with the prime examples > being Symmetrica and SYMPOW debugging on more exotic platforms. > Writing tests for this code should be easy since you already have a > command line mode. And since you can use it from Sage via pexpect it > should be trivial to add a bunch of tests by logging the traffic. +1 I strongly agree with the above comment. If one is porting Sage to system X, then the more one can break down the testing issues the better, for numerous reasons. It's bad if in order to test and debug a little 200K program, it is important that all of the rest of Sage has been built and is working. > If you look at the Makefile of this code you should clearly see that > it needs cleaning up and rewriting it from scratch in this case might > be easier since only a couple files are involved. On problem right off > the bat is that compiler as well as build flags are hard coded for > each file. So if you do something about that and add tests someone > might as well as put files into proper directories, etc. > > And lrs can be build as a library and probably will so be integrated > in Sage in the future. Since there are issues with LLP64 this is not a > fun thing to debug, i.e. anything that can go wrong will lead to a > segfault which isn't fun to debug because it happens *in* Python or > the Sage library, and I wouldn't want to do it via Sage. How things > like this can get screwed up badly (and this is not even a LLP64 > issue) is Symmetrica where we see segfaults on Solaris in 32 bit mode > when running some examples. There is a test suite of about 400 > examples (at least according to the documentation) and after numerous > attempts to contact the author we still don't have the files. The > author does not reply to emails or bug reports and because of that as > well as the truly horribly nature of the code (worst abuse of the > preprocessor I have *ever* seen) I have lobbied to get the code thrown > it. I think you mean "thrown out". I am sympathetic. > Without the test suite it is unclear if Symmetrica even works > reliably on all the platforms I am building Sage on. The same case > about upstream who cannot be bothered to even reply to emails from a > variety of Sage devs is the cddlib upstream. We have send a couple > build system improvements to upstream and six months later we haven't > even gotten an acknowledgment. I have gotten code put on the removal > list, i.e. quaddouble, because it did not work cross platform. And I > will make damn sure no other project like that where I have doubts > about quality will get into Sage. lrs also has LLP64 issues which > will become relevant if it is used as a library from Sage as mentioned > above and that is a killer knock out punch for me right there. > > All of the above leads me to the following conclusion: If upstream is > not willing to help out with doing fresh releases or making > improvements we ask for the code in question is not meant to be in > Sage. The maintenance in this situation often enough ends up in my lap > and I am sick and tired of it. I am not saying that this is the case > here, but if you want to see how communication about issues in code > should look like I would recommend you look at recent conversations on > the flint-devel mailing list I had with Bill Hart. The fact that lrs > does not have a mailing list, did not have a release since 2006 and so > on does not make me bullish. > > Having all said the above I am more than happy to help out fixing > those issues in lrs, but my approval will only happen when I see that > upstream is willing to pitch in. Obviously you might "win" this vote, > but even then I will appeal to the JSage board and argue that the code > quality of lrs is not up to the standard we want. And I am pre
[sage-devel] Re: Proposal for inclusion of lrs as a standard package in Sage
On Jan 17, 6:57 pm, William Stein wrote: > > And lrs can be build as a library and probably will so be integrated > > in Sage in the future. Since there are issues with LLP64 this is not a > > fun thing to debug, i.e. anything that can go wrong will lead to a > > segfault which isn't fun to debug because it happens *in* Python or > > the Sage library, and I wouldn't want to do it via Sage. How things > > like this can get screwed up badly (and this is not even a LLP64 > > issue) is Symmetrica where we see segfaults on Solaris in 32 bit mode > > when running some examples. There is a test suite of about 400 > > examples (at least according to the documentation) and after numerous > > attempts to contact the author we still don't have the files. The > > author does not reply to emails or bug reports and because of that as > > well as the truly horribly nature of the code (worst abuse of the > > preprocessor I have *ever* seen) I have lobbied to get the code thrown > > it. > > I think you mean "thrown out". I am sympathetic. Yep, I have complained about this off list for over one year and on list for more than six months. Note that there has been a trac ticket about this issue for quite a while. > > Having all said the above I am more than happy to help out fixing > > those issues in lrs, but my approval will only happen when I see that > > upstream is willing to pitch in. Obviously you might "win" this vote, > > but even then I will appeal to the JSage board and argue that the code > > quality of lrs is not up to the standard we want. And I am pretty sure > > the board members will listen to my arguments. > > I don't think there should even be a vote until you sign off on the > platform support. Getting new packages into sage involves two > things: (1) a list of minimum requirements about code quality and > portability, and (2) sufficient interest and support by the community. > > IMHO, lrs is in stage (1) right now. Voting should be mainly for stage (2). Thanks and good that you agree. Having said all of the above let me stress again that I highly value how Marshall has been contributing to Sage, i.e. all the future work on porting/reimplementing ideas and code from phcpack will hopefully rock, but I would really like to see a sign of upstream in form of an email before I spend more than an hour or two on the code and start fixing issues like the build system. I have 150+ open tickets against me in trac and I am not going to "waste" my time on this unless there is a chance this will work. And given the number of computer geeks hanging around a math department I am somewhat surprised that code like lrs isn't much cleaner from the get go, especially given the rather central nature of it in its field one would assume that sooner or later someone with build system and portability experience would have fixed the code. This obviously leads to the joke about the professor being asked what his favorite programming language is and the answer being "PhD" :) > William 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 -~--~~~~--~~--~--~---
