[sage-devel] Re: Building sage-3.2.2 fails
On Feb 3, 2:13 am, mabshoff wrote: > On Feb 2, 2:43 pm, dannychrastina wrote: > > > On Jan 14, 4:04 pm, mabshoff wrote: > > > > On Jan 13, 10:13 pm, DavidS wrote: > > > > But further along the compilation, I got stuck here: > > > > ld -opolybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,- > > > > soname,libpolybori-0.5.0.so.0 Cudd/obj/cuddObj.os Cudd/util/ > > > > state.os .. > > > > ld: unrecognized option '-Wl,-soname,libpolybori-0.5.0.so.0' > > > > ld: use the --help option for usage information > > > > scons: *** [polybori/libpolybori-0.5.0.so.0.0.0] Error 1 > > > > scons: building terminated because of errors. > > > > Error buildingPolyBoRi. > > Hi, > > > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in > > which options are given to the compiler in order to pass to the > > linker, but since this is running the linker directly it should just > > be -soname libpolybori-0.5.0.so.0. I grep out the line in the install > > log and change that part it seems to build the .so. I just don't know > > where to change "sonameprefix" such that it doesn't get changed back > > as soon as I run make. What constructs the SConstruct? > > It is in the polybori-0.5rc.p6 .spkg in polybori-0.5rc.p6/patches/ > SConstruct > > The command execute that leads to the problem is > > g++ -o polybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,- > soname,libpolybori-0.5.0.so.0 > > so this is supposed to work since g++ just passes the options to the > linker. For some reasons the binutils you use get their panties in a > twist and things blow up. So: > > * What binutils release are you running (i.e. ld --version) GNU ld (GNU Binutils) 2.18. I notice David (above) had the same problem using 2.19. Also, just for completeness, $ g++ --version g++ (GCC) 4.1.2 (Gentoo 4.1.2 p1.3) > For the ultimate ironic POV: we don't even use the dynamic PolyBoRi > libs and link statically to work around a bug in PolyBoRi. > > I think we can fix by using > > g++ -o polybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,-soname - > Wl,libpolybori-0.5.0.so.0 > > but I would need to do that via a real build. Either way, the issue > with binutils version and suggested solution should be reported > upstream to the PolyBoRi people which I have CCed in case they don't > read *every* email to sage-devel [Tsk, tsk :p]. Thanks for the quick response. --~--~-~--~~~---~--~~ 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: Building sage-3.2.2 fails
Hi, > > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in > > which options are given to the compiler in order to pass to the > > linker, but since this is running the linker directly it should just > > be -soname libpolybori-0.5.0.so.0. I grep out the line in the install > > log and change that part it seems to build the .so. I just don't know > > where to change "sonameprefix" such that it doesn't get changed back > > as soon as I run make. What constructs the SConstruct? one could set a custom SONAMEPREFIX in custom.py, which is at the very same position as: > It is in the polybori-0.5rc.p6 .spkg in polybori-0.5rc.p6/patches/ > SConstruct But, indeed we need a better default setting for the sonameprefix, so I prepare an according patch for the SConstruct file. See: http://polybori.cvs.sourceforge.net/viewvc/polybori/PolyBoRi/SConstruct?view=log > but I would need to do that via a real build. Either way, the issue > with binutils version and suggested solution should be reported > upstream to the PolyBoRi people which I have CCed in case they don't > read *every* email to sage-devel [Tsk, tsk :p]. Thanks, this makes it easier for use to react quickly. Best regards, Alexander --~--~-~--~~~---~--~~ 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: Building sage-3.2.2 fails
On Feb 3, 12:34 am, dannychrastina wrote: > On Feb 3, 2:13 am, mabshoff wrote: > > * What binutils release are you running (i.e. ld --version) > > GNU ld (GNU Binutils) 2.18. > > I notice David (above) had the same problem using 2.19. Also, just for > completeness, I *very* much doubt that Gentoo ships a vanilla binutils and I have not seen this problem with binutils 2.18 or 2.19 compiled from sources. Anyway, this won't and shouldn't prevent us from fixing the bug or at least work properly around it :) > $ g++ --version > g++ (GCC) 4.1.2 (Gentoo 4.1.2 p1.3) > > > For the ultimate ironic POV: we don't even use the dynamic PolyBoRi > > libs and link statically to work around a bug in PolyBoRi. > > > I think we can fix by using > > > g++ -o polybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,-soname - > > Wl,libpolybori-0.5.0.so.0 > > > but I would need to do that via a real build. Either way, the issue > > with binutils version and suggested solution should be reported > > upstream to the PolyBoRi people which I have CCed in case they don't > > read *every* email to sage-devel [Tsk, tsk :p]. > > Thanks for the quick response. I doubt it will happen in the next day or two, but the changes to SConstruct are pretty minimal to change the link directive. So hopefully I will find time to post some spkg to give it a try. Alexander also commented and we might want to check out that solution, too. For Sage itself setting the soname is utterly pointless IMHO anyway, so we might as well get rid of it and let distribution packagers deal with the problem. Either way we should update the PolyBoRi.spkg to the official 0.5 release at some point anyway. 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: Building sage-3.2.2 fails
On Feb 3, 12:36 am, Alexander Dreyer wrote: Hi Alexander, > Hi,> > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems > > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in > > > which options are given to the compiler in order to pass to the > > > linker, but since this is running the linker directly it should just > > > be -soname libpolybori-0.5.0.so.0. I grep out the line in the install > > > log and change that part it seems to build the .so. I just don't know > > > where to change "sonameprefix" such that it doesn't get changed back > > > as soon as I run make. What constructs the SConstruct? > > one could set a custom SONAMEPREFIX in custom.py, which is at the very > same position as: Ok, I checked out your proposed fix and it is the same as I suggested, so I am pleased. Note that this fix in general depends on a GNU ld and it will utterly break with a BSDis or Solaris ld. Not that this matters for Sage at the moment since for Solaris as well as FreeBSD I am using GNU binutils, but it will become an issue in the long term. > > It is in the polybori-0.5rc.p6 .spkg in polybori-0.5rc.p6/patches/ > > SConstruct > > But, indeed we need a better default setting for the sonameprefix, so > I prepare an according patch for the SConstruct file. > See:http://polybori.cvs.sourceforge.net/viewvc/polybori/PolyBoRi/SConstru... > > > but I would need to do that via a real build. Either way, the issue > > with binutils version and suggested solution should be reported > > upstream to the PolyBoRi people which I have CCed in case they don't > > read *every* email to sage-devel [Tsk, tsk :p]. > > Thanks, this makes it easier for use to react quickly. Well, thanks for the quick fix, too :) > Best regards, > Alexander 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: 3.3.alpha4 fails build PPC X.4
> Ok, that is a side effect of not setting -fno-common. I am curious > which gcc release this is. powerpc-apple-darwin8-gcc-4.0.1 > >export SHAREDFLAGS="-fno-common" > > and restart the build. Okay, I will try that. Apparently it is picking up where it left off and separately doing each of that long list of .o files with -fno- common, and is now running the various tests for NTL. Let's hope it doesn't stop again! Thanks, - kcrisman --~--~-~--~~~---~--~~ 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: Integration syntax
I agree, some consistent syntax for multiple integrals is needed.
For example, to me this seems strange:
sage: x,y = var("x,y")
sage: f = y*sin(x*y)
sage: bool(diff(f,x,y) == diff(diff(f,x),y))
True
sage: bool(integral(f,x,y) == integral(integral(f,x),y))
False
At least, it is a possible source of confusion for students.
Years ago, one of my collegues (now retired) argued that because
the Maple syntax for plot3d and the Maple syntax for double integrals
was the same, this helped the students understand limits in
calc3 better. For definite integrals, I wonder if we should use this
reasoning to argue that, in terms of the syntax design, we should
try to align the plot/plot3d and integral syntax in a similar way?
On Mon, Feb 2, 2009 at 11:16 PM, kcrisman wrote:
>
> Dear Devel list,
>
> Before reading this, read the discussions at
> http://groups.google.com/group/sage-devel/browse_thread/thread/8ec32e4d895da60c
> and tracs # 1221 and # 2787.
>
> Since nothing has been done on this in over a year, and because I feel
> fairly strongly that it is *very* important (to keep "insane ease of
> use", in wdj's words) to keep things like
> sage: integrate(sin(x),x,0,pi)
> viable, I messed around with a toy implementation of some alternate
> syntax that would preserve backward compatibility but allow for the
> Mathematica-style syntax and multiple integration.
>
> I now have a working (still toy) implementation that keeps all current
> syntax, but adds the following possibilities giving correct answers:
>
> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
> instead of lists if you like parentheses
> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
> integrals
>
> One would not (yet) be able to do something like
> sage: integrate(sin(x),[0,pi])
> though I suppose it would be easy to implement; this seems a little
> weird to me personally, though, esp. if
> sage: integrate(sin(x),0,pi)
> is already available.
>
> Because the integration code is spread in a few places, I am sure it
> will take some work to make this work properly, but I am familiar
> enough with it from previous work that this proof of concept has
> convinced me. (Thanks, Python, for making such things so easy!) It
> is really just a matter of asking the right arguments to be passed at
> some point, since Maxima and the interface to it take care of the
> rest.
>
> So I am wondering if there is any feedback from esp. William, Ondrej,
> Jason, and whomever else posted or discussed this on trac. Certainly
> having "native" multiple integrals seems like a no-brainer to try to
> have, and enabling easy transfer from Mma is definitely useful. But
> I'd also like to ensure that
> sage: integrate(sin(x),x,0,pi)
> and friends live happily ever after, or at least until I stop
> teaching, and I am quite happy to do all the work to make that happen
> while addressing the valid points these tickets make.
>
> Thanks,
> - kcrisman
> >
>
--~--~-~--~~~---~--~~
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: Building sage-3.2.2 fails
On Feb 3, 9:36 am, Alexander Dreyer wrote: > > > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems > > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in > > > which options are given to the compiler in order to pass to the > > > linker, but since this is running the linker directly it should just > > > be -soname libpolybori-0.5.0.so.0. I grep out the line in the install > > > log and change that part it seems to build the .so. I just don't know > > > where to change "sonameprefix" such that it doesn't get changed back > > > as soon as I run make. What constructs the SConstruct? > > one could set a custom SONAMEPREFIX in custom.py, which is at the very > same position as: > > > It is in the polybori-0.5rc.p6 .spkg in polybori-0.5rc.p6/patches/ > > SConstruct > > But, indeed we need a better default setting for the sonameprefix, so > I prepare an according patch for the SConstruct file. > See:http://polybori.cvs.sourceforge.net/viewvcpolybori/PolyBoRi/SConstru... Ok, so I extracted the .spkg of polybori (having worked out that it was just a bzipped tarball), changed SConstruct (with sonameprefix as '-Wl,-soname -Wl,'), and repackaged it, and it didn't work: ld -o polybori/libpolybori-0.5.1.so.0.0.0 -s -shared -Wl,-soname - Wl,libpolybori-0.5.1.so.0 Cudd/obj/cuddObj.os Cudd/util/ cpu_stats.os ... ld: unrecognized option '-Wl,-soname' So I changed the SConstruct file in the package to set the sonameprefix to be '-soname ' and it built polybori (the .so is in sage-3.2.3/local/lib) and has now moved on to build sage itself. --~--~-~--~~~---~--~~ 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: Integration syntax
Sorry for replying to my own post, as I should have checked this sooner:
sage: import sympy
sage: sympy.integrate(f,x,y) == sympy.integrate(sympy.integrate(f,x),y)
True
sage: sympy.diff(f,x,y) == sympy.diff(sympy.diff(f,x),y)
True
So Sympy is consistent in terms of the diff/integrate syntax. However,
For plot and integrate, the syntax is slightly different:
sage: sympy.integrate( f, [x, 0, pi], [y, 0, pi])
pi - 1/pi*sin(pi**2)
sage: sympy.Plot( f, [x, 0, pi, numsteps], [y, 0, pi, numsteps])
[0]: y*sin(x*y), 'mode=cartesian'
This is because sympy (unlike Sage) does not have a default value for the
number of samples used to create the plot.
Anyway, what Sympy has implemented currently is similar to what I was
trying to say in the previous post.
On Tue, Feb 3, 2009 at 7:44 AM, David Joyner wrote:
> I agree, some consistent syntax for multiple integrals is needed.
> For example, to me this seems strange:
>
> sage: x,y = var("x,y")
> sage: f = y*sin(x*y)
> sage: bool(diff(f,x,y) == diff(diff(f,x),y))
> True
> sage: bool(integral(f,x,y) == integral(integral(f,x),y))
> False
>
> At least, it is a possible source of confusion for students.
>
> Years ago, one of my collegues (now retired) argued that because
> the Maple syntax for plot3d and the Maple syntax for double integrals
> was the same, this helped the students understand limits in
> calc3 better. For definite integrals, I wonder if we should use this
> reasoning to argue that, in terms of the syntax design, we should
> try to align the plot/plot3d and integral syntax in a similar way?
>
>
>
> On Mon, Feb 2, 2009 at 11:16 PM, kcrisman wrote:
>>
>> Dear Devel list,
>>
>> Before reading this, read the discussions at
>> http://groups.google.com/group/sage-devel/browse_thread/thread/8ec32e4d895da60c
>> and tracs # 1221 and # 2787.
>>
>> Since nothing has been done on this in over a year, and because I feel
>> fairly strongly that it is *very* important (to keep "insane ease of
>> use", in wdj's words) to keep things like
>> sage: integrate(sin(x),x,0,pi)
>> viable, I messed around with a toy implementation of some alternate
>> syntax that would preserve backward compatibility but allow for the
>> Mathematica-style syntax and multiple integration.
>>
>> I now have a working (still toy) implementation that keeps all current
>> syntax, but adds the following possibilities giving correct answers:
>>
>> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
>> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
>> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
>> instead of lists if you like parentheses
>> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
>> integrals
>>
>> One would not (yet) be able to do something like
>> sage: integrate(sin(x),[0,pi])
>> though I suppose it would be easy to implement; this seems a little
>> weird to me personally, though, esp. if
>> sage: integrate(sin(x),0,pi)
>> is already available.
>>
>> Because the integration code is spread in a few places, I am sure it
>> will take some work to make this work properly, but I am familiar
>> enough with it from previous work that this proof of concept has
>> convinced me. (Thanks, Python, for making such things so easy!) It
>> is really just a matter of asking the right arguments to be passed at
>> some point, since Maxima and the interface to it take care of the
>> rest.
>>
>> So I am wondering if there is any feedback from esp. William, Ondrej,
>> Jason, and whomever else posted or discussed this on trac. Certainly
>> having "native" multiple integrals seems like a no-brainer to try to
>> have, and enabling easy transfer from Mma is definitely useful. But
>> I'd also like to ensure that
>> sage: integrate(sin(x),x,0,pi)
>> and friends live happily ever after, or at least until I stop
>> teaching, and I am quite happy to do all the work to make that happen
>> while addressing the valid points these tickets make.
>>
>> Thanks,
>> - kcrisman
>> >>
>>
>
--~--~-~--~~~---~--~~
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: Building sage-3.2.2 fails
On Feb 3, 4:53 am, dannychrastina wrote: Hi, > Ok, so I extracted the .spkg of polybori (having worked out that it > was just a bzipped tarball), changed SConstruct (with sonameprefix as > '-Wl,-soname -Wl,'), and repackaged it, and it didn't work: > > ld -o polybori/libpolybori-0.5.1.so.0.0.0 -s -shared -Wl,-soname - > Wl,libpolybori-0.5.1.so.0 Cudd/obj/cuddObj.os Cudd/util/ > cpu_stats.os ... > ld: unrecognized option '-Wl,-soname' For whatever reason on your box SCons is using ld directly instead of g ++ to link and the fix you suggest won't work on many other platforms. So please send us * a dump of env * the build log (All of it, not just the failed lines since they are useless without context). You should compress install.log and post a link so I can download it. Do *not* send the compressed install.log as an attachment to the email. > So I changed the SConstruct file in the package to set the > sonameprefix to be '-soname ' and it built polybori (the .so is in > sage-3.2.3/local/lib) and has now moved on to build sage itself. 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: 3.3.alpha4 fails build PPC X.4
> > Well, I am much more interested in gcc -v since the above can cover 3 > or so XCode releases. Build 5370. --~--~-~--~~~---~--~~ 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.3.alpha4 fails build PPC X.4
On Feb 3, 3:54 am, kcrisman wrote: > > Ok, that is a side effect of not setting -fno-common. I am curious > > which gcc release this is. > > powerpc-apple-darwin8-gcc-4.0.1 Well, I am much more interested in gcc -v since the above can cover 3 or so XCode releases. > > > > export SHAREDFLAGS="-fno-common" > > > and restart the build. > > Okay, I will try that. Apparently it is picking up where it left off > and separately doing each of that long list of .o files with -fno- > common, and is now running the various tests for NTL. Let's hope it > doesn't stop again! With SHAREDFLAGS set in the NTL.spkg the build of Sage finished for me on a OSX 10.4/PPC box. Either way, the fix will be in alpha5, but we are still doing something odd the way we build the dynamic NTL library on OSX, but I can't put my finger on it at the moment. > Thanks, > > - kcrisman 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: 3.3.alpha4 fails build PPC X.4
On Feb 3, 8:53 am, kcrisman wrote: > > Well, I am much more interested in gcc -v since the above can cover 3 > > or so XCode releases. > > Build 5370. Thanks. I ran testlong on that OSX 10.4/PPC and I am seeing one surprising doctest failure sage -t -long "devel/sage/sage/symbolic/function.pyx" [this is now #5166] Other than that there are the usual suspects sage -t -long "devel/sage/sage/calculus/calculus.py" [#5129] sage -t -long "devel/sage/sage/rings/polynomial/ toy_d_basis.py" [#5027] sage -t -long "devel/sage/sage/schemes/elliptic_curves/ ell_finite_field.py" [too lazy to look that one up] Expect alpha5 today which actually will build on OSX :) In a supreme notion of irony alpha4 actually build out of the box on Solaris 10/x86 with my own toolchain. 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: Integration syntax
On Tue, Feb 3, 2009 at 5:22 AM, David Joyner wrote: > > Sorry for replying to my own post, as I should have checked this sooner: > > sage: import sympy > sage: sympy.integrate(f,x,y) == sympy.integrate(sympy.integrate(f,x),y) > True > sage: sympy.diff(f,x,y) == sympy.diff(sympy.diff(f,x),y) > True > > So Sympy is consistent in terms of the diff/integrate syntax. However, > For plot and integrate, the syntax is slightly different: > > sage: sympy.integrate( f, [x, 0, pi], [y, 0, pi]) > pi - 1/pi*sin(pi**2) > sage: sympy.Plot( f, [x, 0, pi, numsteps], [y, 0, pi, numsteps]) > [0]: y*sin(x*y), 'mode=cartesian' > > This is because sympy (unlike Sage) does not have a default value for the > number of samples used to create the plot. Sage's plot syntax is better imho, so we should fix it in sympy. Ondrej --~--~-~--~~~---~--~~ 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: Integration syntax
kcrisman wrote:
> Dear Devel list,
>
> Before reading this, read the discussions at
> http://groups.google.com/group/sage-devel/browse_thread/thread/8ec32e4d895da60c
> and tracs # 1221 and # 2787.
>
> Since nothing has been done on this in over a year, and because I feel
> fairly strongly that it is *very* important (to keep "insane ease of
> use", in wdj's words) to keep things like
> sage: integrate(sin(x),x,0,pi)
> viable, I messed around with a toy implementation of some alternate
> syntax that would preserve backward compatibility but allow for the
> Mathematica-style syntax and multiple integration.
>
> I now have a working (still toy) implementation that keeps all current
> syntax, but adds the following possibilities giving correct answers:
>
> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
> instead of lists if you like parentheses
> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
> integrals
>
> One would not (yet) be able to do something like
> sage: integrate(sin(x),[0,pi])
> though I suppose it would be easy to implement; this seems a little
> weird to me personally, though, esp. if
> sage: integrate(sin(x),0,pi)
> is already available.
>
> Because the integration code is spread in a few places, I am sure it
> will take some work to make this work properly, but I am familiar
> enough with it from previous work that this proof of concept has
> convinced me. (Thanks, Python, for making such things so easy!) It
> is really just a matter of asking the right arguments to be passed at
> some point, since Maxima and the interface to it take care of the
> rest.
>
> So I am wondering if there is any feedback from esp. William, Ondrej,
> Jason, and whomever else posted or discussed this on trac. Certainly
> having "native" multiple integrals seems like a no-brainer to try to
> have, and enabling easy transfer from Mma is definitely useful. But
> I'd also like to ensure that
> sage: integrate(sin(x),x,0,pi)
> and friends live happily ever after, or at least until I stop
> teaching, and I am quite happy to do all the work to make that happen
> while addressing the valid points these tickets make.
I have no opinion on the integrate(sin(x),x,0,pi), since I don't (like
to) use that syntax and don't plan on teaching it to students. However,
a strong +1 to getting MMA-like syntax integrate(sin(x), (x, 0, pi)). I
really miss that.
Thanks,
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: Integration syntax
On Tue, Feb 3, 2009 at 2:21 PM, Fredrik Johansson wrote: > > On Tue, Feb 3, 2009 at 2:22 PM, David Joyner wrote: >> So Sympy is consistent in terms of the diff/integrate syntax. However, >> For plot and integrate, the syntax is slightly different: >> >> sage: sympy.integrate( f, [x, 0, pi], [y, 0, pi]) >> pi - 1/pi*sin(pi**2) >> sage: sympy.Plot( f, [x, 0, pi, numsteps], [y, 0, pi, numsteps]) >> [0]: y*sin(x*y), 'mode=cartesian' >> >> This is because sympy (unlike Sage) does not have a default value for the >> number of samples used to create the plot. > > Huh? sympy.Plot(y*sin(x*y), [x, 0, pi], [y, 0, pi]) works for me. > Not me: sage: version() 'Sage Version 3.3.alpha3, Release Date: 2009-01-28' sage: sympy.Plot(y*sin(x*y), [x, 0, pi], [y, 0, pi]) ERROR: An unexpected error occurred while tokenizing input ... ValueError: Could not interpret [x, 0, pi] as a function or interval. > Fredrik > > > > --~--~-~--~~~---~--~~ 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] interactive licenses for non-free stuff (like nauty)
There is quite a bit of discussion going on at ticket http://trac.sagemath.org/sage_trac/ticket/4890 about nauty's interactive installation that demands that a user agree to a license. I originally made that spkg and the result of the discussion at that time was that an interactive license was needed. There is strong disapproval of having an interactive license now. The end of the discussion on the ticket points to having a thread on sage-devel to address the question. For your convenience, here is the last comment: "> I would still not call this interactive error message "stupid" since > it was done deliberately. "I think interactive license agreements are annoying. They are all done deliberately. "> Nauty is not only non-free, but its license prohibits its use for > works involving primarily military applications, so this is not about > non-GPL vs. GPL. "Nauty is free as in beer, but the free license it is under is not "libre" i.e., not OSI approved and not GPL-compatible. Nauty's license is: "Permission is hereby given for use and/or distribution with the exception of sale for profit or application with nontrivial military significance." There are essentially no other restrictions. "Since we have a fundamental disagreement here, this will need to be discussed on sage-devel and possibly voted on." Note that in this case, apparently nauty is included in an (optional?) package we install with gap, so at least there is inconsistency here. Does someone (William?, mabshoff?) want to explicitly state the proposal we are voting on? Personally, I don't care either way. I guess I've been weaned off of nauty for a while now, thanks to Robert's good code :). Thanks, 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: Integration syntax
On Feb 2, 9:16 pm, kcrisman wrote:
> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
> instead of lists if you like parentheses
> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
> integrals
Since the Sage project does not have the burden of history
(relatively speaking) I think you guys should go nuts and try
to do it "right".
I'll leave it to you to decide what's right but to me it means
trying to directly represent general integrals, so the syntax is:
integrate(F, R) or integrate(F, R, mu) where F is a function,
R is a region, and mu is an optional measure.
Leaving aside mu for the moment, F is specifically a function
(named or unnamed, and not a general expression) and R is an
interval or product of intervals or some more general set.
1-d integrals would be like integrate(lambda([x], sin(x)), [0, pi])
(sorry, I don't know the python lambda notation)
or integrate(sin, [0, pi]). 2-d like
integrate(lambda([x, y], x*y), [0, 1] cross [0, 1]),
more general region like integrate(lambda([u, v], exp(u - v)),
set((u, v) s.t. u - v < 0)).
I've imagined some notations such as cartesian product
and so-called "set builder" which may not yet exist in Sage.
The existing notation integrate(a, b, c, d) could be preserved
as a convenience function equivalent to integrate(lambda([b], a), [c,
d]).
I've left out many details but the general point is that I think
you guys (= Sage project) should aim high.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
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: interactive licenses for non-free stuff (like nauty)
On Feb 3, 1:27 pm, Jason Grout wrote: > There is quite a bit of discussion going on at > tickethttp://trac.sagemath.org/sage_trac/ticket/4890about nauty's interactive > installation that demands that a user agree to a license. I originally > made that spkg and the result of the discussion at that time was that an > interactive license was needed. There is strong disapproval of having > an interactive license now. The end of the discussion on the ticket > points to having a thread on sage-devel to address the question. For > your convenience, here is the last comment: > > "> I would still not call this interactive error message "stupid" since > > it was done deliberately. > > "I think interactive license agreements are annoying. They are all done > deliberately. > > "> Nauty is not only non-free, but its license prohibits its use for > > works involving primarily military applications, so this is not about > > non-GPL vs. GPL. > > "Nauty is free as in beer, but the free license it is under is not > "libre" i.e., not OSI approved and not GPL-compatible. Nauty's license > is: "Permission is hereby given for use and/or distribution with the > exception of sale for profit or application with nontrivial military > significance." There are essentially no other restrictions. > > "Since we have a fundamental disagreement here, this will need to be > discussed on sage-devel and possibly voted on." > > Note that in this case, apparently nauty is included in an (optional?) > package we install with gap, so at least there is inconsistency here. The fact that nauty is part of some gap related spkg and we do not have a warning there does not mean that we should proceed the same way with the nauty.spkg also. I would in fact vote for either removing nauty from the gap-essentials.spkg (unless it is only the bindings) or also requiring an iterative license. A lot of things ended up in the essential gap.spkg that these days would not even make it into Sage without a lot of mandatory cleanup. > Does someone (William?, mabshoff?) want to explicitly state the proposal > we are voting on? > > Personally, I don't care either way. I guess I've been weaned off of > nauty for a while now, thanks to Robert's good code :). This is not free vs. non-free, the point it that no other piece of free or commercial software either in the optional/experimental spkg repo or otherwise available via a pexpect interface does not restrict the user in any way on what to use that piece of software for. Nauty does restrict the user. We do have a significant number of users who the nauty restriction does apply to and I take offense of having the ticket summary contain the word "stupid". The decision to make the license agreement interactive was made after deliberate discussion on sage-devel and the ticket IIRC. And people installing spkgs do not first do a license audit, so the interactive spkg-install prevents anyone from accidentally installing nauty when they should not. So I vote to keep the license agreement, but we can make it so that if some env variable (maybe SAGE_MILITARY_USE_OK == yes) is set where no one can claim to have set it by accident does skip the interactive portion of spkg-install. The same should apply to whatever gap related spkg that contains either nauty or nauty bindings and we should consider splitting it off the spkg to make things simpler license wise. > Thanks, > > Jason 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: interactive licenses for non-free stuff (like nauty)
I definitely think that a passive approach is better. Debian, for example, has their repositories split into "free" and "non-free". I believe that this would be the best solution to this problem. Click-through interactive licensing agreements are no stronger than passive licenses. The law is the law, and claiming ignorance is never a defense unless the law / license is deliberately obscured. Since we're not obliterating the license file, if we put the package into a non-free repo there should be no problems. On Tue, Feb 3, 2009 at 1:42 PM, mabshoff wrote: > > > > On Feb 3, 1:27 pm, Jason Grout wrote: > > There is quite a bit of discussion going on at tickethttp:// > trac.sagemath.org/sage_trac/ticket/4890about nauty's interactive > > installation that demands that a user agree to a license. I originally > > made that spkg and the result of the discussion at that time was that an > > interactive license was needed. There is strong disapproval of having > > an interactive license now. The end of the discussion on the ticket > > points to having a thread on sage-devel to address the question. For > > your convenience, here is the last comment: > > > > "> I would still not call this interactive error message "stupid" since > > > it was done deliberately. > > > > "I think interactive license agreements are annoying. They are all done > > deliberately. > > > > "> Nauty is not only non-free, but its license prohibits its use for > > > works involving primarily military applications, so this is not about > > > non-GPL vs. GPL. > > > > "Nauty is free as in beer, but the free license it is under is not > > "libre" i.e., not OSI approved and not GPL-compatible. Nauty's license > > is: "Permission is hereby given for use and/or distribution with the > > exception of sale for profit or application with nontrivial military > > significance." There are essentially no other restrictions. > > > > "Since we have a fundamental disagreement here, this will need to be > > discussed on sage-devel and possibly voted on." > > > > Note that in this case, apparently nauty is included in an (optional?) > > package we install with gap, so at least there is inconsistency here. > > The fact that nauty is part of some gap related spkg and we do not > have a warning there does not mean that we should proceed the same way > with the nauty.spkg also. I would in fact vote for either removing > nauty from the gap-essentials.spkg (unless it is only the bindings) or > also requiring an iterative license. A lot of things ended up in the > essential gap.spkg that these days would not even make it into Sage > without a lot of mandatory cleanup. > > > Does someone (William?, mabshoff?) want to explicitly state the proposal > > we are voting on? > > > > Personally, I don't care either way. I guess I've been weaned off of > > nauty for a while now, thanks to Robert's good code :). > > This is not free vs. non-free, the point it that no other piece of > free or commercial software either in the optional/experimental spkg > repo or otherwise available via a pexpect interface does not restrict > the user in any way on what to use that piece of software for. Nauty > does restrict the user. We do have a significant number of users who > the nauty restriction does apply to and I take offense of having the > ticket summary contain the word "stupid". The decision to make the > license agreement interactive was made after deliberate discussion on > sage-devel and the ticket IIRC. And people installing spkgs do not > first do a license audit, so the interactive spkg-install prevents > anyone from accidentally installing nauty when they should not. > > So I vote to keep the license agreement, but we can make it so that if > some env variable (maybe SAGE_MILITARY_USE_OK == yes) is set where no > one can claim to have set it by accident does skip the interactive > portion of spkg-install. The same should apply to whatever gap related > spkg that contains either nauty or nauty bindings and we should > consider splitting it off the spkg to make things simpler license > wise. > > > Thanks, > > > > Jason > > 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: interactive licenses for non-free stuff (like nauty)
For the bean-counters, that's a -1 to interactive crap. On Tue, Feb 3, 2009 at 2:09 PM, Tom Boothby wrote: > I definitely think that a passive approach is better. Debian, for example, > has their repositories split into "free" and "non-free". I believe that > this would be the best solution to this problem. > > Click-through interactive licensing agreements are no stronger than passive > licenses. The law is the law, and claiming ignorance is never a defense > unless the law / license is deliberately obscured. Since we're not > obliterating the license file, if we put the package into a non-free repo > there should be no problems. > > > On Tue, Feb 3, 2009 at 1:42 PM, mabshoff wrote: > >> >> >> >> On Feb 3, 1:27 pm, Jason Grout wrote: >> > There is quite a bit of discussion going on at tickethttp:// >> trac.sagemath.org/sage_trac/ticket/4890about nauty's interactive >> > installation that demands that a user agree to a license. I originally >> > made that spkg and the result of the discussion at that time was that an >> > interactive license was needed. There is strong disapproval of having >> > an interactive license now. The end of the discussion on the ticket >> > points to having a thread on sage-devel to address the question. For >> > your convenience, here is the last comment: >> > >> > "> I would still not call this interactive error message "stupid" since >> > > it was done deliberately. >> > >> > "I think interactive license agreements are annoying. They are all done >> > deliberately. >> > >> > "> Nauty is not only non-free, but its license prohibits its use for >> > > works involving primarily military applications, so this is not about >> > > non-GPL vs. GPL. >> > >> > "Nauty is free as in beer, but the free license it is under is not >> > "libre" i.e., not OSI approved and not GPL-compatible. Nauty's license >> > is: "Permission is hereby given for use and/or distribution with the >> > exception of sale for profit or application with nontrivial military >> > significance." There are essentially no other restrictions. >> > >> > "Since we have a fundamental disagreement here, this will need to be >> > discussed on sage-devel and possibly voted on." >> > >> > Note that in this case, apparently nauty is included in an (optional?) >> > package we install with gap, so at least there is inconsistency here. >> >> The fact that nauty is part of some gap related spkg and we do not >> have a warning there does not mean that we should proceed the same way >> with the nauty.spkg also. I would in fact vote for either removing >> nauty from the gap-essentials.spkg (unless it is only the bindings) or >> also requiring an iterative license. A lot of things ended up in the >> essential gap.spkg that these days would not even make it into Sage >> without a lot of mandatory cleanup. >> >> > Does someone (William?, mabshoff?) want to explicitly state the proposal >> > we are voting on? >> > >> > Personally, I don't care either way. I guess I've been weaned off of >> > nauty for a while now, thanks to Robert's good code :). >> >> This is not free vs. non-free, the point it that no other piece of >> free or commercial software either in the optional/experimental spkg >> repo or otherwise available via a pexpect interface does not restrict >> the user in any way on what to use that piece of software for. Nauty >> does restrict the user. We do have a significant number of users who >> the nauty restriction does apply to and I take offense of having the >> ticket summary contain the word "stupid". The decision to make the >> license agreement interactive was made after deliberate discussion on >> sage-devel and the ticket IIRC. And people installing spkgs do not >> first do a license audit, so the interactive spkg-install prevents >> anyone from accidentally installing nauty when they should not. >> >> So I vote to keep the license agreement, but we can make it so that if >> some env variable (maybe SAGE_MILITARY_USE_OK == yes) is set where no >> one can claim to have set it by accident does skip the interactive >> portion of spkg-install. The same should apply to whatever gap related >> spkg that contains either nauty or nauty bindings and we should >> consider splitting it off the spkg to make things simpler license >> wise. >> >> > Thanks, >> > >> > Jason >> >> 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: interactive licenses for non-free stuff (like nauty)
On Tue, Feb 3, 2009 at 1:27 PM, Jason Grout wrote: > > There is quite a bit of discussion going on at ticket > http://trac.sagemath.org/sage_trac/ticket/4890 about nauty's interactive > installation that demands that a user agree to a license. I originally > made that spkg and the result of the discussion at that time was that an > interactive license was needed. There is strong disapproval of having > an interactive license now. The end of the discussion on the ticket > points to having a thread on sage-devel to address the question. For > your convenience, here is the last comment: > > > "> I would still not call this interactive error message "stupid" since > > it was done deliberately. > > "I think interactive license agreements are annoying. They are all done > deliberately. > > "> Nauty is not only non-free, but its license prohibits its use for > > works involving primarily military applications, so this is not about > > non-GPL vs. GPL. > > "Nauty is free as in beer, but the free license it is under is not > "libre" i.e., not OSI approved and not GPL-compatible. Nauty's license > is: "Permission is hereby given for use and/or distribution with the > exception of sale for profit or application with nontrivial military > significance." There are essentially no other restrictions. > > "Since we have a fundamental disagreement here, this will need to be > discussed on sage-devel and possibly voted on." > > > > > Note that in this case, apparently nauty is included in an (optional?) > package we install with gap, so at least there is inconsistency here. > > Does someone (William?, mabshoff?) want to explicitly state the proposal > we are voting on? PROPOSAL 1: When installing official Sage spkg's, Sage should not interactively ask the user to agree to licenses. Justification: (1) My understanding is that interactive license agreements are no more legally binding than non-interactive ones. (2) Debian/Ubuntu doesn't require interactive license agreements -- instead they require the user to add the non-free repo to /etc/apt/sources.list. (3) Interactive license agreements make automatic scripted installation of software difficult. (4) Where do we draw the line? I just gave a talk at Microsoft a few minutes ago, and for them, installing GPL'd software is far far more dangerous than installing Nauty. VOTE: [ ] Yes [ ] No PROPOSAL 2: We add a restricted repository, and make installing spkg's in it require a non-default option, e.g., sage -i -restricted nauty-x.y The nauty, Kash, and several other spkg's would be moved there. VOTE: [ ] Yes [ ] No -- 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: A Mac OS X Sage Launcher
Ok, thanks to Ivan who did upload some patches to trac 3.3.alpha5 out in a couple hours will create a Sage app if you run -bdist. Check out a screenshot of it in action at http://sage.math.washington.edu/home/mabshoff/SageApp.png It is based on Sage 3.3.alpha0 since I did no feel like hosing my current alpha4 build, but it works very well. Note that a couple things need to be fixed, but that will be done later. Another issue is that we should create the app without having to run bdist since that takes rather long. In the png you can see the console of the current output from the notebook, the about Sage dialog and the icon. All in all very smooth and certainly a giant improvement in usability if you ask me. So thanks to Karl-Dieter and Ivan for finally makeing this a reality since we have been talking about this since ye old Sage 2.5 at least when I posted some crummy manually assembled app. 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: interactive licenses for non-free stuff (like nauty)
William Stein wrote: > PROPOSAL 1: When installing official Sage spkg's, Sage should not > interactively ask the user to agree to licenses. > > Justification: (1) My understanding is that interactive license > agreements are no more legally binding than non-interactive ones. (2) > Debian/Ubuntu doesn't require interactive license agreements -- > instead they require the user to add the non-free repo to > /etc/apt/sources.list. (3) Interactive license agreements make > automatic scripted installation of software difficult. (4) Where do > we draw the line? I just gave a talk at Microsoft a few minutes ago, > and for them, installing GPL'd software is far far more dangerous than > installing Nauty. > > VOTE: > [ ] Yes > [ ] No Yes. > > PROPOSAL 2: We add a restricted repository, and make installing spkg's > in it require a non-default option, e.g., > > sage -i -restricted nauty-x.y > > The nauty, Kash, and several other spkg's would be moved there. > > VOTE: > [ ] Yes > [ ] No Yes. 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: interactive licenses for non-free stuff (like nauty)
On Feb 3, 2:15 pm, William Stein wrote: > On Tue, Feb 3, 2009 at 1:27 PM, Jason Grout > wrote: > > Does someone (William?, mabshoff?) want to explicitly state the proposal > > we are voting on? > > PROPOSAL 1: When installing official Sage spkg's, Sage should not > interactively ask the user to agree to licenses. Phrasing the question with a negative is not going to make this any easier :) > Justification: (1) My understanding is that interactive license > agreements are no more legally binding than non-interactive ones. That is not the issue at all. This has nothing to do with the Sage project enforcing licenses. > (2) > Debian/Ubuntu doesn't require interactive license agreements -- > instead they require the user to add the non-free repo to > /etc/apt/sources.list. Well, if we had proposal 2 this would be an argument, but as is there is no way to differentiate between free and non-free spkgs. And in fact the issue is more complicated, i.e. while kash is free as in beer, but not free as in freedom it does not restrict the user what area they are doing research in or whom they are affiliated with. > (3) Interactive license agreements make > automatic scripted installation of software difficult. This can be trivially worked around by using env variables for testing. > (4) Where do > we draw the line? I just gave a talk at Microsoft a few minutes ago, > and for them, installing GPL'd software is far far more dangerous than > installing Nauty. The GPL does not state in any way that if you work for MS or MSR that you are not allowed to use this piece of software. MSR is for some reason I do not truly understand (I have heard the reasons, but they do not convince me, but that doesn't matter) prevented from using software licensed under the GPL V3, but that is a completely different situation than the Nauty license. > VOTE: > [ ] Yes > [ ] No I voted above. > PROPOSAL 2: We add a restricted repository, and make installing spkg's > in it require a non-default option, e.g., > > sage -i -restricted nauty-x.y > > The nauty, Kash, and several other spkg's would be moved there. > VOTE: [ x ] Yes [ ] No At least Nauty. I don't think any other spkg is restricted aside from potentially the bits in the gap-essentials.spkg that involve Nauty. It would be good to have non-free to differentiate the free spkgs and move everything that is not GPL compatible that would be potentially linked to a Sage component like graphviz for example to non-free. > -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Integration syntax
On Tue, Feb 3, 2009 at 2:22 PM, David Joyner wrote: > So Sympy is consistent in terms of the diff/integrate syntax. However, > For plot and integrate, the syntax is slightly different: > > sage: sympy.integrate( f, [x, 0, pi], [y, 0, pi]) > pi - 1/pi*sin(pi**2) > sage: sympy.Plot( f, [x, 0, pi, numsteps], [y, 0, pi, numsteps]) > [0]: y*sin(x*y), 'mode=cartesian' > > This is because sympy (unlike Sage) does not have a default value for the > number of samples used to create the plot. Huh? sympy.Plot(y*sin(x*y), [x, 0, pi], [y, 0, pi]) works for me. Fredrik --~--~-~--~~~---~--~~ 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: Integration syntax
Robert Dodier wrote:
> On Feb 2, 9:16 pm, kcrisman wrote:
>
>> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
>> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
>> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
>> instead of lists if you like parentheses
>> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
>> integrals
>
> Since the Sage project does not have the burden of history
> (relatively speaking) I think you guys should go nuts and try
> to do it "right".
>
> I'll leave it to you to decide what's right but to me it means
> trying to directly represent general integrals, so the syntax is:
> integrate(F, R) or integrate(F, R, mu) where F is a function,
> R is a region, and mu is an optional measure.
Wow, you've really opened up possibilities here. This is a very
intriguing idea.
We can define a function so that it knows what the variables and
constants are, i.e.,
sage: var('y')
sage: f(x) = sin(x)*y
So integrating this function should be okay with the below
sage: integrate(f, [0, pi])
In fact, the following general form
sage: integrate(expression, (x, a, b), (y, c, d))
could be a shortcut for
sage: integrate((x,y) |--> expression, set( (x,y) s.t. a<=x<=b and c<=y<=d))
and we would still have the familiar syntax while supporting much more
powerful statements. (Note that I use Sage functions instead of Python
lambda functions, so they can be sped up using fast_float easily).
Robert, please keep contributing to the conversation. You've obviously
thought a lot more about this than we have. I'd like to hear you
elaborate on this if you have time.
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: interactive licenses for non-free stuff (like nauty)
On Feb 3, 2:09 pm, Tom Boothby wrote: > I definitely think that a passive approach is better. Debian, for example, > has their repositories split into "free" and "non-free". I believe that > this would be the best solution to this problem. > > Click-through interactive licensing agreements are no stronger than passive > licenses. The law is the law, and claiming ignorance is never a defense > unless the law / license is deliberately obscured. Since we're not > obliterating the license file, if we put the package into a non-free repo > there should be no problems. There is no such indication of any spkg in optional if it is "free" or "non free". And the the problem is not if if such a license agreement is legally binding or not, the point is that the user should be given a chance to not violate nauty's license since it is unique for any software that is part of the Sage universe. 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: 3.3.alpha4 fails build PPC X.4
On Feb 3, 9:33 am, mabshoff wrote: > On Feb 3, 8:53 am, kcrisman wrote: > > > > Well, I am much more interested in gcc -v since the above can cover 3 > > > or so XCode releases. > > > Build 5370. > > Thanks. > > I ran testlong on that OSX 10.4/PPC and I am seeing one surprising > doctest failure > > sage -t -long "devel/sage/sage/symbolic/function.pyx" [this is > now #5166] > > Other than that there are the usual suspects > > sage -t -long "devel/sage/sage/calculus/calculus.py" [#5129] Arrh, this problem is not the numerical noise issue, but a different issue now #5167 that is caused by the root being displayed in a different order. But as Carl Witty pointed out a while ago in IRC this is likely solved by #4544 which I am reviewing at the moment and will likely merge in a short while. > sage -t -long "devel/sage/sage/rings/polynomial/ > toy_d_basis.py" [#5027] > sage -t -long "devel/sage/sage/schemes/elliptic_curves/ > ell_finite_field.py" [too lazy to look that one up] > > Expect alpha5 today which actually will build on OSX :) > > In a supreme notion of irony alpha4 actually build out of the box on > Solaris 10/x86 with my own toolchain. > > Cheers, > > Michael 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: tinymce tickets for 3.3
On Tue, Feb 3, 2009 at 12:19 AM, wrote: > William, > > Could you (or Mike) review #5141 and #5143? #5141 is a one-line fix to make > sure that tinymce is disabled on published worksheets, while #5143 > implements William's feature request of shift-enter submitting a tinyMCE > form. I also put the extra font formatting buttons William requested in > #5143. > > Both patches are relatively short. Jason -- many thanks for doing this! Jason -- I have one request after having given two major talks using Sage + tinyMCE. Could we just get rid of that text hint "Doubleclick to edit..." over the HTML? This was incredibly annoying during my talks, because I like to point with the mouse, and it's hard to see the slides through that text hint. Or, at least it would be nice if there were some way to turn it off (even an option when starting the notebook for now). 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: tinymce tickets for 3.3
On Feb 3, 5:36 pm, William Stein wrote: > On Tue, Feb 3, 2009 at 12:19 AM, wrote: > > William, > > > Could you (or Mike) review #5141 and #5143? #5141 is a one-line fix to make > > sure that tinymce is disabled on published worksheets, while #5143 > > implements William's feature request of shift-enter submitting a tinyMCE > > form. I also put the extra font formatting buttons William requested in > > #5143. > > > Both patches are relatively short. And they are both in alpha5 #5141: Jason Grout: tinymce should be disabled on published worksheets [Reviewed by Timothy Clemans, Michael Abshoff] #5143: Jason Grout: shift-enter should save and exit tinyMCE; new font formatting buttons [Reviewed by Timothy Clemans] which should be out in less than an hour. I am right now merging GAP 4.12 and then will cut the release. > Jason -- many thanks for doing this! > > Jason -- I have one request after having given two major talks using > Sage + tinyMCE. > Could we just get rid of that text hint "Doubleclick to edit..." over > the HTML? This was > incredibly annoying during my talks, because I like to point with the > mouse, and it's > hard to see the slides through that text hint. Or, at least it > would be nice if there were > some way to turn it off (even an option when starting the notebook for now). > > 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 -~--~~~~--~~--~--~---
[sage-devel] Re: tinymce tickets for 3.3
William Stein wrote: > On Tue, Feb 3, 2009 at 12:19 AM, wrote: >> William, >> >> Could you (or Mike) review #5141 and #5143? #5141 is a one-line fix to make >> sure that tinymce is disabled on published worksheets, while #5143 >> implements William's feature request of shift-enter submitting a tinyMCE >> form. I also put the extra font formatting buttons William requested in >> #5143. >> >> Both patches are relatively short. > > Jason -- many thanks for doing this! > > Jason -- I have one request after having given two major talks using > Sage + tinyMCE. > Could we just get rid of that text hint "Doubleclick to edit..." over > the HTML? Okay, patch is up at #5170. See what you can do to convince mabshoff it should go into 3.3 :). I'm glad this tinymce thing is getting lots of exposure before being released into the wild. I feel like this was a success story in how to get something into an alpha and tweaked from feedback before being released in the final release. 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: A Mac OS X Sage Launcher
> So thanks to Karl-Dieter and Ivan for finally makeing this a reality > since we have been talking about this since ye old Sage 2.5 at least > when I posted some crummy manually assembled app. You're welcome, and thanks to Ivan as well, as this seems to be nicer than anything I could cook up. I have to say that I prefer the icosahedron icon, though :) And the hope is that now one could much more easily make incremental improvements to this skeleton in order to support e.g. dropping .sws or .sage files on it. I look forward to using it! - kcrisman --~--~-~--~~~---~--~~ 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: tinymce tickets for 3.3
On Tue, Feb 3, 2009 at 7:09 PM, Jason Grout wrote: > > William Stein wrote: >> On Tue, Feb 3, 2009 at 12:19 AM, wrote: >>> William, >>> >>> Could you (or Mike) review #5141 and #5143? #5141 is a one-line fix to make >>> sure that tinymce is disabled on published worksheets, while #5143 >>> implements William's feature request of shift-enter submitting a tinyMCE >>> form. I also put the extra font formatting buttons William requested in >>> #5143. >>> >>> Both patches are relatively short. >> >> Jason -- many thanks for doing this! >> >> Jason -- I have one request after having given two major talks using >> Sage + tinyMCE. >> Could we just get rid of that text hint "Doubleclick to edit..." over >> the HTML? > > > > > Okay, patch is up at #5170. See what you can do to convince mabshoff it > should go into 3.3 :). > > I'm glad this tinymce thing is getting lots of exposure before being > released into the wild. I feel like this was a success story in how to > get something into an alpha and tweaked from feedback before being > released in the final release. I tried to referee it but Timothy beat me to it (thanks Timothy). I added a tiny one-line patch though so that when one clicks "help" in the upper right, the screen that comes up mentions how to create html cells (shift-click) and to double click to edit them. Otherwise, somebody would never know given that the tooltip is gone. Maybe you should referee my 1-line patch. 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: Integration syntax
Wow, that was definitely not the direction I was anticipating this to take... Robert's contribution is very interesting, though I'm not sure how indefinite integrals (without "+C") fit into that framework. As to the issue on the tracs, my view is that an indefinite integral is not a function in the same sense as a derivative, and that (unlike plot and diff) there are two really fundamentally different objects both referred to by the name "integral" (darn you, Leibniz!), so consistency is not as useful a guide for this. As far as I can tell, having integrate(sin(x), (x, 0, pi)) is no problem to add, nor multiple integration in general. The only problem (and presumably deprecation necessity) would be whether integrate (f,x,y,z) is a triple indefinite integral or a definite integral with y and z as endpoints. I've made my views known on this above :) As a side note, it is unfortunate that Python won't (will it?) allow integrate(f,(x),(y),(z)) to indicate the triple integral and needs the tuple notation integrate(f,(x,),(y,),(z,)). Of course it is easy to allow integrate(f,[x],[y],[z]) for this, but that certainly doesn't address the consistency question. - kcrisman --~--~-~--~~~---~--~~ 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] Massively collaborative mathematics + Sage-ready blogs and forums
Hello, I just wanted to point out Tim Gowers' Polymath, an experiment in "massively collaborative mathematics" currently underway on his blog: http://gowers.wordpress.com/ It seems the basic idea is that in an appropriate public setting, mathematicians (or anyone else) may be able to organize and collaborate fruitfully on research-level projects. Here are his posts on points philosophical and procedural: http://gowers.wordpress.com/2009/01/27/is-massively-collaborative-mathematics-possible/ http://gowers.wordpress.com/2009/02/01/questions-of-procedure/ The pilot project, by the way, is about the density Hales-Jewett theorem: http://gowers.wordpress.com/2009/01/30/background-to-a-polymath-project/ http://gowers.wordpress.com/2009/02/01/a-combinatorial-approach-to-density-hales-jewett/ Anyway, whether this effort stays on Gowers' blog, moves to some LaTeX-enabled forum, or does something completely different, I thought I'd ask about integrating Sage into similar environments, for professionals and amateurs alike. Of course, Sage is already a great example and enabler of collaborative mathematics on many levels. But perhaps features of Sage Notebook would be useful in fully-fledged forums? For example, one might embed a live cell with a plot, equation, derivation, etc., in a post, in order to illustrate a point in a thread about smooth operators, rank tensors, etc. Thoughts? (MathLinks, which is oriented to problem solving, appears to be the most prominent example of LaTeX-enabled forums: http://www.mathlinks.ro/Forum/index.php Their software appears to be a heavily customized version of phpBB. Other examples, especially blogs, abound.) My apologies for my ignorance and naivete. Sincerely, Pat LeSmithe --~--~-~--~~~---~--~~ 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: Massively collaborative mathematics + Sage-ready blogs and forums
On Tue, Feb 3, 2009 at 6:52 PM, Pat LeSmithe wrote: > > > Hello, > > I just wanted to point out Tim Gowers' Polymath, an experiment in > "massively collaborative mathematics" currently underway on his blog: > > http://gowers.wordpress.com/ > > It seems the basic idea is that in an appropriate public setting, > mathematicians (or anyone else) may be able to organize and collaborate > fruitfully on research-level projects. > > Here are his posts on points philosophical and procedural: > > http://gowers.wordpress.com/2009/01/27/is-massively-collaborative-mathematics-possible/ > http://gowers.wordpress.com/2009/02/01/questions-of-procedure/ > > The pilot project, by the way, is about the density Hales-Jewett theorem: > > http://gowers.wordpress.com/2009/01/30/background-to-a-polymath-project/ > http://gowers.wordpress.com/2009/02/01/a-combinatorial-approach-to-density-hales-jewett/ > > Anyway, whether this effort stays on Gowers' blog, moves to some > LaTeX-enabled forum, or does something completely different, I thought > I'd ask about integrating Sage into similar environments, for > professionals and amateurs alike. > > Of course, Sage is already a great example and enabler of collaborative > mathematics on many levels. But perhaps features of Sage Notebook would > be useful in fully-fledged forums? For example, one might embed a live > cell with a plot, equation, derivation, etc., in a post, in order to > illustrate a point in a thread about smooth operators, rank tensors, > etc. Thoughts? Yes! +1 It would be great to have things like that. > > (MathLinks, which is oriented to problem solving, appears to be the most > prominent example of LaTeX-enabled forums: > > http://www.mathlinks.ro/Forum/index.php > > Their software appears to be a heavily customized version of phpBB. > Other examples, especially blogs, abound.) > > My apologies for my ignorance and naivete. Well you're just right that it would be great to have some new web-app that uses similar underlying technology to the Sage notebook, but is more like facebook or some sort of community driven discussion and collaboration environment. I really hope somebody does something in this direction. I suspect some of the thoughts Mike Hansen, Timothy Clemans, Alex Clemesha, and others have had about using Django to revamp the Sage notebook would be relevant. Something like the above might also make a good project to pitch to Google for funding... -- 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: A Mac OS X Sage Launcher
On Feb 3, 2009, at 7:19 PM, kcrisman wrote: >> So thanks to Karl-Dieter and Ivan for finally makeing this a reality >> since we have been talking about this since ye old Sage 2.5 at least >> when I posted some crummy manually assembled app. > > You're welcome, and thanks to Ivan as well, as this seems to be nicer > than anything I could cook up. I have to say that I prefer the > icosahedron icon, though :) And the hope is that now one could much > more easily make incremental improvements to this skeleton in order to > support e.g. dropping .sws or .sage files on it. It was the only icon I could find in the (admittedly short) time I looked. Where could I get the icon (as large as possible)? Also, if you can tell me what to do with dropped files I could easily add that. i.e. how does one open a .sage file in the notebook from the command line. I'm sure it's very simple, I just haven't looked at it yet. Any other suggestions are welcome as well. -Ivan --~--~-~--~~~---~--~~ 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: A Mac OS X Sage Launcher
On Tue, Feb 3, 2009 at 7:01 PM, Ivan Andrus wrote: > > On Feb 3, 2009, at 7:19 PM, kcrisman wrote: > >>> So thanks to Karl-Dieter and Ivan for finally makeing this a reality >>> since we have been talking about this since ye old Sage 2.5 at least >>> when I posted some crummy manually assembled app. >> >> You're welcome, and thanks to Ivan as well, as this seems to be nicer >> than anything I could cook up. I have to say that I prefer the >> icosahedron icon, though :) And the hope is that now one could much >> more easily make incremental improvements to this skeleton in order to >> support e.g. dropping .sws or .sage files on it. > > It was the only icon I could find in the (admittedly short) time I > looked. Where could I get the icon (as large as possible)? Also, if > you can tell me what to do with dropped files I could easily add > that. i.e. how does one open a .sage file in the notebook from the > command line. I'm sure it's very simple, I just haven't looked at it > yet. Any other suggestions are welcome as well. Hmm... there might actually be no way to do that. Just to start thinking about this, we would need: (1) a special URL to go to, e.g., http://localhost:8000/open_file/absolute_path_to_file_on_local_filesystem.sage and (2) a command line option, e.g., $ sage foo.sws would start a notebook server if it isn't already running, and once it is, would call basically (1) above for the default sage notebook server running from $DOT_SAGE/sage_notebook. 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: A Mac OS X Sage Launcher
On Feb 3, 7:07 pm, William Stein wrote: > > It was the only icon I could find in the (admittedly short) time I > > looked. Where could I get the icon (as large as possible)? Also, if > > you can tell me what to do with dropped files I could easily add > > that. i.e. how does one open a .sage file in the notebook from the > > command line. I'm sure it's very simple, I just haven't looked at it > > yet. Any other suggestions are welcome as well. > > Hmm... there might actually be no way to do that. Just to start > thinking about this, we would need: > > (1) a special URL to go to, > e.g.,http://localhost:8000/open_file/absolute_path_to_file_on_local_filesy... > > and > > (2) a command line option, e.g., > > $ sage foo.sws > > would start a notebook server if it isn't already running, and once it > is, would call basically (1) above for the default sage notebook > server running from $DOT_SAGE/sage_notebook. I am not sure that will work too well. I can see two things: (a) dropping a sws into firefox and having Sage deal with the event some way (b) write something more full fledged on a CoCoA level and have that deal with drag & drop events Unfortunately I don't have the time, but some other people might have written code in that direction already. > 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 -~--~~~~--~~--~--~---
[sage-devel] Re: A Mac OS X Sage Launcher
On Tue, Feb 3, 2009 at 7:12 PM, mabshoff wrote: > > > > On Feb 3, 7:07 pm, William Stein wrote: > > > >> > It was the only icon I could find in the (admittedly short) time I >> > looked. Where could I get the icon (as large as possible)? Also, if >> > you can tell me what to do with dropped files I could easily add >> > that. i.e. how does one open a .sage file in the notebook from the >> > command line. I'm sure it's very simple, I just haven't looked at it >> > yet. Any other suggestions are welcome as well. >> >> Hmm... there might actually be no way to do that. Just to start >> thinking about this, we would need: >> >> (1) a special URL to go to, >> e.g.,http://localhost:8000/open_file/absolute_path_to_file_on_local_filesy... >> >> and >> >> (2) a command line option, e.g., >> >> $ sage foo.sws >> >> would start a notebook server if it isn't already running, and once it >> is, would call basically (1) above for the default sage notebook >> server running from $DOT_SAGE/sage_notebook. > > I am not sure that will work too well. Why not?I can easily see how to implement (1) and (2). I'm not saying it will be easy to do -- it would likely take several hours work -- but I don't see any technical problem with doing it.I'm sure somebody like Mike Hansen who knows the notebook code would agree. I would do the above by adding something to .sage/sage_notebook that has the port of the currently running sage notebook server (if one is running), then at a Resource in sage/server/notebook/twist.py that handles uploading an sws (there is already one, probably). Then add a command line option to sage/local/bin/sage-sage for handling sws files. > I can see two things: > > (a) dropping a sws into firefox and having Sage deal with the event > some way > > (b) write something more full fledged on a CoCoA level and have that > deal with drag & drop events > > Unfortunately I don't have the time, but some other people might have > written code in that direction already. > >> William > > Cheers, > > Michael > > > -- 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: A Mac OS X Sage Launcher
On Feb 3, 7:16 pm, William Stein wrote: > On Tue, Feb 3, 2009 at 7:12 PM, mabshoff wrote: > >> would start a notebook server if it isn't already running, and once it > >> is, would call basically (1) above for the default sage notebook > >> server running from $DOT_SAGE/sage_notebook. > > > I am not sure that will work too well. > > Why not? I can easily see how to implement (1) and (2). I'm not > saying it will be easy to do -- it would likely take several hours > work -- but I don't see any technical problem with doing it. I'm > sure somebody like Mike Hansen who knows the notebook code would > agree. I would do the above by adding something to > .sage/sage_notebook that has the port of the currently running sage > notebook server (if one is running), then at a Resource in > sage/server/notebook/twist.py that handles uploading an sws (there is > already one, probably). Then add a command line option to > sage/local/bin/sage-sage for handling sws files. > Yeah, you are right. I was more thinking of drag and drop support, so what you suggest is as you said doable with a couple hours work. I also misspelled Cocoa - I guess it is that old habits die hard. 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: interactive licenses for non-free stuff (like nauty)
On Tue, Feb 3, 2009 at 5:15 PM, William Stein wrote: > > On Tue, Feb 3, 2009 at 1:27 PM, Jason Grout > wrote: >> >> >> >> "Since we have a fundamental disagreement here, this will need to be >> discussed on sage-devel and possibly voted on." >> >> The reasoning below applies not just to "picky" packages such as nauty but also possible non-commercial use ones (like kash/kant?). >> > > PROPOSAL 1: When installing official Sage spkg's, Sage should not > interactively ask the user to agree to licenses. +1 if it is not possible to create an interactive step in the compile process (so, after download and before the picky program is first used, the user must agree to something). -1, regretfully. This is the safest way to avoid a copyright infringement charge. > > Justification: (1) My understanding is that interactive license > agreements are no more legally binding than non-interactive ones. (2) This is unclear to me. If it were legally established then there would be no need for EULAs. > Debian/Ubuntu doesn't require interactive license agreements -- > instead they require the user to add the non-free repo to > /etc/apt/sources.list. (3) Interactive license agreements make > automatic scripted installation of software difficult. (4) Where do > we draw the line? I just gave a talk at Microsoft a few minutes ago, > and for them, installing GPL'd software is far far more dangerous than > installing Nauty. First, maybe grape (which includes nauty) should be removed from gap_packages, since that should not contain any picky programs. If others agree, I will do this since I created that optional package. > > VOTE: > [ ] Yes > [ x ] No > > PROPOSAL 2: We add a restricted repository, and make installing spkg's > in it require a non-default option, e.g., > > sage -i -restricted nauty-x.y > > The nauty, Kash, and several other spkg's would be moved there. > > VOTE: > [ ] Yes > [ x ] No > I actually vote that all picky packages be moved offsite. Sage has the ability to install a spkg from any server (I think - I've not tested this), so if we canot agree to a EULA, or get written approval from the copyright holder allowing us to redistribute without a EULA, why risk the sage machines with a copyright infringement charge? However, I vote yes for all picky programs where we have gotten written approval from the copyright holder allowing us to redistribute without a EULA. Unless I am misunderstanding something, I think this opinion is consistent with both WIlliam's and Michael's positions. > -- 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: A Mac OS X Sage Launcher
> It was the only icon I could find in the (admittedly short) time I > looked. Where could I get the icon (as large as possible)? I pulled it either off of sagemath.org, or from Picture2.png from the front page of this google group. It's not particularly big, unfortunately. - kcrisman --~--~-~--~~~---~--~~ 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: A Mac OS X Sage Launcher
And the hope is that now one could much > >> more easily make incremental improvements to this skeleton in order to > >> support e.g. dropping .sws or .sage files on it. > Hmm... there might actually be no way to do that. What about .sage files? My understanding is that OSX apps would support that on the command line level at least. - kcrisman --~--~-~--~~~---~--~~ 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: A Mac OS X Sage Launcher
On Tue, 03 Feb 2009 at 06:19PM -0800, kcrisman wrote: > You're welcome, and thanks to Ivan as well, as this seems to be nicer > than anything I could cook up. I have to say that I prefer the > icosahedron icon, though :) I happen to prefer the orange perspective-cube. Just sayin'... > And the hope is that now one could much > more easily make incremental improvements to this skeleton in order to > support e.g. dropping .sws or .sage files on it. This sounds like a great idea. I've always liked that in OS X if you drop a file on a program's icon, it does the obvious thing with it. I'm sure we can get somethign working. This is very nice work! I will install this on my Macbook as soon as I can. Dan -- --- Dan Drake - KAIST Department of Mathematical Sciences --- http://mathsci.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] pari vs. linbox for elementary_divisors
Almost two years ago, Linbox's implementation of Smith normal form was
taken out of Sage because it was too buggy. After some work, I managed
to reinstate it, hoping that the bugs might have been fixed. Here's a
partial status report:
1. I haven't tested it very broadly, but it seems to work on all of
the matrices that I feed it -- it agrees with Pari, anyway.
2. The Linbox implementation and the Pari implementation differ by a
transpose; that is, if you really want the two to agree on some matrix
m, you need to compare
m.elementary_divisors(algorithm='pari')
to
m.transpose().elementary_divisors(algorithm='linbox').
Actually, I just stuck the transpose into the elementary_divisors
function...
3. The timing is a bit odd. For a 105x455 sparse integer matrix m2,
this is what happened on my iMac with 2GB RAM:
sage: timeit('m2.dense_matrix().elementary_divisors
(algorithm="pari")')
5 loops, best of 3: 431 ms per loop
sage: timeit('m2.dense_matrix().elementary_divisors
(algorithm="linbox")')
5 loops, best of 3: 365 ms per loop
For a 719 x 1347 sparse integer matrix m6:
sage: timeit("m6.dense_matrix().elementary_divisors
(algorithm='pari')", number=1)
1 loops, best of 3: 23.9 s per loop
sage: timeit("m6.dense_matrix().elementary_divisors
(algorithm='linbox)", number=1)
1 loops, best of 3: 397 s per loop
One comment here: although the first timing says "23.9 s per loop", it
took about an hour for this to actually complete.
On sage.math, I got timings which are consistent with this (except
that here, the timings accurately reflect the wall time for the
command). Here, m7 is a 694 x1300 sparse integer matrix:
sage: timeit("m7.dense_matrix().elementary_divisors
(algorithm='pari')", number=1)
1 loops, best of 3: 14.7 s per loop
sage: timeit("m7.dense_matrix().elementary_divisors
(algorithm='linbox')", number=1)
1 loops, best of 3: 219 s per loop
So Linbox is faster for smaller matrices and Pari might be faster on
larger ones, depending on your computer. As far as I can tell, neither
has an implementation for sparse matrices which is accessible from
Sage. Does anyone know if Pari or Linbox have code explicitly for
Smith normal form for sparse matrices? It might be fun to see what
such code could do with these matrices...
Anyway, I'm not sure what conclusions to draw from this, except that I
should do my computations on sage.math :)
Finally, I was unable to do this successfully on the old ubuntu box in
my office: calling the linbox version of elementary_divisors on just a
2 x 3 matrix led to a RuntimeError. I have no idea how to fix this...
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
-~--~~~~--~~--~--~---
