Re: [sage-devel] Re: pynac-0.3.3
On Wed, 8 Apr 2015 05:55:27 -0700 (PDT) kcrisman kcris...@gmail.com wrote: since there seems no permanent maintainer of Pynac I propose to do the next release of Pynac. I have already transferred the source/history as planned to github at: https://github.com/rwst/pynac Ralf, this sounds like a fine idea. Burcin, I'm sure you have no objections? It's great that someone is willing to take over maintenance of pynac. I'd be happy to answer any questions that might come up (about the historical baggage at least). I had registered pynac as an organization on github a while ago. I just sent Ralf an invitation to be an admin. If you're thinking of switching altogether, it would be good to move the existing issues over from bitbucket and the web site repository. Write to me personally with an ssh public key to get access to the web site. One thing I would definitely make sure of is to try to update with the upstream Ginac source as possible. One reason I never took Pynac over is because I knew I wouldn't have time to sync with (useful) changes upstream, but I think in general we want to do that (also to report there, of course). Benjamin Hackl has also made a pull request there for the issue in #15846 and I'm planning to at least fix some infinity comparison issues that look easy to fix. So this is not a hostile but a pragmatic takeover. 8P :-) Oh, and I'm posting this here because my earlier posting to pynac-devel was not even moderated. Huh! The pending message list for pynac-devel is empty right now. I don't recall getting any notices about pending messages. I'll add Ralf as an admin to the group as well. Thanks a lot for working on pynac! Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercion of objects embedded in symbolic expressions
On Sun, 22 Feb 2015 03:17:13 -0800 (PST) Volker Braun vbraun.n...@gmail.com wrote: Just to tell you what you already know, the symbolic ring is the parent of last resort if there is nothing more specific. So its to be expected that you don't have any canonical maps elsewhere. Pynac should probably unwind the comparison of two wrapped (non-symbolic) python objects to the comparison of the underlying python objects. Haven't tried that, though. You have to be careful about infinite recursions, the comparison might again coerce into the symbolic ring. Pynac already calls the Python comparison function if both are pyobjects. In this case, infinity and constants are not pyobjects. They are a basic class as in mul, add, symbol, etc. Cheers, Burcin P.S. The infinity class was added to pynac by Volker. :) On Sunday, February 22, 2015 at 11:02:44 AM UTC+1, Ralf Stephan wrote: Hello, a long standing issue is sage: bool(piInfinity) False sage: bool(SR(3)Infinity) False http://trac.sagemath.org/ticket/12967 at which I'm having a naive stab (because it interferes with #14801). Maybe I can learn something? In the ticket the problem has been said having to do with Pynac, but I don't think so. It would all work nicely if, instead of the expression object, its underlying `pyobject` would be compared. But this does not happen because there is no coerce map from `SR` to `InfinityRing`. So, can we somehow have an indirect coercion map that uses not the parent but the parent of something a member function (like `pyobject`) returns? The problem of SR having no canonical map to anything in spite of some expressions being well behaved is the source of much frustration. Regards, -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Tracking Citations; How?
On Sat, 6 Sep 2014 11:52:33 -0700 (PDT) Bill Hart goodwillh...@googlemail.com wrote: On Saturday, 6 September 2014 20:34:56 UTC+2, Robert Bradshaw wrote: Note that Cython supports cProfile these days: http://docs.cython.org/src/tutorial/profiling_tutorial.html However, that won't help too much as the real missing pieces are the calls from Cython into the various C libraries. I'm also -1 to an approach that slows down all of Sage to track this unconditionally. I am also not comfortable with an approach that slows down the whole of Sage Let me clarify a few points: - the current (profiling) approach slows everything down when you turn it on. It simply turns on the profiler, which either logs _all_ function calls or periodically samples the running process and logs the active function in addition to loads of other data that is irrelevant for citations. - the (decorator) approach suggested in #3317 [1] notes which implementation is being used only at the point it is used. [1] http://trac.sagemath.org/ticket/3317 It would be simple to add a global switch to turn this logging on or off. We didn't think this was necessary because the overhead is incredibly small. See below for details. Since the profiling approach is so slow, it can only be used on toy examples which often use a completely different code path. I will copy from my comment in #16854 [2]: The profiling approach is broken for several reasons: - the code used for different problem sizes is often different. Profiling a small example will not give you the correct information. If you are really working on the cutting edge of what is computable, then you don't want to run the whole computation under the profiler once more. - you have to guess what is being used from the data obtained from the profiler. There is no clean way to associate citation information to functions this way. - it does not allow tracking more fine grained information than function names. If a Sage function wraps several algorithms by calling an external package with different arguments, you cannot differentiate these. [2] http://trac.sagemath.org/ticket/16854#comment:6 Decorators Speed: We spent a lot of effort on speeding up the implementation in #3317 and measuring the effect of adding citation information via decorators. IIRC, the only additional operation performed by the decorated function is to add a string to a Python set. Compared to the overhead of calling a function in Python, this is negligible. There are some benchmarks in this blog post [3]. The title may give the wrong idea, but the numbers are quite impressive. Note that we are not suggesting to decorate arithmetic operations like addition and multiplication, only calls to higher level routines, like groebner basis computation or symbolic integration. [3] http://sage-citation.blogspot.de/2011/08/awful-benchmarks.html Here are some numbers from the link above: - calling a pass-function (empty Python function): 10 loops, best of 3: 110 ns per loop - calling the above function after decorating: 10 loops, best of 3: 295 ns per loop - calling a pass-function, that takes some parameters: 10 loops, best of 3: 399 ns per loop - calling the above function after decorating: 10 loops, best of 3: 796 ns per loop This 200 ns difference would be a measuring error if the function in question did any real work. , just so people like me and my colleagues can get more credit. We suggest to cite not only libraries used by Sage but papers on the algorithms used. See the example in the ticket description here: http://trac.sagemath.org/ticket/3317 Especially when we are trying to speed Sage up. :-) I sincerely hope that you are not saying I am trying to slow Sage down. The decorator approach could be good for annotating functions (e.g. attaching them to some database the citations module would use) but recording every call could be prohibitively expensive. Let me emphasize again. We definitely do not want to recall every function call. The goal is to add annotations to functions that implement / wrap relatively expensive computational routines. In short, I vote +1 for decorators. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: cgal spkg?
Hi Marc, I'm copying sage-devel where more experienced people can help. On Wed, 27 Aug 2014 11:42:45 +0200 Marc Masdeu marc.mas...@gmail.com wrote: Dear Burcin, I saw you had made a spkg for the CGAL libraries. I would like to resuscitate this code and adapt it to CGAL 4.0 if possible. Do you have the spkg around and, if so, would you mind sharing it? That was a very long time ago. Since then, Sage has switched to a different build system where the package build scripts are hosted in the main repository. There are some instructions on the new system here: http://sagemath.org/doc/developer/packaging.html FWIW, I put the old spkg here temporarily: http://erocal.org/spkg/cgal-3.5.spkg Old system is described here: http://sagemath.org/doc/developer/packaging_old_spkgs.html Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] installing optional packages requires running sage -b
On Mon, 4 Aug 2014 06:57:20 -0700 William A Stein wst...@uw.edu wrote: snip This is absolutely not how Sage should behave. The fixes I can think of: (1) Run sage -b as part of installing any package that requires it for the install to finish. Your argument not to run sage -b isn't convincing, because the user is explicitly installing a package anyways, so they are potentially changing things all over Sage. Or, (2) Tell people they have to run sage -b clearly in the package install message. This won't work, because after 20 pages of build output, nobody is likely to read this. Or, (3) Instead of telling the user to reinstall the missing package (in minisat say), actually give a useful error message, instead of a totally wrong one. E.g., check to see if the minisat library is installed, but the cython module isn't built. I don't like this since it is fragile. So (1) is the best solution I can think of, and solves all cases of this problem for all packages that have it. There is one more option: (4) include the relevant python/cython code in the package, build and install it with the package. This thread is relevant, even though I misinterpreted the original question and dragged it in this direction: https://groups.google.com/d/topic/sage-devel/meBnEvuBang/discussion I would not be in favour of automatically running sage -b since you might want to install several packages but run sage -b only once, you might want to do something else like checking out some git branch (after which you need to do sage -b anyway) and it wouldn't work for standard packages as you said. I would also advice against doing sage -b while Sage is running, so the install_package() Sage command couldn't do it. +1. Running sage -b does not guarantee that the module will be built. Sage source tree might be in a broken state due to user modifications. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Lattices?
Hi Martin, On Thu, 13 Mar 2014 13:56:41 + Martin Albrecht martinralbre...@googlemail.com wrote: what happened to the Sage 2012 GSoC project on lattices described here: http://gsoc-sage-lattices.blogspot.co.uk/ It doesn't seem to have been merged (?) I could use it to give my discrete Gaussian sampler over lattices code a home. The code is here: https://github.com/poeschko/sage AFAICT, it would require a nontrivial amount of work to merge. It was based on Sage 5.2 IIRC. I don't know if there is a related ticket on trac. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: canonical review/upgrade procedure
On Wed, 12 Mar 2014 04:16:22 -0700 (PDT) Volker Braun vbraun.n...@gmail.com wrote: On Wednesday, March 12, 2014 11:52:06 AM UTC+1, Ralf Stephan wrote: Hello, I'm the annoying person digging up old tickets. Which is much appreciated! +1. Many thanks for finally getting all those symbolics tickets merged. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Google Summer of Code Projects - please advertise
Hi, this year Sage [1] and lmonade [2] are mentoring organizations for the Google Summer of Code [3] again. [1] http://www.google-melange.com/gsoc/org2/google/gsoc2014/sagemath [2] http://www.google-melange.com/gsoc/org2/google/gsoc2014/lmonade [3] http://www.google-melange.com/gsoc/homepage/google/gsoc2014 We have many exciting projects for students to work (from home) over the summer, get mentored by experts in the field and get paid by Google. Sage projects: https://docs.google.com/document/d/15v7lXZR1U4H2pT21d2fyPduYGb74JAFjkXJ6CWYmYfw/pub lmonade projects: http://wiki.lmona.de/get_involved/projects The application deadline for students is March 21st. These days they should be talking to potential mentors and forming an applications. If you know any student who might be interested or have access to any forum such students might read, please forward this announcement. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] GSoC projects
Hi, the application period for the Google Summer of Code starts next week. If we want to apply, we should have a project ideas list ready for review by Google by February 14th. Here is last year's list: https://docs.google.com/document/d/1ipzvwbhfujaubDe0QVO-V9JmmRcLZvitaeXh4r2WNqA/pub Harald agreed to handle the application again this year. If there is interest we should copy that document and start updating the project descriptions. I could suggest some projects on symbolics and pynac, but we need more mentors for an application. Anybody willing to mentor GSoC projects? Any project ideas? For reference, this is page from the Python Software Foundation good summary of the expectations from mentors and students: https://wiki.python.org/moin/SummerOfCode/Expectations Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] QQ multivariate factorization, new(?) errors
Hi Jori, On Mon, 7 Oct 2013 13:29:45 +0300 (EEST) Jori Mantysalo jori.mantys...@uta.fi wrote: I just make a small test: P.a,b,c,d=QQ[] for i in range(1,10): p1=ZZ.random_element(1,5)*P.random_element() p2=ZZ.random_element(1,5)*P.random_element() p3=ZZ.random_element(1,5)*P.random_element() p=p1*p2*p3 if p==0: continue print p f=p.factor() tulo=f.unit()*prod([f[i][0]^f[i][1] for i in range(0,len(f))]) if (p-tulo) 0: print Error! I got few floating point exceptions, but they seems to be already reported: http://trac.sagemath.org/ticket/14658 However, I also found one new error: 16*a^3*b*c^2 - 144*a^2*b*c^3 + 112*a^2*b*c^2*d - 1008*a*b*c^3*d + 16*a^2*b*c*d^2 - 16*a^2*c^2*d^2 - 624*a*b*c^2*d^2 + 4320*b*c^3*d^2 - 48*a*b*c*d^3 - 112*a*c^2*d^3 + 432*b*c^2*d^3 - 16*a*c*d^4 + 480*c^2*d^4 + 48*c*d^5 + 16*a^3*b*c - 48*a^2*b^2*c + 16*a^3*c^2 - 144*a^2*b*c^2 + 432*a*b^2*c^2 + 16*a^2*c^3 + 160*a^2*b*c*d - 272*a*b^2*c*d + 112*a^2*c^2*d - 1440*a*b*c^2*d + 2448*b^2*c^2*d + 112*a*c^3*d + 16*a^2*b*d^2 - 32*a*b^2*d^2 - 96*a*b*c*d^2 + 288*b^2*c*d^2 - 464*a*c^2*d^2 - 480*c^3*d^2 - 208*a*c*d^3 + 272*b*c*d^3 - 48*c^2*d^3 - 16*a*d^4 + 32*b*d^4 - 16*a^2*b^2 + 32*a*b^3 + 16*a^3*c - 48*a^2*b*c + 144*a*b^2*c - 288*b^3*c + 16*a^2*c^2 - 48*a*b*c^2 + 160*a^2*c*d - 272*a*b*c*d + 160*a*c^2*d - 272*b*c^2*d + 16*a^2*d^2 - 16*a*b*d^2 - 32*b^2*d^2 + 16*a*c*d^2 - 32*b*c*d^2 - 16*a^2*b + 32*a*b^2 - 16*a*b*c + 32*b^2*c gives RuntimeError: Segmentation fault. Should I report this as new bug or as a comment to ticket 14658? I tried to run this on loop and see how often errors happen. But then I got *** Error in `python': free(): invalid pointer: 0x03b22330 *** === Backtrace: = /lib64/libc.so.6[0x332ba7d0e8] /home/jm58660/sage-5.11/local/lib64/libstdc++.so.6(_ZdlPv+0x1f)[0x7f648d3aeebc] /home/jm58660/sage-5.11/local/lib64/libstdc++.so.6(_ZdaPv+0x18)[0x7f648d3aeef4] /home/jm58660/sage-5.11/local/lib/libsingular.so(_Z15sparseHeuristicRK13CanonicalFormRK4ListIS_ERPS3_S5_i+0x2d96)[0x7f64736d3096] /home/jm58660/sage-5.11/local/lib/libsingular.so(_Z14multiFactorizeRK13CanonicalFormRK8Variable+0x2590)[0x7f647364f3e0] /home/jm58660/sage-5.11/local/lib/libsingular.so(_Z12ratFactorizeRK13CanonicalFormRK8Variableb+0x256)[0x7f64735e6c06] /home/jm58660/sage-5.11/local/lib/libsingular.so(_Z9factorizeRK13CanonicalFormb+0xf23)[0x7f64735e5373] /home/jm58660/sage-5.11/local/lib/libsingular.so(_Z18singclap_factorizeP8spolyrecPP6intveci+0x643)[0x7f647345e413] /home/jm58660/sage-5.11/local/lib/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so(+0x24d9a)[0x7f6473c4cd9a] /home/jm58660/sage-5.11/local/lib/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so(+0x270e3)[0x7f6473c4f0e3] . . . Odds of getting errors are about 1 againsta 89. Can you check if these problems are still there with the Singular spkg posted on #14333? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: The results of some integration test.
On Mon, 16 Sep 2013 00:59:51 -0700 (PDT) Fredrik Johansson fredrik.johans...@gmail.com wrote: Curious that no one seems to have attempted to port Rubi to Sage yet! Perhaps a possible project for next year's GSoC? This might be an interesting exercise to test our symbolics and pattern matching capabilities. Looking for a license, I only see the following statement on the Rubi web pages [1]. The mathematical knowledge on this website is freely available for any educational, academic or commercial use. Please include the website address and appropriately acknowledge its author in any product incorporating its contents. [1] http://www.apmaths.uwo.ca/~arich/ I guess this means we can use the MMA notebook files as a basis. Is anyone interested in trying to convert these rules to Sage syntax and find / document shortcomings of our pattern matching engine in the mean time? Cheers, Burcin P.S. For the record, I don't think this is the silver bullet for an integration engine in Sage. I like algorithmic approaches better. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Answers to queries about flooved.com, and some questions as well...
On Tue, 03 Sep 2013 11:31:43 -0500 Jason Grout jason-s...@creativetrax.com wrote: On 9/3/13 11:26 AM, Jason Grout wrote: And a collaborative annotation system for books is certainly something interesting to see. *Especially* if there is an easy way to export the annotations out of the system. I'm not very much a fan of systems where comments and other interesting content is locked into a proprietary layer above the free stuff. Talking about open standards and annotations, you might find this interesting: http://hypothes.is/ Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] default component owners on trac
Hi, is there a way to see the default owners assigned to trac components? I just noticed that I am not assigned to new symbolics tickets any more. I can't decide yet if that's good or bad yet. Was there a reason behind this change? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] spkg statistics
On Fri, 05 Jul 2013 15:23:51 +0200 Hikari Boulders hikari.bould...@gmail.com wrote: about 4ti2: is there some master-plan to make sage more modular or smaller? Unfortunately, no. lmonade takes a step in this direction by making the package system more flexible: http://www.lmona.de In the near future, I will make some standard components of Sage optional in lmonade, much like William's initial effort with the psage distribution. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: _cleanup method in DifferentialForms class
On Thu, 4 Jul 2013 04:49:16 -0700 (PDT)
vdelecroix 20100.delecr...@gmail.com wrote:
If the differential forms are somewhat immutable we may also save the
result of is_zero once for all. Why do not make is_zero a
cached_method of symbolic expressions ?
Do you mean wrapping sage.symbolic.expression.Expression.is_zero() with
the cached_method decorator?
Symbolic expressions are not really immutable. It is possible to
declare new assumptions (with the assume() function), change properties
of the variables (with var('x', domain=RR)) and change the result of
is_zero(). Caching results of calls to Maxima is not an option.
On the other hand, improving the implementations of __nonzero__() and
test_relation() method in sage.symbolic.expression.Expression is
definitely possible.
Cheers,
Burcin
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Sqrt simplification
On Sun, 30 Jun 2013 13:23:50 -0700 (PDT)
Eric Gourgoulhon egourgoul...@gmail.com wrote:
Meanwhile, I've written the following workaround in python:
basically, it scans all the sqrt's in a given symbolic expression,
send them to radcan, takes the absolute value of the output and then
calls simplify(). It is not optimal but it works:
sage: assume(x0)
sage: simplify_sqrt_real( sqrt(x^2) )
-x
sage: simplify_sqrt_real( sqrt(x^2-2*x+1) )
-x + 1
sage: simplify_sqrt_real( sqrt(x^2) + sqrt(x^2-2*x+1) )
-2*x + 1
Here is the source code:
def simplify_sqrt_real(expr):
r
Simplify sqrt in symbolic expressions in the real domain.
EXAMPLES:
Simplifications of basic expressions::
sage: assume(x0)
sage: simplify_sqrt_real( sqrt(x^2) )
-x
sage: simplify_sqrt_real( sqrt(x^2-2*x+1) )
-x + 1
sage: simplify_sqrt_real( sqrt(x^2) + sqrt(x^2-2*x+1) )
-2*x + 1
from sage.symbolic.ring import SR
from sage.calculus.calculus import maxima
# 1/ Search for the sqrt's in expr
sexpr = str(expr)
if 'sqrt(' not in sexpr: # no sqrt to simplify
return expr
pos_sqrts = [] # positions of the sqrt's in sexpr
the_sqrts = [] # the sqrt sub-expressions in sexpr
for pos in range(len(sexpr)):
if sexpr[pos:pos+5] == 'sqrt(':
pos_sqrts.append(pos)
parenth = 1
scan = pos+5
while parenth != 0:
if sexpr[scan] == '(': parenth += 1
if sexpr[scan] == ')': parenth -= 1
scan += 1
the_sqrts.append( sexpr[pos:scan] )
Instead of going through strings, you might want to try pattern
matching:
sage: t = sin(x)*sqrt(x^2)*e^(sqrt(x+1))
sage: w = SR.wild()
sage: t.find(w^(1/2))
[sqrt(x + 1), sqrt(x^2)]
Note that this won't catch sqrt() in the denominator. You will need to
specify a negative exponent for that:
sage: u = 1/sqrt(x+1)
sage: u.find(w^(-1/2))
[1/sqrt(x + 1)]
# 2/ Simplifications of the sqrt's
new_expr = # will contain the result
pos0 = 0
for i, pos in enumerate(pos_sqrts):
# radcan is called on each sqrt:
x = SR(the_sqrts[i])
simpl = SR(x._maxima_().radcan())
This is x.maxima_methods().radcan().
# the absolute value of radcan's output is taken, the call to
simplify()
# taking into account possible assumptions regarding the sign
of simpl:
new_expr += sexpr[pos0:pos] + '(' +
str(abs(simpl).simplify()) + ')' pos0 = pos + len(the_sqrts[i])
new_expr += sexpr[pos0:]
return SR(new_expr)
Putting the new values back can be done with subs().
sage: t
sqrt(x^2)*e^(sqrt(x + 1))*sin(x)
sage: t.subs({sqrt(x^2): x})
x*e^(sqrt(x + 1))*sin(x)
Cheers,
Burcin
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Jenks Prize
On Sat, 29 Jun 2013 09:48:55 -0700 William Stein wst...@gmail.com wrote: According to Victor Miller [1], Sage one the Jenks Prize [2] last night. Congrats to us Sage developers! [1] https://plus.google.com/112503503275509870006/posts [2] http://www.sigsam.org/awards/jenks/awardees/ Congratulations! Was there anyone from the team at ISSAC this year to receive the prize? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: _cleanup method in DifferentialForms class
On Thu, 27 Jun 2013 07:42:14 -0700 (PDT) Timo Kluck tkl...@gmail.com wrote: I think most time is spend in the is_zero() method for a symbolic expression, and that the reassignments you refer to are largely irrelevant. The thing is that it can cost a lot of time to decide whether, for example sin(x)cos(x) - sin(2x)/2 is equal to zero, because there is so many things to try (in this case goniometric identities). Symbolic expressions have a .is_trivial_zero() method which is more suitable for use here. It doesn't try anything advanced so it has predictable runtime. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] OT: SWMATH
Hi, here is an official announcement for the swMATH project. Cheers, Burcin Begin forwarded message: Date: Mon, 17 Jun 2013 17:00:29 +0200 From: Gert-Martin Greuel gre...@mathematik.uni-kl.de Subject: swMATH Dear all, I would like you to inform you about a new service on mathematical software, www.swmath.org The database contains information on more than 5,000 software packages and literature, citing the software. More information is attached. It would be nice if many of you would check swMATH and provide feedback. For example, by answering the questions in the (rather short) questionnaire: https://de.surveymonkey.com/s/swMATH-survey Best regards, Gert-Martin Greuel --- What is swMATH? swMATH is a freely accessible, innovative information service for mathematical software. swMATH not only provides access to an extensive database of information on mathematical software, but also includes a systematic linking of software packages with relevant mathematical publications. The intention is to offer a list of all publications that refer to a software recorded in swMATH. In particular, all articles are given, which are included in Zentralblatt MATH (zbMATH). It can be both, articles that describe the background and technical details of a program, as well as those publications in which a piece of software is applied or used for research. In this way, swMATH provides information on actual use of the software that is otherwise impossible or very difficult to obtain. At the same time the documentation of literature referring to a software is a valuable source of information for the authors of the software about where their software is used. Moreover, if software is cited in scientific publications, this is also an important quality criterion, which is used by swMATH for software selection. swMATH sees itself as a service to the mathematical community. Additions, corrections and other notes from authors and users of mathematical software can be communicated under 'Feedback' and are very welcome. Project Information swMATH is a project of the Mathematical Research Institute Oberwolfach (MFO) and FIZ Karlsruhe (FIZ), funded by the Leibniz Association 2011-2013. Project leader: Gert-Martin Greuel (MFO); Wolfram Sperber (FIZ) Concept, programming, design: Michael Brickenstein, Christoph Knoth (MFO); Sebastian Bönisch, Hagen Chrapary (FIZ) -- Gert-Martin Greuel Professor, Department of Mathematics Head, Centre for Computer Algebra University of Kaiserslautern D-67653 Kaiserslautern, P.O.Box 3049, Germany e-mail: gre...@mathematik.uni-kl.de phone: +49 631-205-2850 (office) -3141 (Secretary Mrs. Baesell) fax:+49 631-205-4795 (Secretary) internet: www.mathematik.uni-kl.de/~greuel/en Editor-in-Chief, Zentralblatt MATH gre...@zentralblatt-math.org www.zentralblatt-math.org/zbmath Mathematisches Forschungsinstitut Oberwolfach gre...@mfo.de www.imaginary.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] OT: SWMATH
On Mon, 17 Jun 2013 20:49:16 +0100 John Cremona john.crem...@gmail.com wrote: I think someone ought to correct their page on Sage which says Authors: William Stein; David Joyner; David Kohel; John Cremona; Eröcal, Burçin but it is hard to know what to replace that list other than cast of thousands! Wow! I suppose I should have looked at it a bit before sending the announcement. Disclaimer: Even though my name appears on that list (with correct Turkish characters and all), I had nothing to do with the Sage entry on swmath. I guess giving a link to the developer map on sagemath.org would be a better solution: http://www.sagemath.org/development-map.html Any other ideas?? On another note, it is annoying that the swmath site doesn't let me submit corrections to the entry without filling out a form with all kinds of other information. http://www.swmath.org/contribute Cheers, Burcin On 17 June 2013 19:59, Burcin Erocal bur...@erocal.org wrote: Hi, here is an official announcement for the swMATH project. Cheers, Burcin Begin forwarded message: Date: Mon, 17 Jun 2013 17:00:29 +0200 From: Gert-Martin Greuel gre...@mathematik.uni-kl.de Subject: swMATH Dear all, I would like you to inform you about a new service on mathematical software, www.swmath.org The database contains information on more than 5,000 software packages and literature, citing the software. More information is attached. It would be nice if many of you would check swMATH and provide feedback. For example, by answering the questions in the (rather short) questionnaire: https://de.surveymonkey.com/s/swMATH-survey Best regards, Gert-Martin Greuel --- What is swMATH? swMATH is a freely accessible, innovative information service for mathematical software. swMATH not only provides access to an extensive database of information on mathematical software, but also includes a systematic linking of software packages with relevant mathematical publications. The intention is to offer a list of all publications that refer to a software recorded in swMATH. In particular, all articles are given, which are included in Zentralblatt MATH (zbMATH). It can be both, articles that describe the background and technical details of a program, as well as those publications in which a piece of software is applied or used for research. In this way, swMATH provides information on actual use of the software that is otherwise impossible or very difficult to obtain. At the same time the documentation of literature referring to a software is a valuable source of information for the authors of the software about where their software is used. Moreover, if software is cited in scientific publications, this is also an important quality criterion, which is used by swMATH for software selection. swMATH sees itself as a service to the mathematical community. Additions, corrections and other notes from authors and users of mathematical software can be communicated under 'Feedback' and are very welcome. Project Information swMATH is a project of the Mathematical Research Institute Oberwolfach (MFO) and FIZ Karlsruhe (FIZ), funded by the Leibniz Association 2011-2013. Project leader: Gert-Martin Greuel (MFO); Wolfram Sperber (FIZ) Concept, programming, design: Michael Brickenstein, Christoph Knoth (MFO); Sebastian Bönisch, Hagen Chrapary (FIZ) -- Gert-Martin Greuel Professor, Department of Mathematics Head, Centre for Computer Algebra University of Kaiserslautern D-67653 Kaiserslautern, P.O.Box 3049, Germany e-mail: gre...@mathematik.uni-kl.de phone: +49 631-205-2850 (office) -3141 (Secretary Mrs. Baesell) fax:+49 631-205-4795 (Secretary) internet: www.mathematik.uni-kl.de/~greuel/en Editor-in-Chief, Zentralblatt MATH gre...@zentralblatt-math.org www.zentralblatt-math.org/zbmath Mathematisches Forschungsinstitut Oberwolfach gre...@mfo.de www.imaginary.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] OT: SWMATH
Hi Michael, On Mon, 29 Apr 2013 03:56:51 -0700 (PDT) Michael Brickenstein brickenst...@mfo.de wrote: Yes, and it even includes Sage ;-). Well, at the moment it's at position 8 in total number of citations which is not bad, considering it's age. How do you see this on the current swmath.org site? I couldn't manage to get a list of software by citation count. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: 3 GSoC projects for Sage
I am going to respond to the comments below, since they come from a senior member of the symbolic computation community. I would have appreciated them a lot more if they were better informed, at least by reading the original project proposal also posted on this list [1], and intended as constructive criticism instead of just trolling. [1] https://groups.google.com/forum/#!topic/sage-devel/00_Is5q_0IY On Wed, 29 May 2013 15:08:02 -0700 (PDT) rjf fate...@gmail.com wrote: On Tuesday, May 28, 2013 5:46:13 AM UTC-7, Harald Schilly wrote: Mathematical Functions Library Eviatar Bach http://www.phas.ubc.ca/%7Eeviatarb/ – University of British Columbia in Vancouver, Canada (Mentor: Flavia Stan, Backup: Burcin Erocal) Sage interfaces with multiple third-party libraries, such as MPFR, GSL, GP/PARI, mpmath, and Maxima, for numerical evaluation of special functions. There are significant discrepancies between these backends in the performance for numerical approximations of the same expression. An initial benchmark reveals, for example, that calculating spherical_bessel_J(1, 5.2) with SciPy is over 100 times faster than with Maxima. The project has the following goals: 1. develop a benchmark framework to determine which backend should be used by default to evaluate a special function over a specific domain, This sounds like a really bad idea for 2 reasons. 1. none of the backends are stationary. If someone comes up with a spherical_bessel evaluator that is 100X faster yet again than SciPy, but is in Maxima, you are losing. The point of the benchmark framework is to be able to repeat the measurements when the backends change, on different platforms, etc. See explanation of item 2 from [1]. 2. To determine over an arbitrary span of floats which program is most accurate and fastest requires a fairly sophisticated set of tests. For example even a function like sine can be delicate to evaluate, say at a high integer multiple of pi. And how do the functions respond at singularities? Just generating random arguments is not sensible. Again, see explanation of item 2 from [1]. Oh, for some programs you may need to figure out what to do with unbounded inputs (integers, bigfloats). How is this related? We already have interfaces to the packages mentioned above to handle conversion issues. 1. 2. create symbolic wrappers for all the special functions that can be evaluated numerically by a package included in Sage, Um, I'm not sure what is required here, but maybe just bookkeeping?? Yes, these are simple wrappers in Sage. Somebody needs to write them. 1. 2. create a data structure for generalized hypergeometric functions and extend the symbolic wrappers to obtain representations in terms of generalized hypergeometric functions when possible, huh? Wouldn't it always be possible to express generalized hypergeometric functions as generalized hypergeometric functions? For example, we want the software to convert bessel_j(2,x) to 1/8*x^2*hypergeometric_pfq(0, 1, 3, -1/4*x^2). If you mean to simplify them, whose algorithm are you going to use? Or did you not know about such things? The goal is to provide a basis to implement algorithms used in DDMF [2]. [2] http://ddmf.msr-inria.inria.fr/ 1. 2. implement closure properties for holonomic functions as a next step to improve the symbolic processing of special functions in Sage. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: git integration repository, please test
On Thu, 17 Jan 2013 07:17:43 + (UTC)
Dima Pasechnik dimp...@gmail.com wrote:
On 2013-01-17, Robert Bradshaw rober...@gmail.com wrote:
On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik dimp...@gmail.com
wrote:
On 2013-01-16, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_588_6290856.1358340327889
Content-Type: text/plain; charset=ISO-8859-1
I guess there are at least two different meanings of the Sage
tarball in this context. I was talking about the sum of all code
checked into the Sage repositories, which is what one would
usually call the release. And the third party code is not going
to be part of the git repo under the current proposal.
I don't see how this would be an improvement as far as 3rd party
code spkgs maintainance/updating is concerned. Are you saying it
stays under the same ugly patchquilt model?
Or everyone rolls his/her own spkg repos on bitbucket or github or
whatever (as you do for libGAP)?
Mind you, when I worked on the latest Maxima update (#13364), I
had to do git bisect on *Maxima* repo to debug *Sage*, and then
apply the results of this investigation to stripped of .git/
Maxima source tree, for which I did not have an exact mapping back
to Maxima repo. It goes without saying that this is rather ad hoc,
error-prone, etc etc. And then, when Sage patches (which are often
experimental upstream's patches) for the spkg are merged upstream,
a similar error-prone manual labour toil, sweat, and tears will be
needed...
Expanding on http://wiki.sagemath.org/WorkflowSEP one would have
sage_root/
sage # the binary
Makefile # top level Makefile
(configure) # perhaps, eventually
... # other standard top level files (README, etc.)
build/
core/ # sage's build system/bootstrapping
pkgs/ # install, patch, and metadata from spkgs
maxima/
pacakge_manager_file # emerge or whatever, would
point to some upstream source, patch1.diff, etc.
patch1.diff
...
...
A single commit would remove create patch1.diff and modify
pacakge_manager_file to use it, when patch1.diff is merged upstream,
we would do another commit to point pacakge_manager_file to the
newer upstream and remove patch1.diff. Here upstream is ideally an
upstream-provided src tarball (though we might distribute it
ourselves) and relating that to whatever revision control system
they use is out of scope.
This still looks like an ugly hack. Shouldn't we rather use
something like [git-subtree]
(https://github.com/apenwarr/git-subtree/) to deal with upstream
source?
git-sub{tree,module} is too much. As long as there is an easy way to
get at the source and work with it, there is no reason to import the
source code from other projects into our repository . Note that I am
even trying to keep the packaging stuff out.
lmonade can check out the upstream sources and compile it for you under
devel/package_name. This gives easy access to upstream sources for
debugging, encourages people to submit patches/pull requests and ask
for reviews from upstream developers.
Once you have an improvement, you can either export it as a patch and
add it to the package Sage depends on, or if it is complex enough,
create your fork on bitbucket, github, etc., point the live ebuild
there and make Sage depend on that.
Here what you need to do on lmonade to get a development setup for
pynac:
cd local/etc/portage
echo sci-libs/pynac devel.env package.env
echo =sci-libs/pynac- ** package.accept_keywords
emerge pynac
This will be scripted at some point.
Cheers,
Burcin
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
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.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: git integration repository, please test
On Thu, 17 Jan 2013 11:31:41 + (UTC)
Dima Pasechnik dimp...@gmail.com wrote:
On 2013-01-17, Burcin Erocal bur...@erocal.org wrote:
On Thu, 17 Jan 2013 07:17:43 + (UTC)
Dima Pasechnik dimp...@gmail.com wrote:
[...]
This still looks like an ugly hack. Shouldn't we rather use
something like [git-subtree]
(https://github.com/apenwarr/git-subtree/) to deal with upstream
source?
git-sub{tree,module} is too much. As long as there is an easy way to
get at the source and work with it, there is no reason to import the
source code from other projects into our repository . Note that I am
even trying to keep the packaging stuff out.
I gave above a good reason (debugging a Maxima spkg within Sage), I
think.
Were you debugging Maxima or the Maxima spkg? I presume the bug fix
produced in the end is intended to be included in Maxima. In that
case, why not develop Maxima proper instead of just looking at it only
as a component of Sage?
Even more to the point would be spkgs which are more or less a
part of Sage, such as libGAP.
Note that libGAP spkg at the moment ships a large chunk of patched GAP
spkg. So basically one has 3 source trees to coordinate, manually,
two of them overlapping quite abit, if
git-sub* is not used.
(And also, actually, GAP spkg has nontrivial spkg dependencies.)
Another example is eclib, which (probably) most users use from Sage.
Indeed, there are spkgs that seldom get really worked on, such as gcc
or python, but it does not mean that the rest should be locked into
the same inconvenient model.
lmonade can check out the upstream sources and compile it for you
under devel/package_name. This gives easy access to upstream
sources for debugging, encourages people to submit patches/pull
requests and ask for reviews from upstream developers.
Once you have an improvement, you can either export it as a patch
and add it to the package Sage depends on, or if it is complex
enough, create your fork on bitbucket, github, etc., point the live
ebuild there and make Sage depend on that.
And how do you coordinate this with the eventual changes in the Sage
lib proper? By trac comments? SPKG.txt?
Mark that the Sage package depends on version = foo. Where version
does not have to correspond to an upstream release. It might have a
revision tagged on that indicates your fix.
For example, Sage depends on lcalc built with pari and the patches
specified in the ebuild:
https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/sage-5.5-r4.ebuild#L28
See the line =sci-mathematics/lcalc-1.23-r4[pari]
Here is the lcalc ebuild:
https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/lcalc/lcalc-1.23-r4.ebuild
Why not use git-sub* for this?
This is what looks the most bothersome point to me.
This bothersome process is how the free software ecosystem works. If
you benefit from the source some people bothered to put out there,
then spot some errors and fix them, you should also take some trouble
to share these with others, not only with users of Sage.
Cheers,
Burcin
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
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.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: git integration repository, please test
On Wed, 16 Jan 2013 01:49:22 -0800 (PST) Timo Kluck tkl...@gmail.com wrote: Op woensdag 16 januari 2013 04:17:48 UTC+1 schreef Michael Orlitzky het volgende: Gentoo: emerge sage Fedora: yum install sage Debian: apt-get install sage Ubuntu: apt-get install sage Mac: port install sage FreeBSD: pkg install subversion ... And then it would be nice if we'd distribute two tarballs for downstream to package, the one depending on the other: sage (or sagemath) which is the command line interface and the notebook, and something like python-sage (in the Debian naming convention) which is just the python library. +1 It would be better to keep the ipython interface separate from the notebook. The ipython interface is very lightweight once the Sage library is available. The notebook depends on a lot of web development packages. In this case, perhaps the ipython interface should be bundled in the Sage library. It is small enough to justify being an option on the Sage library. In Gentoo speak, this would be controlled by a USE Flag [1]. [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html Let me restate my suggestion in response to Andrew's post. I suggest including sage-doctest and sage-ipython scripts in the Sage library. Instead merging all the repositories together. Here is the full argument: https://groups.google.com/d/msg/sage-devel/z4jPFf_vlRY/L5xBd__j0FYJ Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: git integration repository, please test
On Wed, 16 Jan 2013 08:43:15 +0100 Julien Puydt julien.pu...@laposte.net wrote: Le 15/01/2013 23:28, Volker Braun a écrit : The specialist mathematical libraries, by contrast, don't get much exposure. And even if somebody packaged them then generally in useless form. E.g. Fedora ships symmetrica, but its useless since it is not compiled with -DFAST. Which nobody knows what it does except that, otherwise, you'll get segfaults. So for all practical purposes we have to build private versions of some libraries. And since they haven't been written by software engineers the individual build systems are generally a mess, so you can mostly forget about configure/make/make install. So essentially we'll have to use the current system of shell scripts to build the beast, there often isn't much logic that can be shared between them. (1) Any patch to upstream should be forwarded upstream. (2) If upstream doesn't have a good build system, provide one, and don't forget (1). I agree with Julien. The symmetrica example shows that everyone can benefit from the testing and packaging work done by the Sage team. I don't see how treating mathematical software as second class can be justified because most of it does not have a proper build system. We benefit from the code released by the author, we should at least contribute our fixes back and publicize them instead of maintaining our own copy. Take eclib as an example. IIRC, it was John Cremona's private code until William convinced him to release the code under GPL, and included it in Sage. In time it got progressively better, for example an autotools based build system and using FLINT for some functionality (only in a development release I suppose). These improvements are available for anyone else to use. If eclib was just imported to the Sage sources, I doubt if it would become such a successful independent library. Singular has quite a few examples of these too. Omalloc, the memory manager, and factory, multivariate polynomial factorization library, were both written independently. They were imported into the Singular sources. Over time, the boundary between these got blurred. Now the Singular team is spending considerable effort trying to refactor the code to expose these as separate units. On Tue, 15 Jan 2013 14:51:57 -0800 Robert Bradshaw rober...@gmail.com wrote: Do we really need to coordinate these? Why is Sage any different from any other large software package out there? The standard solution to this problem is to add a configure script to the library which checks if the dependencies are satisfied and sets various options for the compilation process accordingly. For better or for worse, Sage couples very tightly with (and even patches) its dependencies, and while moving away from this is a noble goal I don't foresee it happening any time soon (at least I don't want to postpone our development model until we get there). Eventually the dependencies could be see if X is on the system rather than install this (s)pkg on a package by package basis. How does moving to proper DVCS based development relate to merging the repositories? How many tickets on trac touch more than one repository? What is the disadvantage of adding see if X is on the system type checks in the Sage library right now? The initial design of Sage separated the mathematics library from the distribution system, then further separated the user interface (notebook) from the mathematics library. Why are we now trying to reconcile a bunch of shell scripts with a Python/Cython library for mathematics? Because drawing (really, creating and then enforcing) a line between them is hard (it's certainly not in the right place now), and I don't see either one taking a life of its own without the other. Also, maintaining and developing on N repositories is much more painful for any value of N 1. Sage's build system almost took life of its own in the past. Ondrej used it for FEMHub for instance. There are quite a few projects for packaging scientific software these days. So life is clearly possible in this area. Merging everything in one repository would just make the distinctions disappear over time. Making these distinctions clear is better software practice. It would make maintenance easier over time. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: git integration repository, please test
On Tue, 15 Jan 2013 10:27:38 -0500 Jordi Gutiérrez Hermoso jord...@octave.org wrote: Actually, I don't see what ditching hg has anything to do with the real meat of the actual problem, fixing the build system. +1000 I don't recall the design of the new development model, directory structure or build system being discussed anywhere public. From references on the mailing lists, I understand that there were discussions during various Sage days. But shouldn't there be a thread on sage-devel where people can give feedback before we go through with these changes? Keshav, Jordi and many others have pointed these out before, but our main problem seems to be: - we are not really using a DVCS - the build system is showing its limits due to the rapid growth of Sage I don't think switching to GIT will solve either of these problems directly. Why don't we discuss the solutions to these problems separately and put them into action? - Development model: I like the idea of keeping a branch for each issue on Trac. I have even suggested using mercurial's pbrach extension for this purpose privately to William about 2 years ago. With a student, I even set up a patched roundup install with this feature. I can enable it on the lmonade issue tracker if anybody is interested in testing this out. Though I believe using gitlab and not reinventing the wheel is far better. - Build system This actually has two items: - integrating the repositories Why? AFAICT, the only reason is to allow us to specify the dependencies of the Sage library better. ATM, when a patch goes into Sage, the corresponding patch to update the spkg is in a separate repository. Putting these together would help coordinate the two. Do we really need to coordinate these? Why is Sage any different from any other large software package out there? The standard solution to this problem is to add a configure script to the library which checks if the dependencies are satisfied and sets various options for the compilation process accordingly. The initial design of Sage separated the mathematics library from the distribution system, then further separated the user interface (notebook) from the mathematics library. Why are we now trying to reconcile a bunch of shell scripts with a Python/Cython library for mathematics? - rewriting the build system I agree that things can be done much better, but I don't understand why there is talk of rewriting. There are plenty of excellent package managers around. Why not just use one of them? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: git integration repository, please test
On Tue, 15 Jan 2013 08:32:29 -0800 (PST) Timo Kluck tkl...@gmail.com wrote: Op dinsdag 15 januari 2013 17:01:09 UTC+1 schreef Burcin Erocal het volgende: Why don't we discuss the solutions to these problems separately and put them into action? - Development model: I like the idea of keeping a branch for each issue on Trac. With a student, I even set up a patched roundup install with this feature. I can enable it on the lmonade issue tracker if anybody is interested in testing this out. Though I believe using gitlab and not reinventing the wheel is far better. You may have seen that I set up a testing server for gitlab with a couple of branches imported into git from trac. (see http://vps805.directvps.nl) Unfortunately, the issue management in Gitlab is rather primitive and they don't really want to make that any better. From my perspective, the most viable option is to keep on using trac, and set up a Gitlab server specifically for managing access to the git repository and for discussing pull requests. I'm not sure what advantages a Gitlab server will have over just using Github in that case, though. I didn't try your gitlab setup. I only know about it from reading the sage-git@ list. If git does not come with a killer-app to solve the development model problem, I don't see the motivation to switch to git. AFAIK, we don't want to use github. If we are going to write a trac plugin to manage a branch per ticket, or something similar, this can also be written for a mercurial backend. Karl-Dieter pointed this out before, but let's reiterate: Switching to git will mean rewriting all hg_* functionality and the developer guide, as well as retraining many existing user/developers. - Build system This actually has two items: - integrating the repositories Why? AFAICT, the only reason is to allow us to specify the dependencies of the Sage library better. ATM, when a patch goes into Sage, the corresponding patch to update the spkg is in a separate repository. Putting these together would help coordinate the two. Do we really need to coordinate these? Why is Sage any different from any other large software package out there? The standard solution to this problem is to add a configure script to the library which checks if the dependencies are satisfied and sets various options for the compilation process accordingly. The initial design of Sage separated the mathematics library from the distribution system, then further separated the user interface (notebook) from the mathematics library. Why are we now trying to reconcile a bunch of shell scripts with a Python/Cython library for mathematics? I think the main reason is that Sage currently tries to be both a package manager and a mathematics library. I guess in a way, it would make sense to have 2 repositories: * the sage library * the package manager The 4 that we have now is too much, though. Yep, ATM there are too many repositories. I find this amusing: sage: hg_ hg_extcode hg_root hg_sage hg_sagenb hg_scripts Life was easier in the early days, when there were only two repositories that mattered, Sage library and scripts. Thinking about it, even then there were a lot of confusions. But it is pretty clear that the package manager will depend so much on the sage library I don't see why. Do you need computational algebra to compute dependency trees and drive a couple of shell scripts? ATM, the scripts in spkg/ don't rely on the library at all. The package database and the versions may depend on changes in the Sage library. This information might as well be included in the library, through a configure script, or a recipe file for a package manager, like a gentoo ebuild, nix expression, etc. But I think it would be nice for the two parts to be at least separable enough that it is possible to release a tarball for just the sage library. +1 This would also simplify lives of people packaging Sage for distributions. - rewriting the build system I agree that things can be done much better, but I don't understand why there is talk of rewriting. There are plenty of excellent package managers around. Why not just use one of them? I looked into this, seeing whether we could use portage, pkgsrc, apt or macports for this. Unfortunately, they all either require root privileges and/or a dedicated user added to the system (portage, apt), require you to have the entire dependency tree (pkgsrc), or rely on mac-specific libraries (macports). There are a few alternatives that run as a regular user. Gentoo Prefix, Nix, and maybe GoboLinux come to mind. Technically, the macports system is actually really nice: each 'portfile' contains a list of dependencies, a url for the tarball, and can optionally specify/override configure/make
Re: [sage-devel] Re: git integration repository, please test
On Tue, 15 Jan 2013 09:44:13 -0800 R. Andrew Ohana andrew.oh...@gmail.com wrote: On Tue, Jan 15, 2013 at 8:01 AM, Burcin Erocal bur...@erocal.org wrote: Keshav, Jordi and many others have pointed these out before, but our main problem seems to be: - we are not really using a DVCS - the build system is showing its limits due to the rapid growth of Sage I don't think switching to GIT will solve either of these problems directly. Why don't we discuss the solutions to these problems separately and put them into action? FYI, the whole switching to git is only looking at addressing the development model, not the build system -- but as switching to git gives us a chance to re-examine the directory structure, and modify it, the (current) build system will necessarily have to be modified. IMHO, trying to solve all problems at once is not a good approach. - Development model: I like the idea of keeping a branch for each issue on Trac. I have even suggested using mercurial's pbrach extension for this purpose privately to William about 2 years ago. With a student, I even set up a patched roundup install with this feature. I can enable it on the lmonade issue tracker if anybody is interested in testing this out. Though I believe using gitlab and not reinventing the wheel is far better. Please see http://wiki.sagemath.org/WorkflowSEP for a description of the issues, and a work in progress of the proposal. I have seen this of course. As anyone else involved with Sage development for a long time, I am familiar with the problems as well as various unsuccessful solutions that were proposed in the past, editors, stopgaps, etc. Let's look at the items in the Problems Section: #. Sage has four major repositories and arbitrarily many SPKG repositories, instead of one repository like most software. This adds to complexity and may confuse new developers. As William repeatedly states in his Sage talks, Sage stands for many things at once. At least: - mathematical software distribution - Python/Cython library for computational algebra - graphical user interface - interfaces to mathematical software From these, the graphical user interface got it's own repository. Now we are trying to consolidate the rest? The argument that most software has only one repository, so should Sage is absurd. The problem with the repositories is that they are not self contained enough. For example, sage-doctest scripts should be in the Sage library repository itself. They are solely for testing Sage, when they change, the library also changes. If the library did not rely on environment variables being set in specific ways, I don't see why else the scripts need to be merged with it. Similarly for packages. I don't understand why a computational algebra library should include a package manager in its repository. #. Requiring human developers to manually create and upload patch files adds to the maintenance burden for coordinators. +1 #. The lack of a standardized machine-readable format in which to specify on a ticket which patches to apply where and in what order causes the patchbot to often guess the answers to these questions incorrectly, and causes developers to be uncertain as to how to influence the patchbot's guesses. The fact that a ticket needs to have patches for several repositories indicates that the files in these repositories should be shuffled a bit to prevent this situation from happening again. #. The common practice of continually updating patches with new versions is confusing because one ends up with a soup of patches on a trac ticket, only the latest few of which are actually relevant anymore. snip +1 #. In that vein, continually updating patches (as opposed to only adding new patches on top of existing ones) encourages history rewriting, which leads to a loss of granularity and larger individual commits in the final Mercurial history of the Sage repositories. snip +1 #. Patch files by nature provide no information about what revision they should be applied to. This means that reviewers and the patchbot are forced to guess the correct revision to use. +1 #. If it becomes necessary to rebase a patch file on another patch file, it is often difficult to do so manually. snip The items above say that we should be using a DVCS, and our repositories are not separated logically. #. The fact that development versions of Sage have throwaway commits in them is extremely confusing and a bad practice, as commits that have been publicized (in a full alpha/beta/rc tarball no less, not just on a repository website), should *not* be rescinded if at all possible. #. The impossibility of upgrading from such a development version of Sage is a problem in and of itself. These two are about the release management process. Keshav tried to argue about
Re: [sage-devel] Re: About log and ln. Free fight.
On Thu, 10 Jan 2013 22:15:45 +0800 P Purkayastha ppu...@gmail.com wrote: On 01/10/2013 10:09 PM, Nathann Cohen wrote: H Yep, log2 and log10 sound good indeed ! So what do we do, in the end ? ln(e) = 1 log(10) = 1 log2(2) = 1 Or do we stick log(e) = ln(e) = 1 ? Don't change anything. Status quo is fine. +1 We have too many aliases as it is. Anybody who needs these can add a suitable lambda expression to their init.sage file. -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Why does - (x 100) return -x -100 ?
On Tue, 18 Dec 2012 09:16:05 +0100 Burcin Erocal bur...@erocal.org wrote: This was indeed intentional at the time. When writing the new symbolics code based on pynac, William and I thought that this behavior was the one that led to least confusion. Working with expression trees that involve relational objects can be confusing: f = x y; xy -5*f; -5*(xy) sin(-5*f) + x^2; x^2+sin(-5*(xy)) If arithmetic with relational objects is left unevaluated as above, we have no well established interface to work with these expressions. So we chose the simple solution... This decision led to a lot more confusion than expected and there was an agreement to change it quite a while ago: http://trac.sagemath.org/sage_trac/ticket/7660 It should just be a matter of removing the block starting with if is_a_relational(left._gobj): in the _mul_, _add_, etc. methods of sage.symbolic.expression.Expression. Patches are welcome. I posted a prototype patch on the ticket. Please try it out and comment on the ticket. http://trac.sagemath.org/sage_trac/ticket/7660#comment:12 Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] ask.sagemath spam
Hi Karl-Dieter, On Thu, 3 Jan 2013 05:11:44 -0800 (PST) kcrisman kcris...@gmail.com wrote: The last few weeks there has been a marked increase in spam of the following nature on ask.sagemath Title: Irrelevant Question Content: How do I do something unrelated to Sage Answer (by different author): Your best way of doing it is at the following website or email link It seems to always be from new users, so I don't think that banning them will be useful, though we could try. Currently, people have been flagging them but NOT closing them, and then I have been deleting them. I think this is the best short-term solution - please do NOT *close* them, as then I cannot delete them. Longer-term, we need to think about ways to keep spam to a minimum at this useful resource. Any ideas? Perhaps we could limit the ability to add links in questions/answers to users with karma n. I guess 20 or 30 is a reasonable value for n. BTW, ask.sagemath.org runs ASKBOT 0.7.22, whereas askbot.org has 0.7.43. Here is the changelog: http://askbot.org/doc/changelog.html I haven't gone through it in detail to see if there is anything to solve the spam problem. Thanks for all your efforts to keep ask.sagemath.org going. :) Happy new year. Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Correct procedure for an experimental package
Hi Charles,
On Thu, 20 Dec 2012 12:37:33 +0100
Charles Bouillaguet charles.bouillag...@gmail.com wrote:
I (amongst with others) have written a library that solves boolean
equations in some way. I wanted to include it as an experimental
spkg. I thus wrote a cython interface to Sage. To be usable from
inside Sage, both the library itself and the cython interface are
necessary. What is the proper way to do this ?
I first thought that the Right Way (r) was to conditionally include
the cython part to the library when the spkg is installed, by writing
something like this in module_list.py :
if is_package_installed('stuff'):
ext_modules.extend([ blablabla ])
This works fine, except that it forces potential users to not only
install an spkg but also run sage -b, and it apparently makes it
impossible to update the reference manual: if I add a line
sage/libs/stuff
to libs.rst, then building the reference manual fails when the spkg
is not installed.
What should I do ? Unconditionally include the cython interface to
the sage library, and mark all doctests as optional ?
Can you compile the Cython interface without the header files installed
by your package?
I assume the Cython interface needs to be changed whenever you update
your library. Which Sage version is used with an experimental package
cannot be controlled, since Sage just grabs the latest version available
at install time. Hence, if you keep the interface separate from
the spkg, you will run into many incompatibility issues.
Wouldn't it be easier to include the Cython interface in the package?
AFAIK, Cython's build system improved significantly and there is no
reason to use Sage's build system for a Cython module.
Cheers,
Burcin
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
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.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Correct procedure for an experimental package
On Thu, 20 Dec 2012 13:15:38 +0100 Charles Bouillaguet charles.bouillag...@gmail.com wrote: On 12/20/2012 01:02 PM, Burcin Erocal wrote: What should I do ? Unconditionally include the cython interface to the sage library, and mark all doctests as optional ? Can you compile the Cython interface without the header files installed by your package? No I assume the Cython interface needs to be changed whenever you update your library. Yes, but changing spkg versions requires a ticket, on which the sage library can also be changed. Which Sage version is used with an experimental package cannot be controlled, since Sage just grabs the latest version available at install time. Hence, if you keep the interface separate from the spkg, you will run into many incompatibility issues. OK. But then how do the other spkgs do ? Wouldn't it be easier to include the Cython interface in the package? AFAIK, Cython's build system improved significantly and there is no reason to use Sage's build system for a Cython module. Is it possible to patch the sage library when installing an spkg ? What if the patch fails because the sage library was updated since the last spkg updatye ??? This seems like asking for trouble, and incompatibilities. I am not suggesting to patch the Sage library when installing your package. You can put the interface in a separate Cython module which is built by the usual Python/Cython setup.py magic and installed in the system python module directory. Then people will be able to import your module from the Sage command line as usual. I still don't understand how it is currently done. I don't think there is a well established procedure for this. There is code in the Sage library that depends on optional packages. This works just like you described. modules_list.py already includes some examples. In this case, all doctests will need to be marked optional. Given the fact that there is no way to guarantee that the wrapper code in the Sage library corresponds to the library version available in the package, I don't see how the current practice is better than bundling the wrappers in the package. I can see the benefits of having the wrappers included in Sage from a reputation/review point of view. However, this is not on par with the rest of the Sage library code, since this code is hidden behind optional tags and not tested by Sage users or developers regularly. #13540 improves the situation somewhat. But the way optional packages/modules are handled still leaves something to be desired. Especially if we want to promote creating separate specialized packages as a way of distributing research code: https://groups.google.com/d/topic/sage-devel/fcxNrQqVSz0/discussion Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Correct procedure for an experimental package
Hi Martin, On Thu, 20 Dec 2012 13:15:51 +0100 Martin Albrecht martinralbre...@googlemail.com wrote: Wouldn't it be easier to include the Cython interface in the package? AFAIK, Cython's build system improved significantly and there is no reason to use Sage's build system for a Cython module. my understanding is that Charles was more specifically asking about including his experimental package in the reference manual. My understanding is that this is currently not possible. Aaah.. thanks for the pointer. When I read his message, having to rerun sage -b to get the relevant code seemed more problematic than not being able to access the documentation. I guess I am used to reading the code for documentation. I don't mind if something is not in the reference manual. This is orthogonal to my main point though: I think wrappers for optional packages should live in the package and not the Sage library. I know this goes against the popular general philosophy of Sage development can be streamlined by bringing everything under one roof. I believe the Sage project would benefit more if we stop trying to make research code and a stable library interface fit into the same package and encourage people to build on Sage while we concentrate on creating a rock solid python library with an intuitive interface for generally useful mathematics functionality. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Correct procedure for an experimental package
On Thu, 20 Dec 2012 14:10:55 +0100 Charles Bouillaguet charles.bouillag...@gmail.com wrote: I am not suggesting to patch the Sage library when installing your package. You can put the interface in a separate Cython module which is built by the usual Python/Cython setup.py magic and installed in the system python module directory. Then people will be able to import your module from the Sage command line as usual. The python interface **uses** the sage library (matrices, modules, polynomials, term orders, etc. etc. etc.). It does not make sense outside of sage. It is a binding between sage and my piece of C-code. Some examples of Python/Cython packages that depend on Sage: http://sage.math.washington.edu/home/SimonKing/Cohomology/ https://github.com/williamstein/psage Sage is supposed to be a Python library for mathematics among other things (software distribution, notebook interface, interface to maths software). It is natural to use it as a library. :) I actrually followed the same pattern I found there : http://trac.sagemath.org/sage_trac/ticket/418 I am aware that you followed an often used pattern for development. I am not writing to criticize you in any way. I am merely aiming to point out the deficiencies of this pattern. I don't think there is a well established procedure for this. There is code in the Sage library that depends on optional packages. This works just like you described. modules_list.py already includes some examples. In this case, all doctests will need to be marked optional. Strictly speaking, they don't, because the code is not even considered if the spkg is not there. ??? Won't it be considered if you run doctests on the full Sage library with sage -testall Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Why does - (x 100) return -x -100 ?
On Mon, 17 Dec 2012 18:15:57 -0800 Benjamin Jones benjaminfjo...@gmail.com wrote: snip It's hard to tell from the implementation if this behavior is intentional, unintentional, or a bug. The implementation is just that multiplication maps over relational operators like ==, , =, etc. But I think it's not possible in the current framework to make multiplication preserve the truth of a statement, e.g. if y 0 is true, is x*(y 0) true or false? You can't decide unless you know more about x. If you want to make multiplying by elements in SR preserve truth of a statement you have to decide this. snip Sorry for the noise.. I meant to say (at the top) that from the implementation (of sage.symbolic.expression.Expression._mul_) it's pretty clear that this behavior *is* intentional, not a bug, but that's not to say it's desirable in all situations. This was indeed intentional at the time. When writing the new symbolics code based on pynac, William and I thought that this behavior was the one that led to least confusion. Working with expression trees that involve relational objects can be confusing: f = x y; xy -5*f; -5*(xy) sin(-5*f) + x^2; x^2+sin(-5*(xy)) If arithmetic with relational objects is left unevaluated as above, we have no well established interface to work with these expressions. So we chose the simple solution... This decision led to a lot more confusion than expected and there was an agreement to change it quite a while ago: http://trac.sagemath.org/sage_trac/ticket/7660 It should just be a matter of removing the block starting with if is_a_relational(left._gobj): in the _mul_, _add_, etc. methods of sage.symbolic.expression.Expression. Patches are welcome. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: What to do with research-y code.
On Tue, 27 Nov 2012 01:53:31 +0800 P Purkayastha ppu...@gmail.com wrote: snip Robert's post I think the Sage community could quickly expand and there could be tens, if not hundreds, of git development branches once the switch to git occurs. It would be quite hard to keep track of all the different branches and the individual modifications that people have in their forks. I looked up scipy right now, and that itself has over 500 watchers and 200 forks. The situation is the same for matplotlib, and almost the same for mathjax. It would be nice to see how those communities cope with such a huge number of forks and development branches. Note that most of the research code we are talking about is either a single .sage file or a bunch of .py files in a directory, totaling at most 1500 - 2000 lines of code. Here is a good example: http://math.bu.edu/people/rpollack/OMS/OMS.zip from http://math.bu.edu/people/rpollack/ I cannot imagine research mathematicians wrangling forks of the Sage library (IIRC, ~ 500k lines of code) just to get a small piece working. In most cases, these forks will contain old versions, untouched since the paper was published, so even merging with the latest Sage release will be nontrivial. Especially if the research code required changes in some core Sage library class (add a function to number fields say), only a few people really familiar with Sage (and the DVCS system in use) can handle the merge. This is all to say that git forks are not going to solve the problem Robert brought up. What I describe below is one way I think we could have access to the many individual patches and alpha-quality code people might have. Here is another way, which is not at all new. :) Do what William does with psage: If your code exceeds the single .sage/.py file threshold, it is fairly easy to create a Python package out of it. With the myriad of Python packaging solutions (easy_install, pip, etc.), installing such a package given a URL is also trivial. So just publish the URL on your home page, announce it to your colleagues and you're good to go. There are several problems with this approach, which I mention below. To encourage people to contribute back high-quality version of their research projects into Sage, one thing that could be done is to enable a wikipage where the developers can mention or list their current project/unpolished code. The hope is that such a model will help the person get feedback for his/her code and the person can get encouraged to eventually submit it to trac and include it with Sage. It often happens with me that I get a bit more motivation to finish/polish my work once someone asks me for it - the feedback helps me know that the code might be useful for someone else too! I wonder if other people here have faced similar situations. The wiki page is a good idea, but it would be filled with stale information quickly if it is not supported by some infrastructure to keep it up to date. You're right that getting feedback is a great encouragement to polish the code (which is a big advantage of the combinat model), but I don't see why it also encourages people to submit it to Sage. The review process can be quite painful after all (see #9016). In many cases, from a professional/career perspective, this is even bad for you: * once your code is readily available in Sage, people assume it's standard functionality and stop citing/giving credit to the implementation/paper * the time spent to polish the code is wasted according to academic assessment criteria, which usually only counts publications and citations We tried to address these problems to provide more of an incentive to make people submit their work to Sage with the citation module: http://trac.sagemath.org/sage_trac/ticket/3317 Here is some relevant discussion from sage-devel more than a year ago: https://groups.google.com/d/topic/sage-devel/RtYTIxgn2io/discussion Going back to the problems with individual packages: - code that is not tested regularly against updates in Sage bitrots This problem can be solved by a continuous integration system (like patchbot) that runs the tests against changes in Sage. Depending on hardware availability, this can happen with every beta and rc releases, or even daily. The developer has to commit to fixing the problems revealed by the test suite. This would be in their interest, since it guarantees that if somebody else ever wants to use the code in question, it will (up to amount of test coverage) run on the latest Sage release. - some research code goes beyond just a bunch of python files. For example Simon's p-group cohomology package: http://sage.math.washington.edu/home/SimonKing/Cohomology/ It includes MeatAxe, a C-library, and depends on an optional Sage package. This provides a challange to Salvus (or wakari: http://continuum.io/blog/introducing-wakari) like models. Unless
Re: [sage-devel] Re: Indexing of symbolic expressions
Hi, On Sat, 10 Nov 2012 19:16:55 -0800 (PST) Jean-Pierre Flori jpfl...@gmail.com wrote: IIRC there was some work about this done (but not merged?). No time to search myself now, but searching trac and the pynac-devel list should give some hints, or contacting Burcin and or Florent Hivert. Thanks for pointing this out Jean-Pierre. Here is the ticket: http://trac.sagemath.org/sage_trac/ticket/11576 I don't remember if the patch attached to the ticket is the most recent one. This might be better: http://sage.math.washington.edu/home/burcin/indexed_expression_2018.patch IIRC, the main outstanding issue was how to handle the conversion of these to maxima. At some point I promised to write a function that does some name mangling before the maxima calls, but never got to it. Perhaps libmaxima can handle these without this hack anyway. In any case, we need to revisit the code that converts symbols to maxima and back because of #13655. So this might get solved on the way. On Wednesday, November 7, 2012 8:25:24 AM UTC-6, Michael Orlitzky wrote: On 11/06/2012 10:51 PM, Andrey Novoseltsev wrote: On Nov 6, 7:14 am, Jason Grout jason-s...@creativetrax.com wrote: What about a[None] returning a? That's a little awkward, I guess. Thanks, Jason I would never think that a[None] would return a, whatever a is! I'd expect something empty... I've just removed the parent symbol entirely (and cleaned up the code a bit). Now only the list notation works. If a(1) returned 'a1', it was not preposterous to have a() return 'a'. But a[] is a syntax error, so to hell with it =) How do these interact with existing symbolic expressions in arithmetic or function application? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Bug in functions sin, cos, exp...
On Wed, 31 Oct 2012 05:05:24 -0700 (PDT) kcrisman kcris...@gmail.com wrote: On Wednesday, October 31, 2012 6:01:07 AM UTC-4, Volker Braun wrote: On Tuesday, October 30, 2012 11:08:15 PM UTC, Fredrik Johansson wrote: Returning a Sage Integer would be consistent with this: I also think that returning a Sage integer is the appropriate thing to do. I've updated #10133 with this apparent consensus. Note that in the partial duplicate #10972 Burcin seemed to think that they should return symbolic expressions, but Simon's argument seems reasonable to me as well. ??? The quote on that ticket is from you: https://groups.google.com/d/topic/sage-support/bcwwTYozl6I/discussion We normally try to match the type of the output to that of the input. In the sin(pi) example, pi is a a symbolic expression and the output comes out as a symbolic expression. This also works for inexact input: sage: type(sin(pi)) type 'sage.symbolic.expression.Expression' sage: type(sin(0.)) type 'sage.rings.real_mpfr.RealNumber' There is an inconsistency for exact input, since making that return a type compatible with the input either requires changing pynac, or slowing down all (symbolic) special function evaluation by introducing a check for this case. As you pointed out earlier, this is #10133. I will eventually fix it when I find time. I'd be happy to explain what needs to be done to volunteers. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] patchbot down?
Hi, the patchbot site shows a traceback suggesting the mongodb server is down. http://patchbot.sagemath.org/ Am I looking at the right page? Can somebody bring the database up? Thanks. Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Symbolic calculation
Hi Noud, On Sun, 9 Sep 2012 04:17:24 -0700 (PDT) Noud noud.aldenho...@gmail.com wrote: Let's first take a look at this example sage: f = 2*cos(1/2) sage: f 2*cos(1/2) sage: f.n() 1.75516512378075 I would like to program something like cos(x) that behaves the same as what I showed above. So I want to program a function F which can interact with RingElements and stays symbolic until I want to evaluate it. Then this function F (always) becomes an element of the Ring so you can multiply, add, etc. So I want to create a class F such that you can so something like this: sage: g = 2*pi*F(1,2,3,4)/3 sage: g 2/3*pi*F(1,2,3,4) sage: g.n() 1.23456789# or any other element from some arbitrary Ring in which you work I looked at the source code of /sage/functions/trig.py, but cos(x) is using the GinacFunction class to calculate symbolically. Could someone tell me if this thing is possible? If yes, how can you do this. Are there examples in the source code of Sage which I should look up? Yes, this is possible. You can look at the implementation of exponential integrals deriving from BuiltinFunction in this patch for an example: http://trac.sagemath.org/sage_trac/attachment/ticket/11143/trac_11143-v2.5-rebased.4.patch cos() is not a good example, because custom methods for evaluation, differentiation, etc. are implemented in c++ by ginac already. We don't need to implement them again in Sage. ps. I also want to let it interact with itself! Something like sage: F(1,2,3,4) * F(5,6,7,8) F(9,10,11,12) You cannot get this to work automatically. When you evaluate your function, as in sage: t = F(1, 2, 3, 4) that object, t, is an element of the symbolic ring. Arithmetic between these objects call the same method as any other symbolic expression. Checking for such rules would slow down the multiplication of symbolic expressions. You can use the pattern matching .match() and substitution .subs() functions to implement this and call it manually when you want to normalize your expressions. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Virtual machines -- I'm curious...
On Wed, 29 Aug 2012 07:05:56 + Jan Groenewald j...@aims.ac.za wrote: Hi, On 29 August 2012 06:38, David Kirkby david.kir...@onetel.net wrote: On 28 August 2012 20:55, William Stein wst...@gmail.com wrote: Hi, See the exchange below. I'm curious if there is anybody reading this who would want to manage a bunch of Virtualbox VM's, if we had a server *devoted* solely to running them, all for making Sage build in a much wider range of distros. This would take a person with a very particular set of skills and interests... in like maybe installing the top 10 linux distros or something like that. -- William It sounds an awlful job. Realistically to do it properly, there should be VMs for not just the latest version, but older versions too. Perhaps up to say two years old. Also one should really look at installing beta versions of the OS, so we know in advance if the next version of $some_distribution is going to cause a problem. So for 10 distributions, that's probably 50 or so virtual machines. If each was given 6 GB RAM, which is not an unreasonable amount, that would amount to 300 GB of RAM for just virtual machines. If you only restrict yourself to the latest version of the operating system, then it seems you wont catch the problems that people have, as a lot of the Linux issues seem to be a result of there being little or no attention paid to backwards compatibility with Linux. That seems like a LOT of work to do properly, and if not done properly, you are probaby wasting your time. I'm not sure I understand completely. My back-of-the-envelope calculation came out an order of magnitude differently. Two Gigabytes is sufficient for each for RAM. Ubuntu has six supported and development versions http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Table_of_versions, while Debian has 3 supported versions (including one development) http://en.wikipedia.org/wiki/Debian#Release_history. I guess similarly (around 4 average, that is 3 releases and one development version) for each of Redhat+Fedora+ScientificLinux, also for Gentoo, and also for Suse. That's a good spread and might require four volunteers (1 for apt, 1 for 3xrpm, 1 for gentoo/emerge, 1 for suse/yast). That multiplies to less than 64G, which is what is available. From my experience, this is a perfectly reasonable calculation. I run 6 virtual machines on my workstation with 16 GB RAM for testing lmonade. I can even use that machine for web browsing and emails when the virtual machines are busy. It is possible to script the creation of virtual machines: https://launchpad.net/vmbuilder http://wiki.debian.org/VMBuilder Buildbot support starting and stopping a virtual machine before sending a task to the slave: http://buildbot.net/buildbot/docs/current/manual/cfg-buildslaves.html#latent-buildslaves So in theory, many more virtual machines can be hosted on the same machine and started automatically when needed. BTW, it would be great to have a large enough SSD on the machine and use partitions on this disk directly on the virtual machines. Besides using a ramdisk, I don't think there is any other way to get reasonable build/disk performance out of virtual machines. The four (or six) volunteers are presumably adept at installing a machine, adding buildbot_slave and auto updates, and repsonding every few months to an anomaly. I could be missing something. I'm half volunteering for the Debian/Ubuntu, because I imagine I can get them up in a weekend and hardly touch them after that. I would be willing to help with the configuration of the whole system and I can try to come up with scripts to create a simple gentoo server install. Would it be possible to use these virtual machines to test lmonade as well? Cheers, Burcin -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] feature suggestion: decorator to convert python function to symbolic function
Hi Timo, On Sun, 5 Aug 2012 10:12:41 -0700 (PDT) Timo Kluck tkl...@gmail.com wrote: I think that the distinction between def f(x): return x^2 and f(x) = x^2 is a common source of confusion, and everyone will run into it when trying to define piecewise functions. It would be possible to introduce a decorator, say @symbolic_function, that makes sure that @symbolic_function(x) def f(x): return x^2 makes f a symbolic function. I've done just that in this published worksheet: http://www.sagenb.org/home/pub/4919 This looks great. Can you upload your code to #7636 on trac. http://trac.sagemath.org/sage_trac/ticket/7636 As you can see, it works with piecewise functions, too. Of course, it should probably do something sane with multiple variables, class methods, etc, but it seems possible. I can probably produce a patch for this, but I would like some feedback first. On Sun, 5 Aug 2012 10:28:43 -0700 (PDT) Timo Kluck tkl...@gmail.com wrote: Sorry, I didn't realize that. Here's the code. --- def symbolic_function(variables, *args, **kwds): def result(f): def evalf_func(self,x,parent=None): if parent == None: return f(x) else: return parent(f(x)) return function(f.__name__, variables, evalf_func=evalf_func, *args, **kwds).operator() return result @symbolic_function(x) def steps(x): if x 0: return -x elif x 3: return x else: return 3 It might be better to use the function_factory method from sage.symbolic.function_factory instead of the top level function() method. This would remove the need to specify the names of the variables, then get the symbolic function using .operator(). You can get the number of arguments with f.__code__.co_argcount. Cheers, Burcin -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building farey_symbol.pyx on Cygwin
Hi Jean-Pierre, On Thu, 19 Jul 2012 06:22:32 -0700 (PDT) Jean-Pierre Flori jpfl...@gmail.com wrote: I'll do when I'm finished, for the moment, I'll just keep track of the progress on the wiki page. Hopefully there is only one problematic file left: expression.pyx. I've looked into this all night long but failed to solve the problem. g++ complains about a template instantiation (parse error, blah, cannot find function, blah) using the infinity class (from pynac). More precisely functions like bool is_ainfinity(const ex), ex_toinfinity and similar ones. The link I posted on the wiki page does not seem useful after all, although the problem shall dwell in this part of the code. What's strange is that the same functions are used with different classes, even earlier in expression.cpp and are not problematic. Looking at infinity.c/h and e.g. relational.h/c, and what's about them in basic.h/c and ex.h/c I can not spot an obvious difference. As I'm not really an expert of templates I hope I have missed something obvious. I'll try to cc Burcin about that, as he's surely the more acquainted with pynac source code and organization. The infinity class is a recent addition to pynac by Volker. It is possible that we missed something there, but I cannot spot any obvious problems just by looking at the (pynac) code. Can you post the error messages? Cheers, Burcin -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Algebraic numbers in symbolic ring
On Sun, 13 May 2012 14:13:46 -0700 (PDT) mmarco mma...@unizar.es wrote: My problem was that i needed to do implicit derivation. Something like: sage: f=3*x^2*y^3-5*x*y+x^2-3*y^2+4*x-3*y+1 sage: f.diff(x) 9*x^2*y(x)^2*D[0](y)(x) + 6*x*y(x)^3 - 5*x*D[0](y)(x) - 6*y(x)*D[0](y) (x) + 2*x - 5*y(x) - 3*D[0](y)(x) + 4 and then substitute the value of x, y(x) (which in general will be an algebraic number) and solve for D[0](y)(x). I know that the first derivative is just minus the quotient of the partial derivatives of f, but i would need also the higher order derivatives, which forces me to repeat the previous process several times. In fact i finally found a solution the implicit derivation (see ticket 12922), but since i run into this issue of not being able to work with algebraic numbers in the symbolic ring, i thought it would be a nice feature to have. My solution is to convert these numbers into symbolic variables before feeding them to the symbolic ring, and then converting back these variables into their value when i get them back in my polynomial ring. But that sounds like a dirty hack. In sage/symbolic/ring.pyx, lines 167-175 have the following code: if ComplexField(mpfr_prec_min()).has_coerce_map_from(R): # Anything with a coercion into any precision of CC # In order to have coercion from SR to AA or QQbar, # we disable coercion in the reverse direction. # This makes the following work: # sage: QQbar(sqrt(2)) + sqrt(3) # 3.146264369941973? return R not in (RLF, CLF, AA, QQbar) Modifying this should allow you to use algebraic numbers in symbolic expressions. IIRC, this is left from the days when we thought having coercions in both directions is not acceptable. I don't think changing it will cause any problem apart from a few broken doctests. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Algebraic numbers in symbolic ring
On Mon, 14 May 2012 04:27:15 -0700 (PDT)
mmarco mma...@unizar.es wrote:
I don't think the problem here is coercion, but conversion (and,
mostly, the ability of the symbolic framework to handle these
numbers).
The symbolics framework can handle these numbers. You can use
arbitrary python objects as coefficients in symbolic expressions.
Everything should work fine as long as they live in a field. Even a
commutative ring should be enough, but I'm not sure if some
normalization routines behave well in that case.
If you want to try without messing with coercions, convert the
algebraic numbers you will use as coefficients to symbolic constants
with SR._force_pyobject(). Then you can go through the computation and
see if there are any errors.
sage: K.a = NumberField(x^3-2)
sage: t = SR._force_pyobject(K.random_element())
sage: t
8/3*a^2 + 2/3*a + 1/3
sage: u = SR._force_pyobject(K.random_element())
sage: u
-31*a
sage: t*u
-62/3*a^2 - 31/3*a - 496/3
sage: var('x,y,z')
(x, y, z)
sage: t*x + exp(u*y^z)
(8/3*a^2 + 2/3*a + 1/3)*x + e^(-31*a*y^z)
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: GSOC
On Tue, 27 Mar 2012 07:36:40 -0500 Jason Grout jason-s...@creativetrax.com wrote: On 3/27/12 4:13 AM, William Stein wrote: On Tue, Mar 27, 2012 at 10:12 AM, Ivan Andrusdarthand...@gmail.com wrote: FWIW, when I subscribed to this list I apparently signed up for the no email option (though I would never have done such a thing consciously). So if you are wondering why you didn't get any email that may be why. The same happened to me when I was subscribed to the list. It confused me for a while as well. I was invited to the list, and apparently I was invited to the no email option because I haven't seen any emails from it either. I'm not even sure how to change my setting since my email address is not a google email. This happened to me as well. I could still change the options even though I don't use a gmail address. I fixed your membership options nevertheless. Can someone change my email options to deliver email? Done. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GSOC
On Tue, 27 Mar 2012 07:52:10 -0500 Jason Grout jason-s...@creativetrax.com wrote: On 3/27/12 7:47 AM, Burcin Erocal wrote: This happened to me as well. I could still change the options even though I don't use a gmail address. I fixed your membership options nevertheless. How did you change your options? Is there a way to email commands to google groups? This might not make any sense since my knowledge of the inner workings of google's web interface is minimal... I guess my email address is associated to a google profile, which I can use for google docs, groups, and so on. When I log in to with that profile, the google groups interface lets me change my membership options. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage, gentoo-prefix lmonade was: log messages
On Tue, 21 Feb 2012 00:56:13 +0800 Keshav Kini keshav.k...@gmail.com wrote: Burcin Erocal bur...@erocal.org writes: snip Just to be clear, sage-on-gentoo itself has no goal of being a way to distribute Sage in general. It is simply a port of Sage and its SPKGs to the Gentoo package management system, using the overlay architecture the Gentoo distro has (similar to Personal Package Archives on Ubuntu, if you're familiar with those). Basically you just put something in a config file on your Gentoo system which says augment the package repository with ebuilds from sage-on-gentoo, and you can now install Sage system-wide. It is Burcin's lmonade project which combines sage-on-gentoo with Gentoo Prefix, which is a portable version of the Gentoo package management system which can be run in a folder on any system, and more importantly, can be customized to supply any set of packages, not necessarily the entire set of officially sanctioned packages that comprise the Gentoo Linux distribution. As the name suggests, it's similar to how you might use `./configure --prefix=/some/dir` in order to install a program to /some/dir/bin rather than /usr/bin, say. Thanks Keshav, that's a great summary of the relation between gentoo-prefix, sage-on-gentoo and lmonade [1]. For the record, I'd be very happy to see Sage use lmonade for the distribution aspects. [1] http://www.lmona.de/ lmonade was born because I thought that a customized Sage distribution like William's psage [2] was not maintainable in the long term. It still needs some work to cover all functionality of the Sage distribution, such as relocation and support for development of Sage. Given time, these are not hard problems. Unfortunately, I haven't had much time to work on lmonade lately. [2] http://purple.sagemath.org/ Hmm, so basically you wanted psage to just be sage with certain USE flags turned off? Essentially, yes. psage (like Sage) is a separate python library as well as a distribution. psage the python library would have its ebuild, which depends on Sage. The Sage ebuild would have USE flags to choose if you want fortran or maxima installed. snip Here is a highly abbreviated directory tree of lmonade, as it appears in the installation I made the other day, for reference: lmonade/ | dist package management / build system | | distfiles/ downloaded upstream source tarballs | | log/build logs | ` portage/ebuilds, patches, etc. | ` sci-mathematics/ | ` gap/ | | files/ | | | gap-4.4.12-sage-and-steve-lintons-itanium.patch | | ` gap-4.4.12-sage-strict_aliasing.patch | | gap-4.4.12-r2.ebuild | ` metadata.xml ` local/software is installed here | bin/, etc/, include/, lib/, libexec/, sbin/ ` share/ ` sage/ ` devel/ corresponds to $SAGE_ROOT/devel today So the package repository would be dist/portage, and the sage library repository would be kept at local/share/sage/devel/sage-main (or hopefully just ...devel/sage, once we get rid of `sage -clone`). I don't actually know my way around this directory structure very well, but those are the main takeaways, I think. Your description is accurate. The development repositories will be in devel/. pynac and pypolymake live ebuilds already put their files in this location. The separation of the sage ebuilds stopped me from using the same scheme for sage up to now. The goal is to put the development repository for a package foo in devel/foo once the user runs lmnd devel foo Well, by ...devel/sage I meant local/share/sage/devel/sage , as opposed to local/share/sage/devel/sage-main . Are you saying that you would put development repositories in a top level directory, lmonade/devel ? Yep. Top level directory named devel/, like it is in Sage, but only specific to the Sage library and notebook. I don't see a live ebuild for pynac nor any ebuild for pypolymake, btw... I think I have the latest lmonade version (prefix-20111201.tar.bz2, right?). The files with version number are live ebuilds. They pull from the mercurial repositories and build the latest version of the code: https://bitbucket.org/burcin/lmnd-prefix/src/tip/sci-libs/pynac https://bitbucket.org/burcin/lmnd-prefix/src/tip/sci-mathematics/pypolymake Try this (from your lmonade root, in the prefix shell): cd local/etc/portage echo sci-libs/pynac devel.env package.env echo =sci-libs/pynac- ** package.accept_keywords emerge pynac Then check lmnd root/devel/. If the above doesn't work, you probably don't have local/etc/portage/env/devel.env yet. Previous installers didn't install that file. :) https://bitbucket.org/burcin/lmnd-prefix/raw/6f22d7022a14/scripts/devel.env You will probably have to update
[sage-devel] sage, gentoo-prefix lmonade was: log messages
Hi Keshav, thanks for pointing out this thread. log messages is an interesting title to discuss the future directions for Sage. :) I added gentoo-science to the CC list, since that is the most likely location for sage-on-gentoo discussion and the gentoo-developers might be interested in the contents of this thread. On Mon, 20 Feb 2012 22:45:24 +0800 Keshav Kini keshav.k...@gmail.com wrote: Robert Bradshaw rober...@math.washington.edu writes: On Fri, Feb 17, 2012 at 1:09 AM, Keshav Kini keshav.k...@gmail.com wrote: Robert Bradshaw rober...@math.washington.edu writes: In the category of glue code I meant to include everything in $SAGE_LOCAL/bin/sage-*. I see much of that stuff as more related to maintenance of the entire distribution of software we ship than to the actual Python/Cython code in the Sage library. Of course, if we do switch to Prefix or something like it, most of it will become unnecessary, or can actually be fit into the portage data tree as Tools, so I see your point. Yeah, tools describes it well (or at least what remains after the package management stuff is gone, like testing and coverage and stuff). Well, I meant that there is a Tools directory in sage-on-gentoo. I'm not sure if this is a standard thing in the directory structure of a Gentoo Prefix tree, or, if it is, what sort of stuff is supposed to go there, but I see some utility scripts, presumably written by François or Christopher, in there and was suggesting we might be putting our sage-* scripts there too. But I don't know enough about Prefix to be sure whether that makes sense. AFAIK, Tools contains the scripts that are used to maintain the overlay. sage-on-gentoo contains these packages for Sage: sage-baselayout sage-clib sage-data-conway_polynomials sage-data-elliptic_curves sage-data-graphs sage-data-polytopes_db sage-doc sage-extcode sage-flasknotebook sage-notebook sage baselayout is what gentoo calls basic scripts. That is the package containing the relevant part of sage-scripts. While I like the separation of the data packages (I assume these don't depend on code from the sage library), I am not sure about the clib, doc and the library separation. I'd like to keep those together to match the Sage development pattern as close as possible. I think Sage will be monolithic and Windows be VM for the near future at least, with a larger percentage of people using a Sage install in the cloud on a university or otherwise hosted server for the near-mid term future. But as you said who knows... Yes, I agree. That seems like the most likely future, at the moment. However, William has asked me to write a Sage Enhancement Proposal for switching to git, and I think we concluded on IRC that it might make sense to make a long term timeline for other big changes as well, such as what we're talking about now - or at least a proposal for such a timeline :) +1, which is why we should be having this discussion now. Switching to git could probably happen a lot faster than revamping the build system, but at least we could consolidate some of the repositories and re-seat it at a higher level in the directory structure so moving to a new build system is just a patch :). Absolutely. Switching to git is much easier than revamping the build system. The only reason I'm mentally grouping them together is that consolidating SPKGs, which would be part of remaking the build system as I've described, is also related to version control. But that actually doesn't make a lot of sense now that I think about it. We would basically be throwing away the old SPKGs' files, so I don't know if it's even really worth preserving their history in the portage tree of Prefix, assuming we move to Prefix - we could easily preserve their history somewhere else instead. Of course, even if it's not really related to the switch to git, I'd definitely like to keep a build system revamp on the horizon! Thanks for filling me in. I was aware of the sage-on-gentoo effort, but never looked into it technically. The more I see of it the better it sounds. This seems to have precisely the flexibility we need. I'm very glad to hear you think so too! Spread the word! :P Just to be clear, sage-on-gentoo itself has no goal of being a way to distribute Sage in general. It is simply a port of Sage and its SPKGs to the Gentoo package management system, using the overlay architecture the Gentoo distro has (similar to Personal Package Archives on Ubuntu, if you're familiar with those). Basically you just put something in a config file on your Gentoo system which says augment the package repository with ebuilds from sage-on-gentoo, and you can now install Sage system-wide. It is Burcin's lmonade project which combines sage-on-gentoo with Gentoo Prefix, which is a portable version of the Gentoo package management system which can be run in a folder on
Re: [sage-devel] Re: I^(0.5)
On Wed, 15 Feb 2012 02:22:32 -0800 (PST) Keshav Kini keshav.k...@gmail.com wrote: http://trac.sagemath.org/sage_trac/ticket/12511 is now awaiting review. Thanks, Robert! Robert's patch now has positive review and is waiting to be merged. Thanks to Robert for the quick fix, Keshav and aapitzsch for their help. There is a ticket to remove the symbolic power_helper module: http://trac.sagemath.org/sage_trac/ticket/8659 I just uploaded a patch that passes all tests here. It would be great if someone can review that as well. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Question about system dependencies policy...
On Mon, 13 Feb 2012 04:58:49 -0800 William Stein wst...@gmail.com wrote: On Mon, Feb 13, 2012 at 3:35 AM, Dr. David Kirkby david.kir...@onetel.net wrote: On 02/13/12 11:18 AM, Jason Grout wrote: On 2/13/12 4:17 AM, Dr. David Kirkby wrote: Since some of packages will not have the or later version added into the license, we can't distribute Sage as GPL 3 or even GPL 2 or any later version, since some of the components don't have the or any later version. Which packages are those? I thought we were being really careful to not include any packages that were GPLv2 only in the base, standard distribution of Sage? Or are you just imagining that there probably is such a package? Thanks, Jason First one I find is gfan. This is SPKG.txt: gfan is GPLv2+. I know the author of gfan personally; I don't remember for sure, but I think got him to GPL it in the first place. All he did was take his code and put the standard GPL COPYING file (which has the GPLv2 license in it) in the same directory, and include a LICENSE file that says: - deep:src wstein$ more LICENSE The Gfan software is distributed under the GNU GENERAL PUBLIC LICENSE as described in the file COPYING. Ask the author if you want a more reasonable license. - Because the LICENSE file (and code) do not specifically state that the program is GPLv2, one may use any version of the GPL license (= 2). I asked Anders about the license off list before William's post. To clarify this, he changed the LICENSE file to the following : -- The Gfan software is distributed under the GNU GENERAL PUBLIC LICENSE version 2 or any later version as described in the file COPYING. Ask the author if you want a more reasonable license. -- This will be in a later release of gfan. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Question about system dependencies policy...
On Mon, 13 Feb 2012 20:34:40 + Dr. David Kirkby david.kir...@onetel.net wrote: On 02/13/12 05:19 PM, Keshav Kini wrote: If I understand correctly, William's point is that simply placing a copy of the GPL, with a version number attached or otherwise, with a or any later version included or otherwise, in the program's source code is not equivalent to a declaration of licensing under the GPL of a particular version, even if said copy of the GPL specifies a particular version of the GPL which said copy constitutes. Further, Michael Abshoff's comment at http://trac.sagemath.org/sage_trac/ticket/3043 is that the FSF's interpretation of what license the software is under if it simply includes some copy of the GPL in its source code but does not declare itself to be under that license is that the software is under that GPL copy's declared version and any later version, regardless of whether the text or any later version appears in said copy of the GPL. (Of course, I don't vouch for any of these statements - just trying to clarify the discussion.) -Keshav I can understand and agree with Alex's comments = Both the version of gfan that's currently in Sage (0.3) and the latest version (0.4plus) have a file COPYING which is just the text of GPL version 2. I would say that's pretty clear, and it should be in the file SPKG.txt. = I would interpret Alex as saying that's version 2, and only version 2. I've no idea how Michael Abshoff can say the FSF consider that code is licensed under version X+, even if you include a license with version X, and no comment about later versions. That makes no sense to me, and I've no idea where Micheal got that from. He has not provided any evidence to back up that dubious claim. See here for instance: https://fedoraproject.org/wiki/Licensing/FAQ#How_do_I_figure_out_what_version_of_the_GPL.2FLGPL_my_package_is_under.3F Quoting from item 4 in that answer: If neither the source, nor the upstream composed documentation says anything about the license version, then it could be under _ANY_ version of the GPL. The version listed in COPYING is irrelevant from this perspective. Technically it could be under any license, but if all we have to go by is COPYING, we'll use COPYING to imply that it is under the GPL, all versions (GPL+). I think we could argue this all night. I for one think Sage is on dodgy ground license-wise. Jeroen Demeyer is even more adamant there are legal issues. William is happy. IMHO, the tone on sage-devel has been deteriorating lately. Please try not to contribute to the noise this way. Several people have tried to give helpful responses to your initial claim. Repeating the same point over and over without looking anything up is not productive. On Mon, 13 Feb 2012 15:42:27 + Dr. David Kirkby david.kir...@onetel.net wrote: But currently SPKG.txt and COPYING state version 2 only. SPKG.txt for Mercurial states == License == * GNU General Public License version 2, or any later version but the COPYING file does not state or any later version. Some programs do (like znpoly), but Mercurial does not. Nor does gfan - despite you say you know different. Nor does the COPYING file in 'moin', though SPKG.txt says it is GPLv2+. Mercurial source code clearly states GPLv2+. They also have it on their web site: http://mercurial.selenic.com/wiki/License Same for moinmoin: http://moinmo.in/GPL Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] use ./configure; make for Sage?
On Sun, 5 Feb 2012 13:23:19 -0800 (PST) John H Palmieri jhpalmier...@gmail.com wrote: Various aspects of building Sage might be cleaner if we used autoconf: ./configure OPTIONS make OPTIONS could include a location to install Sage, various flags for building ATLAS, and other options which we currently control by setting environment variables. For typical users, we should aim for ./configure make to work. We should also continue to use the current environment variables--no need to remove them, just provide another way of setting them. Should we vote? [ ] Switch to autoconf [ ] Keep the current build system There was a similar discussion earlier: http://groups.google.com/group/sage-devel/t/b2ece135b42b5d98 The SEP Ralf wrote is also mentioned in that thread: http://wiki.sagemath.org/AutoToolsSEP IMHO, moving the checks from prereq to a top level configure file makes sense. I used a waf script to handle this in lmonade: https://bitbucket.org/burcin/lmnd-prefix/src/tip/scripts/wscript Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Create numpy-functions from sage symbolic functions
Hi Maximillian, On Fri, 27 Jan 2012 19:27:45 +0100 Maximilian Trescher faucon.emeril...@googlemail.com wrote: I'm very new to the developers list. About my background: I'm studying physics (in Berlin) and I'm using sage regularly for some physical calculations. Three days ago I wondered if there is any possibility to create a numpy-enabled function from a sage's symbolic expression. But i couldn't find a solution. (Right: there is fast_callable, but it doesn't eat numpy arrays) So I came to an own solution, and thought it might be of interest for you. You can find it here: https://github.com/faucon/numpybuilder I would be happy to contribute this to sage, if you think there is a need for it. You should use the infrastructure (written by Mike Hansen) in sage.symbolic.expression_conversions to do this. Once somebody (me?) changes that to use ginac directly for tree traversal, that will be the fastest way to do these conversions. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Two articles of interest to Sage in latest Notices
On Wed, 18 Jan 2012 12:26:33 -0800 (PST) kcrisman kcris...@gmail.com wrote: Publishing Computational Mathematics, by Tim Daly (of Axiom, a frequent contributor on sage-devel) http://www.ams.org/notices/201202/rtx120200320p.pdf Literate programming is not just adding comments to code, but here are a few numbers nevertheless... FriCAS (I couldn't find Axiom on ohloh.net): https://www.ohloh.net/p/fricas # of lines of code: 1218007 # of comment lines: 205615 Singular: https://www.ohloh.net/p/Singular # of lines of code: 456764 # of comment lines: 73429 Sage: https://www.ohloh.net/p/sage # of lines of code: 474866 # of comment lines: 551813 Gap wasn't available for comment at the time of publication: https://www.ohloh.net/p/gap-system This is also a good occasion to paste sage -coverageall output from 5.0.prealpha0: Overall weighted coverage score: 86.3% Total number of functions: 28917 We need 1056 more function to get to 90% coverage. We need 2502 more function to get to 95% coverage. We need 3658 more function to get to 99% coverage. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Question about scoping
On Tue, 17 Jan 2012 09:02:11 -0800 (PST) Nils Bruin nbr...@sfu.ca wrote: On Jan 17, 2:54 am, Keshav Kini keshav.k...@gmail.com wrote: [...] How does it make anything easier or clearer or better for the interactive user that var() injects things into global scope? We found ourselves trying in vain to explain this to students several times when teaching our Sage-based undergraduate course last fall. (CCing to sage-devel, assuming I did this right...) The preprocessor allows even finer jewels: sage: y=1 sage: def one(): : _(y)=1 : return 1 : sage: one() 1 sage: y y If this is biting people so badly, perhaps var should inspect its call frames via frame=inspect.currentframe() and dig down a bit with frame.f_back to see if it's at the sage top-level. If it's not, it could throw an error instructing people to use a non-globals- clobbering version of var (e.g., SR.var) instead. Since this routine goes digging in globals anyway, I think it's quite reasonable if it also does some stack frame exploring. Good idea! One possible drawback is that most users who call var() from a function definition will not understand what we mean by top level. Any suggestions for an informative error message? Are we also going to prevent people from defining callable expressions using the f(x) = x+1 syntax within functions? Using a globals-clobbering var at anything but top-level is almost certainly undesirable, so perhaps it's better to forbid it. +1 Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] the ARM port - numerical noise
On Mon, 16 Jan 2012 04:21:37 -0800 (PST) Dima Pasechnik dimp...@gmail.com wrote: Once again, let me bring up the numerical noise issue on ARM. The problem is that while we pretty much narrowed it down to a particular function computing the log of the gamma-function, lgammal, in elibc, an implementation of libc used on Ubuntu 11.10 (on ARM, at least), the chances that the upstream fixes it seem to be rarher slim. Fixing it myself does not look trivial – this C code is not at all pretty, uses a lot of hardwired largish constants, etc etc (and we cannot just patch a system library easily anyway, so it needs to get into the upstream, etc etc...) I can produce doctest patches that will to the appropriate rounding, but this potentially would make the corresponding doctests less reliable (we talking about things like 120.0 vs 199.9997 for gamma(float(6)), something like this). As far as I know, doctests cannot be OS-dependent. Any way out of this Catch-22? I guess this is the same problem as #9162. We should call a more reliable lgamma() function on these platforms. IIRC, the cephes package was included in Sage for this purpose. We could call the lgam() from cephes in sage/symbolic/pynac_cc.h to fix this. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Why use cp for patching
Hi Maarten, On Sat, 17 Dec 2011 14:28:47 -0800 (PST) Maarten Derickx m.derickx.stud...@gmail.com wrote: I was merging my new ipython spkg wich needed review for some time already at http://trac.sagemath.org/sage_trac/ticket/11235 but now needs work because in the time that it needed review some people made http://trac.sagemath.org/sage_trac/ticket/11460 and upgraded ipython. Now I noticed that in the new spkg they use patch in the spkg-install file (it was not in the old spkg-install) but in the developer guide they there is explicitly stated to not use it: http://www.sagemath.org/doc/developer/patching_spkgs.html#use-cp-for-patching. But there is no explanation why one should not do that, so can someone tell me why? Because using patch seems much more logical to me. This used to be the case to avoid a dependency on the patch tool. At some point, patch was included in Sage (see sage-devel archives). I guess no one updated the documentation since then. Can you open a ticket for the documentation update if there isn't already one? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Indexed expressions again...
Hi Jean-Pierre,
thanks a lot for looking into this.
On Sat, 26 Nov 2011 13:13:49 -0800 (PST)
Jean-Pierre Flori jpfl...@gmail.com wrote:
By the way:
- I used Burcin's patch, somehow I could not use Florent's one
- The patch is based on pynac-0.2.2, but applies on 0.2.3
Here is the output of the patch version
sage: class bla(SageObject):
: def __add__(self, other):
: print Add
:
sage: m1 = bla()
sage: m2 = bla()
sage: a = x.ind[m1]
sage: b = x.ind[m2]
sage: a+b
x.class '__main__.bla' + x.class '__main__.bla'
sage: a+a
2*x.class '__main__.bla'
Your patch for pynac works great here. Starting from plain Sage-4.7.2
and pynac-0.2.3, doctesting the usual suspects
(sage/{symbolic,calculus,functions}) shows only a couple of printing
differences. Considering this change within the context of #9880, they
are mostly harmless. :)
I merged your patch in my pynac queue [1]. We'll have to sort out the
headers once #9880 is done and we're making the pynac release.
[1] https://bitbucket.org/burcin/pynac-patches/src
Florent, shall we create a temporary pynac spkg so you can carry on
with your work on indexed expressions?
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] SAGBI bases?
Hi Simon, On Fri, 25 Nov 2011 06:58:15 -0800 (PST) Simon King simon.k...@uni-jena.de wrote: After some serach_src, it seems to me that there are no SAGBI bases in Sage. Are there plans to add them? Is there free software (with appropriate licence) that one could build upon? If I remember correctly, Nicolas Thiéry used SAGBI bases for computing invariant rings of permutation groups. Perhaps he can give a pointer? Did you look in Singular? http://www.singular.uni-kl.de/Manual/latest/sing_1136.htm#SEC1212 They are not wrapped in Sage of course. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Indexed expressions again...
Hi Florent,
On Thu, 24 Nov 2011 22:20:26 +0100
Florent Hivert florent.hiv...@lri.fr wrote:
I'm working on #11576 make it possible to generate sequences of
variables easily. I actually need to achieve a larger goal: I need
to have symbolic variables indexed by any Sage objects (eg: integers,
group element, matrices...). As as said previously here, I started to
work on Burcin patch. So I extended a little Burcin patch. Now I'm
faced with the problem that GiNaC indexed variable seems to have a
not trivial semantic that I don't understand at all. Moreover I don't
know how to debug Cython / C++ code so I'm quite stuck. Here is the
problem I have:
To get it you should apply
attachment:indexed_expression-experimental-fh.patch from #11576 on a
fresh Sage-4.7.2 install. Then I can
Your changes seem to be based on an older version of my patch. The latest
version was here:
http://sage.math.washington.edu/home/burcin/indexed_expression_2018.patch
I used a dummy symbolic variable as the dimension when it's not
specified. This doesn't make any difference though.
To make thing crystal clear (I hope):
sage: class bla(SageObject):
... def __add__(self, other):
... print Addition called
snip
Your example was trying to multiply two instances of the class bla.
Here is what I guess you meant to write:
sage: m1 = bla()
sage: m2 = bla()
sage: a, b = x.ind[m1],2*x.ind[m2]
Traceback (most recent call last)
snip
in sage.symbolic.expression.Expression._add_
(sage/symbolic/expression.cpp:11082)()
TypeError: unsupported operand type(s) for -: 'bla' and 'bla'
Note that it is trying to subtract the objects. Probably trying to
check equality. :)
WTF ! Why is it adding or multiplying my indices for nothing ! It is
a problem of Ginac ? of the wrapper ? or behind the chair and the
screen ?
Here is the backtrace:
Breakpoint 2, GiNaC::numeric::sub (this=0x7fffb4a0, other=...)
at numeric.cpp:1745
1745 {
(gdb) call this-dbgprint()
class '__main__.bla'
(gdb) call other.dbgprint()
class '__main__.bla'
(gdb) bt
#0 GiNaC::numeric::sub (this=0x7fffb4a0, other=...) at numeric.cpp:1745
#1 0x7fffd687c599 in GiNaC::operator- (lh=value optimized out,
rh=value optimized out) at operators.cpp:97
#2 0x7fffd6879226 in GiNaC::numeric::compare_same_type (this=0x4796060,
other=...) at numeric.cpp:1700
#3 0x7fffd67ca25a in compare (this=0x3d9cd10, other=...) at ex.h:339
#4 GiNaC::idx::compare_same_type (this=0x3d9cd10, other=...) at idx.cpp:278
#5 0x7fffd6ce0aad in compare (this=value optimized out,
other=value optimized out)
at /home/burcin/sage/sage-4.7.2/local/include/pynac/ex.h:339
#6 GiNaC::containerstd::vector::compare_same_type (
this=value optimized out, other=value optimized out)
at /home/burcin/sage/sage-4.7.2/local/include/pynac/container.h:625
#7 0x7fffd67b5f5e in compare (this=0x45508e0, lh=value optimized out,
rh=...) at ex.h:339
#8 GiNaC::expairseq::construct_from_2_ex (this=0x45508e0,
lh=value optimized out, rh=...) at expairseq.cpp:887
#9 0x7fffd6771beb in GiNaC::add::add (this=0x45508e0, lh=..., rh=...)
at add.cpp:70
#10 0x7fffd687c46c in exadd (lh=..., rh=...) at operators.cpp:42
#11 GiNaC::operator+ (lh=..., rh=...) at operators.cpp:69
#12 0x7fffd644e489 in
__pyx_f_4sage_8symbolic_10expression_10Expression__add_
(__pyx_v_left=0x4757050, __pyx_v_right=0x4757d40,
In English: it tries to normalize the resulting expression in
construct_from_2_ex(). This means checking if the two arguments are equal.
Going through idx::compare_same type(), it ends up in
numeric::compare_same_type(). Here is the code for that function:
int numeric::compare_same_type(const basic other) const
{
GINAC_ASSERT(is_exactly_anumeric(other));
const numeric o = static_castconst numeric (other);
int cmpval = (real() - o.real()).csgn();
if (cmpval != 0)
return cmpval;
return (imag() - o.imag()).csgn();
}
We should change this somehow. Maybe we could try PyObject_Compare and fall
back to this if it fails.
Comments?
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Symbolic nth_root()
On Tue, 22 Nov 2011 09:41:56 -0800 (PST) kcrisman kcris...@gmail.com wrote: I don't think it exists, The symbolic functionality in Sage is supposed to make it easy for users to define a new symbolic function at runtime, including how that function gets simplified. This is supposed to not involve any C++ coding with Pynac. So it _should_ be easy to add what you suggest. Maybe Burcin can pipe up. Here is a symbolic function which wraps RR.nth_root(): from sage.symbolic.function import BuiltinFunction, is_inexact from sage.symbolic.expression import Expression from sage.structure.coerce import parent class RealNthRoot(BuiltinFunction): def __init__(self): BuiltinFunction.__init__(self, real_nth_root, nargs=2) def _eval_(self, base, exp): if (not isinstance(base, Expression) and is_inexact(base)) or \ (not isinstance(exp, Expression) and is_inexact(exp)): self._evalf_(base, exp, parent=parent(base)) def _evalf_(self, base, exp, parent=None): if isinstance(base, float): return RR(base).nth_root(exp) try: return base.nth_root(exp) except AttributeError: return base**(1/exp) return parent(base)**parent(exp) The code is also here: http://sage.math.washington.edu/home/burcin/real_nth_root.py I can plot this without trouble: sage: attach real_nth_root.py sage: real_nth_root = RealNthRoot() sage: v = real_nth_root(x, 3) sage: plot(v, (x, -1, 1)) firefox displays the plot Maybe this would be the best solution. If you put this on a ticket with patch I'll try to make sure this gets reviewed properly at Sage Days 35.5. Thanks! I attached a patch to #12074. Still needs documentation and tests. http://trac.sagemath.org/sage_trac/ticket/12074 Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Maxima vs Ginac numerator semantic
Hi Florent, On Tue, 22 Nov 2011 09:04:13 +0100 Florent Hivert florent.hiv...@lri.fr wrote: Follow up from thread indexed symbolic variables. Do we have to call Maxima to compute the numerator of a rational fraction ? Is seems to me that Pynac/Ginac should be able to do it by themselves. Unfortunately, we still call maxima for a lot of trivial operations. This is now #12068 To speedup some computation I'm trying to wrap Ginac numer and denom method. Thanks to Cython, this is very easy. However, Maxima and Ginac have a different semantic for those two functions: - Maxima: Does not change the expression; if the expression is not a quotient, then this will return the expression itself. - Ginac: try to normalize the expression to put it in the form N/D and then return N; For example, with an expression such as x + y/(x + 2), - Maxima: numer = x + y/(x + 2), denom = 1 - Ginac: numer = (x^2 + 2x + y), denom = x + 2 I can more or less emulate Maxima's behavior with Ginac, but I'm not sure what's best to do. I see several options: 1 - Forget about Maxima and follows Ginac semantic; 2 - Follows Maxima semantic as close as possible using Ginac; 3 - Have a parameter 'algorithm' to select the needed one. Depending one the algorithm the semantic differ; 4 - Have a parameter 'normal' to select if we normalize or nor the result before computing the numerator, always use Ginac however. 5 - 3 and 4, have two parameters, one for selecting Maxima or Ginac, one for performing a normalization before. 6 - other options ??? In case 3, 4, 5, we also should decide what is the default. What do you think ? I like 4 best, though I suggest calling the parameter 'normalize.' How do you plan to handle normalize=False? I suggest if the expression is not a mul: return self else: separate the positive and negative exponents Thank you. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Symbolic nth_root()
On Sun, 20 Nov 2011 18:16:18 -0800 William Stein wst...@gmail.com wrote: On Sun, Nov 20, 2011 at 5:52 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: When searching sage-support, there are several threads about people complaining they cannot plot x^(1/3) or similar on the negative axis because (-1)^(1/3) is a complex number, not a real number. The answer is to plot something like lambda x:RR(x).nth_root(3). This is not very satisfactory because this is not a symbolic function, so I can't differentiate it for example. It is also more complicated and hard to explain to beginners using Sage. So I think the question still remains: is there something like a symbolic nth_root() function? Or, alternatively, a way of evaluating the symbolic expression x^(1/3) yielding only real numbers with real input? Such functionality would certainly be desirable. I don't think it exists, The symbolic functionality in Sage is supposed to make it easy for users to define a new symbolic function at runtime, including how that function gets simplified. This is supposed to not involve any C++ coding with Pynac. So it _should_ be easy to add what you suggest. Maybe Burcin can pipe up. Here is a symbolic function which wraps RR.nth_root(): from sage.symbolic.function import BuiltinFunction, is_inexact from sage.symbolic.expression import Expression from sage.structure.coerce import parent class RealNthRoot(BuiltinFunction): def __init__(self): BuiltinFunction.__init__(self, real_nth_root, nargs=2) def _eval_(self, base, exp): if (not isinstance(base, Expression) and is_inexact(base)) or \ (not isinstance(exp, Expression) and is_inexact(exp)): self._evalf_(base, exp, parent=parent(base)) def _evalf_(self, base, exp, parent=None): if isinstance(base, float): return RR(base).nth_root(exp) try: return base.nth_root(exp) except AttributeError: return base**(1/exp) return parent(base)**parent(exp) The code is also here: http://sage.math.washington.edu/home/burcin/real_nth_root.py I can plot this without trouble: sage: attach real_nth_root.py sage: real_nth_root = RealNthRoot() sage: v = real_nth_root(x, 3) sage: plot(v, (x, -1, 1)) firefox displays the plot Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Maxima vs Ginac numerator semantic
On Tue, 22 Nov 2011 11:56:51 +0100 Florent Hivert florent.hiv...@lri.fr wrote: method. Thanks to Cython, this is very easy. However, Maxima and Ginac have a different semantic for those two functions: - Maxima: Does not change the expression; if the expression is not a quotient, then this will return the expression itself. - Ginac: try to normalize the expression to put it in the form N/D and then return N; For example, with an expression such as x + y/(x + 2), - Maxima: numer = x + y/(x + 2), denom = 1 - Ginac: numer = (x^2 + 2x + y), denom = x + 2 I can more or less emulate Maxima's behavior with Ginac, but I'm not sure what's best to do. I see several options: 1 - Forget about Maxima and follows Ginac semantic; 2 - Follows Maxima semantic as close as possible using Ginac; 3 - Have a parameter 'algorithm' to select the needed one. Depending one the algorithm the semantic differ; 4 - Have a parameter 'normal' to select if we normalize or nor the result before computing the numerator, always use Ginac however. 5 - 3 and 4, have two parameters, one for selecting Maxima or Ginac, one for performing a normalization before. 6 - other options ??? In case 3, 4, 5, we also should decide what is the default. What do you think ? I like 4 best, though I suggest calling the parameter 'normalize.' How do you plan to handle normalize=False? I suggest if the expression is not a mul: return self else: separate the positive and negative exponents This is indeed what I had in mind. I don't recall a pynac function which separates negative and positive exponents in a mul. There is some code for this in mul::do_print_rat_func() (in Pynac). Maybe we should move that to a new function. How do you do this ATM? AFAIK, you can't access the expairseq stored in a mul from Cython. Any idea for the default for normalize ? IHMO, True. The response you get when it's false is nonsense in most cases. If you want that behavior, you should state that you know what you are doing by passing normalize=False. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] indexed symbolic variables
Hi Florent, On Thu, 17 Nov 2011 14:44:35 +0100 Florent Hivert florent.hiv...@lri.fr wrote: On Wed, Nov 16, 2011 at 03:48:10PM +0100, Burcin Erocal wrote: On Wed, 16 Nov 2011 15:10:54 +0100 Florent Hivert florent.hiv...@lri.fr wrote: Pynac supports indexed expressions already. It just isn't wrapped in Sage yet. Again, there is an experimental patch available: http://sage.math.washington.edu/home/burcin/indexed_expression-20110727.patch Since you can wrap any hashable Python object in a symbolic expression with SR._force_pyobject(), this could replace your IndexedVarExpr class. I would appreciate any help with cleaning up these patches, adding doctests etc. so they can be merged. :) I'll try to cleanup this one, though I don't know anything about Pynac's internal... Is there a lot more work to do than adding doctests ? It should be only doctests, but you never know what comes up. :) I haven't looked at the patch in detail. I don't recall if any low level modification is needed. I'll be on IRC if you run into anything. I'm at a conference so I don't have that much time working on it right now. I'll probably have more time next week. My two first attempts weren't successful: first of all, it seems that you cannot index variables by any Python objects, only integers or sequences of thereof. I typically want to put permutations, trees or group elements in the index. Is that a limitation of Pynac or of your wrapper ? This was a limitation of the wrapper. It tries to coerce the argument to SR. If Pynac doesn't need to do any arithmetic with these objects, one can skip the coercion rules with the SR._force_pyobject() function. I updated the patch to allow arbitrary (hashable) Python objects and omit the dimension argument. Second, I got some Segfault so there is probably more work that only doctest. I have to investigate more to get a simple reproducible behavior. Can you check that I have the latest version of your patch: it is called: indexed_expression-20110727.patch That was the latest version. :) Here is a new one: http://sage.math.washington.edu/home/burcin/indexed_expression_2018.patch Note that I never actually used this. It is possible that there are problems. I can try to fix these when you have a simple example. It's possible that your segfault is caused by #9880. We are trying to finish that ticket off for the next release. Unfortunately, I am really short on time these days. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] indexed symbolic variables
Hi Florent, On Tue, 15 Nov 2011 17:29:38 +0100 Florent Hivert florent.hiv...@lri.fr wrote: moved indexed variable discussion below So I'm trying to inherits from Expression. Here is my code: from sage.symbolic.expression import Expression class IndexedVarExpr(Expression): def index(self): return self._index class IndexedVar(SageObject): def __init__(self, name, parent = SR): self._name = name self._parent = parent @cached_method def __getitem__(self, i): res = IndexedVarExpr(self._parent, self._parent.symbol(%s[%s]%(self._name, i))) res._index = i return res This seems to work as a first glance: sage: Y = IndexedVar(Y) sage: v = Y[1,2,3] sage: v Y[(1, 2, 3)] sage: v^2+1 Y[(1, 2, 3)]^2 + 1 sage: vbis = (v^2+1).variables()[0] sage: vbis Y[(1, 2, 3)] sage: vbis == v Y[(1, 2, 3)] == Y[(1, 2, 3)] sage: bool(vbis == v) True However, vbis doesn't return my exact object: sage: type(v), type(vbis) (class '__main__.IndexedVarExpr', type 'sage.symbolic.expression.Expression') The Expression class hard codes the type of the resulting object after arithmetic, like many other element classes in Sage. This is done for speed of course. There have been many requests of this kind lately, I'm starting to think it is worth the speed penalty. See the discussion here for a patch that should fix the error and some timings: http://groups.google.com/group/sage-support/t/f749ba3cd079c6f4 We would also need this for #9556: http://trac.sagemath.org/sage_trac/ticket/9556 I'm trying to make sage aware of indexed variables. For the information, this is a long standing Sage-Combinat wish. more precisely, basically I need a sage object Y such that, for any object (say hashable) o: 1 - the call Y[o] returns a variable which is legal in symbolic expressions. 2 - the variable v = Y[o] has a method index such that v.index() return o Since Expression doesn't have any __dict__ I can't use the quick hack consisting in inserting the attribute index in it. Pynac supports indexed expressions already. It just isn't wrapped in Sage yet. Again, there is an experimental patch available: http://sage.math.washington.edu/home/burcin/indexed_expression-20110727.patch Since you can wrap any hashable Python object in a symbolic expression with SR._force_pyobject(), this could replace your IndexedVarExpr class. I would appreciate any help with cleaning up these patches, adding doctests etc. so they can be merged. :) Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] indexed symbolic variables
On Wed, 16 Nov 2011 15:10:54 +0100
Florent Hivert florent.hiv...@lri.fr wrote:
Pynac supports indexed expressions already. It just isn't wrapped in
Sage yet. Again, there is an experimental patch available:
http://sage.math.washington.edu/home/burcin/indexed_expression-20110727.patch
Since you can wrap any hashable Python object in a symbolic
expression with SR._force_pyobject(), this could replace your
IndexedVarExpr class.
I would appreciate any help with cleaning up these patches, adding
doctests etc. so they can be merged. :)
I'll try to cleanup this one, though I don't know anything about
Pynac's internal... Is there a lot more work to do than adding
doctests ?
It should be only doctests, but you never know what comes up. :)
I haven't looked at the patch in detail. I don't recall if any low
level modification is needed. I'll be on IRC if you run into anything.
Thanks a lot for looking into this.
By the way my buggy implementation revealed something that looks
strange to me:
sage: Z = IndexedVar(Z)
sage: ex = (Z[1] + Z[2])/(Z[3] + Z[4])
sage: ex
(Z[1] + Z[2])/(Z[3] + Z[4])
sage: ex.numerator()
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (647, 0))
---
TypeError Traceback (most recent call
last) [...]
TypeError: unable to make sense of Maxima expression 'Z[2]+Z[1]' in
Sage
Do we have to call Maxima to compute the numerator of a rational
fraction ? Is seems to me that Pynac/Ginac should be able to do it by
themselves.
Unfortunately, we still call maxima for a lot of trivial operations.
For example, pynac can easily handle the functions
Expression.{coeff,poly}().
Feel free to open tickets for these issues.
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] deprecate symbolic function call notation
On Mon, 7 Nov 2011 12:00:57 -0800 William Stein wst...@gmail.com wrote: Twice in the last day I've hit this deprecation warning due to making a stupid typo: sage: d(N) = (1/2)*(N^2-1)(N^2-N)/(N-1) # contains stupid typo /Users/wstein/sage/install/current/local/lib/python2.6/site-packages/IPython/iplib.py:2073: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...) exec code_obj in self.user_global_ns, self.user_ns I've been trying to get rid of this mistake in symbolic calculus since probably 2007. I say we get rid of it soon, e.g., in sage-4.8 (or certainly in sage-5.0). It's time for it to go. This is #8214: http://trac.sagemath.org/sage_trac/ticket/8214 It would be great to finally remove this warning and display a helpful message instead. Unfortunately, I don't have any time to work on this these days. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: or sage-5.0? (Re: [sage-release] Next release: sage-4.7.3 or sage-4.8?)
On Sat, 5 Nov 2011 17:23:38 -0700 (PDT) leif not.rea...@online.de wrote: On 5 Nov., 21:24, Justin C. Walker jus...@mac.com wrote: On Nov 5, 2011, at 12:16 , Julien Puydt wrote: Le 05/11/2011 17:42, William Stein a écrit : What do you base this probably on? Having started and watched Sage evolve of over 6 years, if anything it is not evolving in the direction you suggest. Fair point. But that can't last. Trying to make a self-contained system that utilizes a wide variety of system-provided libraries is an exercise leading to premature grey hair and high blood pressure. There are so many different versions of each library and system (for Linux, in particular) that it's a practical impossibility to produce a package like Sage that will work on the systems currently supported. Well, one could check much more in Sage's 'configure', and eventually instruct the user to install (or update) some system packages and/or download additional spkgs, probably specific to the system (e.g. MacOS X, Cygwin, Solaris). We could keep the bloated [almost] everything included source tarball, but could also offer a stripped-down one which doesn't carry all that unnecessary baggage (like Cephes, iconv, termcap, readline, gfortran binaries(!), patch, Mercurial, ...). Projects like Sage-on-Gentoo show that it's possible to use much more system packages / libraries than we do, and shipping all *by* *default* (without any option to omit some packages), some just doing if [ $UNAME = foo ]; then # no need to build it on 'foo' exit 0 fi or building vanilla upstream without any Sage-specific configuration (except --prefix=...) is certainly suboptimal, although probably easier to maintain (modulo issues *we* have to deal with that would otherwise get reported upstream, either package or OS / distribution). As discussed elsewhere, a first step would be to split off the Sage- specific parts of spkgs from the upstream tarball / source tree. We'd also need better dependencies, with version number matching, a distinction between build and runtime requirements, etc. pp., i.e. modular, formal package metadata (which could include our current build scripts, although they'd also better be split into pieces, with a lot factored out). Most of this has already been done by the sage-on-gentoo project. Using gentoo-prefix, it is even possible to install it on different operating systems. I've been working on making a sage like distribution by merging these two. The repository is here: https://bitbucket.org/burcin/sage-prefix Instructions on the bitbucket wiki are probably old. Latest tarball is here: http://www.lmona.de/files/prefix-20111027.tar.bz2 With this framework, it would be simple to split the profiles for different linux distributions and customize the package.provided file to install only a subset of the dependencies. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: libSingular much slower than Singular via pexpect??
Hi Simon, On Thu, 27 Oct 2011 03:11:42 -0700 (PDT) Simon King simon.k...@uni-jena.de wrote: On 27 Okt., 11:39, Martin Albrecht martinralbre...@googlemail.com wrote: On Thursday 27 October 2011, Simon King wrote: Is that something to worry about? Yes! Good. I created trac ticket #11957. Hence my guess: we are using different memory allocation functions for GMP and these functions might be slower (for Singular's use case)? Isn't Singular using a fairly uncommon memory management? If I remember correctly what Hans presented at the last Singular Sage Days in Kaiserslautern, their memory management is a lot faster for what Singular needs. Singular uses omalloc for memory management. This library was developed by Olaf Bachmann specifically for Singular's use case. This blog post has some slides about it: http://singular-team.blogspot.com/2011/09/sicsa2011.html I don't think we can use omalloc in Sage since it is not thread safe. Using GMP with two different memory allocators is not an option either. So I am not sure if this problem can be solved easily. On the other hand, any help to make omalloc thread safe would be much appreciated. :) Interested parties should contact libsingular-devel@googlegroups. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: asking if Sage has support for computations with differential operators
Hi Pablo,
On Sat, 22 Oct 2011 18:49:39 -0300
Pablo De Napoli pden...@gmail.com wrote:
On Thu, Oct 20, 2011 at 6:02 PM, Pablo De Napoli pden...@gmail.com
wrote:
Hi,
I need to perform computations with linear differential operators
whose coefficients are polynomials
in several variables (in Euclean space).
Has Sage some support for this kind of computation?
Could you suggest me some tool for doing that?
For instance assume that you have two first order differentian
operators (vector fields in the language of differential geometry)
like
X = x D_x - y D_y
Y= x D_x - y D_z
where D_x is the partial derivative with respect to x. I would like
to compute XY
[which is a second order operator], or things like the Lie bracket
[X,Y]=XY-YX) [which is a first order one]
You can also do this in Sage, after applying the patches at #4539:
http://trac.sagemath.org/sage_trac/ticket/4539
This is a generic interface to the noncommutative part of Singular.
http://www.singular.uni-kl.de/Manual/latest/sing_387.htm#SEC427
sage: F.x,y,z,dx,dy,dz = FreeAlgebra(QQ, 6)
sage: G = F.g_algebra({dx*x: x*dx + 1, dy*y: y*dy + 1, dz*z: z*dz + 1})
sage: G.inject_variables()
Defining x, y, z, dx, dy, dz
sage: X = x*dx - y*dy
sage: Y = x*dx - y*dz
sage: X*Y
x^2*dx^2 - x*y*dx*dy - x*y*dx*dz + y^2*dy*dz + x*dx + y*dz
sage: X*Y - Y*X
y*dz
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: asking if Sage has support for computations with differential operators
Hi Pablo, On Mon, 24 Oct 2011 10:32:12 -0300 Pablo De Napoli pden...@gmail.com wrote: Many thanks! I see that with this patches, it would be esasy to have also a Weyl algebra implementation in Sage Yes, writing constructors for Weyl algebras will be an easy step when it is merged. We've been waiting a long time for this. Thanks to Alexander Dreyer and Oleksandr Motsak's work at SD24 and Simon King's at SD34, it is finally ready. :) Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Bug in symbolic expression simplification?
On Sun, 16 Oct 2011 11:06:54 -0700 (PDT) Simon King simon.k...@uni-jena.de wrote: Bump. On 13 Okt., 08:43, Simon King simon.k...@uni-jena.de wrote: ... sage: q1 = SR(p1) sage: q2 = SR(p2) sage: q3 = SR(p3) sage: q4 = SR(p4) sage: q5 = SR(p5) sage: q = ((q1/q2+q3)^2+(q3/(q4+q5)))/((q3/(q4+q5/(q1+q2)))+q2) sage: q.simplify() Traceback (most recent call last): ... TypeError: Do you agree that an error in simplifying a simple arithmetic expression of polynomial symbolic expressions is a bug? Do you agree that a naked type error (that gives no hint on what's wrong) is another bug? I agree that raising an error without a message is a bug and we should open a ticket. Keshav already pointed out the cause of the problem in his message. It's a one line fix + the relevant doctests. ATM, simplify() just converts the expression to maxima and get's it back. If you change the coefficient ring for the polynomial ring to one that we can convert to maxima (say QQ), even then simplify doesn't do anything to the expression. simplify_rational() does. Making simplify() work for this expression can be an enhancement, though without a concrete solution strategy, I'm not sure if we should open a ticket. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Choosing names for exponential integral type special functions
On Sat, 15 Oct 2011 14:40:49 -0700 (PDT) Benjamin Jones benjaminfjo...@gmail.com wrote: In Trac ticket #11143, there is some discussion [1] about the naming of exponential integral type special functions which are added to the global namespace there. Here are the names of the functions which are wrapped in #11143, according to Maxima: expintegral_e (v,z)Exponential integral E expintegral_e1 (z) Exponential integral E1 expintegral_ei (z) Exponential integral Ei expintegral_li (z) Logarithmic integral Li expintegral_si (z) Exponential integral Si expintegral_ci (z) Exponential integral Ci expintegral_shi (z)Exponential integral Shi expintegral_chi (z)Exponential integral Chi In the patch provided (by me) for #11143, all the functions are called ``exp_integral_*`` where * is e, e1, ei, li, etc.. It was suggested to change the names to something more intuitive, for example ``log_integral`` intstead of ``exp_integral_li``. This would match the names of these functions in Mathematica and Maple, for example. On the other hand, having the whole group of function named starting with ``exp_integral_*`` allows the user to type ``exp_integraltab`` and see the list of all the functions in this group easily. I like the log_integral, sin_integral forms better. For tab completion, you could import the sage.functions module to the command line. This will give: sage: functions.exp_integral.tab functions.exp_integral.exp_integral_e functions.exp_integral.exp_integral_e1 functions.exp_integral.exp_integral_ei functions.exp_integral.log_integral functions.exp_integral.log_integral_offset functions.exp_integral.cos_integral functions.exp_integral.sin_integral functions.exp_integral.sinh_integral functions.exp_integral.cosh_integral Since these functions will also be available in the reference manual, it shouldn't be so hard to find them. Thanks for all the great work on this ticket. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Bug in symbolic expression simplification?
On Tue, 18 Oct 2011 10:26:57 -0700 (PDT) Simon King simon.k...@uni-jena.de wrote: On 18 Okt., 19:08, Burcin Erocal bur...@erocal.org wrote: ATM, simplify() just converts the expression to maxima and get's it back. If you change the coefficient ring for the polynomial ring to one that we can convert to maxima (say QQ), even then simplify doesn't do anything to the expression. simplify_rational() does. Note that (if I remember correctly) q.simplify_rational() is raising a TypeError without error message as well. I know. With Keshav's suggested fix, there will be an error message like Cannot convert complex interval field elements to maxima. I don't think we can do better, unless maxima can work with intervals. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GiNaC and Python disagree on arithmetic
Hi Keshav, On Mon, 12 Sep 2011 03:16:27 -0700 (PDT) Keshav Kini keshav.k...@gmail.com wrote: I believe that error message is propagated from GiNaC. See line 523 of src/ginac/power.cpp in the pynac spkg. The error message is hard-coded and doesn't refer to python's eval() function. This should be fixed in pynac. Since you already spent the time to identify the problem, do you want to submit a patch with the fix? https://bitbucket.org/burcin/pynac/src Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] polymake wrapper
Hi, I just uploaded a prototype python wrapper for the new library interface to polymake on bitbucket: https://bitbucket.org/burcin/pypolymake The docstrings in polymake.pyx contain examples of what is possible right now: https://bitbucket.org/burcin/pypolymake/src/tip/polymake.pyx#cl-105 The wrapper looks much uglier than it should be. I wanted to use the C++ support in Cython. Unfortunately, I couldn't get many things working with the Cython version in Sage (0.14). I didn't try installing the latest version of Cython (0.15). Getting the wrapper working, that is, installing Sage, polymake and the wrapper properly is a major hassle. There are instructions below describing how I set up my testing environment within Sage. A few remarks: - The latest polymake version (2.10) doesn't build with the partial boost install that comes with Sage. I just used a package I had from a prerelease. - Embedding perl in a python module is quite an adventure. Perl needs the RTLD_GLOBAL flag to be set so that the modules it loads can find symbols from the main (perl) library. However, modifying dlopenflags with sys.setdlopenflags() doesn't help (at least on my machine). It seems that adding the polymake library to LD_PRELOAD is the only solution for now. Installation instructions: - get a recent Sage version (we won't apply any patches to Sage) - Update the MPFI and MPFR versions in Sage ./sage -i http://sage.math.washington.edu/home/burcin/polymake/mpfi-1.5.spkg ./sage -i http://sage.math.washington.edu/home/burcin/polymake/mpfr-3.0.0.spkg - Rebuild MPIR: ./sage -f spkg/standard/mpir-1.2.2.p2.spkg - Install (old) polymake: http://sage.math.washington.edu/home/burcin/polymake/polymake-2.9.10.p0.spkg - rebuild (part of) Sage library so that it works with the updates ./sage -b - go to $SAGE_ROOT/local/bin and apply attached sage-env.patch cd local/bin hg qimport sage-env.patch hg qpush - Clone the wrapper hg clone https://bitbucket.org/burcin/pypolymake - Start a sage shell, go into the wrapper directory and install ./sage -sh cd wrapper_dir python setup.py install - Preferably on a different shell, start sage and enjoy Comments suggestions welcome. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage/Singular days - Kaiserslautern - Sept 26-30
Hi, there will be a Sage/Singular workshop in Kaiserslautern, Germany on September 26-30, 2011. http://wiki.sagemath.org/days34 The main focus of the meeting will be to improve libSingular and the Sage - Singular interface. We anticipate a coding oriented event with few talks. Newcomers, especially those interested in C-level usage of Singular or writing Sage interfaces are welcome. So far we did not plan any tutorial sessions, but some veterans will be present to answer questions. We have limited funding to support travel and accommodation costs. Please write to the organizers if you need financial support. There is no registration fee or a formal application procedure. If you plan to participate, please add your name to the list on the wiki page http://wiki.sagemath.org/days34 or contact the organizers. This will help us with the local arrangements. Looking forward to seeing you there. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Citing used Sage components automatically
Hi Andrey,
On Wed, 27 Jul 2011 10:08:18 -0700 (PDT)
Andrey Novoseltsev novos...@gmail.com wrote:
I have just looked over PARI citing discussion and recently I had a
talk with a developer of a software package X who was concerned that
inclusion of X into Sage will mean that people will stop giving credit
to X (and this developer in particular ;-)) Sometime ago there were
suggestions to somehow gather statistics on how many times which
function was called, which in practice does not seem like a great idea
due to performance hits and privacy issues. Figuring out manually
which components are used is somewhat boring and actually quite hard.
But how about this: suppose I have written a function f that does what
I need and I want to properly cite people and systems who made it
possible, but at the same time I am too busy/lazy to do much to
achieve it. However, I can do
sage: uc = UsedComponents(f(75))
and then
sage: uc
Flint, PARI, Singular
sage: print uc.acknowledgement()
Computations were performed using CAS Sage~\cite{Sage}, interfacing
Flint~\cite{Flint}, PARI~\cite{PARI}, Singular~\cite{Singular}.
which I copy-paste into my paper (or better yet - use SageTeX) and
sage: print uc.BiBTeX()
BiBTeX entries for keys Flint, PARI, Sage, Singular
which I include into my bibliography file (or hopefully SageTeX can
somehow take care of).
To get these lists, it seems to me that one can execute the code
f(75) in a profiler, collect used functions, and then look for
substrings (either modules or particular functions) from a list that
gives matches of substrings to components. This list has to be
manually maintained, as in general this matching is probably non-
trivial, but authours of particular functions and interfaces can
easily add them, I think. As a bonus such automated citer will include
proper versions for everything.
We already have this, without the bibtex formatting of course:
sage: from sage.misc.citation import get_systems
sage: get_systems(integrate(cos(x^2), x))
['MPFI', 'ginac', 'GMP', 'Maxima']
There are also two issues on trac about this #3317 and #1422.
I've heard similar complaints from many people, including the Singular
group where I'm currently employed. It's true that Sage can do much
better to provide information on what was used in the background during
a computation, but overall, I think the main problem with citations is
changing the perspective of the users.
For many years, this field was dominated by large, closed computer
algebra systems. Even though some were more transparent than others,
it became common place to say MMA can compute this, Magma can do that.
As pointed out in the Sage Pari thread recently, we should give
credit to the algorithm and the implementor for a nontrivial
computation.
To improve the capabilities of Sage to provide such information, Niels
Ranosch, a student currently employed in Oberwolfach (and supervised by
Michael Brickenstein), is implementing a new citation module:
https://bitbucket.org/niels_mfo/sage-citation/
We plan to start integrating this in Sage in August. To describe the
motivation and the goals to Niels, I'd started writing this:
http://bitbucket.org/niels_mfo/sage-citation/src/e13a2151d368/citation_description.rst
This blog entry has some design details, subject to change of course:
http://sage-citation.blogspot.com/2011/07/design.html
We would appreciate any comments and suggestions on this citation
system. At this stage, it is just an experiment for us too. :)
There are also plans to make a C-library interface to such a system, so
that libraries used during a computation, for example libSingular or
Gfan, can provide the citation information directly. Unfortunately,
there is no real code for this yet, apart from a header file defining
the proposed interface.
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Citing used Sage components automatically
On Wed, 27 Jul 2011 10:40:02 -0700 William Stein wst...@gmail.com wrote: On Wed, Jul 27, 2011 at 10:08 AM, Andrey Novoseltsev novos...@gmail.com wrote: I have just looked over PARI citing discussion and recently I had a talk with a developer of a software package X who was concerned that inclusion of X into Sage will mean that people will stop giving credit to X (and this developer in particular ;-)) Sometime ago there were suggestions to somehow gather statistics on how many times which function was called, which in practice does not seem like a great idea due to performance hits and privacy issues. Figuring out manually which components are used is somewhat boring and actually quite hard. But how about this: suppose I have written a function f that does what I need and I want to properly cite people and systems who made it possible, but at the same time I am too busy/lazy to do much to achieve it. However, I can do sage: uc = UsedComponents(f(75)) I believe Mike Hansen implemented something that does the above (using the profiler) already. However, I don't remember if it is in Sage or not, or where to find it. Maybe we should export this function to the top level namespace and put an entry in the FAQ. sage: from sage.misc.citation import get_systems sage: get_systems(integrate(cos(x), x)) ['ginac', 'Maxima'] If nothing else, it would be very nice if we had an entry in the database for each paper listed here: http://sagemath.org/library-publications.html showing what systems are used. For example, at would be good if somebody wrote a webform or something for submitting papers, and part of what it asked is for a list of systems used (and a command like you mention above would be suggested by the form). Then we could make it so after each entry in http://sagemath.org/library-publications.html there would be a little list of links for the components used, or a single link to a list of components for that paper, or maybe just a way of showing all papers that use a given component. Then when Karim B. of PARI complains you don't cite us, we can respond with a link like: http://sagemath.org/library-publications.html?system=pari that shows a nicely formatted list of papers all of which cite PARI. He can then include a link to this list in his grant proposals, etc. Many, many components of Sage (including Pari!?) don't have a page listing publications that used their system, so we would be providing a useful service to them. Great idea! Such statistics would also help convince package authors that Sage provides exposure for their project as well as a separate (mathematical) test suite, regular build tests on many platforms and in many cases bug fixes. Like Andrey, I heard the FUD that inclusion of X into Sage will mean that people will stop giving credit to X. Maybe we should be more proactive about this issue. How about changing the credits() function to include a list of components of Sage with links to their web pages and an example with the get_systems() function? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Adding new unit tests
On Mon, 25 Jul 2011 12:20:35 -0400 Michael Orlitzky mich...@orlitzky.com wrote: On 07/20/11 13:26, Burcin Erocal wrote: If you are adding tests only for integration, starting a new file sage/symbolic/tests.py might be better. ... Don't forget to mention the ticket number in the test. How's this looking? It is a good start. Here are some suggestions: - The code blocks should be preceeded with :: and indented. More information is available here: http://sagemath.org/doc/developer/conventions.html#documentation-strings - Since the file only contains integration tests, sage/symbolic/integration/tests.py is a better place for it IMHO. - I am not sure if a separate comment block is necessary for each test. I guess this makes sure that the test environment is always clean. It might add up to the time since it starts Sage so many times though. You can create a new ticket on trac and upload the patch there so it doesn't get lost. Thanks. Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Fw: Save Feza Gursey Institute! -- http://savefezagursey.wordpress.com
Hi, Feza Gursey Institute in Turkey, which hosted the only Sage notebook server in Turkey and contributed a Turkish translation of the notebook as well as hosting many workshops to popularize computational algebra, is being closed. There is more information below, with a (hidden) link to the petition: Petition: http://savefezagursey.wordpress.com/imza-kampanyasi-petition/ It would be a great help if you can sign the petition and spread the word. Burcin PLEASE DELETE THE ABOVE LINES BEFORE REDISTRIBUTING = Dear Colleague, The current administration of TUBITAK, the Turkish counterpart of NSF/DFG/CNRS, has decided to close down the Feza Gursey Institute (FGI), Turkey’s only institute devoted to research in theoretical physics and mathematics. To help us you may want to write a letter directly to the Science, Technology and Industry Minister, the president of TUBITAK and/or to also consider signing the petition. We would be happy to publish your letter in http://savefezagursey.wordpress.com/category/akademisyen-mektuplari/akademisyen-mektuplari-int/ For your letters, you could use the following header, the email addresses and the fax numbers: Dear Minister Nihat Ergun, Minister of Science, Technology and Industry Dear Dr. Hüsnü Tekin, Deputy Undersecretary, Ministry of Science, Technology and Industry Dear Professor Nuket Yetis, TUBITAK President nihat.er...@tbmm.gov.tr, husnu.te...@sanayi.gov.tr nuket.ye...@tubitak.gov.tr, Fax: +90 312 219 67 45 (Minister Nihat Ergun) Fax: +90 312 219 68 22 (Deputy Undersecretary Dr. Husnu Tekin) Fax: +90 312 467 95 82 (TUBITAK President Prof. Nuket Yetis) Petition: http://savefezagursey.wordpress.com/imza-kampanyasi-petition/ More detailed information can be found in the attachments of this email or on the blog http://savefezagursey.wordpress.com as well as many letters written to the Minister and the TUBITAK President. Some websites supporting Feza Gursey Institute: http://www.phys.sci.kobe-u.ac.jp/~hetweb/fgisave/ http://noncommutativegeometry.blogspot.com/ Thank you very much for all your support. Best regards, savefezagursey.wordpress.com PS : We would also be grateful if you could distribute this message. ABOUT THE ATTACHMENTS: (1) CallForHelpFezaGursey.txt -- gives a more in depth description of what is happening to the only theoretical physics and math institute of Turkey, Feza Gursey Institute. (2) PublicDeclarationByTUBITAKInformationOffice.txt ( also available at http://savefezagursey.wordpress.com/2011/07/21/tubitaks-public-declaration/ at the REQUEST of TUBITAK Information Office ) -- Upon writing a letter to the TUBITAK President Prof. Nuket Yetis, you will receive the Public Declaration in the form of a letter from the president as Prof. Sonoda of Kobe University did: http://www.phys.sci.kobe-u.ac.jp/~hetweb/fgisave/TBAE-EN.pdf (3) AReplytoPublicDeclaration.txt ( also available at http://savefezagursey.wordpress.com/2011/07/21/an-answer-to-public-declaration/ ) -- clarifies some untouched points in the Public Declaration and asks some significant questions... TUBITAK Information Office has made no further public announcements YET! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org Dear Professor, Feza Gursey Institute, Turkey's single theoretical physics and math institute was closed down by TUBITAK, the mother organization to which Feza Gursey Insitute belongs to. This decision - was made by TUBITAK's highest council, named the Scientific Board on July 9th, - was delivered to the Institute on July 11th, - and declared that Feza Gursey Institute is going to become a part of the Informatics and Information Safety Center (BILGEM in Turkish) in Gebze, the main research campus of TUBITAK, by July 15th. By this decision, the charter of Feza Gursey Institute was changed in two ways: - Structural Changes: As a part of this Information Safety Center, Feza Gursey Institute is no longer an independent institute, but rather a department within this cryptology research center. - Scientific Changes: Feza Gursey Institute mission was redefined to help pure and applied problems of Turkey, etc... Although it seems that TUBITAK would keep the renowned physicist Feza Gursey's name for the institute, Institute will be terminated as a theoretical physics and math institute and will be reinvented as an applied sciences Institute within Information Safety Center, BILGEM. Here, I add a very raw English translation of the decision letter to close down/restructure Feza Gursey Institute and the following preliminary paragraph about Feza Gursey Institute's history: = Preliminary Information for the second paragraph of the
Re: [sage-devel] Importing units into module
Hi, On Thu, 21 Jul 2011 00:42:38 -0700 (PDT) Eviatar eviatarb...@gmail.com wrote: I am working on a physical constants module, but for whatever reason I can't get it to correctly import the units module. I import the units class using from units import units, but I get: snip /home/eviatar/sage-4.7-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux/ local/lib/python2.6/site-packages/sage/symbolic/all.py in module() 12 from units import units 13 --- 14 import physical_constants 15 16 snip backtrace Is it a problem that physical_constants is imported in all.py along with the units module? Because when I run the file using %run, there is no error. I don't see what other way there is to do it though. You introduce a circular import when you add the import statement for physical constants to sage/symbolic/all.py. The first part of the traceback looks exactly like the one from #6. I was just trying to clean up some of those dependencies. The patch attached to that ticket doesn't solve the problem there, but it might help you. http://trac.sagemath.org/sage_trac/attachment/ticket/6/trac_6-fix_imports.patch Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Adding new unit tests
On Tue, 19 Jul 2011 14:44:10 -0400 Michael Orlitzky mich...@orlitzky.com wrote: 2. Subject to #1, where is the most appropriate place to add the tests? My first guess would be in the TESTS: section of sage/calculus/calculus.py, but there appear to be some standalone tests defined in sage/tests, too. If you are adding tests only for integration, starting a new file sage/symbolic/tests.py might be better. There is a list of open integration tickets here: http://trac.sagemath.org/sage_trac/wiki/symbolics Don't forget to mention the ticket number in the test. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Matrix multiplication
Hi Simon, On Thu, 14 Jul 2011 07:40:24 -0700 (PDT) Simon King simon.k...@uni-jena.de wrote: On 14 Jul., 16:37, Simon King simon.k...@uni-jena.de wrote: Perhaps it would be best to study http://sage.math.washington.edu/home/burcin/dense_ctypes.patch Is there a ticket where that patch is dealt with? AFAIK, there are 3 tickets on trac: 4260, 4968, 4258 We could merge these and close 2 of them as duplicates. When I get a chance I will take a look at redoing the template structure in the dense_ctypes.patch. I am back to normal schedule only today, so this will probably happen sometime tomorrow. Perhaps you can help with the pickling, coercion, etc. problems once I get the linbox wrapper working. ;) Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Matrix multiplication
On Tue, 12 Jul 2011 14:12:18 -0700 (PDT) Simon King simon.k...@uni-jena.de wrote: On 12 Jul., 21:09, Martin Albrecht martinralbre...@googlemail.com wrote: If one is serious about this then one should probably use the FFLAS/FFPACK low-level routines directly (Burcin might have some old patches for this, he's the last person I know of who tried) since that avoids compiling all thee layers of C++ in LinBox. That would probably be beyond my scope. At SD16, Clement and I looked into wrapping linbox directly. The speeds were promising, but we never took the time to fix pickling, etc. The patch is most likely unusable by now: http://sage.math.washington.edu/home/burcin/dense_ctypes.patch I can quickly redo the work to create a template that handles the short and long ints as special cases if there is interest. The linbox calls in that patch can also be much better now that Cython has C++ support. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Iterator appears to be broken in 4.7
On Sat, 18 Jun 2011 23:08:27 -0700 Jason Grout jason-s...@creativetrax.com wrote: On 6/18/11 10:59 PM, Ars-Magna wrote: Hi all, I noticed that in the 4.6.2 one has the following expected behavior sage: list(x.iterator()) [] where as in 4.7 sage: list(x.iterator()) ValueError . Is it just my machine or any one else observed this behavior I wanted to confirm before creating a Ticket. What is x? I suppose it's a symbolic variable. This was changed in #7537: http://trac.sagemath.org/sage_trac/ticket/7537 Why do you think an empty list is the expected behavior? Note that t.operator() will return None for any object that does not have a list of operands (constant, numeric or symbol). This can be used as a test criteria if you are trying to traverse the expression tree. Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Translation
Merhaba Ege, On Tue, 14 Jun 2011 06:01:44 -0700 (PDT) Ege Sertçetin sertce...@itu.edu.tr wrote: I now translated it. Does the person I will show it have to be a developer of Sage? I'd be happy to review the translation. When you open a ticket [1] add me (user name: burcin) to the CC list please. [1] http://sagemath.org/doc/developer/trac.html Thanks. Burcin On Jun 14, 2:13 pm, Minh Nguyen nguyenmi...@gmail.com wrote: Hi, On Tue, Jun 14, 2011 at 8:58 PM, Ege Sertçetin sertcetin...@gmail.com wrote: Also I can find one or two person to help translating. But I don't know where to start. As a first step, you could try translating the document A Tour of Sage [1]. It's short and would require less work to translate than the Sage tutorial [2]. Once you have translated A Tour of Sage, you need to get another person to review your translation, preferably someone fluent in Turkish. It's very important that anything that goes into the official Sage distribution be reviewed by someone other than the person who wrote it. [1]http://www.sagemath.org/doc/a_tour_of_sage/ [2]http://www.sagemath.org/doc/tutorial/ -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ANN] flint 2.2 released
Hi, On Fri, 10 Jun 2011 09:27:47 +0100 Martin Albrecht martinralbre...@googlemail.com wrote: I'm wondering whether we should do a Sage-FLINT days thingy/coding sprint (either somewhere in the big blue room or online) to make use of all the cool new features in FLINT 2.x? Or should we wait until everything from 1.5 are in 2.x? We could do it gradually if it was possible to install the two side by side. Since the API changed drastically and 2.x will not provide all the bells and whistles of 1.x in the near future (by fast-paced full of impatience Sage measures), this makes perfect sense. Could anybody modify the build system so we can use both of these together? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sage days in KL in September
Hi, we are planning to organize Sage/Singular days in Kaiserslautern some time in September. The focus will be on the development of the Sage-Singular interface, and libSingular, but anybody interested is welcome to participate. Financial support will be available, especially for the brave who can look libSingular in the eye. :) If you are interested, please write back to me this week with date constraints and any other suggestions. We will probably settle the dates towards the end of next week. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage-4.7 release schedule
On Sun, 15 May 2011 20:51:54 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: On the other hand singular seems to be getting a python interface it may be an idea to investigate switching to that. This interface allows calling python from the Singular interpreter, which gives access to PolyBoRi for example. Modulo a few bugs, Sage functions can also be called this way. If anybody is interested in experimenting with these features I'd be happy to help. Getting things running initially might be a bit of a hassle, at least if you intend to call Sage. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Sun, 08 May 2011 07:06:03 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: On Sat, 07 May 2011 21:15:11 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: Removing the sse2 use flag makes the gf2x build crash. Should NTL depend on gf2x conditionally? snip log exchange I see the kind of problem in configure. It will be a problem if we want to create binaries for older machines. It is definitely a bug. That raise the question of useflags do we give people some choices before they start? We should make sure the packages build with different use flags. They provide great flexibility. In this case, they could just replace the SAGE_FAT_BINARY environment variable. I don't know how/when to let the user configure use flags. I only set sse2 by default because gf2x didn't build otherwise. :) I would expect this to be done by some autodetect script in the future, but for now, we can make the install script work in two stages. First sets up portage proper, the next stage installs the rest which would include packages that might be affected by the optimization flags. I will introduce functions for these stages in install.sh and allow them to be run individually with command line arguments. Thanks. Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Sat, 7 May 2011 08:39:07 -0700 (PDT) Volker Braun vbraun.n...@gmail.com wrote: On Saturday, May 7, 2011 3:57:02 PM UTC+1, Burcin Erocal wrote: Since there is already the standard CFLAGS variable I didn't implement an extra WRAPPER_CFLAGS. I want the compiler wrapper to handle building programs within the prefix without the user having to keep track of the prefix root, etc. The prefix should be easy to use as a development environment for math software, where all the core libraries are already present. Then why not use CPATH / C_INCLUDE_PATH / CPLUS_INCLUDE_PATH? http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html Because I didn't know about them. :) I will change the baselayout-prefix ebuild to add these as default environment variables for the prefix. This saves me having to patch compilerwrapper. Thanks. Are these GCC specific? Are there equivalent parameters for Intel/Sun compilers? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Wed, 11 May 2011 00:10:29 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: On Sun, 08 May 2011 07:06:03 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: On Sat, 07 May 2011 21:15:11 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: Removing the sse2 use flag makes the gf2x build crash. Should NTL depend on gf2x conditionally? snip log exchange I see the kind of problem in configure. It will be a problem if we want to create binaries for older machines. It is definitely a bug. That raise the question of useflags do we give people some choices before they start? We should make sure the packages build with different use flags. They provide great flexibility. In this case, they could just replace the SAGE_FAT_BINARY environment variable. I don't know how/when to let the user configure use flags. I only set sse2 by default because gf2x didn't build otherwise. :) I would expect this to be done by some autodetect script in the future, but for now, we can make the install script work in two stages. First sets up portage proper, the next stage installs the rest which would include packages that might be affected by the optimization flags. I will introduce functions for these stages in install.sh and allow them to be run individually with command line arguments. OK, I am sorry I haven't provided you with a fix yet. Things are a bit hectic again for me at the moment. Hopefully I'll have a nice quiet spot on Thursday. No worries. We also haven't faced any of the bigger outstanding issues, like relocating the tree or setting up packages in an easy to patch/developer friendly way. There really is no hurry to fix this. :) Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Sat, 07 May 2011 21:15:11 +1200
Francois Bissey francois.bis...@canterbury.ac.nz wrote:
On Thu, 05 May 2011 00:33:57 +1200
I added support for logging and put the repository on bitbucket:
https://bitbucket.org/burcin/sage-prefix
I will be heading home now. No time to make a new tarball
unfortunately.
Tomorrow, I will try to look into Volker's problem with NTL. You are
probably right and it is caused by the wrapper not working as
expected.
Removing the sse2 use flag makes the gf2x build crash. Should NTL
depend on gf2x conditionally?
That's not normal. Could you forward me the failing log? As for
conditional dependency it used to be that way but I don't see a
reason to change it.
I'm building without the sse2 use flag now. I'll put the logs up
somewhere if/when it fails.
I have started populating your tree - it is not complete yet. I think
I haven't put any autotools which will be an extra requirement
compared to vanilla sage. I will also create a virtual/gmp so we can
switch between mpir and gmp. I am not sure how complete this is yet.
I'll have to test from the mac :)
I just pushed some more changes to bitbucket. The latest version builds
on a 32-bit debian squeeze machine. I will also try it on other linux
variants I find.
http://sage.math.washington.edu/home/burcin/sage-prefix-20110507.tar
I am hoping to get away without installing autotools, at least on
platforms Sage doesn't need them. Using the gentoo wrappers for
auto{conf,make} were enough for debian. It seems the debian autoconf
wrapper chooses the older version by default whereas gentoo picks the newer
one. :)
This tarball should also solve Volker's problem where ntl couldn't find
gf2x. I realized that I completely misunderstood what exactly the
compilerwrapper does. After all it was necessary to add the include and
library paths to CFLAGS. I plan to patch compilerwrapper in the future
to do this itself.
Cheers,
Burcin
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Sat, 07 May 2011 21:15:11 +1200 Francois Bissey francois.bis...@canterbury.ac.nz wrote: Removing the sse2 use flag makes the gf2x build crash. Should NTL depend on gf2x conditionally? That's not normal. Could you forward me the failing log? As for conditional dependency it used to be that way but I don't see a reason to change it. Here is the log: http://sage.math.washington.edu/home/burcin/gf2x-0.9.5:20110507-133059.log All the logs from that build are here: http://sage.math.washington.edu/home/burcin/gf2x_sse2_logs.tar.bz2 This should be reproducible by just removing any mention of sse2 from install.sh. Thank you. Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage gentoo prefix
On Sat, 7 May 2011 07:30:52 -0700 (PDT) Volker Braun vbraun.n...@gmail.com wrote: You shouldn't need autotools to build anything, only the autogenerated scripts that are in the source tarball. But it seems like some patches are re-running autoconf. On my Fedora 14 install it breaks early on: snip error log Unfortunately gentoo ebuilds assume that autotools are available. Initially, it failed in the same place while trying to build on debian. If you already have autoconf and autoheader, it is merely a problem of the wrapper picking the right executable. I will see if I can get access to a fedora 14 box to fix this. Thanks. Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
