[sage-devel] Re: hash for algebraic field
Volker Braun gmail.com> writes: > > sage: FiniteEnumeratedSet(GF(3)) > > sage: sum(FiniteEnumeratedSet([0,1,2])) > > 0 > But I would rather blame the use of caching rather than equality > testing. > Just removing the caching here isn't that easy, FiniteEnumeratedSet really is just a UniqueRepresentation. I'm pretty sure there are similar issues in other UniqueRepresentations... For one thing it illustrates that FiniteEnumeratedSet (due to being a full-blown parent and hence having UniqueRepresentation) is a rather heavy-weight object. Note that "equality" of FiniteEnumeratedSet is going to be a bit funny when construction from arguments starts to use an equivalence test more strict than "==": It means that we can have two enumerated sets V = FiniteEnumeratedSet(GF(3)) W = FiniteEnumeratedSet([0,1,2]) such that all( any(v==w for w in W) for v in V) and all( any(v==w for v in V) for w in W) and not( V == W ) (having UniqueRepresentation and not EqualityById would be horrible) > Really, caching ought to apply a stricter comparison that our "== after coercion". IMHO we should require that the parents match before coercion, that is, use (parent(x), x) as cache dictionary key. Otherwise there will always be cases where an incorrectly primed cache will give you wrong answers. Not to mention the impossibility to test a cached_function/method that it does not depend on the previous inputs. And since the arguments get processed already in order to get hashed, it would probably be quite doable to process them such that SageElement instances get replaced by (elt.parent(), elt), or perhaps better: if objects provide a "_cache_key_" method, use its value. -- 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] Java3D usable in any form?
Concerning interactive 3d vis tools: Is there currently *any* way of getting Java3D to work reliably together with sage on, say Mac G5 systems running OSX and on i386/ amd64 with linux? It doesn't necessarily have to be from the notebook, although that would be preferable. Are instructions for this available? Will we have this running well in advance of August 2008? Are there other high quality interactive 3D visualisation tools that work nicely with Sage and are so easy to install that you can ask the average sysadmin to do it? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
On Dec 3, 4:51 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > I think Java3d already works fine on Macs and Linux from , so long as > > you have java installed. I use it "all the time" when I want to do > > 3d visualization. This was something Robert Bradshaw implemented > > last summer (it was a huge amount of work), but it's been usable > > for quite a while. > > I should add that the quality and *speed* of what one gets using Java3d > is amazing. One can fluidly animate hundreds of objects at once with > lighting, textures, etc. This is definitely the future for Sage 3d graphics > in the notebook.. OK, I would be very interested to see instructions that allow me to do just that, then. I have tried the example in sage.plot.plot3d.base? which in the notebook gives me the static picture but clicking the "interactive view" link has only given results varying from no effect to a crashed browser (firefox). Are there further instructions somewhere? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
I've looked into Java3D a bit and it seems to need all kinds of scary fiddling and installing to get working - especially in a browser. Instructions I found referred to "jre1.2" and "java2". Given that "jre1.6" seems to be current, I think those instructions might be outdated. Some people here seem to have been able to get java3d working in their browser. Does anybody have a pointer to a reasonable installation guide for, say, fedora 7? Any attempt on my side has led to sending firefox into a non-responsive busy-loop. I agree that screenshots of java3d look really promising, but Ted's applet has the distinct advantage of actually putting something in my browser that works. (although it looks like it will only be able to make graphs - no general 3d pictures) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
OK, I finally found some instructions that looked halfway trustworthy. https://java3d.dev.java.net/binary-builds.html has a readme for 1.5.1 that had relatively easy to follow instructions. These actually worked! I've been able to view the little "capeman" in a "java applet window" (I guess it doesn't do inlining in the web page yet?) In order to save people the trouble next time, I'll put an easily found search string here: In order to get Java3d working with sage in your browser, you have to install the Java3d extension that can be found on "https:// java3d.dev.java.net/binary-builds.html". Follow the instructions in the README posted there to install the Java3d extension in your local java installation. After that, the following actually works: sage: from sage.plot.plot3d.shapes import * sage: from sage.plot.plot3d.plot3d import plot3d sage: S = Sphere(.5, color='yellow') sage: S += Cone(.5, .5, color='red').translate(0,0,.3) sage: S += Sphere(.1, color='white').translate(.45,-.1,.15) + Sphere(. 05, color='black').translate(.51,-.1,.17) sage: S += Sphere(.1, color='white').translate(.45, .1,.15) + Sphere(. 05, color='black').translate(.51, .1,.17) sage: S += Sphere(.1, color='yellow').translate(.5, 0, -.2) sage: def f(x,y): return math.exp(x/5)*math.cos(y) sage: P = plot3d(f,(-5,5),(-5,5), ['red','yellow'], max_depth=10) sage: cape_man = P.scale(.2)+S.translate(1,0,0) sage: cape_man.show() --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
On Dec 3, 9:55 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: [...] > In principle it should be able to download the necessary jars without > the user having to install anything (beyond Java itself). This is why > the initial download is so large. Obviously there are robustness > issues. Also, it should be possible to install the necessary jars and > a lightweight version of the applet could then be used, and jar > caching needs to improve too. [...] The thing is - It's not just a matter of jar-files. The java3d install process drops 2 library files in place: creating: lib/ creating: lib/i386/ inflating: lib/i386/libj3dcore-ogl.so inflating: lib/i386/libj3dcore-ogl-cg.so creating: lib/ext/ inflating: lib/ext/vecmath.jar inflating: lib/ext/j3dcore.jar inflating: lib/ext/j3dutils.jar You can't possibly expect to be able to ship those over to the browser. Therefore, the instructions should be very clear about the fact that one actually has to install 3d *client-side* to get nice graphics. Given that people already have to install java and fonts, I don't think that's too much of a penalty. Given how well the four-by-four applet behaves inside the browser, I think you should try for an inlined applet that gets "enlivened" when necessary and "freezes" when it's no longer necessary to be responsive. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
On Dec 3, 10:33 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > Actually, that is the point of gluegen-rt.jar--it lets one ship > native code (so/dll/dylib) libraries within the jars themselves, and > why there has to be singed code involved. Does the 4x4 applet still > work for you if you uninstall java3d? Hm, I have tried uninstalling java3d and the 4x4 applet indeed works. More confusingly, the notebook does now too! In fact, I noticed that when I thought I installed "Java3d" on my laptop, I in fact put the files in a directory where java should not be able to find them at all. That is strange because I think I think the java3d applet didn't work on my laptop before either. So it looks like my java "cache" was dirty and was causing problems. For some reason, "installing" java3d solved the problem. Possible contributing factors: - I normally run my desktop computer with the NVidia proprietary driver disabled, because the screen refresh doesn't play nice with my favourite (ancient) editor. I don't think java3d works on non- accellerated drivers (glxgears doesn't even run when I have the proprietary driver disabled) - Any caching would happen in my homedir, which is network mounted and gets used by different operating systems and hardware platforms. - I have tried the 3d stuff in Sage before, so I might have had old copies lying around in cache. In any case, possibly by my own doing, I had a very bad experience with the java3d applet before, which lead me to believe that it was total crap and unusable. It was only the fact that William and Robert seem to think quite the opposite that made me have some doubts. It does need to be way more robust, and for that you need to test it on a wide variety of platforms. My testing ability was very limited because I absolutely had no idea where to start troubleshooting. There's no diagnostic output and it is completely opaque where files & caching stuff are stored. The only feedback was an unresponsive firefox and a 100% system load. The author of the applet would probably have a much better idea what to look for. Perhaps it's an idea to do a java3d try-out at one of the sage days? I bet that a bunch of sage developers give a wide range of platforms to try out on, probably with nice and quirky configurations. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Java3D usable in any form?
On with the bug reports: - When I run the applet, I get a scary number of requests for "trust", including some "identification required" dialogue boxes (on fedora 7) that supply no information whatsoever. It feels like signing a blank cheque. These are the kinds of dialogues that students should learn to answer "NO!" to, so a solution for these has to be found. - On OSX with firefox, there is a problem with a "secure connection". I only get a colourful cube, which is the default scene I presume. At the same place, Safari asks for a password to open the keychain and then works well, so I guess the problem is that firefox doesn't know how to access the keychain on OSX and therefore is not allowed to grant java access to the secure connection (if that makes sense to you, you're better off than I am)? - On fedora 7, if I open the applet once and then close it, reopening it is very flaky. Most of the time I have to exit firefox altogether and run the "trust" gauntlet again. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Scientific calculator in the notebook
Scientific calculator programs already abound. As a gentle introduction to sage, you might want to consider including a side- window where the sage commands that effect the same computation scroll by. That way, one could use it as a "scientific calculator-to-sage" translator and people might be able to pick up sage syntax while typing in on a familiar calculator. By the way, my experience is that students don't necessarily know how to operate a standard scientific calculator anymore. They only use the superfancy graphing calculators. For instance, to calculate sin(1), they would actually type in [SIN] ( 1 ) [ENTER] or [SIN] 1 [ENTER] rather than 1 [SIN]. On Dec 7, 10:55 am, [EMAIL PROTECTED] wrote: > On Fri, 7 Dec 2007, Ted Kosan wrote: > > > I have been working on ways to make SAGE as easy to use as possible > > for beginners because I am interested in encouraging high school > > students to use SAGE. The approach I have been working on recently is > > to embed a scientific calculator into the notebook that SAGE newbies > > should be able to start using immediately with zero SAGE training. > > +1 -- I've been wanting this feature for a while. > > > At this point I am still trying to get my mind around the details of > > the communications between the notebook and the server and I will > > probably be asking questions about the communications protocol in the > > near future. > > I wrote most of the client-side communications stuff, and it is relatively > easy to explain, so if you have any questions, feel free to send them my way. > > -- tom --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Scientific calculator in the notebook
On Dec 7, 2:23 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote: > 1) Not only can the applet inject javascript code into the browser, > but it can also inject SAGE code into a worksheet. When a given > applet launches, it can automatically inject code into the SAGE > environment on the server which can be used by the user to interact > with the applet. That would have excellent applications in other contexts too. There are some tasks that are more conveniently done interactively: Pick a viewpoint for a 3d picture, select the viewport for a graph, select colors in a graph, etc. Each of those options can be set on the commandline too. It would be wonderful to have applets that let you select these things and then give you back the command line for later use (so that you can generate the picture through another toolchain that produces a print-quality version, for instance, or inside a script that generates many similar graphs which need the same parameters set). If the interactive tools always have the option of "giving back" to the command line, you would really have the best of both worlds. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Auto-login under VMware
> On Dec 11, 2007 3:08 PM, John Voight <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > Is it possible to automatically login the VMware appliance as "sage"?
You may have other reasons for wanting to have someone logged in
automatically and I don't use the VMs mysef, so perhaps I am
suggesting something that is already done.
Since these VMs have the sole purpose of running sage (in notebook
mode), they should probably have a "service" that gets automatically
started, much like "sshd", "httpd" etc. On redhat derived systems this
works via the "runlevel" scripts in /etc/init.d and /etc/rc* . This is
how our sysadmin has made the sage service robust in the face of
reboots.
something along these lines would do the trick:
- /etc/init.d/sage ---
#! /bin/sh
#
#
# chkconfig: 345 98 55
#
# description: init script to start and stop sage
# sage will be run as nobody
#
# Source funciton library.
. /etc/init.d/functions
# If sage binary not there exit
if [ -f /usr/local/bin/sage ] ; then
SAGE="/usr/local/bin/sage"
else
exit 0
fi
SAGE_PID="/home/nobody/sage_notebook/twistd.pd"
# Source config
if [ -f /etc/sage.conf ] ; then
. /etc/sage.conf
else
SAGE_OPTIONS=" -c 'notebook()' &> sage.log"
fi
case "$1" in
start)
echo -n "Starting Sage"
# echo -n "$SAGE $SAGE_OPTIONS"
# /bin/su - nobody -c '$SAGE -c "notebook()" &>
sage.log'
/bin/su - nobody -c "$SAGE $SAGE_OPTIONS"
echo "."
;;
stop)
echo -n "Stopping Sage"
#kill sage
kill `cat $SAGE_PID`
echo "."
;;
*)
echo "Usage: /sbin/service sage {start|stop}"
exit 1
esac
exit 0
#EOF
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Auto-login under VMware
You would have to run "chkconfig" to make sure that the service actually gets added to the /etc/rc.[0.6] directories, which control which services get started at what run level. You'd also have to make sure that the service is configured to run at the appropriate runlevel (in the script above it's levels 3,4,5) and that your system actually boots into that runlevel. Then again, all of this might well work differently in Ubuntu/Debian. [again, this info might not be relevant for you, but might be handy for someone who "wants to run the sage notebook as a service on redhat or fedora systems"] On Dec 12, 9:05 am, John Voight <[EMAIL PROTECTED]> wrote: > Thanks Yi and Nils, > > Yi: I wasn't sure this really applied, as Ubuntu seems to lack an /etc/ > inittab file. But anyway I downloaded and installed mingetty, created > such a file according to the website, and there is still no automatic > login. > > Nils: I also created a /etc/init.d/sage file like yours, but it's not > enough under VMware--apparently, I really need automatic login. > > JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] xgcd problem
At present xgcd(12,2) == (2,1,-5), whereas most people would expect the answer (2,0,1) [being the smallest linear combination]. Ticket: http://sagetrac.org/sage_trac/ticket/1482 Since xgcd is central to so many algorithms and is very speed- sensitive, I hesitate to put in a simple-minded fix. Hopefully someone with comprehensive knowledge of the code can take a look? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-newbie] Integer points on Elliptic Curves
On Dec 18, 3:35 am, "John Cremona" <[EMAIL PROTECTED]> wrote: > The only implementations I know of are in > SiMath (now defunct) and Magma, but it has been suggested as a good > project for a Masters student to reimplement it in Sage, and someone > might be doing that. KANT/KASH (http://www.math.tu-berlin.de/~kant/) has routines to find integral points on curves y^2=x^3+a*x+b. It uses the Thue-equation solver, so I think this implementation might be independent of Magma's. The code to translate into Thue equations might even be readable kash-code. You should check their licence if reading their code with the purpose of replicating the behaviour is allowed. I would expect that Pari can already solve Thue-equations. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: #1482: xgcd suboptimal output
I don't think anybody should care about the signs. Given the close connection between continued fractions and Euclid's algorithm (which does guarantee minimality), I guess you could try and see what signs would be given back by a continued fractions approach. It actually looks like they had a very good reason for departing from returning minimal solutions in GMP's xgcd. It is nice to have an option for minimality, but it should perhaps not be the default. The way I ran into this problem was that I tested for one of the parameters to be zero to detect if the gcd is equal to one of the inputs. This example shows you're better off doing that by testing for equality on the GCD and the inputs. The "bug" should perhaps be the failure of the documentation to point out that minimality is not guaranteed (people will naively expect Euclid's algorithm) On Dec 23, 9:40 am, David Harvey <[EMAIL PROTECTED]> wrote: > Hi Nils, > > I've been looking at > >http://www.sagetrac.org/sage_trac/ticket/1482 > > and approximately diagnosed the problem (see comments on the ticket), > but it's not clear to me exactly how to proceed. > > The new underlying gcd code produces quite inscrutable output, for > example: > > sage: xgcd(3, 3) > (3, 0, 1) > sage: xgcd(3, 6) > (3, -3, 2) > sage: xgcd(3, 9) > (3, -8, 3) > sage: xgcd(3, 12) > (3, -3, 1) > sage: xgcd(3, 15) > (3, -14, 3) > sage: xgcd(3, 18) > (3, -17, 3) > sage: xgcd(3, 21) > (3, -20, 3) > sage: xgcd(3, 24) > (3, -15, 2) > sage: xgcd(3, 27) > (3, -26, 3) > sage: xgcd(3, 30) > (3, -29, 3) > sage: xgcd(3, 33) > (3, -32, 3) > sage: xgcd(3, 36) > (3, -35, 3) > sage: xgcd(3, 39) > (3, -38, 3) > sage: xgcd(3, 42) > (3, -41, 3) > sage: xgcd(3, 45) > (3, -44, 3) > sage: xgcd(3, 48) > (3, -15, 1) > sage: xgcd(3, 51) > (3, -50, 3) > > It's very hard to see any rhyme or reason in that. Certainly the GMP > documentation doesn't guarantee any properties of the cofactors, > apart from bezout, either at the mpz or mpn levels, so it's not a bug. > > I'm inclined to do the following in Sage. Provide a "fast" flag which > just calls GMP and doesn't provide any guarantees about the output > (apart from satisfying bezout). If "fast" is False (default), then we > convert to a "standard" form, which should be unique, mathematically > sensible, and carefully documented. > > But having thought about it for a while, it's not even clear to me > what exactly the right definition of "standard" should be. I don't > quite understand the minimality condition you proposed. > > Apart from the kind of special case listed above, GMP does seem to > follow some "rules", but I'm not sure they are always satisfied, and > we can't rely on them since the GMP documentation doesn't promise > anything. > > For example, if 0 < a < b, then xgcd(a, b)[1] always seems to be > negative and xgcd(a, b)[2] always positive, but it swaps around if 0 > < b < a: > > sage: xgcd(11, 17) > (1, -3, 2) > sage: xgcd(17, 11) > (1, 2, -3) > > i.e. it looks like it swaps them to make a < b, and then swaps the > cofactors at the end. > > It generally seems to handle input signs in the same way, i.e. it > first does xgcd(|a|, |b|), then throws the signs back in at the end: > > sage: xgcd(11, 17) > (1, -3, 2) > sage: xgcd(-11, 17) > (1, 3, 2) > sage: xgcd(11, -17) > (1, -3, -2) > sage: xgcd(-11, -17) > (1, 3, -2) > > But none of this is particularly canonical. > > What's the "right" way to do this? > > david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Education: Tying SAGE into an online course management system
For people who are seriously interested into developing SAGE into a tool that can easily be used for teaching and/or student assignments, I warmly recommend that they look into LON-CAPA. It has the advantage that it is already based on open source technology. Maxima is already packaged with it for symbolic capabilities. One simple integration I would imagine is tying SAGE into LON-CAPA's authentication system (or at least provide a plug-in to that effect). Presently, one big obstacle to offering SAGE as a tool for a largish class is the account management (together with the problems of running sage as a widely accessible service in a secure way) One could just say "use sagenb.org" in class, but I imagine that could end the offering of that service. There is going to be a LON-CAPA conference in May at SFU: http://www.sfu.ca/~capachem/conference/ There are some lecturers at SFU who are quite knowledgeable concerning LON-CAPA and may well be interested in seeing how SAGE and LON-CAPA could be integrated to advantage of both. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Notebook revision info leakage
I posted http://sagetrac.org/sage_trac/ticket/1751 In general, the incredible persistence of the notebook is great. However, it makes "deleting" things a rather opaque procedure and it is not entirely clear to me what to do to make sure that notebook information has been properly deleted. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Mark your calendars
*** Preliminary Announcement * Sage days 9: Mathematical graphics and visualization workshop Vancouver, Canada August 9 - 16, 2008 This instructional workshop is primarily aimed at graduate students in mathematics and related areas. It will concentrate on practical use of graphics in mathematical exposition, both in traditional and in new media. Tools covered will include the computer algebra system SAGE (www.sagemath.org) and and the graphics description language Postscript. A large part of the program will consist of student projects, either for producing new and interesting mathematical graphics or for developing graphics and visualization tools within SAGE. Mark your calendars. Details on how to apply will follow soon. Funded by MITACS / PIMS / SFU ** --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] forall and exists cannot be used as predicate
Presently, because forall and exists return tuples rather than booleans, their return value is always True, so they cannot be used as a predicate, which is very unintuitive given their names. Proposed solution: optional parameter witness (default: False) that determines return value type. Ticket (has patch) http://trac.sagemath.org/sage_trac/attachment/ticket/1987 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: forall and exists cannot be used as predicate
On Jan 30, 2:49 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote: [...] > name. Also, there are functions in Python which have similar > functionality. > > sage: l = [1,2,3] > sage: any([i == 2 for i in l]) > True > sage: all([i == 2 for i in l]) > False That's instructive. In that case, forall and exists should probably have their help extended by a pointer that if a witness is not required, the user should type: any(P(s) for s in S) or all(P(s) for s in S) That's actually a nicer syntax anyway and it would be a shame if people keep hobbling along with forall and exists when there is a much nicer option. (I got a tab completion hit on "forall" and "exists" and assumed those were the right functions to use. They are often not). That teaches me to *not* write patches :-) > On Jan 30, 2008 2:45 PM, Nils Bruin <[EMAIL PROTECTED]> wrote: > > > > > Presently, because forall and exists return tuples rather than > > booleans, their return value is always True, so they cannot be used as > > a predicate, which is very unintuitive given their names. Proposed > > solution: optional parameter witness (default: False) that determines > > return value type. > > > Ticket (has patch) > > >http://trac.sagemath.org/sage_trac/attachment/ticket/1987 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: forall and exists cannot be used as predicate
OK, I changed the patch on http://trac.sagemath.org/sage_trac/ticket/1987 so that "forall" and "exists" do not change functionality, but have a pointer to "all" and "any" in their docstrings. Incidentally, it is *crucial* to *not* use square brackets inside any and all. If you do, you destroy any possible "short circuit evaluation". sage: all(a %2 == 0 for a in ZZ) #terminates quickly False sage: all([a %2 == 0 for a in ZZ]) #blows up --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: forall and exists cannot be used as predicate
On Jan 31, 6:50 pm, "William Stein" <[EMAIL PROTECTED]> wrote: [...] > Also, in your posted patch you emphasize that forall and exists > are *NOT* suitable for use in an if, etc. I would have written that > to use them thus you have to use the ugly forall(...)[0], and it is > much nicer to use all(...) and any(...). [...] sage: L=[1..10^6] sage: L[10^6-3]=-1 sage: %timeit any(a<0 for a in L) 10 loops, best of 3: 2.44 s per loop sage: %timeit exists(L, lambda a: a<0) 10 loops, best of 3: 2.84 s per loop sage: g=lambda a: a<0 sage: %timeit any(g(a) for a in L) 10 loops, best of 3: 1.14 s per loop If you don't need the witness, you should not be using "exists". It's a bit weird the lambda clause actually speeds things up in "any". --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: forall and exists cannot be used as predicate
I forgot one case. This is weird. Exists seems *faster* than any. That should never be happening! sage: L=[1..10^6] sage: L[10^6-3]=-1 sage: %timeit any(a<0 for a in L) 10 loops, best of 3: 2.47 s per loop sage: %timeit exists(L, lambda a: a<0) 10 loops, best of 3: 2.83 s per loop sage: g=lambda a: a<0 sage: %timeit any(g(a) for a in L) 10 loops, best of 3: 1.19 s per loop sage: %timeit exists(L, g) 10 loops, best of 3: 1.04 s per loop --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: forall and exists cannot be used as predicate
The timing differences between "any" and "exists" still bother me a bit, so I tried plain sage -ipython: sage: def exists(S, P): ...: for x in S: ...: if P(x): return True, x ...: ...: return False, None sage: L=range(10^6) sage: L[10^6-3]=-1 sage: g=lambda a: a<0 sage: %timeit any(g(a) for a in L) 10 loops, best of 3: 7.09 µs per loop sage: %timeit exists(L, g) 10 loops, best of 3: 4.44 µs per loop sage: %timeit any(a<0 for a in L) 10 loops, best of 3: 4.57 µs per loop sage: %timeit exists(L, lambda a: a<0) 10 loops, best of 3: 4.86 µs per loop The differences are crazy. Assigning a lambda expression to an identifier speeds things up? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.10.1 released
I tried a "sage --upgrade" from a clean, relocated install of sage 2.10. The install seems to succeed, but running sage leads to: -- | SAGE Version 2.10.1, Release Date: 2008-02-02 | | Type notebook() for the GUI, and license() for information.| -- --- Traceback (most recent call last) /usr/local/sage/2.10.1/local/bin/ in () : No module named sage.misc.preparser_ipython WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' --- Traceback (most recent call last) /usr/local/sage/2.10.1/local/bin/ in () : No module named sage.misc.misc I suspect that attaching a 13MB install.log is not the right method of supplying that info. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] minor issue with notebook "...?startup_token=..." URLs
It's really convenient that starting up a local notebook actually also pops up a browser with admin already logged in. There's a slight issue, though. When one does (AJAX?) operations on the page that has the decorated URL, the notebook seems to get confused: http://trac.sagemath.org/sage_trac/ticket/2117 (just reporting because I seem to recall people prefer a newsgroup posting announcing a trac ticket) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mpoly factoring woes
Mark uses LLL to solve the knapsack problem that arises from solving how the local factors should be bundled together to reconstruct the global factors. It's only used to tame the combinatorial explosion that you get if there are many local factors, but only very few global ones. This is completely analogous in the multivariate situation, where your specializations give local factorizations. (i.e., take a square-free multivariate polynomial f(x,y), find a y0 such that f(x,y0) is also square-free, determine the factorization of f(x,y0), lift it to a power-series factorization of f(x,y0+z), use LLL to see how these factors pack together to give a polynomial factorization of f(x,y). I can image that for polynomials, you can do something faster. However, if the combinatorial explosion is a problem there as well, Mark van Hoeij's trick should still apply. On Feb 18, 10:21 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Feb 18, 2008 10:08 AM, Roman Pearce <[EMAIL PROTECTED]> wrote: > > > > > On Feb 18, 6:21 am, Bill Hart <[EMAIL PROTECTED]> wrote: > > > Laurent Bernardin and Michael B. Monagan. > > > Efficient Multivariate Factorization Over Finite Fields. > > > If Sage has or can get fast LLL you should implement the new algorithm > > of Mark van Hoeij. > > Sage does have a very fast LLL implementation (fpLLL by Damien Stehle). > However, I don't know of any new (or old) algorithm by Mark van Hoeij > that addresses the problem of "Efficient Multivariate Factorization Over > Finite Fields" using LLL. Could you please clarify. > > I am aware of Mark's algorithms for univariate polynomial factorization > over global fields using LLL. > > -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: interact versus manipulate
Is there a standard/precedent for function decorations being verbs, adverbs or adjectives? I could see the verb from the implementor's point of view (you are wrapping/changing the given function), but the python syntax puts the identifying in a clearly declarative place. That indicates that it should be should be an adjective (you declare an "interactive" function. It's only later that it "interacts" with the user) Is there any desire in Sage to keep naming consistent consitent from a grammmatical point of view? (i.e., nouns for functions that return a value, verbs for destructive operation) Very cool technology. What happens if you use this decorator outside of a notebook context? If LON-CAPA developers contact you, be sure to point them to a screenshot. It will surely get them interested. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Can maxima do more than sage?
I tried the first example below in sage. It failed , complaining that
maxima wanted to know whether x was positive, negative or 0. Hence, I
tried maxima via "sage -maxima". To my surprise, maxima computed the
limit without asking for extra information. Is the maxima that gets
called from sage put in a more inquisitive mode?
I figure this might be a symptom of a sub-optimal interaction between
sage and maxima and hence might have some interest to developers.
///
%sage
var('p x')
limit((p+1)/pi*(1-x^2/4)/((sqrt(p)+sqrt(1/p))^2-x^2),p=oo)
//complains that maxima wants extra information
%maxima
f(p,x):=(p+1)/pi*(1-x^2/4)/((sqrt(p)+sqrt(1/p))^2-x^2);
limit(f(p,x),p, infinity);
//works
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: notebook features discussion
Just a thought: if for some reason, the click event gets registered twice instead of once, one would go around a cycle of length 3 "the wrong way around". Perhaps change the cycle length and see how that affects the bug? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Change the default base_ring for matrices from ZZ to QQ
-1. While I agree that defaulting to matrices over QQ rather than over ZZ would lead to more expected behaviour for most users, I don't see how the rule for changing the base ring can be made both consistent and cheap. Imagine R1 = QQ[x,y]/(x^2+y^2-1). Then FieldOfFractions(R1) is well- defined, so one would expect that matrix([x]) would be over the field of fractions. If R2=Q[x,y]/( x^2-y^2), FieldOfFractions(R2) does not exist. Deciding whether FieldOfFractions(Ri) exists is a fairly expensive operation in these cases. I think special-casing matrix([ZZ(1)]) etc. is a bad idea. You would need a method R.has_an_obvious_field_of_fractions() on rings to both deal with ZZ and avoid expensive operations for R1 and R2 above. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] unsupported operand parent(s)
Hi all, Could anybody point me to a link to understand the coercion model of sage. ... or, if anybody is willing to have a look at my problem: [EMAIL PROTECTED]:~$ sage -- | SAGE Version 3.0.3, Release Date: 2008-06-17 | | Type notebook() for the GUI, and license() for information.| -- sage: load 'http://sage.math.washington.edu/home/nils/ automorphic_forms_rings.sage' Attempting to load remote file: http://sage.math.washington.edu/home/nils/automorphic_forms_rings.sage Loading: [.] sage: h = AutomorphicFormsRing(QQ, [17], 'a') sage: a = h.gen(0) sage: a*a --- TypeError Traceback (most recent call last) /home/nils/ in () /home/nils/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c:8528)() /home/nils/coerce.pxi in sage.structure.element._mul_c (sage/structure/ element.c:16256)() /home/nils/element.pyx in sage.structure.element.RingElement._mul_ (sage/structure/element.c:8689)() /home/nils/element.pyx in sage.structure.element.RingElement._mul_c_impl (sage/structure/ element.c:8655)() TypeError: unsupported operand parent(s) for '*': '' and '' Thanks in advance, ---Nils Skoruppa --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Imrpove X3D format export
In anticipation of SD9, I tried out viewing sage generated X3D files using a big projection screen, using LCD shutter 3d glasses. The results were quite encouraging: The basic infrastructure works. However, there are lots of small things that could be improved to make it really useful. I've put a few on a trac enhancement "wishlist" ticket: http://trac.sagemath.org/sage_trac/ticket/3702 We can probably iron out a lot of these things during SD9. The idea would be to have X3D files exported that work really well with at least one viewer (and adhering to the standard of course). We'd have a good chance to have something working quite well with a lot of viewers as a result. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sagemath.org issues
Would it be possible to have the "download source" file referred to on the linux download page as well? Right now, one has to go to "other systems" first, which felt rather counterintuitive. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 22, 6:33 pm, David Philp <[EMAIL PROTECTED]> wrote: > map(lambda x: x>0 and x or 0, data) > > [0, 2, 3] > > Can someone translate that "lambda x: x>0 and x or 0" into William's > "the words in your head" please? I suspect this is coming from someone who learned python before it acquired a conditional expression and illustrates why it was introduced. The alternative >>> map(lambda x: x if (x>0) else 0, data) reads a little more comfortably for me as: "Apply the function that, given x, returns x itself if x>0 and 0 otherwise, to each element of data" It is rather cool to see that the whole ... if ... else ... construct is not necessary and that the ... ? ... : ... from C can be encoded in the exact same order in python if you are willing to read ? for "and" and : for "or". --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 22, 10:43 am, Harald Schilly <[EMAIL PROTECTED]> wrote: > >>> data = [-1,2,3] > >>> gt0 = lambda x: x>0 and x or 0 > >>> map(gt0, data) > > [0, 2, 3] > > in python - or more geeky > > >>> map(lambda x: x>0 and x or 0, data) I'm sorry for derailing the thread a little bit, but this is actually a dangerous paradigm to code conditional expressions with (I know because I did not see the catch myself until later either). Your code would work, but in similar situations (say, replace all 0's by 1's and leave everything else the same) you might be tempted to write: >>> data = [None, 0, 1] >>> map(lambda x: x <>0 and x or 1, data) [1, 1, 1] The problem being that if x is considered false then 1 will be returned anyway. On a related note: sage ints and python ints seem to differ in where they put None in their ordering: sage: None > 0 True sage: None > int(0) False [I really would have appreciated an error here, but I guess Python requires all objects to be comparable?] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Comparing complex numbers
I understand that Python really likes things to be comparable with "<", but from a mathematical point of view the following makes me cringe: sage: C.=ComplexField() sage: 1+i > 1-i True sage: 1+i < 1-i False Imagine being shown this by a student after you have explained your complex variables class that complex numbers do NOT have an ordering. Convincing the student that Sage is being non-mathematical here requires some work, because sage's choice of comparing first the real part and then the imaginary part is actually quite a smart one. Would it break Python too much if comparison would simply throw an exception in these cases? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Comparing complex numbers
On Aug 23, 1:00 pm, "Fredrik Johansson" <[EMAIL PROTECTED]> wrote: > Hardly, considering that this is what Python itself does: > > >>> 1+1j > 1-1j > > Traceback (most recent call last): > File "", line 1, in > TypeError: no ordering relation is defined for complex numbers Ah, well, if python itself already has uncomparable objects, then I think Sage should only allow "<" comparison when it has a mathematical footing. See also: http://trac.sagemath.org/sage_trac/ticket/3936 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] adding custom canonical coercions
With the advent of the new coercion model, did we get the incredibly cool possibility of adding canonical coercions locally, as promissed at SD7? I'd love to be able to type something like: K.=Numberfield(x^2-2) E=EllipticCurve([0,0,r2,0,0] for m in K.real_embeddings(): with CanonicalEmbedding(m): R=Codomain(m) E_over_R=E.base_extend(R) print E.real_period() in order to get the real periods of E wrt. the two real embeddings of K into R. In general, getting all the "derived" maps from a non-canonical base- extension is very painful. If one could just locally make these things "canonical", you'd get a free ride on the coercion infrastructure. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Comparing complex numbers
On Aug 23, 1:27 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > Did you read through the article Alfredo Portes posted, which > also explains some of the gotchas and subtleties of disallowing > comparisons? I'm curious what you thought of it. At the very least, "<" should be transitive wherever it is allowed. The one example that David Mertz gives in favour of universal ordering is sorting, which completely hinges on transitivity of "<". As it stands at the moment with 1 < None < int(0), this is already violated. That means that any algorithm based on sorting can fail in unpredictable ways. In the article he already mentions that one of the main reasons for sorting - doing quick membership tests - can be avoided by using sets and hashing instead (which should be a superior solution anyway?). And the reality in Python is that "<" is not universal anymore anyway. The examples he gives that (1+1j) < "a" but that (1+1j) < 0 raises an exception are just hairraisingly inconsistent. I would hope that the former will lead to an exception in some future version of python as well. I would say that the goal of Sage - being a viable alternative to various Ms - means that Sage should stay as close to the mathematical meaning of things as possible (without creating a strange dialect of python) rather than allow tricks convenient to programmers. Concerning Carl Witty's argument for universal cmp(): It seems hard to me to ensure transitivity for a universal cmp() if you want to depart "<" from "cmp()", plus it will be a big gotcha for beginning/intermediate sage programmers if cmp and "<" can behave differently. Is it really so bad to do a L.sort(compare_function=compare_memory_addresses) or L.sort(compare_function=compare_hash_values) when you absolutely want to sort anything at all? At least it makes a clear statement "yes, I want to sort using a completely arbitrary order that is at least consistent on short timescales". I imagine such code could actually be quite efficient. So in short, the article that Alfredo posted convinced me even more that sage would benefit from taking a hard line on comparison. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "Edit a copy" does not work on published worksheet
I confirm this bug. This used to work. I assumed you didn't have a trac account so I filed a bug report for you. This is now http://trac.sagemath.org/sage_trac/ticket/3960 I'm sure the developers appreciate your report (I do, but I'm not really a developer) On Aug 26, 10:08 am, "Philippe Saade" <[EMAIL PROTECTED]> wrote: > Hi > > It seems that if you are logged as a normal user, browse the published > worksheet and try to Edit a Copy, it just create a copy for user "Pub" > but not for the regular user. > So you can not Edit a personal copy. > > Maybe somebody can confirm the bug > > Philippe > > PS : Sage 3.1.1 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Additive Groups
On 28 Aug., 15:20, "John Cremona" <[EMAIL PROTECTED]> wrote:
> Thanks for your comments, David. I am having some success:
>
> The one thing I cannot get to work in the additive case is (for
> example) 2*g where g is a group element. I have tried all possible
> combinations of __lmul__, _lmul_, __rmul__, _rmul_, but although I
> have this ok:
>
> sage: a,b=A.gens()
> sage: b._lmul_(20)
> 2*b
> sage: 2*b
>
> inputting 20*b gives an error:
> TypeError Traceback (most recent call last)
> >> John
Hi John,
I have a class which derives from AdditiveGroupElement and whose
parent derives from AbelianGroup. Concerning multiplication I did not
implement more than __mul__() with two underscores ( and no _lmul_,
_rmul_, mil_impl-c ... and the like). It seems to work OK:
sage: A. = FiniteQuadraticModule ('3^3')
sage: 5*a
2*a
sage: b*7
b
sage: -a +
2*c
2*a + 2*c
I cannot explain why this works, but if you want to have a look:
http://hg.countnumber.de/fqm-devel/file/98bb736f0c07/cn_group/finite_quadratic_module.sage
(and then line 2132 class
FiniteQuadraticModuleElement(AdditiveGroupElement).
---Nils
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Additive Groups
On 29 Aug., 11:55, mabshoff <[EMAIL PROTECTED]> wrote: > > Out of curiosity: Do you plan to submit the code to Sage eventually? > > Cheers, > > Michael Hi Michael, yes, I shall definitely do so within the next weeks. ---Nils --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hashing and equality of number field ideals
On Sep 3, 5:25 pm, Nick Alexander <[EMAIL PROTECTED]> wrote: > Hi sage-devel, > > So I'd like opinions on two things: > 1) changing the printing of number field ideals, and > 2) changing the hash key of a residue field K/I to not reference I > directly, but instead the map K -> K/I. I assume that you mean R/I where R subset K is the order with respect to which I is an ideal? Since the same code is probably going to be used for fractional ideals as well, you probably need to put the denominator in there too, i.e., hash ( d, R->R/(d*I) ), where d is the minimal positive integer such that d*I subset R. What is the hash of R->R/(d*I) ? Is it the hash of the HNF of the Z- basis of d*I, expressed relative to the basis of R? Are there cases where computing that hash is expensive? I imagine it could be for, say, principal ideals. One can give a very compact representation in that case (the generator), but the HNF can be quite nasty. In extremely big cases, one may have to settle for an LLL-reduced basis instead. Is it acceptable that asking for the hash of such an ideal might cause sage to explode? Still, I imagine that the worst case of that is not nearly as bad as computing the standard 2-generator form of an ideal. Can orders change their basis? Are isomorphic orders with different bases considered equal? Are isomorphic ideals in such orders considered equal? How does that interact with hashes? OK, it's not really an opinion. My opinion is that hash should be cheap whenever possible and your proposal seems to go that way, so that's great! I just recall that the choice of hash function has been problematic before, so I thought I'd give some feedback on of possible problems that sprang to mind. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: calling symbolic expressions, was: Why Sage needs var(...) commands unlike Mathematica?
If we change the name and nature of the objects a little bit, one can
actually write down examples where Robert D's interpretation is not so
outlandish.
For instance:
sage: var("D, x");
sage: f=D^2+D+1;
sage: f(x^3)
x^6 + x^3 + 1
In an article about differential operators, one would probably mean
that D= d/dx or something like that and then one would expect
f(x^3)=6*x+3*x^2+x^3
admittedly, multiplication (composition) of differential operators is
not commutative, so the symbolic ring would get that wrong as well
(one has D*x=x+1)
Allowing for such exotic interpretations in the symbolic ring would
probably ruin many conveniences for calculus, which I guess is still
the main application, so I would think that properly documenting the
current behaviour is probably the better way to go forward.
I think it also provides an argument for the explicit "var"
declaration: If you declare "D" to be a variable, it's pretty clear
that you shouldn't expect operator semantics, whereas if you're
allowed to use "D" without declaring anything about it, you could make
an argument that Sage was a little bit presumptuous in assuming that
it's not an operator.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Possible undergraduate projects
I probably have funding available to let an undergraduate do some work on Sage for 4 months. I would welcome a list of programming tasks that need some attention. The tasks should be rather limited in scope, because an undergraduate should be able to dive in, work, and get some result within 4 months. Examples I thought of myself: - Integer Sequences project - HNF (I think William commented present open source implementations are all rather bad. I don't know if it is realistic to expect that an undergraduate will be able to fix this) - Plotting real algebraic (plane) curves by analyzing the singularities and using a DE solver to get the intermediate curves. Maple does that, as does Surf. Projects that are more of a computer science nature could also be doable. Any ideas here? Should I be looking somewhere on the wiki? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: integer.valuation and polynomial.valuation
On Jan 26, 12:39 pm, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote: > The integer object method "valuation" computes the p-Adic valuation, but the > polynomial object method "valuation" computes a different sort of valuation. > It seems to me that they could be more analogous, but maybe there's something > I'm not seeing. I agree that the valuation for polynomials is confusing. Presently, P.valuation() and P.degree() are the same for non-zero polynomials. If defined at all, P.valuation() should be "the valuation at the infinite place", which would be -P.degree() for non-zero P. The place at infinity is indeed the only one that stands out for a polynomial ring. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: doc browser
A wonderful interface and a very useful way of browsing the documentation. The help accessibility would really improve if from the prompt it would be possible to jump to the relevant reference page, for instance via: doc(IntegerRing) Usage script: 1. I am working in sage and need help on, say, VectorSpace. 2. Using tab completion I have found the right candidates for the name of the routine 3. With "VectorSpace?" I have gained some insight in its use, but I need to read up on the background info. 4. I type doc(VectorSpace) and one of the following alternatives happen: a. The relevant documentation gets inserted in my current worksheet b. A new tab/browser window opens on the relevant documentation c. A new tab/browser window opens with a bunch of entries extracted from the documentation index that seem relevant (putting me one click away from the desired information) Note that options (b) and (c) would even be feasible from the command line, using "firefox -remote" or something similar. I use magma with option "c" set up. Ad 3: Would it be possible to typeset the "...?" information using tex2html? It would make it much more pleasant to ready, especially because the mathematics typesetting is now of such a high quality. Oh, and can you fully hyperlink the documentation, so that you can jump around via in-text references? [If people get all kinds of ideas how to improve something, it's usually a sign you've done something really well] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Using ssh for port-forwarding
The following is easily found on the man page of ssh, but William pointed out to me that many users may not be aware of the possibility to use ssh to forward ports. In particular, if you want to run "sage - notebook" on computer A, but only want to let it listen to a local port out of security considerations and yet want to run a web browser on computer B to connect to the server, you can do the following [EMAIL PROTECTED]> firefox & [EMAIL PROTECTED]> ssh -L 8000:localhost:8000 [EMAIL PROTECTED] [EMAIL PROTECTED]> sage -notebook [] --- now, in firefox on B, you can visit http://localhost:8000, which will get tunneled by ssh to port 8000 on A and hence will give you a connection to the sage notebook on A. I am sure one can use ssh on windows to do port forwarding as well. Perhaps someone who knows can reply with a small note explaining how? Enjoy. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] problem upgrading linbox after tree relocation
when trying to upgrade to the new linbox-20070219, I get the following
error:
libtool: link: cannot find the library `/usr/local/sage/current/local/
sage/default/local/sage/sage-2.1.2/local/lib/libgmp.la'
my sage-location is identical to the one William attached to an
earlier message.
Originally, the tree was located at /usr/local/sage/sage-2.1.2. This
directory was renamed to
/usr/local/sage/current
and there is a symbolic link /usr/local/sage/default that points to /
usr/local/sage/current.
The file it is looking for would be located at /usr/local/sage/current/
local/lib/libgmp.la or /usr/local/sage/default/local/lib/libgmp.la
My guess is that, upon relocation, the "/usr" from the original /usr/
local/sage/sage-2.1.2/local/lib/libgmp.la got replaced by the
relocated root "/usr/local/sage/default"
After running sage using /usr/local/sage/current/sage, a "relocation"
was detected and the now "/usr" got replaced by the now current root "/
usr/local/sage/current/" etc. A little experimentation shows I can
make the pathname arbitrarily long in this way.
I think I see what is the culprit: in sage-location, in
update_library_files, there is a
i = z.find('local/')
which hopes to find the local in front of lib, but in this example it
finds the local just after usr. This indeed explains the current
behaviour.
I'm afraid you'll have to look for the *last* occurrence of "local",
not the *first*
(that, or instruct people to not install sage anywhere under /usr/
local/, but that seems a bit harsh)
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: problem upgrading linbox after tree relocation
Sorry about replying so quickly to myself. In my case, the problem is
indeed solved by replacing line 35 in sage-location by
i = z.rfind('local/')
(A one letter patch!)
I still get the following during the linbox build (on an x86_64
running redhat):
WARNING WARNING
using frickin' slow GSL C-blas
WARNING WARNING
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] First remarks on new padics model
Congratulations on the new p-adic model. This really looks very promising and extensible. A few remarks: - It should be possible to create elements with a given precision, without the overhead of first creating the elements to the entire "cap": If you don't know the precision you'll need yet, you would probably create a ring with a huge cap and just create all your elements with way lower precision (having a huge cap floating around should not be very costly). You can just lift your elements to higher precision when it turns out you need more. - Currently trying to create an element in a "lazy" ring leads to a Exception (click to the left for traceback): File "integer.pyx", line 669, in integer.Integer.__pow__ TypeError: exponent (=lazy) must be an integer Coerce your numbers to real or complex numbers first. (that's the pyrex "**" thing I guess) - We're going to need a "lifttoprecision" method that returns an element with a changed precision. For lowering the precision you already have add_bigoh, but one needs to be able to obtain a lift of an element too (for instance, if you want to increase precision using newton iteration, you need to create the room first) - I assume the ringextension is just a rough first draft? The following was rather disconcerting: sage: Zp=pAdicRing(3) sage: ZpX.=Zp[] sage: R=pAdicRingExtension(X^2-3) sage: R.uniformiser(); 3 + O(3^21) In general, the ramified extensions cannot completely be implemented via polynomial quotient rings, and you'll find relating precisions in the extensions with precisions in the base ring to be a general headache. Another thing: R.=pAdicRingExtension(X^2-3) throws an error at the moment (we cannot name the new generator!) Uniqueness of rings: in the future, I'm sure we'll be able to ask for: K.=NumberField(x^2+1) Q5a,KtoQ5a=Completion(K,Place(2+i)) Q5b,KtoQ5b=Completion(K,Place(2-i)) Are Q5a, Q5b going to be the same ring with all the difference relegated to the embedding maps of K? Are Q5a, Q5b going to have coersions from K? Are Q5a, Q5b going to be wrapper classes around the same pAdicField(5) to distinguish their relation to K? I'm happy to take this conversation to a different platform if appropriate. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: First remarks on new padics model
> > - Currently trying to create an element in a "lazy" ring leads to a > > Exception (click to the left for traceback): > > File "integer.pyx", line 669, in integer.Integer.__pow__ > > TypeError: exponent (=lazy) must be an integer > > Coerce your numbers to real or complex numbers first. > > (that's the pyrex "**" thing I guess) > > What code did you run to try to create the lazy element? My mistake, but the errors let me think it was sage's fault. I typed pAdicRing(3,prec="lazy") which gets accepted. Doing anything with the ring afterwards leads to the above error. You should probably validate all construction parameters at construction time. > > In general, the ramified extensions cannot completely be implemented > > via polynomial quotient rings. > > Why not? Can't we just use an Eisenstein polynomial f(x) and have x > be the uniformizer? If the user wants to use a different polynomial, > we convert between x and the user defined variables... On second thought, yes, possibly you can. Your Valuation(polyquoelt) would be min([n*valuation(polyquoelt[i])+i for i in 0..n-1]) and similar for precision. The problems will arise when you start working with precisions that are not a nice multiple of the extension degree n, i.e., what if you want to find the unit part of pi+3+O(pi^3) where pi=sqrt(3) in Z_3? > We haven't yet decided how to do this. Generally, we're trying to > have fields be uniquely determined by the parameters that define > them. We could have no automatic coercion from the number field to > the localization and have the user have to use __call__ instead. > Maybe syntax like def __call__(self, x, absprec = None, place = None) > where place determines the embedding of K into Q5? Feel free to share > any thoughts you have on this. The place can't be a parameter on the receiving end. (imagine places of higher degrees?) I wouldn't mind a field homomorphism K -> K_p that you have to call explicitly. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: magma interface
I have tried your examples and I get expected resuts back (i.e., not the ones you are listing here) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: First remarks on new padics model
> Yeah. Precision there bears more thinking on. I was actually even > considering > having precisions and valuations normalized so that valuation(p) = 1, > and then only > integral precisions would be allowed. I'm not sure whether I like > this idea though... I'm sure I do not like that idea. That's not the language in which "algorithms over arbitrary complete discrete valuation rings" are normally formulated. Ultimately, I would like that if someone defines Zp=pAdicRing(5,prec=20) R.=Zp[] A.=EisensteinExtension(X^3+5*X+5) then elements in A should behave as a0+a1*pi+a2*pi^2+...+ar*pi^r+O(pi^(r+1)) where the ai are representatives of the residue field (here GF(5)) It may well be that in order to have efficient arithmetic, you end up implementing it as a polynomial quotient ring, but then the behaviour should be modified to be consistent with the above model. In particular, if you represent your elements as (b0+O(p^e0))+(b1+O(p^e1)*pi+...+(b(n-1)+O(p^e(n-1)))*pi^(n-1) then some thought will be required on what to do with "excess precision" in one of the coefficients. It could well be that other "rawer" models also have their application, but I found that the p-adic extensions as, for instance, implemented in magma, allowed me to write programs that test for local solvability etc. that would work in arbitrary extensions. [whatever model you come up with, it should behave well wrt towers: Ultimately, we'll probably end up making unramified extensions of eisenstein extensions of unramified extenstions etc... In magma, this works seamlessly] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: A menu for the notebook
If lots of options get added then menus are unavoidable, but currently I don't think the options presented in the notebook take up real estate that would otherwise get good use. Avoiding drop-down menus has the advantage that all options are immediately visible. Having to first drop down the menu does add another layer of indirection. For the help: From experience (my university uses them quite a bit), I find that multi-level CSS drop down menus are a rather mixed blessing. The problem: Path of the pointing device becomes important in addition to the position of the click. Try navigating one a few levels deep using an oversensitive trackpad on a laptop. Does anybody know how accessibility tools can make sense of drop down menus? I think good search access would provide a much better interface to the help than a drop-down hierarchical contents list. Even just a search tool that produces a page with the lines from the index that match a given substring would be very useful. I find I never access computer algebra system help via contents lists, but always via search or index. In all, I think I'd side with Tish on this one. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion in multivariable polynomial rings
There are many cases where you would *WANT* to coerce between polynomial rings with different orderings, think: *Q1[x,y] with grevlex for heavy duty computations *Q2[x,y] wih elimination order for y to project on the x-line *Q3[x,y] with elimination order for x to project on the y-line (of course this only becomes important for higher dimensions) You would be going back and forth between these rings all the time and conceptually they would be representing the same ring for you - just equipped with other algorithmic properties. Hence, in that situation it would not be entirely undesirable to be able to coerce back and forth between Q1, Q2, Q3 and the match-up should prefer the corresponding names rather than the relative ordering (as far as that even can be done). Bases on that, I would say automatic coercion between polynomial rings should be allowed if the names of the variables (which are unalterable) can be matched up. Of course that would encourage people to make the names of variables in polynomial rings indistinguishable, which is not good, because it then becomes harder to recognise the parent from an element representation. I would actually be happy with virtually no automatic coercions between polynomial rings. For any set of rules I think you will be able to come up with an example where the system will do something the user did *not* intend. Requiring the user to be explicit by means of a homomorphism might avoid confusion. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Focus problem in 2.4 notebook
I appreciate the great work done on the notebook, but I noticed a few usability degradations in the 2.4 notebook, having to do with focus of input cells. I think these are due to the introduction of syntax highlighting in cells without focus. The highlighting is useful, but the following problems arise (at least in both Firefox 1.5 and 2.0) - If an input cell has focus, and the firefox window loses focus (e.g., "focus follows mouse") and then regains focus, the input cell has lost focus! In 2.3, the input cell that had focus before the pointer left the firefox window, would regain focus, and that feels natural. I find the 2.4 behaviour confusing. - If I select text in a cell that does not have focus by dragging the mouse (i.e., either another cell has focus or no cell at all), then in 2.4 the cell with the selected text does not gain focus. In 2.3 it did. If you subsequently try to delete the selected text by pressing "backspace", the key press goes to the main browser window instead of the cell and you go to the previously visited page (shortcut for the "back" button) I can see how having text highlighting forced you to chance the cell type from "text input" to "html text block" or so and that an explicit click is needed to capture the event of gaining focus. However, the resulting interface behaviour feels very unnatural and sluggish to me (to the point of feeling uncooperative), whereas the 2.3 behaviour was quite natural and felt accommodating by comparison. If it really turns out to be a choice between syntax highlighting and sensible focus behaviour, I would have a serious preference for the focus behaviour, i.e., 2.3. Unfortunately I don't have the knowledge to assess whether that's the case, but I'm sure the notebook team has. bugtrac has been filed. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Notebook tab completion in magma mode
If the notebook has a worksheet open in "magma" mode, then tab completion almost works: One does get relevant completions back, but all of them are prefixed by "magma." Selecting one of the completions naturally leads to an error, because "magma.RationalField()" is not valid magma. Would it be possible to include a hook that allows post processing of the tab completion strings, depending on worksheet type? Simply stripping "magma." from each tab completion string would make the magma notebook mode a lot more useful. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Failure to install 2.6 documentation via -upgrade?
When I did a sage -upgrade, it ran into the following problem for the installation of the documentation: Extracting package /usr/local/sage/default/spkg/standard/ doc-2.6.spkg ... -rw-r--r-- 1 nbruin nbruin 3121152 Jun 5 16:25 /usr/local/sage/ default/spkg/standard/doc-2.6.spkg doc-2.6/ doc-2.6/#Makefile# [...] doc-2.6/ref/sage.functions.piecewise.tex Finished extraction There is no spkg-install script, no setup.py, and no configure script, so I do not know how to install /usr/local/sage/default/spkg/standard/ doc-2.6.spkg. make: *** [installed/doc-2.6] Error 1 It seems there is no installation script included in the documentation, so while I do seem to have a functioning sage 2.6 system now, the documentation is still old (2.5.3) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Make "attach" easier to use from the notebook
I just posted http://www.sagemath.org:9002/sage_trac/ticket/386 Currently, once a user outgrows the stage where their "def"s fit comfortably in cells in the worksheet, there is a rather abrupt change where they have to learn how to edit and maintain separate files and, what's more, put them in a location that is accessible from the notebook in order to attach the files. Currently, you can hack your way around it by creating files using %sh cat > file.sage
[sage-devel] Problem with linear algebra over Integers(D)
The bug below is actually a blocker for certain linear algebra problems over Z/dZ. From what I can see, apparently, elements of Integers(D) can be of one of IntegerMod_int, IntegerMod_int64 or IntegerMod_gmp and apparently they get mixed in the same parent. Coercion problems ensue. Unfortunately, resolving the problem is way beyond me. Would it be possible for someone who knows about the architecture to look into this problem? http://www.sagemath.org:9002/sage_trac/ticket/387 Example: A=matrix([(70, 49, -20, -34, 57), (-49, -14, 95, 43, 85), (-95, -63, 68, 52, 12), (11,-16, -50, 43, 76), (-55, 83, 55, 40, -14)]) D=A.determinant() R=Integers(D) MD=MatrixSpace(R,A.nrows(),A.ncols()) AD=MD(A) # You would expect elements of R and entries of AD to be of exactly the same type. # this is not the case, however: print parent(AD.row(1)[1]) print parent(R(3)) # Indeed, the types of these are not the same: print type(AD.row(1)[1]) print type(R(3)) # and this has consequences: You'd expect the following to work, but it gives an error: R(3)*AD.row(1) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE notebook 2
Looks great! I assume that the login and account stuff will all be configurable in the end. Can that be linked into unix authentication and kerberos tickets? I guess not . The browser probably doesn't have access to these things. It would be nice if I don't have to log in to sage to use it on my own machine, though, and still have some protection if it is a multi-user machine. (even on my desktop, other people in the network can log in in principle) I did find a few things when I gave it a whirl. Use them to your liking. It's really impressive that you got something this functional in only a couple of days! - Initially I found it hard to rename a worksheet. It's actually dead easy: click on the name. This was just not obvious to me from the start. - Currently the "Edit" button does nothing and the "Text" button gives the edit environment. However, I have been unable to save my changes from edit mode. Should that be the "save" button? - How and from where do I save and load objects? - How and from where do I attach files? - On the "home" page, I am called "Me", but in the revisions page I am called by my login - What is "archive" vs. "active"? - Can I empty the trash? - I was unable to import a saved worksheet from the old notebook - I do not like the 2 pull-down menus on the left - The third one (system) is great. I am afraid that currently it's a bit too minimalist, though. I think it needs to say "system: [sage| magma|...]" - The "new" option there is particularly confusing. The entries in that menu all pertain to the current sheet, except this one. What's worse, it's the default one, so it is always showing! - One/Multi Cell mode is a different thing from Interrupt/Evaluate all/Restart etc. You can't put those in the same menu. - tab completion in systems other than sage is still largely broken (prefixes) - search_doc is currently broken - Can the output of search_doc be prettified? title of page/section rather than the filename, perhaps? You may need some logic/conventions to find a sensible title for every page. - Help browser in the notebook needs a "search" box that interfaces to search_doc. (tree view on the side too?) - You can actually copy help pages from the notebook and make them worksheets for yourself! That's really good! It breaks the links, though :-) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE notebook 2
On Jun 27, 1:57 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > I'm a little worried about creating new accounts for each user, just because > that means the Notebook server has to have the ability to create new accounts, > which is probably a pretty serious ability to have. But I suppose sudo could > give them just access to the adduser command and not much else. Actually, > I sort of like this idea. > > William I understand that the ideas you are developing here are highly appropriate for an open notebook and are probably applicable to VMware'd systems too. However, the typical potential user doesn't have admin access themselves. It will be hard enough to convince system administrators to install software that listens on an outside port, but if that software can ALSO make new user accounts, it will probably be impossible (and otherwise the sysadmin should be fired) Please keep in mind there are other usage scenarios as well: - sage runs on a private machine, with essentially only one authorised login (think laptop) - sage runs on a workstation, with one main user but multiple people authorized to login (standard networked workstation) - sage runs on a rack server; multiple people are allowed to login and regularly do - prof wants to use sage as a teaching tool and for students to do assignments. Students are not very trusted, but the prof administering the sage system probably only has limited authority on the machine it runs on. Scenarios 1 through 3 would not necessarily be chrooted, because people using the notebook would normally have shell access anyway. The notebook could just listen on a local port and people can connect via ssh tunnels. It might even be desirable that, after authentication, I can access my own homedir files (makes for easy attaching & editing of custom programs and allows me to communicate easily with normal - homedir centric software. On the other hand, sage su-ing to my uid would make me slightly uncomfortable (sage is too complicated a program to do such delicate things). Scenario 4 does need good lockdown and probably protection against vandalism. However, the prof may not have enough permissions to set up what you described before. In this scenario, the notebook would probably have to listen on an outward port. The only thing that makes it not quite a "public" notebook is that accounts are not freely given out. Incidentally, if the notebook connects via ssh to the sage sessions, there is no reason for them to live on the same computer either anymore! This opens the road of running a central notebook process, where all the members of the department can connect. From there, the sage processes are run on a collection of machines! This setup only needs that the system can trust that the relevant parts of the filesystem are network shared, or (for the read-only parts) exact copies on all machines involved. These conditions are normally easy to meet on departmental research networks. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Quitting ignored worksheet vs. long computations
I understand the necessity to quit ignored worksheets in many cases, to save resources. However, it does kill a highly desirable behaviour that existed before: 1) start very long computation at work 2) kill browser, log out (process still running) 3) from home, connect to worksheet to check partial data, log out again 4) next morning, fire up browser and use results in worksheet that were completed at, say, 3am In the current model, I'm afraid the results would not be "living" anymore, because shortly after the session completed, it would probably get killed due to being "ignored". I understand there are work-arounds, like saving the resulting object as soon as it is computed, and in long computations it's advisable anyway to save checkpoints. The sage notebook behaviour used to be really friendly for these things, though. Cheers, Nils --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Quitting ignored worksheet vs. long computations
> [...] Would the following work for you? [...] >[Save] [Save & Close] [ Close & Leave Running ] [Discard Changes] Since you ask explicitly, yes that would work. The magical behaviour before was really surprisingly friendly, but rather unpredictable in resource usage. Keep in mind that it is still too easy to steer away from a page in most browsers, so a sheet can be "accidentally" closed. Is it possible to block navigation events? Also, from what I understand, worksheets are kept alive by the "polling" of the client? In that case, a flaky network connection (wireless?) or an accidental suspend of your laptop connecting to your backroom server could make you lose the state of a worksheet! This makes me think that a checkbox "this worksheet is persistent" might be better. Obviously, this option should not exist on servers that serve a wide range of users. It's really for people doing big computations on their own set of computers. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Error in determinant (serious!)
Probably something for upstream. Serious error in determinant of an integer matrix. Sometimes, 0 is returned for a full rank matrix. This is accompanied by some printed error warning, but no exception is raised. A bug has been filed: http://sagetrac.org/sage_trac/ticket/498 but given that this actually makes sage return wrong answers, I thought some extra attention might be due. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Algebraic number theory timings: Part I
Congratulations on your result. This is a very useful project and I am sure that nearly all computational number theorists will be very interested in the outcomes. If you do it properly, you could even considering submitting it to ANTS (it's not really mathematics, because the objects of study are the programs, not the mathematics, but because of the importance a good benchmarking will be very interesting. At the least worth a poster at ANTS) t is really useful to do a fair comparison between Pari and Magma. I would expect those two to be the leaders anyway. I would suggest running the timings, including the magma code you are using, past, for instance, Claus Fieker. It is in their interest to let magma come out well and if your tests show that it is hard to let magma choose the right parameters, they may improve the interface. The subexponential algorithms are very similar to the number field sieve and tuning the algorithms is very subtle and sensitive to the input. - I know the KANT/KASH project concentrated on larger degree, not large discriminant. Your fields do not really get into the large degree range (that would be more like degree 6 and up I would think) - Degree 2 is really special. You may want to talk to Michael Jacobson (University of Calgary) about that. He has worked on some really big computations for those and may be willing to share code/ ideas. - The "BachBound/40" should *only* come into play if *checking* that the full class group has been found takes considerable time. For higher degree or larger discriminant fields, you expect that you can easily find enough relations on a factor base much smaller than the minkowskibound, but at the same time, the factor basis should not be chosen too small. Sure, you only have to find very few relations then, but for a very small factor base they may be very hard to find. By feeding magma a smaller bound, you may be putting it at a disadvantage. Are you using SetClassGroupBounds? It takes two bounds: one for the factor basis, the other for checking the class group. - Representation of the field can make a *huge* difference. Doing a ClassGroup(LLL(MaximalOrder(K))) is sometimes *much* faster than ClassGroup(MaximalOrder(K)) (note that you should be timing the LLL and MaximalOrder separately) I have also seen examples where changing the representation of K (take a different generating element) hugely affects the running time (from not finising to finishing in a second) >From what I understand from the experts, the heuristics for finding relations are largely black art. - If at all possible, you should split your timings in 1) finding the class group (i.e., finding sufficient relations to get consistent unit and class group info) 2) verifying the class group information (checking that the ideals not in the factor base but below the bach bound, minkowski bound or whatever you want to use have classes that are already generated by the factor basis) since these are very distinct operations. - You seem to be picking your fields by choosing random generating polynomials. The lattices of their integer rings may have very different properties from fields that actually arise in practice (composite fields etc.). I don't have a good alternative, but you may invest some time in thinking about other kinds of fields and seeing if the algorithms behave similarly on them. - I recall somebody telling me that the newest versions of pari are using a customized GRH dependent bound. Apparently, they actually look at the L-series of the field and analyze some zero-free region to improve the Bach bound. If they are really doing that, and doing it correctly, that would eliminate the objection brought forward in the magma documentation (except that the results are still conditional on GRH by default). --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Possible SAGE days themes
Dear SAGE developers, William and I are considering organizing SAGE days at Simon Fraser University (Vancouver, Canada), probably somewhere in the summer of 2008, subject to securing the required funding. Both for the effectiveness of the meeting and for the purposes of getting funding, it is good to give a specific theme to the meeting. At this point we are open to suggestions. Points to keep in mind: - Themes that coincide with active development or badly needed development on sage are a little better - Themes that allow big shot speakers to be invited are a little better (helps finding funding and some of them can even be fun to listen to) - Themes that allow participation of undergraduates are a little better (again, helps finding funding) (of course, there is nothing wrong with having coding sprints and/or break-out sessions on topics that do not directly relate to the theme) One possible theme would be visualization and long range collaboration. SFU happens to have good equipment for this and has activity and experience in it. Sage is definitely in need of good visualization tools. Often, people turn to maple, matlab or mathematica simply to make pictures, so this is really an important use of a CAS. It is also a theme that has a low threshold for undergrad participation. Finding big shot speakers is perhaps a little harder. Suggestions welcome. Feel free to email me off list if that is more appropriate. The long range collaboration bit perhaps deserves some explanation. Consider a situation where people are in a real-time collaboration situation, for instance communicating via an audio/video link. It is common to have a common "whiteboard" in scenarios like that (essentially a shared drawing application, where people share the canvas) Perhaps it would be preferable to have a really intelligent canvas, i.e., a sage session? This could be either a notebook problem (how to handle a notebook that is opened by several clients simultaneously) or it could consist of two separate SAGE sessions with some shared objects. Formulated in the latter form, it has much in common with parallel computing, except that now two nodes get user input instead of a strict master/slave relation. It remains to be seen whether this is actually usable and/or preferable over other collaboration methods, but it is certainly a novel way of using a CAS and, thanks to its open architecture, SAGE would be by far the most suited. Anyway, if you have any ideas, either on a vis/coll theme or on some alternative theme, I would be happy to hear from you, either on this list or via off-list via email if more appropriate. Kind regards, Nils Bruin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Algebraic Number Theory Timings : Part 1 - Take 2
I would be very disappointed if this approach would be taken. Sure, it has to be straightforward and convenient to choose the level of rigour desired in class group computations, but by default results should be unconditional. It would be a real shame if SAGE, which tries to up the level of trustworthiness of computational proofs by having the source open for inspection would at the same time lower the level by tacitly assuming conjectures. Would you advocate that ranks of elliptic curves should be computed analytically because BSD is a well-established conjecture without known counter examples? Should we be computing ranks of arbitrary abelian varieties analytically because BSD doubtlessly holds for these too? It makes a big difference whether you prove "subject to GRH, this curve does not have rational points" or "this curve does not have rational points". By allowing unproved default behaviour in Sage for this, you will set a very bad precedent and you risk getting a bad word-of-mouth reputation of the kind "Oh you used SAGE for that? Better verify those results. They assume conjectures". Pari definitely suffered from that effect due to their "bachbound/40" and made me avoid it. I also don't agree that class group computations are virtually infeasible without conjectures. If the minkowskibound (or if someone wants to work out an improvement, the improved bound) is around, say 10^6, one can easily check the factorisation of all ideals up to that norm, even for degree 12 fields. This actually does happen for certain applications. On Sep 5, 10:00 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > On 9/5/07, Bill Hart <[EMAIL PROTECTED]> wrote: > > > Are you asking me? I'm not even sure I understand all the different > > options Magma offers yet!! > > > Basically I don't see any problem with doing the computation the way > > Pari does it, whatever that equates to in Magma. > > I'm specifically asking you, but would like to get feedback from > others. It seems to me that with most class number calculations, > one either assumes conjectural bounds or they all become > virtually impractical. > > Unless anybody seriously objects, I'm going to set the default > to False in SAGE, based on your comments below and my own > personal inclinations. > > > > > *IF* I understand it correctly, from Magma's point of view, Pari uses > > the bound BachBound/20 or BachBound/40 (depending on whether the field > > is quadratic or not) and uses the "subgroup" level of proof. > > > If you do demand "proof = true" then I believe you can do better than > > Minkowski's bound. Zimmert's bounds are also unconditional and better > > than Minkowski. > > > My reason for feeling that Pari's approach is OK is that in many cases > > you know that hR is at least correct from the way the algorithm works, > > if not it has checked up to a fairly conservative bound. You really > > can't go too wrong (though obviously it is not excluded > > theoretically). Furthermore there is a conjecture which gives an even > > lower bound than the bound used by Pari. There are also no known > > exceptions. > > > The thing that surprises me the most about this subject is that it > > probably isn't possible to compute the class number faster than the > > class group structure, especially in the generic case. One could get > > hR from the analytic class number formula, but to compute R one would > > need fundamental units, but computing those is essentially equivalent > > to what we are doing. Anything else I think of seems to have the same > > complexity except in very special cases where one knows something else > > in advance. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] let sage call the editor for you
A small enhancement that may be useful for people: since sage known about source file and line number of nearly any piece of code in sage, why not let sage open an editor window for you? Currently only works from the command line: http://sagetrac.org/sage_trac/ticket/768 Please try it out and improve it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multivariate polynomial coefficients
Both the poly.coefficients({x:1,y:2}) and poly.coefficients(x=1,y=2)
seem confusing to me (the latter one downright scary. Exponents and
variable names have no business being on opposite sides of an equality
sign). In mathematical terms, what you want to do is view the
polynomial ring k[x,y,z] as the ring k[z][x,y] and ask for the
coefficient of the monomial x*y^2.
Wouldn't it be clearer to have a call like
poly.polynomial_coefficient({z},x*y^2) ?
i.e., give the sum of the terms in poly that are of the form
z^e*x*y^2 ? In this setting,
(x^2*y^2+z*x*y^2+x*y).polynomial_coefficient({z,y},x*y^2) == y+z
which may be useful. polynomial_coefficient seems an ugly name to me,
but this interface is a lot easier to explain and much more explicit
about what the routine does.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: multivariate polynomial coefficients
On Oct 12, 1:25 pm, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
[...]
> Suppose I had a poly ring with 19 variables and one of them was named "y".
> How would I get the coefficient for y^0 in your syntax? (That is, the
> constant term in k[y][...].) This is the sticking point in what is currently
> implemented.
No, that would be the constant term in k[...][y]. The syntax would
then be:
poly.coeff({ a for a in poly.parent().generators() if a != y }, 1)
(i.e., all variables except y are allowed)
except that python doesn't like set comprehension (why not? is there
an unordered list type with quick membership test?), so we might want
to make it a list instead:
poly.coeff([ a for a in poly.parent().generators() if a != y ], 1)
If that is the most common usage scenario you have in mind, then this
notation might be a tad wasteful. Would surgery on poly.dict() solve
your problems?
Incidentally, poly.coefficient does have documentation. The behaviour
you describe is a bug relative to that description. The alternative
behaviour that you describe, nor mine, is in line with the definition
given there either.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade and file corruption
I think you can easily make tar-archives that contain a checksum, if you agree on some extremely mild file naming convention for such a checksum (i.e., the archive is not allowed to contain a filename that clashes with the file that stores the checksum). Of course, the key is that when you add something to the archive, the file changes, so the plain md5sum of the total archive changes. You have to md5sum something that is easily extracted and independent of the later added md5sum. The options -O (dump to stdout), -r (append file) and -- exclude provide the necessary features for tar. Procedure for storing a checksum in a tar archive: -- (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum > md5sum.check tar -rf file.tar md5sum.check -- Procedure for checking that the stored sum agrees with the computed one: -- tar xf file.tar md5sum.check -O > storedcheck (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum > computedcheck cmp storedcheck computedcheck -- Note that we need to include the directory listing information as well, because the output of -O does not include file names (i.e., one could move files around and still have the same checksum) If it is ever decided that .spkgs should be signed, then you could include a .gpg-file via the same procedure. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] edit_module patch updated
See: http://sagetrac.org/sage_trac/ticket/768 I have updated the attached patch to be clean against 2.8.8.1. When I checked the edit() command in sage 2.8.8.1, I realized it was really broken -- It doesn't work if EDITOR is unset in the environment. The patch attached to the trac ticket is supposed to fix that. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
OK, so this is caused by my lack of knowledge of how emacs operates.
Really, we are talking about two editors here, one a tty-application
and the other an X-windows application. They happen to be called by
the same command invocation, so there must be something in the
environment that decides which gets run (or at least in which mode it
gets run). Wouldn't it be nicer if sage would look at the environment
and predict the behaviour of emacs? Does emacs decide what to do based
on the DISPLAY variable? Does emacs always do that? How about people
that have an older, non-X-windows aware emacs?
I understand that the "bg=" hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
Jf we want sage to pop up "the appropriate editor", the user should
not be required to give an extra option like that. In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
&')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
wrap this into the set_editor command instead of the "bg=" option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
until it is an encyclopedia of editor invocation sequences)
Another solution would be two possible "editor templates": emacs-fg
and emacs-bg.
On Oct 23, 11:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
>
> > See:
>
> >http://sagetrac.org/sage_trac/ticket/768
>
> > I have updated the attached patch to be clean against 2.8.8.1. When I
> > checked the edit() command in sage 2.8.8.1, I realized it was really
> > broken -- It doesn't work if EDITOR is unset in the environment. The
> > patch attached to the trac ticket is supposed to fix that.
>
> I'm generally happy with this patch, though I don't agree with removing
> the bg option. Perhaps you're removing that functionality because
> your particular workflow is more rigid than mine. For example, I use
> emacs quite a lot, both in a console (especially when I login to other
> machines), but also as a popup separate application. When I use emacs
> in console mode, putting the editor in the background is very frusting,
> and doesn't work at all. When I use emacs as a separate popup application, it
> is very very frustrating if the console session freezes, since often the
> reason
> I'm popping up the editor is to create some examples in the console and
> paste them into the docstring of a function. In both cases the command
> name is exactly the same "emacs".
>
> So please change the patch back to have the bg option.
>
> This is a lot like black on white versus white on black. Most people
> exclusively
> use one or the other mode, and it's impossible to know which from the
> application's point of view.So applications have to support both and make
> it easy to switch between generating colors for each. I often switch between
> using emacs and vi, both in window and console mode, and between black
> on white and white on black, depending on my mood, eye strain, computing
> I'm logged into, etc. So it needs to be easy to support changing modes.
> The bg= option to edit is 3 lines of code and does just that; it allows one to
> very easily override automatic defaults on a per-use basis.
>
> -- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
OK. Sounds like SAGE will *NOT* be able to read your mind, then. "bg"
option added back in
(can both be used to strip "&" from and to add in "&" to the default).
Ticket reopened.
Thank you for explaining why you need the "bg" option and why the
obvious workarounds don't work in your case.
The "problem" with the options in general is that they clutter the
interface and should be limited to the minimum. Their perceived need
often points to a design flaw. In this case it does too: we are
failing to predict what emacs is going to do. However, as you
describe, it seems too difficult to do so, so I'm happy putting it
back.
On Oct 24, 9:50 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
>
> > I understand that the "bg=" hack is a quick way of getting the
> > configurability you want, but frankly, I would find it hard to explain
> > the existence of that option independent of the very particular usage
> > scenario you describe.
>
> To you, since you don't use it, it is a "very particular usage scenario".
> To me it is the normal very common (for me at least) usage scenario.
>
> > Jf we want sage to pop up "the appropriate editor", the user should
> > not be required to give an extra option like that.
>
> I certainly don't propose that they have to give the extra option.
> It is optional. There should still be the default proposal you implemented.
>
> edit(.., bg=None)
>
> does the default
>
>edit(..., bg=True)
>
> does the background = True mode,
>
>edit(..., bg = False)
>
> does the background = False mode.
>
> > In the model I
> > proposed (which clearly is inconvenient to you, so we need to see how
> > to wrap this), the solution would be to put into your init.sage
> > (basically following a suggestion Justin made):
>
> > if os.environ.haskey('DISPLAY'):
> > sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
> > &')
> > else:
> > sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
>
> > So, if you're sure that this does for emacs what you want, we could
>
> I'm sure that does *not* do what I want. When I login to my laptop
> under Linux the DISPLAY environment variable is not even set, yet
> emacs pops up in a window.When I login remotely to another machine
> (or my laptop, from OS X), it can easily be that DISPLAY is not set.
> I also have a similar issue with my office desktop, which I use both
> remotely and when I'm actually in my office at the console.
>
> > wrap this into the set_editor command instead of the "bg=" option.
> > Then the appropriate magic gets executed if either 'EDITOR=emacs' or
> > if set_editor('emacs'), and currently even if edit(..,
> > editor='emacs').
>
> > Guessing a user's configuration and preferences will stay hackish
> > guesswork. I'm happy to put some guesses into set_editor. Ultimately,
> > however, people should just put personal configuration stuff into
> > init.sage. (either that or every user patches sage.misc.edit_module
>
> ^
>
> That doesn't work for me, since in my usage the init.sage is the same
> in both cases, and I often switch between both usage scenarios.
>
> > Another solution would be two possible "editor templates": emacs-fg
> > and emacs-bg.
>
> I just want to type
>sage: edit(name)
> and have it work. If it happens to be that a window pops up, and will
> say to myself -- gee, I need this to be backgrounded so I can type
> command still, and I'll instead do
>sage; edit(name, bg=True).
>
> Anyway, I can't see the problem with having that option, and your only
> argument against it is that "it is difficult to explain in the documentation".
>
> -- William
>
>
>
>
>
> > On Oct 23, 11:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > > On 10/22/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
>
> > > > See:
>
> > > >http://sagetrac.org/sage_trac/ticket/768
>
> > > > I have updated the attached patch to be clean against 2.8.8.1. When I
> > > > checked the edit() command in sage 2.8.8.1, I realized it was really
> > > > broken -- It doesn't work if EDITOR is unset in the environment. The
> > > > patch attached to the trac ticket is supposed to fix that.
>
> > > I'm generally happy with this patch, though I don't ag
[sage-devel] Re: Specifying variable names
> One possibility, which I haven't quite thought through, is to allow the > user to get away with: > > R=PolynomialRing(ZZ) > In principle, the only reason why one *has* to give the indeterminates a name, is to make sure that polynomials can print in a sensible way. However, in the absence of variable names, there are still sensible ways of printing polynomials. To give some ideas: sage: R=PolynomialRing(ZZ) sage: f=R.0^2+2 sage: f Polynomial over Integers() with coefficient vector [2,0,1] Or, perhaps for multivariate poly's sage: R=PolynomialRing(ZZ,3) sage: f= R.0*R.1+3*R.1^2 Multivariate polynomial over Integers() given by [(1,(1,1)),(3,(0,1))] (i.e., specify a sparse polynomial by a list of pairs of coefficient and exponent vector) As a related example: When I define VectorSpace(Rationals(),5) I shouldn't be required to specify names for the basis vectors either, should I? Would you like to extend your binding injection to get sage: VectorSpace(Rationals(),5,'b') sage: b0,b1,b2 (1 0 0 0 0) (0 1 0 0 0) (0 0 1 0 0) I would be strongly in favour of not making it mandatory to specify indeterminate names. Is it acceptable to allow name assignment later anyway? Or would the violation of the immutability of rings be unacceptable. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Possibility for a PIMS Sage days
Since both SFU and UW are PIMS participants, there is a very good case to be made for a PIMS funded Sage Days at SFU. We should write a 1 page proposal: - Emphasize UW/SFU link (collaboration between different PIMS sites!) - Come up with other sources of funding. That way PIMS can match rather than foot the entire bill. Doesn't even have to be 1:1. Do we have other funds? - Speaker list. Good names help - Time frame: When should PIMS sage days be happening? I'd say December 2007 at the earliest. - Undergrad involvement/educational aspects Do people already have information/documents along these lines they wish to share? If we are aiming for late 2007/2008 we should probably submit a proposal soon. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] ECL as a library
A little experiment to see if ECL can be used as a library from python, and after browsing through ECL's API, it looks like it should be fairly straightforward to wrap the API with cython. The data format that ECL uses for its objects should also be easy to interface with, and since many of the atomic types of ECL have a direct analogue in Sage, binary conversions should also be feasible. My first try was the result of a lot of reading and then cut&pasting completely obvious code. At least I learned something in the process. My compliments to the cython people. It's amazingly easy to use! (although not so easy outside of sage. I couldn't get it to find the library, even though I was working in the appropriate "sage -sh". Anyway, hello world: http://trac.sagemath.org/sage_trac/ticket/6781 It makes sage segfault on exit, though, and I have no idea why. Further obstructions: - If one keeps pointers to ECL objects outside of ECL's management (i.e., a cl_object pointer in a cython object), one needs to tell ECL's garbage collector about it. I don't know how. - If one wants to use this for maxima, it needs to be built as a lisp library rather than an executable. Judging from the recommended ECL build process, I suspect that such a thing already does get built, but I didn't check. In the mean time, it seems like a nice project to allow "ECL programming in python". Any feedback on the obstructions above? I respect William's comment on "no big picture talk without doing the work", so I might give the wrapper a further shot if I can solve the preliminary issues. Nils --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
On Aug 20, 2:09 pm, Juanjo wrote: > > - If one keeps pointers to ECL objects outside of ECL's management > > (i.e., a cl_object pointer in a cython object), one needs to tell > > ECL's garbage collector about it. I don't know how. > > extern ECL_API void ecl_register_root(cl_object *p); > > But a more useful procedure is to store the data in lisp variables. Thank you! Should I call that on any cl_object that lives outside ecl? or only (as the name suggests) on the root of a cl_object tree? Can the garbage collector move allocated pieces around? (so, can pointed become invalid for reasons other than deallocation?) Am I right in assuming that if a cl_ routine gives me back a cl_object pointer, I can trust that this pointer will remain valid until the next time that I call a cl_ routine? Would threads invalidate that assumption? Should I call ecl_register_root immediately after being supplied with the pointer to ensure the object doesn't inadvertently get deallocated? Is there a corresponding ecl_deregister_root to be called when I no longer need the object? Are you suggesting that I'd be better off allocating a vector or an a- list in ecl and store any reference to an ecl structure in that and address it using an index or a handle? That could definitely be arranged. > I wonder whether you have found some of the embedding examples in the > mailing list and wiki (http://sourceforge.net/apps/mediawiki/ecls/ > index.php?title=Simple_embedded_usage) More sophisticated recipies can > be posted, if needed. Yes I have and in fact, the track ticket contains a straight translation of that example into cython. The initial usage scenario I am thinking about is to first create a cython class cl_object, which wraps an essentially opaque pointer cl_object. c_string_to_object can easily be wrapped to produce such objects, and via write-to-string they are easily turned into strings as well. Translating the ecl API is completely straightforward in that model. Once that works, one could gradually de-opaque-ify cl_object and provide access to the different fields, depending on the type. This would allow more efficient conversion between ecl and python native data types. If you know of examples that may contain relevant code for this, I'm very interested in pointers. > ECL can build maxima using a list of object files. The last step is > now a build-program (see maxima/src/maxima.system). If instead of that > you use build-fasl, you will get a big binary file maxima.fasl, that > you can load using ECL's library function (cl_load). Great. That's exactly what I hoped. Incidentally, I managed to attach gdb to sage to get a little insight in the segfault that happens when sage with ecl shuts down: Program received signal SIGSEGV, Segmentation fault. GC_free (p=0x1c584fc0) at malloc.c:412 backtrace: #0 GC_free (p=0x1c584fc0) at malloc.c:412 #1 0x2b5798868966 in ecl_dealloc (ptr=0x184) at /usr/local/sage/4.1.1/spkg/build/ecl-9.4.1/src/src/c/alloc_2.d: 265 #2 0x2b57790572e2 in __pyx_pf_4sage_5rings_7integer_free_integer_pool ( __pyx_self=, unused=0x8) at sage/rings/ integer.c:29479 #3 0x004933b5 in PyEval_EvalFrameEx (f=0x1c92d8d0, throwflag=) at Python/ceval.c:3690 [...] It seems a bit strange to me that the sage integers would have any business calling ecl_dealloc, but this may ring bells with people who have looked at either the sage or the ecl memory management. In order to reproduce, apply patch on ticket 6781 and run something like this in sage: sage: from sage.libs.ecl import * sage: hello() sage: quit --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
On Aug 21, 2:27 am, Juanjo wrote: > [...] ecl_register_root is only scarcely > used, and only for static variables. If you keep references to objects > in the C stack, this will not be needed (as far as the garbage > collector knows your thread) Thank you very much. Keeping an array of pointers in LISP memory definitely sounds like the way to go then. Since GC is conservative, I wouldn't even need to use those pointers to access the objects, only to keep them reachable in the view of GC > > Once that works, one could gradually de-opaque-ify cl_object and > > provide access to the different fields, depending on the type. > > Please do not do that! Use the standard accessors that Common Lisp > provides (http://www.lispworks.com/documentation/HyperSpec/Front/ > Contents.htm) I agree. I'll use those functions as much as possible. However, there are no functions there to efficiently create a bignum out of a gmp integer or vice versa. I also didn't find a function to turn a lisp string into a c string. I'll have to reach into the implementation of cl_object for those (where, currently, these operations are indeed trivial). I can understand that ecl doesn't want to pin itself to gmp for bignums, so efficient conversion of those will have to be non- portable. [.. regarding the stack trace .. ] > Why is Sage calling an ECL function at all? I'm out of my depth there. William says corrupted stack. Could uncoordinated signal handlers have to do with that? cl_boot does install signal handlers, which obviously doesn't sit well with sage. With the current patch on ticket 6781, after running "hello()", a CTRL- C will drop you into an ECL top level prompt -- with keyboard echo turned off. Typing "(continue)" gets you back at the sage prompt. We are going to need a way to either prevent cl_boot from installing a signal handler or to pop cl_boot's signal handler (are those things stacked?) or replace it with the original again. Are there on-exit hooks that both python and ecl sign up for? I imagine both ecl and python have rather invasive memory managers. Perhaps their clean-ups clash? --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
Maxima can indeed be coerced into behaving like a library in ECL. The changes required are relatively small and it would be easy to incorporate them into the current spkg. I haven't bothered, since other people are already working on a new maxima. Details posted on: http://trac.sagemath.org/sage_trac/ticket/6781 The ticket also contains an example session where maxima functionality is used in a library-like way. The wrapper for ECL is still only a hack. Should this be a road worth taking, someone would have to think what the most appropriate way would be to set it up. Issues: 1. Signal handler collision between sage and ecl 2. sage segfaults upon exit if ecl has run 3. ecl by default has an error handler that doesn't work well inside sage 4. current wrapper is not GC-safe, but that's straightforward to fix. I'm completely out of my depth for 1, 2, so input from someone else would be highly appreciated. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
On Aug 22, 2:23 am, Juanjo wrote: > A C function can be used to deactivate trapping of signals Thanks! that is probably a more elegant way. I found the POSIX "sigaction" which allows signal handlers to be read and set. Bracing cl_boot between an appropriate amount of those seems to do the trick. Incidentally, must be one of the most painful headers to translate into cython: It uses both a function "sigaction" and a data type "struct sigaction". Since cython squashes the struct namespace into the general namespace, there are some collisions to work around. > > 2. sage segfaults upon exit if ecl has run > > Run cl_shutdown() manually before Sage exits. ECL registers its own > exit handler using atexit(), perhaps that is the problem. running cl_shutdown manually doesn't seem to be correlated. I tried removing the one atexit() call that appears in the ecl source, but the segfault still occurs. The segfault only occurs after sage has printed its goodbye message, so it's definitely something in the cleanup process and it doesn't really functionally affect anything. A C-level debug wizzard would probably find the offence in no-time. This is the only unresolved issue for now, because: > > 3. ecl by default has an error handler that doesn't work well inside > > sage > > In what sense? I think browsing your replies to other people's questions solved that one (good candidate to include in embedding examples!): si_safe_eval(3,obj,NIL,NULL) evaluates obj and returns NULL upon error. It seems that NULL is a completely illegal cl_object, so that is sufficient to properly detect an error condition. (of course, by now we have completely lost any idea of *what* the error was. Or does the "last raised error message" get cached somewhere?) --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
On Aug 22, 2:16 pm, William Stein wrote: > Nils -- why don't you build everything in your (presumed) account on > sage.math.washington.edu? Then you can easily given Juanjo access to that, > since he also has an account on sage.math.washington.edu. Done. The following is now available on sage.math: /scratch/nbruin/sage-4.1.1-ecl/--- a working sage tree with an ecl- library extension /home/nbruin/sage-4.1.1-ecl-x86_64-Linux.tar.gz --- the above tree "- bdist"-ed /home/nbruin/ecl-crash.sage a script to effect the crash /home/nbruin/use-ecl-maxima.sage a script demoing interfacing with maxima the crash is completely predictable and reproducible. This does the trick: /scratch/nbruin/sage-4.1.1-ecl/sage < /home/nbruin/ecl-crash.sage I'm looking forward to any insights people might have. In fact, I think I already know the cause of the error: the GMP library does have some global state in the form of mp_set_memory_functions. cl_boot does call that via init_number to set ECLs memory allocation routines. Of course, sage uses GMP as well, and allocates some integers right from the start. So it's no surprise at all that integer_free_integer_pool seems to call ecl_dealloc, because it does (via some gmp macro for deallocating a gmp integer), and since that integer was allocated by another memory manager, a segfault is entirely expected. I think this is a complete showstopper for including ecl as a library. Should we call mp_set_memory_functions before and after each call to ecl? And then just be very hygienic about which gmp integer goes where? Not letting ecl set its memory management for gmp would not be an option, because only ecl knows if the memory can be freed. I thought the fact that ecl also using gmp would make it very compatible with sage. Turns out it's a major stumbling block. --- Concerning the safe-eval: Ah, of course. You are just catching the error on lisp-level. Now I can write my own error handler if that's necessary. Concerning signals: Is it necessary for ECL to be notified of signals? I think it's good if sage gets them, so "sigaction" might be the better way to go. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Using MPIR or GMP with multiple memory managers
The following problem came up while trying to use ecl as a library inside sage: Both sage and ecl use GMP for their multi-precision arithmetic, and both call mp_set_memory_functions to register their memory managers. This obviously doesn't work, since GMP only keeps track of one set of memory management routines. Ecl needs to use its memory manager, since it relies on Boehm for garbage collection and sage needs to use its own because python relies on reference counting. I have left the discussion specific to ECL, but the problem arises in general: GMP has global state, so using the same GMP from several places can lead to conflicts. Juanjo, the lead developer of ecl has suggested several work-arounds (Thank you, Juanjo. Your expertise is a great help). I hope some people with more knowledge of sage memory management, mpir and build processes can comment on the feasibility and maintainability of the different options: 1. Build ecl with its private gmp library. (a) Can that be done on link level? i.e., take ecl.so and gmp.so and produce ecl-gmp.so from the two, with all references of ecl.so to gmp.so resolved and made private? (i.e., make an ecl.so with gmp "statically linked in"). (b) Can that be done compile-time for ecl? i.e., when you compile ecl to produce ecl.so, make the compiler/linker resolve any references to gmp and prevent any of the gmp symbols from leaking out as public in ecl.so? (c) Is there an economical and maintainable way of pushing gmp-for- ecl in its own namespace? 2. Make the mp_set_memory_functions state thread-local and run ecl in its own thread. (a) Does that involve changing the gmp/mpir library? 3. Make sage use Boehm as well :-). That may be an option when reference counting is discovered to be an insufficient memory management strategy for sage in general. 4. Change ECL so that its uses of GMP are braced by mp_set_memory_function (a) That wouldn't be thread-safe, would it? Or are GMP instructions "atomic" with respect to threads? Could we make them that way? (b) In that case, it might be helpful to have a complete list of GMP instructions that could possibly lead to calls to alloc,realloc,free. Only those would need treatment. (c) Could this be done by properly mangling gmp.h? Thanks to Juanjo for helping this project progress. Other possibly relevant remarks: 5. This problem isn't unique for ecl/sage. Any setting where gmp is used by several libraries at once potentially causes this problem 6. This problem does not arise in general when you try to extend python with ecl, because normal python does not use gmp. So building a python/lisp hybrid is quite feasible. 7. The main drive for using ecl-as-a-library in sage is to get a faster interface with Maxima. If all options above turn out to involve a lot of work or are expensive to maintain, perhaps we need to find another way of speeding up the interface. As a side effect, we already have maxima-as-a-library in ecl now. Processes can communicate efficiently in various ways. Shared memory? Send data info through a pipe? With a little programming on both the sage and the ecl side, we could make a binary communication protocol. Definitely not as satisfying a solution as a library interface, but perhaps good enough. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ECL as a library
On Aug 23, 3:43 am, Juanjo wrote: > > Concerning signals: > ECL does not need to be notified of signals. The important thing is > that Sage's code does not interrupt ECL's code at arbitrary places and > then transfers control out of them. > > For instance, interrupts during memory allocation are bad. Also when > initializing certain objects. If the interrupt handler jumps out of > that code in an arbitrary way, the program may be left in a corrupt > state. > > If your signal handler does not jump to outer points, but rather does > normal returns, then there is no problem with installing that handler. > Otherwise, as I said, we can instruct ECL's handler to delay signals > after the critical code has finished and then pass them to whatever > handler was installed before. > > Use of sigaction inside ECL is definitely _not_ an option. It is a > very expensive call to put in front of every memory allocation > routine. > > As a side note, no sensible signal handler would do any other thing > than returning, for POSIX interrupts do not guarantee reentrancy of > code. However, I do not know what is the quality of Sage's interrupt > handling right now. That is good to know. I noticed that in cython code, there are options for turning signals on and off. We could just turn signals off any time we enter ecl and back on when we return. The obvious drawback would be that this means the CTRL-C will not work within ECL code. If ECL were to get signals, I guess it could just raise an error if CTRL-C happens. But then ECL would indeed need to have its signal handler in place (and hence call the previous signal handler too, to give sage a shot). Anybody with good knowledge of sage signal handling with some input? --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 23, 4:08 pm, Martin Albrecht wrote: > > > Both sage and ecl use GMP for their multi-precision arithmetic, and > > > both call mp_set_memory_functions to register their memory managers. > > > This obviously doesn't work, since GMP only keeps track of one set of > > > memory management routines. Ecl needs to use its memory manager, since > > > it relies on Boehm for garbage collection and sage needs to use its > > > own because python relies on reference counting. > > This is not correct, last time I checked we basically told GMP to use system > malloc (1). There is no issue of reference counting at this stage. Can't we > just steal the memory management functions back after ECL was initialised? > This is what we do after libSingular is loaded which also registers its own > malloc/free/remalloc functions. Ah, that is very useful information. That means that at least SAGE will call mpz_clear etc. on any unused integers. When grepping through the ecl source, I was only able to find one call to mp.*clear, and that is in the rational-to-double routine: Rationals in ECL are stored as numerator-denominator pairs. In order to arrive at a double, ECL constructs the corresponding mpq, asks for the double and clears the auxiliary mpq. A few observations on how ECL seems to use GMP. If we can verify these assumptions, it may not be too big a problem to steal back the GMP memory management routines: 1. bignum allocation seems to avoid mpz_init and use ecl_alloc_object to get its memory directly 2. computational routines seem to end with "copy register into preallocated bignum". If this is true, then ECL bignums will always live in Boehm managed memory, even if the GMP memfunctions are set otherwise. Registers, on the other hand, could live entirely under GMP memory control. These assumptions are currently not entirely met: a. big_register_free does not call mpz_clear (perhaps it shouldn't! but then it shouldn't be zeroing out its contents either. The next time the register would already have space preallocated) b. I'm not sure about init_big_registers c. In big_register_copy, there is a shortcut that tries to avoid copying if the mpz has undergone a realloc. This would allow leaking out of GMP managed mpz's into bignum objects. However, it seems if all the violations are in one small file: big.d. So the questions for Juanjo now are: A. is my analysis above correct? so, are mpz routines only called to modify a "register"? B. am I correct in thinking that one would only need to change "big.d" to make assumptions 1,2 hold? C. would you be interested in having those assumptions hold in ECL in general (or perhaps have a compile-time option to make them hold)? D. would you be willing to write the patch? I might be able to do it, but for you it's probably easier to oversee ramifications of the changes. My compliments on a very clean codebase, by the way. I wasn't expecting that it would be so easy to figure out how ECL works (but then again, I might have misunderstood). Kind regards, Nils --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 23, 1:58 pm, William Stein wrote:
> To whet our appetite though, might you do some benchmarks that compare
> the speed of adding 2+2 via the library and via pexpect?
OK, here's a little experiment. I thought adding 2 and 2 would be too
hard for now, so I stuck with 1+2. Good news is that all routines
arrived at the correct answer. I did count the conversions back and
forth every time as well, so times are not so very low. The
conversions are completely string based, so I think performance can be
quite a bit better still. Anyway, results:
ecl/library (+ 2 2): 27.6 µs per loop
maxima/library(+ 2 2): 134 µs per loop
maxima/pexpect(+ 2 2): 4.97 ms per loop
python/strings(2+2): 14 µs per loop
So yes, library access does work a little better than pexpect.
code used:
sage: from sage.libs.ecl import *
sage: init_ecl()
sage: ecl_eval("(require 'asdf)")
;;; Loading #P"/home/wstein/build/sage-4.1.1/local/lib/ecl-9.4.1/
asdf.fas"
;;; Loading #P"/home/wstein/build/sage-4.1.1/local/lib/ecl-9.4.1/
cmp.fas"
;;; Loading #P"/home/wstein/build/sage-4.1.1/local/lib/ecl-9.4.1/
sysfun.lsp"
sage: ecl_eval('(load "%s")'%(SAGE_ROOT+"/local/lib/maxima/
maxima.fasb"))
;;; Loading "/scratch/nbruin/sage-4.1.1-ecl-x86_64-Linux/local/lib/
maxima/maxima.fasb"
sage: ecl_eval('(in-package :maxima)')
>
sage:
sage: def ecladd(a,b):
: return eval(str(ecl_eval('(+ %s %s)'%(a,b;
:
sage: def libadd(a,b):
: return eval(str(ecl_eval('(MEVAL #$ %s + %s$)'%(a,b
:
sage: def maxadd(a,b):
: return (maxima(a)+maxima(b)).sage()
:
sage: def pythadd(a,b):
: return eval("%s + %s"%(a,b))
:
sage: timeit("ecladd(1,2)")
625 loops, best of 3: 27.6 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 134 µs per loop
sage: timeit("maxadd(1,2)")
5 loops, best of 3: 4.97 ms per loop
sage: timeit("pythadd(1,2)")
625 loops, best of 3: 14 µs per loop
--~--~-~--~~~---~--~~
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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 23, 8:15 pm, William Stein wrote:
> On sage.math (Linux) I get the same timing as you:
That's good, because that's where I did it.
A sage with the ecl library interface is available in "/scratch/nbruin/
sage-4.1.1-ecl-x86_64-Linux" so if you want to do timings for
yourself, you can.
The slowing down has nothing to do with the sage interface, but
probably with the macro #$...$
sage: timeit("libadd(1,2)")
625 loops, best of 3: 157 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 197 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 265 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 347 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 450 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 611 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 840 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 995 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 1.23 ms per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 1.42 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 1.54 ms per loop
If we take maxima's parser completely out of the picture:
sage: def libadd(a,b):
: return ecl_eval("(meval* '((mplus) %s %s))"%(1,2))
:
sage: timeit("libadd(1,2)")
625 loops, best of 3: 14.5 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 14.4 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 13.9 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 14.9 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 14.9 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 15.1 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 15.1 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 14.9 µs per loop
we see a much more respectable time, and more importantly, no
systematic increase. There is still a "string_to_object" involved
here. We could also do:
sage: L=string_to_object("(meval* '((mplus) %s %s))"%(1,2))
sage: L
sage: timeit("L.eval()")
625 loops, best of 3: 3.42 µs per loop
sage: timeit("L.eval()")
625 loops, best of 3: 3.41 µs per loop
sage: timeit("L.eval()")
625 loops, best of 3: 3.42 µs per loop
sage: timeit("L.eval()")
625 loops, best of 3: 3.47 µs per loop
which takes all communication out of the picture. It's just maxima
simplifying the expression to 3. ECL has a good C-level interface to
construct and take apart lisp S-expressions, so ultimately we would
not be talking to maxima's parser at all. I just haven't interfaced
those routines yet. I think it does shows that there are considerable
gains to be had.
--~--~-~--~~~---~--~~
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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 7:55 am, Robert Dodier wrote:
> The #$ macro constructs a string input stream and eventually
> calls ADD-LINEINFO so it suffers from the bug I mentioned in
> a previous message.
The $NOLABELS variable seems to live in local scope somewhere, and
hence setting it does not affect the detoriation in the #$...$ macro:
with the following code (which just calls the #$...$ macro a lot):
from sage.libs.ecl import *
init_ecl()
ecl_eval("(require 'asdf)")
ecl_eval('(load "%s")'%(SAGE_ROOT+"/local/lib/maxima/maxima.fasb"))
ecl_eval('(in-package :maxima)')
ecl_eval('(setq $nolabels t))')
def libadd(a,b):
return eval(str(ecl_eval('(MEVAL #$ %s + %s$)'%(a,b
sage: timeit("libadd(1,2)")
625 loops, best of 3: 192 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 654 µs per loop
sage: timeit("libadd(1,2)")
625 loops, best of 3: 1.51 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 1.85 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 1.94 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 2.02 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 2.13 ms per loop
sage: timeit("libadd(1,2)")
125 loops, best of 3: 2.23 ms per loop
sage: ecl_eval('$nolabels')
--~--~-~--~~~---~--~~
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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: spkg trouble
On Aug 24, 1:21 pm, "Dr. David Kirkby" wrote: > I can see from the processes being created that something is calling > 'top -b -n' thousands of times. Had Sage been distributed as a big > tar.bz2 file, I could extract that, and then use a recursive grep to > find 'top -b -n'. Why don't you take a source distribution and do: cd $SAGE_ROOT/spkg/build find .. -name \*.spkg -print | xargs -IU tar xjf U That will have all your sources unpacked (modulo patches that install.sh might apply) A grep on that will take a while and give you all hits. > I'd personally much rather see the Sage code was distributed as a more > conventional .tar.gz or .tar.bz2. It is, just a couple of them. With funny filenames. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 2:44 pm, Bill Hart wrote:
> void
> mp_set_memory_functions (void *(*alloc_func) (size_t),
> void *(*realloc_func) (void *, size_t, size_t),
> void (*free_func) (void *, size_t))
> {
> if (alloc_func == 0)
> alloc_func = __gmp_default_allocate;
> if (realloc_func == 0)
> realloc_func = __gmp_default_reallocate;
> if (free_func == 0)
> free_func = __gmp_default_free;
>
> __gmp_allocate_func = alloc_func;
> __gmp_reallocate_func = realloc_func;
> __gmp_free_func = free_func;
>
> }
>
> Not very extensive huh. I actually don't see a solution to this
> problem that involves mpir. In fact I think this is a security issue
> and I don't think this capability should even exist.
I do not understand what you mean, partially because I don't
understand what you mean by "this capability". If you think it's
relevant, would you mind explaining a little more elaborately?
In other news, I now see that my assumptions about ECLs usage of GMP
do not hold at all. They are depending on GMP claiming memory for them
almost everywhere.
However, a bignum in C is immutable, so after its creation it does not
change value anymore. So it might actually make sense to preallocate
bignums as
[mp_size, mp_d, , mp_alloc, limb[0], limb
[1], ... , limb[mp_alloc-1]]
i.e., put the limbs straight after the mpz_t. That way, creating a
bignum only takes one alloc, instead of two.
We would have to ensure that enough limbs are allocated to upon
creation. One way to do that would be to let GMP create the result in
a temporary variable, copy over the limbs into the bignum and call
gmp_free on the temporary variable (or keep the temp around for the
next time). That would always incur an extra copy, but the current
implementation in ECL does something along those lines (but not
always).
Does GMP have routines somewhere that predict how many limbs the sum,
difference, product, exponential of an answer going to need? Naively,
I would think:
nlimbs(a+b) <= nlimbs(a)+nlimbs(b)+1
nlimbs(a*b) <= nlimbs(a)*nlimbs(b)
etc.
Is that correct? Or do certain optimizations/weird platforms mean that
these naive bounds can be wrong?
I think it should be possible to rewrite the bignums of ECL such that
the only "mpz_t"s that GMP allocates/reallocates are "registers",
i.e., temporary variables that do not need to be garbage collected,and
if we can predict the sizes beforehand, we may even be able to gain
some efficiency by eliminating some uses of "registers" in the current
code.
That might make the change a little more palatable to the ECL
maintainers. It would also mean that the "embeddability" of ECL would
increase a bit by not requiring that ECL administer the GMP's memory
allocation.
--~--~-~--~~~---~--~~
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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 4:51 pm, Jason Moxham wrote: > To me 1) sounds like the best option, if ecl links with it own static version > of gmp , then as long as we aren't leaking any symbols everything should just > work . We are leaking some symbols though , some by accident , and some on > purpose for testing/tuning, would have to have a closer look to see how many > and what they exactly are , and how easy it is to "switch them off" for a > local ecl static build. OK, let's make this a bit more concrete. I think the following line gets executed during the ecl build in order to product libecl.so: gcc -o "/usr/local/sage/4.1.1/spkg/build/ecl-9.4.1/src/build/ libecl.so" -L"/usr/local/sage/4.1.1/spkg/build/ecl-9.4.1/src/build/" "c/main.o" "c/all_symbols2.o" "liblsp.a" "libeclmin.a" -shared -L/usr/ local/sage/4.1.1/local/lib -L/usr/local/sage/4.1.1/local/lib -Wl,- soname,libecl.so.9.4 -ldl -lm -lgc -lgmp and it results in a libecl.so that dynamically links to libgmp.so. How do we change this line to produce a libecl.so that has the gmp library privately inside? --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 5:02 pm, Jason Moxham wrote: > nlimbs(a+b)<=max(nlimbs(a),nlimbs(b))+1 > nlimbs(a*b)<=nlimbs(a)+nlimbs(b) > > but this is for the answer only , it doesn't include any temp space needed to > perform the calculation eg we multiply by FFT and need approx 6x the space > above. The temp space is not just limbs but can include structures (eg > matrix'es for GCD calcs , prime tables for factorials,etc) > Perhaps if the sage process sets the ulimit stack high enough , then gmp can > use that (like it used to , back in the bad old days) Oops, thanks for correcting me I already thought something was odd about the bounds. My question was really: If I reserve limbs on the target mpz_t as above, will GMP perform a reallocate on the limb pointer of the target? GMP would still have access to a memory manager, and I assume GMP deallocates temps it allocates. The reason why we cannot change the GMP memory manager when ECL is around, is that ECL does not explicitly deallocate its bignums. It relies on Boehm-Weiser to reclaim the memory. So if we set GMP to use the Python memory manager, the memory would never be reclaimed. Therefore, one solution would be to make it so that any mpz_t that ECL allocates and might not explicitly deallocate, gets explicitly preallocated with enough space so that GMP will not realloc its limbs (this is why I need the bounds). Then we can safely set GMP to use the Python memory manager again. I'm not looking forward to that solution, because it would require a considerable amount of changes to ECL. These changes might not be taken up by upstream either (what's their benefit?), so that could cause quite a maintenance nightmare. Hence, building ecl with a private GMP lib would have my strong preference. I haven't been able to find any documentation on how to do that, though. Do we need a libgmp.a instead of a libgmp.so for that? Do we need libgmp.a built with -fPIC (I've tried with other "libgmp.a"s lying around and that's what gcc suggested)? How do we prevent the symbols in libgmp.a from ending up being exported from libecl.so? Sage currently does not have a libgmp.a in local/lib. Does that have a reason? --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 9:02 pm, Robert Bradshaw wrote: > I think you can do > > -Wl,-Bstatic -lgmp > > at the end. Wonderful, yes that makes the linker look for libgmp.a rather than ligmp.so. However, the libgmp.a that mpir builds yields the "recompile with -fPIC" complaint in this situation. I guess for our purposes, we would need to build a libgmp.a out of the *.lo files rather than the *.o files. I have no idea how to do that (naive tries failed miserably and google hasn't been very helpful either). --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 11:41 pm, Robert Bradshaw wrote: > I think you can still get an -fPIC libgmp.a directly from the same .o > files that the libgmp.so uses. Have you tried just adding that flag > to mpir's make file? yes. You should look at their makefile. The following commands get executed when I do a "make libmpir.la", which seems to create all libraries involved: /bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -fPIC-o libmpir.la -rpath /usr/local/sage/4.1.1/local/lib -version-info 7:4:4 [[a whole bunch of .lo files]] [libmpir.la is a text file. It says it shouldn't be deleted, but I don't see how it influences any linking] gcc -std=gnu99 -shared [[a whole bunch of .o files]] -Wl,-soname - Wl,libmpir.so.3 -o .libs/libmpir.so.3.4.4 [so yes, the .so is created from .o files] [it says "copying selected object files to avoid basename conflicts..."] [a whole bunch of temporary renames of .o files] ar cq .libs/libmpir.a [[a whole bunch of .o files (included renamed ones)]] ranlib .libs/libmpir.a as expected, the static library get made by just "ar" and "ranlib". No place to inject an -fPIC An interesting quote from their makefile: # In libtool 1.5 it doesn't work to build libmpir.la from the convenience # libraries like mpz/libmpz.la. Or rather it works, but it ends up putting # PIC objects into libmpir.a if shared and static are both built. (The PIC # objects go into mpz/.libs/libmpz.a, and thence into .libs/ libmpir.a.) # # For now the big lists of objects above are used. Something like mpz/ *.lo # would probably work, but might risk missing something out or getting # something extra. The source files for each .lo are listed in the # Makefile.am's in the subdirectories. # # Currently, for libmpir, unlike libmp below, we're not using # -export-symbols, since the tune and speed programs, and perhaps some of # the test programs, want to access undocumented symbols. so, at some point they succeeded exactly in building the kind of libmpir.a that we are after. I have a lot of respect for people who can find their way around these build processes. There doesn't seem to be any documentation available. I'll just have to hope that someone can hand me an appropriate library, at some point. Thanks for the help. At least we got the pexect interface with maxima sped up a bit. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 25, 12:21 am, Nils Bruin wrote: > On Aug 24, 11:41 pm, Robert Bradshaw > wrote: > > > I think you can still get an -fPIC libgmp.a directly from the same .o > > files that the libgmp.so uses. Have you tried just adding that flag > > to mpir's make file? Scratch previous: "./configure" accepts an option "--with-pic" which is supposed to seduce libtools into using pic objects for both dynamic and static libraries. Indeed, supplying this to MPIR seems to produce a libgmp.a with different properties: gcc -o libecl.so [...] -Wl,-Bstatic -lgmp doesn't do the trick. This expands to [...] -Bstatic -lgmp -lgcc --as-needed -lgcc_s --no-as-needed -lc - lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat- linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/ 4.1.2/../../../../lib64/crtn.o upon which I get a complaint that -lgcc_s cannot be found. However, if I just include the libgmp.a as one of the files, things still work out. Indeed I get a libecl.so from this process that does NOT list libgmp.so under its dependencies when I do ldd libecl.so However, if I look in the dynamic symbol table with objdump -T libecl.so, it has all kinds of mpz_ symbols. Surprisingly, linking in this libecl.so into sage does seem to cause extra crashes. Just the usual one at the end. Anybody any ideas? --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 25, 8:15 am, Bill Hart wrote: > I think by "this capability" I mean the capability GMP/MPIR has of > allowing user code to supply a memory manager. > > I mean, if that is global, doesn't it imply that user code can spy on > the memory of other user code, say when it comes up for realloc? > > And it is also potentially possible for one process to crash another > by controlling its memory allocation. I think a shared library will have a separate instantiation of its writeable sections for each process that it uses. The problem arises when you're trying to build some frankenstein program that uses two libraries, both using libgmp.so and both wanting to use their own memory management. The conflicts all arise within the same process, so they are already sharing memory. If you have to worry about people injecting untrusted shared libraries into your application, I think mp_set_memory_functions will not be your only vulnerability. --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 25, 3:41 am, Jason Moxham wrote:
> can you post me a list , there may be also mpn_* mpf_* __gmp_* etc , I think
> we will have to find ALL of them .
The experiment I did indicates that the libecl.so I created did *not*
have the property that I wanted:
1) sage is using gmp.so and is linked to that before libecl.so is even
introduced. Thus, presumably sage is fully bound to libecl.so
2) sage initializes some of its "gmp integer pool"
3) upon "from sage.libs.ecl import *" I think libecl.so is "dlopen"-ed
by sage (or does that happen before the integer pool is created?)
4) cl_boot() in libecl.so calls mp_set_memory_functions to set the
memory functions, presumably on the copy of libgmp.a that has been
included in the build of libecl.so (libecl.so is certainly not
advertising any dependencies on libgmp.so when I call ldd on it).
5) I exit sage and get a segfault. The stack trace shows that
free_integer_pool called ecl_dealloc. This is evidence that cl_boot
called the mp_set_memory_functions that sage itself uses as well.
Is the fact that "ldd libecl.so" does not show libgmp.so a guarantee
that libecl.so will be using the mp_set_memory_functions from the
libgmp.a that it was linked with? In that case, apparently sage does
link in libecl.so upon startup and for some silly reason prefers the
gmp symbols from libecl.so rather than from libgmp.so. In that case,
preventing symbols from leaking might solve the problem. I executed
the following, but you should check your manpage to see if "objdump -
T" indeed lists the right symbols.
objdump -T libgmp.so | awk " { print $ 7 } " | sort | uniq >
gmp.symbols
objdump -T libecl.so | awk " { print $ 7 } " | sort | uniq >
ecl.symbols
There are 230 symbols that occur both in libgmp.so and in libecl.so
There are 325 symbols that occur in libgmp.so but not in libecl.so
using python:
F=open("gmp.symbols")
gmp=[l[:-1] for l in F]
F=open("ecl.symbols")
ecl=[l[:-1] for l in F]
[l for l in gmp if (l in ecl)]
"['__bss_start', '__cxa_finalize', '_edata', '_end', '_fini',
'__gmp_0', '__gmp_allocate_func', '__gmp_assert_fail',
'__gmp_assert_header', '__gmp_bits_per_limb',
'__gmp_default_allocate', '__gmp_default_free',
'__gmp_default_reallocate', '__gmp_divide_by_zero', '__gmp_errno',
'__gmp_exception', '__gmp_extract_double', '__gmp_free_func',
'__gmp_invalid_operation', '__gmp_junk', '__gmp_modlimb_invert_table',
'__gmpn_add', '__gmpn_addadd_n', '__gmpn_addlsh1_n',
'__gmpn_addmul_1', '__gmpn_add_n', '__gmpn_addsub_n', '__gmpn_and_n',
'__gmpn_bases', '__gmpn_bdivmod', '__gmpn_bgcd_matrix_init',
'__gmpn_com_n', '__gmpn_copyd', '__gmpn_copyi', '__gmpn_dc_divrem_n',
'__gmpn_divexact_1', '__gmpn_divexact_by3c',
'__gmpn_divexact_byBm1of', '__gmpn_divrem_1',
'__gmpn_divrem_euclidean_qr_1', '__gmpn_divrem_euclidean_qr_2',
'__gmpn_fft_best_k', '__gmpn_fft_next_size', '__gmpn_gcd',
'__gmpn_gcd_1', '__gmpn_get_d', '__gmpn_hbgcd_n',
'__gmpn_hbgcd_n_itch', '__gmpn_hgcd', '__gmpn_hgcd2',
'__gmpn_hgcd2_fix', '__gmpn_hgcd2_lehmer_step', '__gmpn_hgcd_fix',
'__gmpn_hgcd_init', '__gmpn_hgcd_init_itch', '__gmpn_hgcd_itch',
'__gmpn_hgcd_max_recursion', '__gmpn_kara_mul_n', '__gmpn_kara_sqr_n',
'__gmpn_lgcd', '__gmpn_lshift', '__gmpn_lshift1',
'__gmpn_modexact_1c_odd', '__gmpn_modexact_1_odd', '__gmpn_mul',
'__gmpn_mul_1', '__gmpn_mul_2', '__gmpn_mul_basecase',
'__gmpn_mul_fft', '__gmpn_mul_fft_full', '__gmpn_mul_n',
'__gmpn_ngcd_lehmer', '__gmpn_ngcd_matrix1_vector',
'__gmpn_ngcd_matrix_adjust', '__gmpn_ngcd_matrix_init',
'__gmpn_ngcd_matrix_mul', '__gmpn_ngcd_step',
'__gmpn_ngcd_subdiv_step', '__gmpn_nhgcd', '__gmpn_nhgcd_itch',
'__gmpn_popcount', '__gmpn_rsh1add_n', '__gmpn_rsh1sub_n',
'__gmpn_rshift', '__gmpn_rshift1', '__gmpn_sb_divrem_mn',
'__gmpn_sqr_basecase', '__gmpn_sqr_n', '__gmpn_store', '__gmpn_sub',
'__gmpn_subadd_n', '__gmpn_submul_1', '__gmpn_sub_n',
'__gmpn_sumdiff_n', '__gmpn_tdiv_qr', '__gmpn_toom32_mul',
'__gmpn_toom3_interpolate', '__gmpn_toom3_mul', '__gmpn_toom3_mul_n',
'__gmpn_toom3_sqr_n', '__gmpn_toom42_mul', '__gmpn_toom4_mul_n',
'__gmpn_toom4_sqr_n', '__gmpn_toom7_mul_n', '__gmpn_toom7_sqr_n',
'__gmpq_clear', '__gmpq_get_d', '__gmpq_init',
'__gmp_reallocate_func', '__gmp_set_memory_functions',
'__gmp_sqrt_of_negative', '__gmp_tmp_reentrant_alloc',
'__gmp_tmp_reentrant_free', '__gmpz_add', '__gmpz_add_ui',
'__gmpz_and', '__gmpz_cdiv_q_2exp', '__gmpz_cdiv_qr', '__gmpz_cmp',
'__gmpz_cmp_si', '__gmpz_com', '__gmpz_fdiv_q_2exp', '__gmpz_fdiv_qr',
'__gmpz_fits_slong_p', '__gmpz_gcd', '__gmpz_get_d', '__gmpz_get_si',
'__gmpz_init2', '__gmpz_init_set', '__gmpz_init_set_si',
'__gmpz_init_set_ui', '__gmpz_ior', '__gmpz_mul', '__gmpz_mul_2exp',
'__gmpz_mul_si', '__gmpz_mul_ui', '__gmpz_realloc', '__gmpz_set',
'__gmpz_set_d', '__gmpz_set_si', '__gmpz_sizeinbase', '__gmpz_sub',
'__gmpz_sub_ui', '__gmpz_tdiv_q', '__gmpz_tdiv_qr',
'__gmpz_tdiv_q_ui', '__gmpz_tstbit', '__gmpz_xor', '_init',
'mpn_addadd_n', 'mpn_addlsh1_n', 'mpn_addmul_1', 'mpn_add_n',
'mpn_addsub_n', 'mpn_and
