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-d
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
> >
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 simplici
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
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 re
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 d
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]>
> w
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]>
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
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 "
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 alread
+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
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 funct
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 arg
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
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
finit
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 comp
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
h
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
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
>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 func
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 probl
> 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 au
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 i
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 comput
> 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 gr
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 the
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 yo
28 matches
Mail list logo
