[sage-devel] Re: Solaris problem when building readline - due to Darwin test in SAGE
On Apr 24, 7:42 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote: > I tried building sage 3.0 on an x86 laptop running Solaris Express Oops, I relase I posted this before. I did not see it appear. --~--~-~--~~~---~--~~ 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: Initial support for posets
2008/4/24 William Stein <[EMAIL PROTECTED]>: > > On Wed, Apr 23, 2008 at 1:42 PM, Franco Saliola <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 23, 2008 at 4:05 PM, Robert Miller <[EMAIL PROTECTED]> wrote: > > > > > We might want to think about the naming conventions for Lattice. As > > > with all words in mathematics, this one has multiple meanings. A > > > lattice can be a poset with a meet and a join, or it can be a free > > > abelian group with an inner product. > > I call dibs on Lattice being "free abelian group with an inner product". +1 --assuming that we can find a suitable name for the other kind! John > > > :-) > > > > > This is a good point. The only thing I can think of is to append > > something: for example, LatticeGroup. I'm not sure how natural that > > is. LatticePoset is definitely not. Other suggestions? > > > > > > > > -- > > > > > > > > > > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://wstein.org > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Initial support for posets
Hi! I never understood why some people say "lattice" when they have a "poset with meet and join"... But i don't see the point: Would it really be difficult to live with that name conflict? I mean, certainly the two species of "lattice" would live in two different packages, say (just for simplicity), in "group" and in "poset". Now, of course saying sage: from sage.poset import lattice sage: from sage.group import lattice wouldn't work. But if a user really wants to use both types of lattice in the same program, he/she is free to say sage: from sage.poset import lattice as lattice_po sage: from sage.group import lattice as lattice_gr and go ahead. Or is it intended to have both types of lattice in sage without to explicitly import them from the corresponding package? Yours Simon --~--~-~--~~~---~--~~ 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: Test errors for Sage 3.0 on OS X
On Wed, Apr 23, 2008 at 10:35 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Apr 24, 1:54 am, Bjake Hammersholt Roune <[EMAIL PROTECTED]> > wrote: > > Hi Bjake, > > > > It just now occured to me that this might be due to counting wall-time > > instead of CPU-time, since I put the machine to sleep during a lecture > > while it was running the tests. > > Ok, that explains it. On OSX time prints the time elapsed [at least > per default] while on Linux it actually prints the CPU time used. I > guess this boils down to BSD vs. GNU default behavior. Should we > actually fix this? If somebody thinks so please open a ticket and > mention the fact here. The code (in local/bin/sage-*test*) that times out the testing of a file uses walltime instead of cputime. That's the code that led to the error the user observed. This is the only reasonable thing to do, because the file being doctested can involve long calls to separate subprocesses. -- 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] multivariate gcd - the story continues ...
Hi! I am sitting here next to Achim Faßbender. He is working on the multivariate gcd in Singular/factory. As you maybe have noticed, my personal interest would be a collaboration of the different groups working on gcd. It would be nice having more discussion at this point. I also recommended reading the following thread to him: http://groups.google.de/group/sage-devel/browse_thread/thread/bc807fe1db5c8a9c/dafa6cd02b060c2f?lnk=gst&q=maxima+gcd# as well as http://wiki.sagemath.org/MultivariateGCDBenchmarks From my personal experience, I would recommend to everybody working on this topic, running as many examples as possible. This maybe would be good starting point of collaboration to collect examples for the multivariate gcd (maybe in the sage wiki). Hoping for a fast, free gcd (and hoping that this is easier than a world without wars). Best regards, Michael --~--~-~--~~~---~--~~ 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: Initial support for posets
On Thu, Apr 24, 2008 at 4:27 AM, Simon King <[EMAIL PROTECTED]> wrote: > > Hi! > > I never understood why some people say "lattice" when they have a > "poset with meet and join"... Same here. But they do and math terms are pretty arbitrary. > But i don't see the point: Would it really be difficult to live with > that name conflict? > I mean, certainly the two species of "lattice" would live in two > different packages, say (just for simplicity), in "group" and in > "poset". > > Now, of course saying > sage: from sage.poset import lattice > sage: from sage.group import lattice > wouldn't work. > > But if a user really wants to use both types of lattice in the same > program, he/she is free to say > sage: from sage.poset import lattice as lattice_po > sage: from sage.group import lattice as lattice_gr > and go ahead. > > Or is it intended to have both types of lattice in sage without to > explicitly import them from the corresponding package? > Yes. We're only talking about the top-level global namespace. 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: Initial support for posets
On Thu, Apr 24, 2008 at 4:00 AM, John Cremona <[EMAIL PROTECTED]> wrote: > > 2008/4/24 William Stein <[EMAIL PROTECTED]>: > > > > > On Wed, Apr 23, 2008 at 1:42 PM, Franco Saliola <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Apr 23, 2008 at 4:05 PM, Robert Miller <[EMAIL PROTECTED]> > wrote: > > > > > > > We might want to think about the naming conventions for Lattice. As > > > > with all words in mathematics, this one has multiple meanings. A > > > > lattice can be a poset with a meet and a join, or it can be a free > > > > abelian group with an inner product. > > > > I call dibs on Lattice being "free abelian group with an inner product". > > +1 --assuming that we can find a suitable name for the other kind! -1 --- I feel like I should champion the case for posets with meets and joins. :-) Franco -- --~--~-~--~~~---~--~~ 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: Initial support for posets
On Thu, Apr 24, 2008 at 8:49 AM, Franco Saliola <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 24, 2008 at 4:00 AM, John Cremona <[EMAIL PROTECTED]> wrote: > > > > 2008/4/24 William Stein <[EMAIL PROTECTED]>: > > > > > > > > On Wed, Apr 23, 2008 at 1:42 PM, Franco Saliola <[EMAIL PROTECTED]> > wrote: > > > > > > > > On Wed, Apr 23, 2008 at 4:05 PM, Robert Miller <[EMAIL PROTECTED]> > wrote: > > > > > > > > > We might want to think about the naming conventions for Lattice. > As > > > > > with all words in mathematics, this one has multiple meanings. A > > > > > lattice can be a poset with a meet and a join, or it can be a > free > > > > > abelian group with an inner product. > > > > > > I call dibs on Lattice being "free abelian group with an inner > product". > > > > +1 --assuming that we can find a suitable name for the other kind! > > -1 --- I feel like I should champion the case for posets with meets > and joins. :-) +1: Lattice as poset with meet and join -1: Lattice as abelian group with inner product. (of course I'm biaised by my French education and by what I'm working on right now :-) > > Franco > > -- > > > > --~--~-~--~~~---~--~~ 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: Initial support for posets
Hi William On Apr 24, 2:21 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > Or is it intended to have both types of lattice in sage without to > > explicitly import them from the corresponding package? > > Yes. We're only talking about the top-level global namespace. I wouldn't mind to have to load a package before having access to a particular function, if it concerns a thing that is not ubiquitous in math. There is LatticeDiagram and LatticePolytope in Sage. What do you think about LatticeGroup and LatticePoset? Yours Simon --~--~-~--~~~---~--~~ 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: Initial support for posets
The following references would seem relevant for what a "typical" mathematician might think coming to Sage who isn't directly involved in either kind of lattice on a daily basis, though it's not clear that it resolves this discussion, since the authors below are self- selecting. The idea that a "point" lattice (and hence Euclidean lattice) is a special case of a "poset" lattice is interesting, though I don't see how would that work for the cocompact definition or for unordered fields... - kcrisman http://mathworld.wolfram.com/PointLattice.html http://mathworld.wolfram.com/Lattice.html http://en.wikipedia.org/wiki/Lattice_%28group%29 http://en.wikipedia.org/wiki/Lattice_%28order%29 --~--~-~--~~~---~--~~ 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: Initial support for posets
I made an implementation of a self designed algorithm to compute the distribute lattice representing all linear extensions of a given poset. It should be really fast and also gives you the number pretty quickly. If there is interest I can make it SAGE compatible, whatever this means. It is already Python code. See http://bio.math.berkeley.edu/ranktests/lcell/ Used to compute http://www.research.att.com/~njas/sequences/A046873 ... Oliver --~--~-~--~~~---~--~~ 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: Initial support for posets
+1: Lattice as abelian group with inner product. -1: Lattice as poset with meet and join (of course I'm biased by number theory, though I admit that I have heard of the second kind of lattice. ;-) That being said, I'm glad people are working on the poset kind of lattice: I'd wanted to do so for a while, but too many other projects intervened. I'll try to chip in a bit. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Initial support for posets
Axiom's "solution" to the lattice problem is to use an interpreter for user interaction. Instead of just talking to a top level lisp command prompt, you interact with the interpreter. The interpreter looks at the arguments and classifies them by type. It looks for "modemaps" that define the functions (e.g. all lattice functions) and finds a minimum type matching modemap. The process is repeated "working outward" for the final expression type. Thus Axiom has some 1 functions with approximately 3000 names in the name space. The user can explicitly override this process in various ways. You might say lattice(args)$Posets to explictly override the interpreter (although it will fail if the argument types don't match). Given the limits of naming conventions by various fields of math, the interpreter provides a way to overload names in useful and naturals ways. Thus a single function (say, map) can have multiple well defined meanings (there are 80 map functions in Axiom). In compiled code (Spad), you must specify exactly which function of which domain you intend to call. If you're ambiguous about it, the compiler gives you a suitably ambiguous error message. Perhaps someone might give some thought to a Sage-interpreter that helps in name resolution rather than having 80 people try to define which "map" is the "correct" map. Tim Daly --~--~-~--~~~---~--~~ 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: Initial support for posets
On Thu, Apr 24, 2008 at 11:54 AM, root <[EMAIL PROTECTED]> wrote: > > Axiom's "solution" to the lattice problem is to use an interpreter > for user interaction. Instead of just talking to a top level lisp > command prompt, you interact with the interpreter. > > The interpreter looks at the arguments and classifies them by type. > It looks for "modemaps" that define the functions (e.g. all lattice > functions) and finds a minimum type matching modemap. The process > is repeated "working outward" for the final expression type. > > Thus Axiom has some 1 functions with approximately 3000 names > in the name space. The user can explicitly override this process > in various ways. > > You might say lattice(args)$Posets to explictly override the > interpreter (although it will fail if the argument types don't > match). > > Given the limits of naming conventions by various fields of math, > the interpreter provides a way to overload names in useful and > naturals ways. Thus a single function (say, map) can have multiple > well defined meanings (there are 80 map functions in Axiom). > > In compiled code (Spad), you must specify exactly which function > of which domain you intend to call. If you're ambiguous about it, > the compiler gives you a suitably ambiguous error message. > > Perhaps someone might give some thought to a Sage-interpreter > that helps in name resolution rather than having 80 people > try to define which "map" is the "correct" map. > Sage just uses the mainstream language Python; we are not in the language design business. It's an interesting exercise to think through how each of the ideas you generously explained above is expressed using Python. -- 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: Initial support for posets
On Apr 24, 2008, at 2:54 PM, root wrote: > > Axiom's "solution" to the lattice problem is to use an interpreter > for user interaction. Instead of just talking to a top level lisp > command prompt, you interact with the interpreter. > > The interpreter looks at the arguments and classifies them by type. > It looks for "modemaps" that define the functions (e.g. all lattice > functions) and finds a minimum type matching modemap. The process > is repeated "working outward" for the final expression type. > > Thus Axiom has some 1 functions with approximately 3000 names > in the name space. The user can explicitly override this process > in various ways. > > You might say lattice(args)$Posets to explictly override the > interpreter (although it will fail if the argument types don't > match). > > Given the limits of naming conventions by various fields of math, > the interpreter provides a way to overload names in useful and > naturals ways. Thus a single function (say, map) can have multiple > well defined meanings (there are 80 map functions in Axiom). > > In compiled code (Spad), you must specify exactly which function > of which domain you intend to call. If you're ambiguous about it, > the compiler gives you a suitably ambiguous error message. > > Perhaps someone might give some thought to a Sage-interpreter > that helps in name resolution rather than having 80 people > try to define which "map" is the "correct" map. I guess we would just use Python namespaces for this. For example, there might be two modules, sage.groups.abelian_group.lattice and sage.combinat.lattice. Then you would do something like sage: from sage.groups.abelian_group.lattice import Lattice or sage: from sage.cominat.lattice import Lattice depending on which Lattice you wanted to work with. I think the debate going on in this thread is more about which is the default one in the global namespace. I hate the global namespace, so I'm not going to get involved :-) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Initial support for posets
I'll add my 2 cents, since I just read a post by William where he suggested he might remove the command kernel, leaving left_kernel and right_kernel (and I hope, adding kernel_left and kernel_right for tab completion). I'm not strongly in favor of Lattice (alone) for either the poset or the finite rank free ZZ-module. Just as UAT was thinking he might have found a bug in "kernel", someone is going to post an analogous message about Lattice. So, my vote is for LatticePoset and LatticeModule. (There is also a object called a lattice of groups, so LatticeGroup or LatticeAbelianGroup might be confusing). If a use wants to shorten it in his local namespace he/she can more easily than using an import startement. Also, LatticeWhatever allows one to use tab completion to figure out what one wants. On Wed, Apr 23, 2008 at 4:42 PM, Franco Saliola <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 4:05 PM, Robert Miller <[EMAIL PROTECTED]> wrote: > > > We might want to think about the naming conventions for Lattice. As > > with all words in mathematics, this one has multiple meanings. A > > lattice can be a poset with a meet and a join, or it can be a free > > abelian group with an inner product. > > This is a good point. The only thing I can think of is to append > something: for example, LatticeGroup. I'm not sure how natural that > is. LatticePoset is definitely not. Other suggestions? > > > > -- > > > > --~--~-~--~~~---~--~~ 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: Initial support for posets
On Thu, Apr 24, 2008 at 10:55 AM, David Joyner <[EMAIL PROTECTED]> wrote: > > I'll add my 2 cents, since I just read a post by William where he suggested > he > might remove the command kernel, leaving left_kernel and right_kernel (and > I hope, adding kernel_left and kernel_right for tab completion). > > I'm not strongly in favor of Lattice (alone) for either the poset or the > finite rank free ZZ-module. Just as UAT was thinking he might have found > a bug in "kernel", someone is going to post an analogous message about > Lattice. > So, my vote is for LatticePoset and LatticeModule. (There is also a > object called > a lattice of groups, so LatticeGroup or LatticeAbelianGroup might be > confusing). > If a use wants to shorten it in his local namespace he/she can more easily > than > using an import startement. Also, LatticeWhatever allows one to use > tab completion to figure out > what one wants. Another issue is that we *already* have a name for "finite rank free ZZ-module with inner product", namely "FreeModule".This has been in Sage for years. sage: L = FreeModule(ZZ,2,inner_product_matrix=[[1,2],[2,4]]) sage: L.0.inner_product(L.1) 2 Choosing the names for the global namespace is a very important responsibility, and each choice should be taken with a lot of taste and care. It really does matter a great deal. -- 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] An spkg for Frobby
As a first effort of getting Frobby into Sage, I have an spkg ready at http://www.broune.com/frobby-0.7.3.spkg along with a Python interface at http://www.broune.com/frobby.py This interface does irreducible decomposition of monomial ideals using Frobby. I've also created a trac ticket at http://trac.sagemath.org/sage_trac/ticket/3018 I was unable to attach the spkg to the ticket though, since I apparently do not have the requisite access to do that. I've only tried this on a mac, so I'm curious to see if it works elsewhere. I'm ready to work on this, and my main obstacle is that I do not know Python and Sage very well - this is my first time using both. If someone with a bit more experience could take a look at the spkg and the Python file and give me a few suggestions on how to improve it (e.g. to make it more pythonic and fit better into Sage), that would be very nice. Cheers Bjarke --~--~-~--~~~---~--~~ 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] javascript code editor for the notebook
Following up on another thread (see the one on parethesis matching), I posted a very experimental spkg for a (apparently popular) javascript code editor. It and the required enabling patch are up at trac #3016. Those people that care, I'd be interested in hearing comments. The license is LGPL and Apache (dual-licensed). The spkg is barely minimally functional; it breaks everything too. When the editor is toggled on, tab completion, expanding textarea, etc. do not work. I just put it in there so people would have something they could start and play with. Jason --~--~-~--~~~---~--~~ 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: javascript code editor for the notebook
I did something like this. Having more than two EditArea cells in a workshet is terribly slow. The good thing to do, would be a fullscreen editor. I looked into adding tab completion, etc., and it shouldn't be hard: the author made it easy to add hooks for extra key commands. On Thu, 24 Apr 2008, Jason Grout wrote: > > Following up on another thread (see the one on parethesis matching), I > posted a very experimental spkg for a (apparently popular) javascript > code editor. It and the required enabling patch are up at trac #3016. > Those people that care, I'd be interested in hearing comments. > > The license is LGPL and Apache (dual-licensed). > > The spkg is barely minimally functional; it breaks everything too. When > the editor is toggled on, tab completion, expanding textarea, etc. do > not work. I just put it in there so people would have something they > could start and play with. > > Jason > > > > > --~--~-~--~~~---~--~~ 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: Initial support for posets
>Sage just uses the mainstream language Python; we are >not in the language design business. It's an interesting >exercise to think through how each of the ideas you generously >explained above is expressed using Python. This is a general purpose python idea, actually. If there was a python function that looked at the namespace available for each .py file then it could decide that there are two lattice functions. This could issue an "import lattice from poset" to disambiguate the lattice question automatically. (I have no idea how you might look at a .py file and get its namespace). This is not a new issue because Sage already has several different polynomials available to it at any given time. The user has to specify which one to call by naming the spkg tool explicitly. Thus the various spkgs split the namespace at the moment. As more functionality migrates from the external packages into "Sage-native python" this issue will grow worse. Which package gets to own the name "differentiate"? Axiom shows 25 different functions of that name, e.g. polynomials vs power series. Suppose the user wants to use the "same name" in the "same sentence" (e.g. differentiate(poly)*differentiate(powerseries)). How is this resolved? Does the user have to do special imports? How will the user know that there are 50 differentiates from 7 different spkgs (25 from Axiom alone) and 6 from python packages? It is an explicit design decision of the user interface to decide whether there is an automatic resolution or a user-specified resolution. It would be worthwhile to have a discussion of this design decision before it gets "encoded by default" as a result of the lattice discussion. I don't think that Axiom's solution can work for Sage because Axiom is a strongly typed language. But it does highlight at least one other point in the space of design decisions. Names matter. Tim --~--~-~--~~~---~--~~ 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: Initial support for posets
One thing that Python has going for it here is that it's object oriented. So f.differentiate() is disambiguated because f has a type. The time when this doesn't help is object creation (thus the issue for Lattices). It's worth having this discussion, and I agree that names matter, but the problem isn't quite as extensive as might be feared. :-) David On Thu, Apr 24, 2008 at 4:00 PM, root <[EMAIL PROTECTED]> wrote: > > >Sage just uses the mainstream language Python; we are > >not in the language design business. It's an interesting > >exercise to think through how each of the ideas you generously > >explained above is expressed using Python. > > This is a general purpose python idea, actually. If there was > a python function that looked at the namespace available for > each .py file then it could decide that there are two lattice > functions. This could issue an "import lattice from poset" > to disambiguate the lattice question automatically. (I have no > idea how you might look at a .py file and get its namespace). > > This is not a new issue because Sage already has several different > polynomials available to it at any given time. The user has to > specify which one to call by naming the spkg tool explicitly. > Thus the various spkgs split the namespace at the moment. > > As more functionality migrates from the external packages into > "Sage-native python" this issue will grow worse. Which package > gets to own the name "differentiate"? Axiom shows 25 different > functions of that name, e.g. polynomials vs power series. > > Suppose the user wants to use the "same name" in the "same sentence" > (e.g. differentiate(poly)*differentiate(powerseries)). How is > this resolved? Does the user have to do special imports? How > will the user know that there are 50 differentiates from 7 > different spkgs (25 from Axiom alone) and 6 from python packages? > > It is an explicit design decision of the user interface to decide > whether there is an automatic resolution or a user-specified > resolution. It would be worthwhile to have a discussion of this > design decision before it gets "encoded by default" as a result > of the lattice discussion. > > I don't think that Axiom's solution can work for Sage because > Axiom is a strongly typed language. But it does highlight at > least one other point in the space of design decisions. > > Names matter. > > Tim > > > > > > > > > > --~--~-~--~~~---~--~~ 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: Initial support for posets
> This is a general purpose python idea, actually. If there was > a python function that looked at the namespace available for > each .py file then it could decide that there are two lattice > functions. This could issue an "import lattice from poset" > to disambiguate the lattice question automatically. (I have no > idea how you might look at a .py file and get its namespace). This seems like it has way too much guess-work for my liking. As David Roe mentioned, this is handled pretty nicely by using an object-oriented language. The only place this doesn't work is for the initial creation of some objects. The discussion at hand is closer to choosing the name ARRAY1 for Axioms's OneDimensionalArray instead of something like ONEARRAY. > I don't think that Axiom's solution can work for Sage because > Axiom is a strongly typed language. But it does highlight at > least one other point in the space of design decisions. Python _is_ a strongly typed language. It is just dynamically typed rather than statically typed. --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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Initial support for posets
On Thu, Apr 24, 2008 at 3:00 PM, root <[EMAIL PROTECTED]> wrote: > > I don't think that Axiom's solution can work for Sage because > Axiom is a strongly typed language. But it does highlight at > least one other point in the space of design decisions. `argument dependent name lookup' (which is what Axiom systems have as language feature) is not just a trait of a statically typed language. Given sufficient motivation, Python could be extended to make it work. However, the way it works in Axiom systems is just half part of the story. It works only one of the arguments has domain (or category) that exports the operation. Meaning if you stick the operations in a package, then you are hosed. :-( Which brings us to the fundamental problem I raised in an previous message: Axiom systems want to insist that a value belongs to a single domain (so that ADL, for example, can work), when in fact that view is too restrictive and too limited. Axiom systems have the strength that they are strongly typed; but their computation models need to be deeply revised when they are intended to be `solved' as solutions. -- Gaby --~--~-~--~~~---~--~~ 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: multivariate gcd - the story continues ...
Hello folks! Thank you, Michael, for introducing me. To me it seems sensible, that a fast gcd implementation should consist of a bunch of algorithms and a heuristic, that chooses one of them in dependence of the input. Currently I'm working on the heuristic. I'm thinking about letting the computer do the annoying job of fine- tuning, which to me looks like a global optimization problem. Has anyone experience with simulated annealing? http://en.wikipedia.org/wiki/Simulated_annealing Curious, Achim --~--~-~--~~~---~--~~ 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: Initial support for posets
> Suppose the user wants to use the "same name" in the "same sentence" > (e.g. differentiate(poly)*differentiate(powerseries)). How is > this resolved? The pattern is to have differentiate(x) call x._differentiate_(). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] problems with 3.0
I installed 3.0 on my system make worked fine then I run [EMAIL PROTECTED]:/usr/local/sage-3.0# ./sage -testall every thing run fine until I get to: sage -t devel/sage/sage/rings/polynomial/pbori.pyx which hangs I left it over 12 hours and still I just sits there till I ^C to get out of there can anyone tell me what's wrong I am running ubuntu Linux 7.10 gutsy gibbon --~--~-~--~~~---~--~~ 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: problems with 3.0
On Apr 25, 7:53 am, Francis Smit <[EMAIL PROTECTED]> wrote: Hi Francis, > I installed 3.0 on my system make worked fine > > then I run > > [EMAIL PROTECTED]:/usr/local/sage-3.0# ./sage -testall > every thing run fine until I get to: > > sage -t devel/sage/sage/rings/polynomial/pbori.pyx Can you run that example with the added flag "-verbose"? This example takes a lot of RAM, so that is one potential issue. The other possibility is that the communication with Singular for example is the problem. Running it with verbose will likely narrow down the problem. Watching "top" in addition will likely point out if there is a resource problem. > which hangs I left it over 12 hours and still I just sits there > till I ^C to get out of there > can anyone tell me what's wrong I am running ubuntu Linux > 7.10 gutsy gibbon Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
