[sage-devel] Re: sage-2.4 plan
I'm also working on const.tex. It is unfortunately slow going as there are a lot of changes. On 3/15/07, William Stein [EMAIL PROTECTED] wrote: Hello, The plan is to release SAGE-2.4 next Wednesday, March 21. Here's the plan * Bobby Moretti - Calculus * William Stein - Modular forms * William Stein - Modular abelian varieties * David Roed - Updated p-adics * William Stein - add p-adic docs to the reference manual * David Harvey - bug fixes * Clement Pernet - new linbox charpoly * Martin Albrecht and Gregory Bard - m4ri * Bill Alombert - new PARI with new evaluator * William Stein and Kate Minola - official support to run SAGE on solaris * David Joyner - improved tutorial * -- William Stein Associate Professor of Mathematics University of Washington --~--~-~--~~~---~--~~ 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] NTL SageX thoughts and questions
Hi, Some of these matters were touched on in off-list conversations. However, I think it might be of more general interest. My motivation in these things is the movement of the number fields down to SageX and an obsession with getting them 'frickin fast' as Martin might say. Conceptually, it seems we need two levels of bindings between us and NTL. One of these is the python classes which directly encapsulate NTL types. The other layer is a .pxi file and maybe a few C++ helper functions to make utilizing NTL from other SageX classes super-simple. At the moment, the naming schemes between my .pxi stuff and the NTL names are a bit of mish-mash. I enlarge on these comments in what follows. One of the things I worked on (that David Harvey started) is faster routines from gmp mpz_t to NTL ZZ types. Sitting right on top of that is a fast conversion between a sage int and an NTL ZZ. The result seems pleasing to me, but I expect that there will be some tweaks when it gets into public view. I'm not sure what namespace to put these conversions in -- that's my first question. I wanted them as global functions in the ntl.pyx file, but I'm not sure how to make a global pyrex cdef function (Can you do it? It would seem you have to link to the .so generated by ntl.pyx.) An alternative: put a cdef function into the Integer class to fill a ZZ* struct and a cdef function into the Integer_ring to construct an integer from a ZZ*. Thoughts? I also think that we need to make a .pxi file for easy usage of the NTL C++ library from other pyrex classes. I have the beginnings of this in my number field patch (soon to be submitted). I think it needs more thought though. In particular, someone needs to think a bit about how to consistently name-mangle the overloaded C++ functions into a coherent library of functions to use from pyrex. I'm started with all this, but I think I'll want some input. There exist ntl_ZZ and ntl_ZZX (and some others) classes in ntl.pyx. These provide an excellent usage example of the NTL library. I believe that Martin wants these to be turned into python bindings for NTL. I think that could be very pretty and useful to us -- e.g.: I want to efficiently pass an NTL type through honest-to-goodness python code. These classes currently are not immutable (and I abused that in my code) which is inconsistent with the rest of SAGE. I guess they should be made immutable (???) and I need to fix my code when that occurs. That's enough for now! -- Joel --~--~-~--~~~---~--~~ 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: NTL SageX thoughts and questions
On Mar 16, 2007, at 10:13 AM, Joel B. Mohler wrote: Hi, Some of these matters were touched on in off-list conversations. However, I think it might be of more general interest. My motivation in these things is the movement of the number fields down to SageX and an obsession with getting them 'frickin fast' as Martin might say. Conceptually, it seems we need two levels of bindings between us and NTL. One of these is the python classes which directly encapsulate NTL types. The other layer is a .pxi file and maybe a few C++ helper functions to make utilizing NTL from other SageX classes super-simple. At the moment, the naming schemes between my .pxi stuff and the NTL names are a bit of mish-mash. I enlarge on these comments in what follows. One of the things I worked on (that David Harvey started) is faster routines from gmp mpz_t to NTL ZZ types. Sitting right on top of that is a fast conversion between a sage int and an NTL ZZ. The result seems pleasing to me, but I expect that there will be some tweaks when it gets into public view. I'm not sure what namespace to put these conversions in -- that's my first question. I wanted them as global functions in the ntl.pyx file, but I'm not sure how to make a global pyrex cdef function (Can you do it? It would seem you have to link to the .so generated by ntl.pyx.) An alternative: put a cdef function into the Integer class to fill a ZZ* struct and a cdef function into the Integer_ring to construct an integer from a ZZ*. Thoughts? I also think that we need to make a .pxi file for easy usage of the NTL C++ library from other pyrex classes. I have the beginnings of this in my number field patch (soon to be submitted). I think it needs more thought though. In particular, someone needs to think a bit about how to consistently name-mangle the overloaded C++ functions into a coherent library of functions to use from pyrex. I'm started with all this, but I think I'll want some input. There exist ntl_ZZ and ntl_ZZX (and some others) classes in ntl.pyx. These provide an excellent usage example of the NTL library. I believe that Martin wants these to be turned into python bindings for NTL. I think that could be very pretty and useful to us -- e.g.: I want to efficiently pass an NTL type through honest-to-goodness python code. These classes currently are not immutable (and I abused that in my code) which is inconsistent with the rest of SAGE. I guess they should be made immutable (???) and I need to fix my code when that occurs. That's enough for now! Hmmm I'm a bit confused. Here's what I imagine in my ideal world: (1) We have a .pxi file for easy usage of the NTL C++ library from other pyrex classes, as you say above. (2) The Polynomial_integer_dense class is implemented in pyrex. Its member functions call NTL functions directly and work with NTL objects directly. In particular, the ntl.pyx file would no longer exist (except as repository history :-)), and neither would ntl_wrap.cc. Is (2) what you mean by python classes which directly encapsulate NTL types? 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] Re: NTL SageX thoughts and questions
On Fri, Mar 16, 2007 at 10:30:06AM -0400, David Harvey wrote: On Mar 16, 2007, at 10:13 AM, Joel B. Mohler wrote: Hi, ... Hmmm I'm a bit confused. Here's what I imagine in my ideal world: (1) We have a .pxi file for easy usage of the NTL C++ library from other pyrex classes, as you say above. (2) The Polynomial_integer_dense class is implemented in pyrex. Its member functions call NTL functions directly and work with NTL objects directly. In particular, the ntl.pyx file would no longer exist (except as repository history :-)), and neither would ntl_wrap.cc. Is (2) what you mean by python classes which directly encapsulate NTL types? No, I didn't mean (2) that way. I do think the ntl.pyx objects have other purposes (not as a base for core functionality though). I think this echo's Martin's reply. Let me give an example to augment though. The number field *ring* is still python. It has the polynomial which I always need to mod by when doing number field arithmetic. I want this polynomial in NTL format. The easiest way to hold on to it is via a python NTL wrapper. I guess the same thing could be achieved by having a member of ZZ['x'] with easy accessor to the underlying NTL object. I didn't take that route because the polynomial is currently a member of QQ['x'] and I store an ntl_ZZX numerator and ntl_ZZ denominator in the number field. I'm trying to think about the math a little bit behind this too. It seems that I shouldn't need a denominator. Are there number fields that need to be defined in terms of a polynomial with rational coefficients? Or, does it have to do with the fact that the number field code insists on the polynomial being monic? -- Joel --~--~-~--~~~---~--~~ 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: NTL SageX thoughts and questions
On 3/16/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hmmm I'm a bit confused. Here's what I imagine in my ideal world: (1) We have a .pxi file for easy usage of the NTL C++ library from other pyrex classes, as you say above. (2) The Polynomial_integer_dense class is implemented in pyrex. Its member functions call NTL functions directly and work with NTL objects directly. In particular, the ntl.pyx file would no longer exist (except as repository history :-)), and neither would ntl_wrap.cc. True, to provide NTL functionality for core SAGE objects those should vanish. Though, some core SAGE objects might be implemented in Python and call a Pyrex class handling NTL for them. Also libs/ntl could still exist as an NTL shell. This is secondary but might come in handy somehow, I don't know. The ntl.pyx file should never vanish. One of the main points of SAGE is that it provides an interpreter interface to a wide range of major open source math software. NTL is one of these pieses of major open source math software. The ntl.pyx file provides NTL with almost the same *semantics* as NTL. For this, the objects in ntl.pyx must stay mutable (since they are in ntl), and the file itself obviously should continue to exist.That said, as David H suggests objects like polynomials over ZZ, etc., would probably be best implemented by directly calling the NTL library instead of going through ntl.pyx. It is still not clear to me that the ntl_wrap.* structure is slower than anything else for ntl.pyx, since couldn't one inline everything and compile with a C++ compiler? I'm not saying it isn't slower, only that it isn't clear to me that it has to be slower. For example, for linbox I think it was a better approach, since writing the wrapper code in SageX is too complicated. The wrapper code for ntl has so far been simple enough, but perhaps only because we have only partially wrapped ntl -- much remains to be done. Also, and this is probably only important for Linbox, for Linbox I'm going to move linbox_wrap.* out of the SAGE core library and into the linbox-*.spkg. The file linbox_wrap.cpp takes forever to compile, so if I make it a separate library that gets compiled at linbox install time, when one is developing SAGE code (or typing sage -ba), you won't have to wait at all for any linbox compilation anymore. This doesn't solve the problem that modifying linbox_wrap* is slow, but one very rarely does that. On 3/16/07, Joel B. Mohler [EMAIL PROTECTED] wrote: Conceptually, it seems we need two levels of bindings between us and NTL. One of these is the python classes which directly encapsulate NTL types. Yes, agreed. This is how SAGE provides an interface to NTL that is conceptually very very similar to NTL itself. The other layer is a .pxi file and maybe a few C++ helper functions to make utilizing NTL from other SageX classes super-simple. At the moment, the naming schemes between my .pxi stuff and the NTL names are a bit of mish-mash. I enlarge on these comments in what follows. This makes good sense. One of the things I worked on (that David Harvey started) is faster routines from gmp mpz_t to NTL ZZ types. Sitting right on top of that is a fast conversion between a sage int and an NTL ZZ. The result seems pleasing to me, but I expect that there will be some tweaks when it gets into public view. I'm not sure what namespace to put these conversions in -- that's my first question. I wanted them as global functions in the ntl.pyx file, but I'm not sure how to make a global pyrex cdef function (Can you do it? It would seem you have to link to the .so generated by ntl.pyx.) This is not possible at present. I don't think there is a fundamental reason for it not being possible, but maybe there is. (On some OS's you can hack something that will work, but on others the same thing wont work. ) The standard thing to do in such cases, which is actually very nicely object oriented, is to make a cdef'd class whose methods are all the functions you want to export, then instantiate one instance of that class in any file from which you want to call those methods. See ext/arith.pyx for an example. An alternative: put a cdef function into the Integer class to fill a ZZ* struct and a cdef function into the Integer_ring to construct an integer from a ZZ*. Thoughts? I think that's a good idea. Probably put an underscore at the front of the name. I also think that we need to make a .pxi file for easy usage of the NTL C++ library from other pyrex classes. I have the beginnings of this in my number field patch (soon to be submitted). I think it needs more thought though. In particular, someone needs to think a bit about how to consistently name-mangle the overloaded C++ functions into a coherent library of functions to use from pyrex. I'm started with all this, but I think I'll want some input. I agree that this is a good idea. There exist ntl_ZZ and
[sage-devel] Re: NTL SageX thoughts and questions
On Mar 16, 2007, at 1:34 PM, William Stein wrote: The ntl.pyx file should never vanish. One of the main points of SAGE is that it provides an interpreter interface to a wide range of major open source math software. NTL is one of these pieses of major open source math software. The ntl.pyx file provides NTL with almost the same *semantics* as NTL. For this, the objects in ntl.pyx must stay mutable (since they are in ntl), and the file itself obviously should continue to exist.That said, as David H suggests objects like polynomials over ZZ, etc., would probably be best implemented by directly calling the NTL library instead of going through ntl.pyx. Fair enough. It is still not clear to me that the ntl_wrap.* structure is slower than anything else for ntl.pyx, since couldn't one inline everything and compile with a C++ compiler? I'm not saying it isn't slower, only that it isn't clear to me that it has to be slower. It's not just slowness (which as you say, still needs to be demonstrated). Another issue is maintainability. If we can wrap C++ directly in ntl.pyx, why have another C++ layer? For example, when I was writing the fast ZZ-mpz_t code a few weeks back, I needed to touch three layers of code: Polynomial_integer_dense, ntl.pyx, and ntl_wrap.cc. It was pretty annoying. 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] Re: NTL SageX thoughts and questions
On 3/16/07, David Harvey [EMAIL PROTECTED] wrote: It's not just slowness (which as you say, still needs to be demonstrated). Another issue is maintainability. If we can wrap C++ directly in ntl.pyx, why have another C++ layer? For example, when I was writing the fast ZZ-mpz_t code a few weeks back, I needed to touch three layers of code: Polynomial_integer_dense, ntl.pyx, and ntl_wrap.cc. It was pretty annoying. Yes, but in some cases the resulting code is vastly easier to read and to write -- this is definitely the case with the Linbox wrapper, but is probably not the case with the ntl wrapper. I'm trying to think about the math a little bit behind this too. It seems that I shouldn't need a denominator. Are there number fields that need to be defined in terms of a polynomial with rational coefficients? Or, does it have to do with the fact that the number field code insists on the polynomial being monic? All number fields can be defined in terms of a monic polynomial with integer coefficients. Suppose you start with a defining polynomial which is monic but has non-integral coefficients. Multiply the whole polynomial by L^d, where d is the degree and L is the LCM of the denominators of the coefficients. Then you can absorb L into the variable. (Another way to say this is to take any generator of K/k and then multiply it by an appropriate integer to make it an algebraic integer.) On the other hand, the user should be allowed to make number fields by polys with non-integral coefficients. Perhaps you want to translate for them, to make the arithmetic fast and the user experience transparent. Sounds like a pain though. I strongly encourage you to do this. MAGMA can do it, and it's a feature users really really appreciate. They *will* have to do it themselves a lot if you don't -- and it's better to have the pain happen once and be thought out, than have it happen often. Of course to represent *elements* of the number field, you need denominators. Probably best to represent elements using a polynomial in Z[x], with a single denominator, which is I think what you've been suggesting. I suspect Joel was really asking about this, and I agree with your suggestion. 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: Inconsistency in root finding
On Mar 16, 2:23 pm, Nick Alexander [EMAIL PROTECTED] wrote: Do you agree that the current behaviour is brain-dead? 'cuz I'll patch it! Agreed! roots() should always return multiplicity when asked to. didier Nick --~--~-~--~~~---~--~~ 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: Inconsistency in root finding
On 3/16/07, didier deshommes [EMAIL PROTECTED] wrote: On Mar 16, 2:23 pm, Nick Alexander [EMAIL PROTECTED] wrote: Do you agree that the current behaviour is brain-dead? 'cuz I'll patch it! Please send me a patch, so that it returns multiplicities in all cases. -- 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: NTL SageX thoughts and questions
On Friday 16 March 2007 14:10, William Stein wrote: It's not just slowness (which as you say, still needs to be demonstrated). Another issue is maintainability. If we can wrap C++ directly in ntl.pyx, why have another C++ layer? For example, when I was writing the fast ZZ-mpz_t code a few weeks back, I needed to touch three layers of code: Polynomial_integer_dense, ntl.pyx, and ntl_wrap.cc. It was pretty annoying. Yes, but in some cases the resulting code is vastly easier to read and to write -- this is definitely the case with the Linbox wrapper, but is probably not the case with the ntl wrapper. I wanted to write directly to NTL so as to avoid the pain of maintaining layers as David describes. However, I think that keeping ntl_wrap.cc around is important because I think we will find a variety of utility functions which are most convenient to write in C++. One of these is go back and forth from ZZ to mpz_t in fast ways. This is essentially done, but it's a bit of pain to write code to because the functions in ntl_wrap.cc use pointers, whereas NTL uses references. It's just not consistent. -- Joel --~--~-~--~~~---~--~~ 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: NTL SageX thoughts and questions
On Friday 16 March 2007 14:10, William Stein wrote: On the other hand, the user should be allowed to make number fields by polys with non-integral coefficients. Perhaps you want to translate for them, to make the arithmetic fast and the user experience transparent. Sounds like a pain though. I strongly encourage you to do this. MAGMA can do it, and it's a feature users really really appreciate. They *will* have to do it themselves a lot if you don't -- and it's better to have the pain happen once and be thought out, than have it happen often. Ok, then you are agreeing that the polynomial defining the number field should be a member of ZZ['x']? It is currently a member of QQ['x']. Given a general element of QQ['x'], I can clear the denominator and get a member of ZZ['x'], but this won't (necessarily) be monic. Is that ok? The current code complains about non-monics. Of course to represent *elements* of the number field, you need denominators. Probably best to represent elements using a polynomial in Z[x], with a single denominator, which is I think what you've been suggesting. I suspect Joel was really asking about this, and I agree with your suggestion. That's not what I was asking. David answered my question. Elements already have a ZZX numerator and ZZ denominator in my implementation. -- Joel --~--~-~--~~~---~--~~ 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: NTL SageX thoughts and questions
On Friday 16 March 2007 13:57, David Harvey wrote: All number fields can be defined in terms of a monic polynomial with integer coefficients. Suppose you start with a defining polynomial which is monic but has non-integral coefficients. Multiply the whole polynomial by L^d, where d is the degree and L is the LCM of the denominators of the coefficients. Then you can absorb L into the variable. (Another way to say this is to take any generator of K/k and then multiply it by an appropriate integer to make it an algebraic integer.) Oh, clever, I didn't catch the L^d and absorbing trick. I didn't read this e-mail very well before writing one of my other e-mails. This means that it will in fact be monic in the end. I will so implement unless I hear otherwise. -- Joel --~--~-~--~~~---~--~~ 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
I wasn't expecting to like it, but I think I could very much get used to it, especially as the number of options seems to increase. It looks like the menu vs. button mode could almost entirely be handled via css too. - Robert On Mar 15, 2007, at 12:03 PM, Timothy Clemans wrote: There could be a presentation mode in addition to the slideshow mode where the menu would appear. Also cookies could be used to stay in presentation mode until the user switches back to default mode. This way the current navigation system would be the 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] 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: A menu for the notebook
Quote me on this: The SAGE notebook will NEVER have multi-level dropdowns. If I ever suggest it, remind me of this. If I persist, throw something at my head. On Fri, 16 Mar 2007, Nils Bruin wrote: 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: A menu for the notebook
Then can there please be a mode I can go into merge the second menu with the first? Remember everyone that menu is pure css and there are accesskeys that can added for each item. On 3/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quote me on this: The SAGE notebook will NEVER have multi-level dropdowns. If I ever suggest it, remind me of this. If I persist, throw something at my head. On Fri, 16 Mar 2007, Nils Bruin wrote: 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: A menu for the notebook
Oh, jeez. I didn't realize that there were multi-level dropdowns in your example. Guess I only rolled over the top and thought, yeah, that's cool. But that simply won't do. Thanks to recent irreversible decisions, multi-level dropdowns get people hit in the head, and we don't want that. I propose the following: Notebook starts out with three (single level) menu doohickeys in the upper right. The interrupt and restart buttons get moved outside of this somehow. I don't like those being more than a simple click. They can have little graphical buttons no smaller than 16x16 pixels. (For reference, the execute buton is 10x10 and too small for a sensitive input device -- the icon next to the url is 16x16, and I find that to be clickable) But where do we put the documentation, you ask? Well, we sure as hell aren't going to put it in a multi-level dropdown. So. We've recently made the left-hand pane vanishable. Now, it gets three modes: worksheet, documentation, and gone. The documentation will work similar to a dropdown menu, but will come in a more stable explorer flavor. Click something, and it expands the menu down. Everything south of what you clicked gets pushed down. Next week, I'll put a solid day of work into the Notebook. You'll see these changes, and a handful of bugfixes by SAGE 2.5. Complain about the above design before Monday if you want your voice to be heard. As of whenever I start working, I'll run a public notebook highlighting my work in progress, and I'll post here once that happens. That's a good time for input, too. Thanks, --tom On Fri, 16 Mar 2007, Timothy Clemans wrote: Then can there please be a mode I can go into merge the second menu with the first? Remember everyone that menu is pure css and there are accesskeys that can added for each item. On 3/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quote me on this: The SAGE notebook will NEVER have multi-level dropdowns. If I ever suggest it, remind me of this. If I persist, throw something at my head. On Fri, 16 Mar 2007, Nils Bruin wrote: 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] Some work on Minimal Sage in Gentoo
Hi folks, I've wanted to make a minimal sage for some time. I finally got motivated to do some work on it. Don't ask what I _should_ have been doing. I'm working with gentoo linux ... it has nice package management and many of the things I needed were included already. I'll make as many comments as I can to help other reconstruct what I did. Essentially, I did these steps: 1) Extracted sage-2.3 from the overall sage distribution. tar xf sage-2.3 # the top level distro cd sage-2.3/spkg/standard tar xf sage-2.3 # the specific sage code mv sage-2.3 workdir 2) Use a different setup.py and a edit one small thing cd workdir # add marksetup.py to workdir cp other/location/marksetup.py ./ # fix one path problem sed -e 's:../../../:../../:' sage/libs/cf/cf.pyxe tmpfile mv tmpfile sage/libs/cf/cf.pyxe 3) Build the csage stuff by hand and make it available this library build isn't quite right cd sage-2.3/spkg/standard tar xf sage_c_lib-2.3.spkg cd sage_c_lib-2.3/src gcc -fPIC -g -c *.c -I/usr/include/python2.4 gcc -shared -Wl,-soname,libcsage.so -o libcsage.so *.o ln -s libcsage.so csage.so cp *.so workdir/mylibs/ cp *.h workdir/myinc/ 4) Make sure the following programs are installed via portage (gentoo's package manager): you might need more ... i already had a bunch of stuff installed you might have to unmask some of these as well (a gentoo thing) maxima 5.9.3 gsl 1.8 ntl 5.4-r1 singular 3.0.2.1 (i used my own ebuild, but the built in should be ok) pexpect .999 blas-atlas-3.7.24 mpfr-2.2.1_p1 numpy-1.0.1-r1 5) use my shoddy ebuilds for these: you will need to fish out singular-3.0.2-gentoo.diff for factory to use the ebuild I have here pari 2.3.1 (simply a version bump from 2.3.0 in portage) factory 3.0.2.1 (from singular) iml-1.0.1 mpfi-1.3.4 mwrank-061003 6) Build it: python marksetup.py build 7) Figure out everthing that built, but has run time errors! to be determined I haven't tested the produced code AT ALL. It may well be complete junk. I just wanted to get what I've done up so others can (maybe) take advantage of it and/or make progress on it. Files (ebuilds and marksetup.py) can be found at: http://www.cs.pitt.edu/~fenner/work/projects/minimal-sage/minimal-sage.tgz Regards, Mark --~--~-~--~~~---~--~~ 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: Some work on Minimal Sage in Gentoo
On 3/16/07, Mark [EMAIL PROTECTED] wrote: I've wanted to make a minimal sage for some time. I finally got motivated to do some work on it. Don't ask what I _should_ have been doing. I'm working with gentoo linux ... it has nice package management and many of the things I needed were included already. I'll make as many comments as I can to help other reconstruct what I did. Essentially, I did these steps: 1) Extracted sage-2.3 from the overall sage distribution. tar xf sage-2.3 # the top level distro cd sage-2.3/spkg/standard tar xf sage-2.3 # the specific sage code mv sage-2.3 workdir 2) Use a different setup.py and a edit one small thing cd workdir # add marksetup.py to workdir cp other/location/marksetup.py ./ # fix one path problem sed -e 's:../../../:../../:' sage/libs/cf/cf.pyxe tmpfile mv tmpfile sage/libs/cf/cf.pyxe 3) Build the csage stuff by hand and make it available this library build isn't quite right I'm curious -- Is there something wrong with SAGE's csage build process? 4) Make sure the following programs are installed via portage (gentoo's package manager): you might need more ... i already had a bunch of stuff installed you might have to unmask some of these as well (a gentoo thing) I just want to emphasize concern here. SAGE is not likely to work correctly if you replace the components it uses by ones with different versions. In many cases we program around or patch issues in specific versions of the dependent programs, and in other cases we use new features that were recently added. For example... maxima 5.9.3 In maxima, I think version 5.10, a lot of the special functions stuff was reorganized -- there's no way SAGE will past its test suite with maxima 5.9.3. Moreover, SAGE currently ships with maxima 5.11 and assumes it is available. gsl 1.8 SAGE ships with gsl 1.9. I don't remember if we had to change anything going from 1.8 to 1.9 -- I think probably not, though there were some important bug fixes in 1.9. ntl 5.4-r1 SAGE will work fine with that. singular 3.0.2.1 (i used my own ebuild, but the built in should be ok) Probably this is fine... pexpect .999 SAGE uses pexpect version 2.0. The current official version of pexpect is version 2.1, but SAGE will not work with pexpect 2.1 at all. I have no idea if SAGE will work at all with pexpect .999. blas-atlas-3.7.24 Should be fine. mpfr-2.2.1_p1 Should be fine. numpy-1.0.1-r1 Should be fine. 5) use my shoddy ebuilds for these: you will need to fish out singular-3.0.2-gentoo.diff for factory to use the ebuild I have here pari 2.3.1 (simply a version bump from 2.3.0 in portage) SAGE should not work at all with an officially released PARI. For SAGE we do some nontrivial patching to the library, e.g,. replacing calls to exit() with calls to abort(). factory 3.0.2.1 (from singular) I think Martin A might have fixed a bug in factory that needed to be fixed in order to use it from SAGE. iml-1.0.1 I made some minor changes to IML for using in SAGE, but nothing that affects the interface. The changes were to remove the atlas dependency. However, Martin A. implemented arbitrary precision p-adic system solving for the IML included in SAGE, whereas the official release version doesn't have that. mpfi-1.3.4 Carl Witty said he fixed several bugs in mpfi that were uncovered in the course of wrapping it for use in SAGE. mwrank-061003 The official release should be fine. 6) Build it: python marksetup.py build 7) Figure out everthing that built, but has run time errors! to be determined I haven't tested the produced code AT ALL. It may well be complete junk. I just wanted to get what I've done up so others can (maybe) take advantage of it and/or make progress on it. Files (ebuilds and marksetup.py) can be found at: http://www.cs.pitt.edu/~fenner/work/projects/minimal-sage/minimal-sage.tgz Just out of curiosity, how difficult would it be to create a non-minimal normal SAGE ebuild? This would likely actually work perfectly, and hence would get a lot of use. Bobby Moretti did this with a Debian package at one point, and it was pretty impressive and would have been really useful had somebody volunteered to maintain it. 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: Some work on Minimal Sage in Gentoo
William, Well, I had a nice reply typed and ... and I lost it. Typical. I'll try again ... but it won't be nearly as witty. Gentoo has the following higher versions available (then what I used): pexpect-2.1 (not sure why I only read .999) maxima-5.11.0 gsl-1.9 I forgot to mention that there is also a pyrexembed ebuild in my file tarball. On the issue of a batteries included sage for gentoo: this is definitely doable. In fact, I could the following roadmap (note, portage is the gentoo package build and management system): 1) Simple ebuild that just runs the sage build process and install all of the sage stuff out of the way (/opt/sage). The difficult step would be divorcing the build time location from the run time location (b/c portage does a build to a dummy location and then copies it to the live filesystem). 2) Individual ebuilds for each sage specific package that install into (/opt/sage). The ebuilds would live in their own space (not the gentoo main tree). They would also be renamed to prevent conflicts with live packages. Now the fun stuff: 3) Use as many live ebuilds as possible and as few custom ebuilds/sources as possible. Install into the main tree when possible but if we need a customized package for sage, we could put it somewhere out of the way. At some point, we'd also add ebuilds for those packages that aren't in portage at all. 4) Use only live ebuilds. Have separate ebuilds for customized packages (treat these as unique packages unrelated to the mainstream version). Portage can install multiple versions of packages but I'm not sure how general it is. In the worst case, we could have separate subdirectories for different versions if need be (/usr/lib/ntl-123 and /usr/lib/ntl-sage/ or so). Making sure that there aren't conflicts between mainstream and customized versions would be a pain. Anyway, just some thoughts. Regards, Mark --~--~-~--~~~---~--~~ 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: Some work on Minimal Sage in Gentoo
William, Sorry. About the csage build process: I built by hand b/c the automated process has the whole nine yards of autoconf tools with it. I couldn't find the location for specifying Python.h and I noticed there were only two source files and two headers. So, I compiled by hand. The problem I referred to was in my hand building process I don't think I built it 100% correctly. Mark --~--~-~--~~~---~--~~ 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: Some work on Minimal Sage in Gentoo
On 3/16/07, Mark [EMAIL PROTECTED] wrote: Gentoo has the following higher versions available (then what I used): pexpect-2.1 (not sure why I only read .999) Do not use pexpect-2.1. It is very broken. maxima-5.11.0 gsl-1.9 Good. On the issue of a batteries included sage for gentoo: this is definitely doable. In fact, I could the following roadmap (note, portage is the gentoo package build and management system): 1) Simple ebuild that just runs the sage build process and install all of the sage stuff out of the way (/opt/sage). The difficult step would be divorcing the build time location from the run time location (b/c portage does a build to a dummy location and then copies it to the live filesystem). One option is to just copy the build directory over to the run-time location at the end of the build, i.e., as make install. This should work if you run SAGE once from the target location. Let me know when you succeed at doing this. It would be a significant step forward for SAGE. 2) Individual ebuilds for each sage specific package that install into (/opt/sage). The ebuilds would live in their own space (not the gentoo main tree). They would also be renamed to prevent conflicts with live packages. OK. Now the fun stuff: 3) Use as many live ebuilds as possible and as few custom ebuilds/sources as possible. Install into the main tree when possible but if we need a customized package for sage, we could put it somewhere out of the way. At some point, we'd also add ebuilds for those packages that aren't in portage at all. Makes sense. Note that you really _must_ look in the SAGE.txt files and spkg-install files in each .spkg to see if any patches were needed for SAGE, and the same should be done when a package gets upgraded. --~--~-~--~~~---~--~~ 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] DSAGE Questions
Hello, I'm running some computations in SAGE for my research, and they are quite time consuming, but proudly parallel. I'd obviously like to use DSAGE to speed them up, but I have a few questions. 1) Is there an easy/convenient way to start 16 dsage workers on a single machine? 2) If the task requires additional functions / classes defined in a .sage file, I assume all workers would need to load/attach that file to carry out the jobs. This works fine on a single machine, but if you wanted to use multiple machines, would you need to include that entire file within each job being passed around? Is there a better way to do that? 3) Can you use ipython1 (chainsaw/saw) from within SAGE? 4) I've looked through the sage/dsage/dist_functions and was wondering if there were any other primary pieces of DSAGE documentation that I'm missing. Thanks, Mike --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
