On Tue, 19 Oct 2010 at 09:43PM -0700, Nick Alexander wrote:
> If you used emacs sage-mode, tab complete would bring up a buffer of
> completions for X., which you could then interactively search
> (and regexp search), or run M-x occur to find all occurences, etc. In
> my opinion, this is more flexi
On Tue, 19 Oct 2010 09:09 -0700 kcrisman wrote:
> Maybe it's time to relieve the strain on sagenb by publicizing more of
> the other 'semi-secret' servers like David mentions. But that would be
> up to the people in charge of them.
The two servers running at http://sagenb.kaist.ac.kr/ are usually
> How about a function, somewhat like search_doc, search_def, and friends,
> that accepts an object and a string, and returns methods that match that
> string? Would you find that useful?
In my haste to plug sage-mode, I forgot this:
sage: X.*foo*?
...
all methods that match 'foo'.
Only in IPyth
> How about a function, somewhat like search_doc, search_def, and friends,
> that accepts an object and a string, and returns methods that match that
> string? Would you find that useful?
I think this is a good idea, but can't resist...
> Often, I find myself doing
>
> X.a (look through
Here's something that happens to me: I have an object X that has a *lot* of
methods -- matrices and graphs, often -- and I'm wondering if X has a
certain method. Often, I find myself doing
X.a (look through "a" methods...)
X.b (look through "b" methods...)
and so on, through the
On 10/19/10 05:06 PM, kcrisman wrote:
I was not suggesting anyone spend 10,000 hours studying the subject of
software engeering. I'm not suggesting people need to be experts. But
perhaps spending 20-50 hours on it is not unreasonable. I don't know
about you, but I've probably devoted 1000 hours
Nice! Unfortunately the top link for "View Tickets" doesn't point
there, although the "View Ticket Lists" one in the main page does.
Can there be a "My Tickets (active, by component)" one as well?
Hopefully this will help the Trac become more organized.
Maybe there could also be a "New Tickets (l
I made a page that lists the ticket reports in a more organized fashion:
http://trac.sagemath.org/sage_trac/wiki/TicketReports
Enjoy!
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegrou
Gfan does a lot more than compute the Groebner fan. My main use for
it is computing tropical prevarieties. Anders Jensen keeps improving
gfan, and in fact our interface to it doesn't wrap all the current
functionality. I think it would be quite a job to replace it.
-Marshall
On Oct 19, 11:53 a
I strongly object to removing gfan.
-Marshall
On Oct 19, 9:53 am, William Stein wrote:
> On Tue, Oct 19, 2010 at 6:35 AM, mhampton wrote:
> > I support replacing cddlib with PPL for the default computation of
> > exact polyhedra.
>
> Does gfan depend on cddlib? If we remove cddlib, would we th
For reference I've put the buildlog here:
http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-buildlog.txt
There are two related bogus "may be used uninitialized" warnings,
thats all. Actually the warnings look more like a gcc bug, I think it
should have been able to figure out that the variable does ge
On 19 October 2010 17:55, Jeroen Demeyer wrote:
> On 2010-10-19 18:35, Roman Pearce wrote:
>> On Oct 19, 9:09 am, kcrisman wrote:
>>> Yes, let's keep in mind that notebook servers with fewer users are
>>> usually very snappy and a great resource. It's not CPU power, but
>>> number of simultaneo
On 18 October 2010 13:13, Volker Braun wrote:
> === Introduction ===
>
> I would like to have the Parma Polyhedra Library (PPL) included
> as a standard spkg. My goal is to rewrite as much of the
> sage.geometry.* modules on top of a Cython PPL wrapper as opposed
> to piping ASCII to/from cddlib.
On 2010-10-19 18:35, Roman Pearce wrote:
> On Oct 19, 9:09 am, kcrisman wrote:
>> Yes, let's keep in mind that notebook servers with fewer users are
>> usually very snappy and a great resource. It's not CPU power, but
>> number of simultaneous users, I think.
>
> That suggests the bottleneck is
gfan definitely depends on cddlib.
Unless it is somehow broken I would keep sage.geometry.groebner_fan
and the gfan spkg for now. In the long term we should rewrite
sage.geometry.groebner_fan to work with the new Fan class from the
toric geometry stuff. And I think it would be easy enough to take
On Oct 19, 9:09 am, kcrisman wrote:
> Yes, let's keep in mind that notebook servers with fewer users are
> usually very snappy and a great resource. It's not CPU power, but
> number of simultaneous users, I think.
That suggests the bottleneck is disk I/O. Sage is quite large, so
it's not a sur
On Oct 19, 3:37 pm, Andrey Novoseltsev wrote:
> By the way - does PPL use any random numbers like cddlib?
I'm pretty sure that it does not randomize the output; certainly grep
doesn't find any references to rand(). And there is absolutely no
reason to call a pseudo random number generator for the
On Oct 19, 11:31 am, Jeroen Demeyer wrote:
> On 2010-10-19 17:25, Tom Boothby wrote:
>
> >> Is it really true that the public access servers are often bogged down
> >> with lots of users?
>
> > Yes. Everybody that I talk to is very disappointed with the public
> > notebook.
>
> I totally agree
> I was not suggesting anyone spend 10,000 hours studying the subject of
> software engeering. I'm not suggesting people need to be experts. But
> perhaps spending 20-50 hours on it is not unreasonable. I don't know
> about you, but I've probably devoted 1000 hours to working on Sage, so
> 20-50 i
On 2010-10-19 17:25, Tom Boothby wrote:
>> Is it really true that the public access servers are often bogged down
>> with lots of users?
>
> Yes. Everybody that I talk to is very disappointed with the public notebook.
I totally agree (I'm just coming back from an exercice class where
students tr
> Is it really true that the public access servers are often bogged down
> with lots of users?
Yes. Everybody that I talk to is very disappointed with the public notebook.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sa
On 18 Oct, 15:38, Chris Seberino wrote:
> Wolfram Alpha is a low bandwidth portal into Mathematica that doesn't
> provide the full notebook interface.
It's not in Wolfram Research's interst to make the full power of
Mathematica available to anyone for free. If they did, their sales of
Mathemat
On Tue, Oct 19, 2010 at 8:09 AM, Dr David Kirkby wrote:
> If that crashes Sage, and stops lots of people working on a
> Sage server, I think that's pretty serious, though not as bad as
> incorrect results.
It only crashes that one user's session. Each worksheet is run in a
different process.
--
On 18 Oct, 21:33, Robert Bradshaw
wrote:
> On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby
> On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby
> > sage: seed(1,2)
> > sage: seed(100,34)
> > sage: seed(1,2,3,4,5,6,7)
>
> > will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of in
On Oct 19, 8:53 am, William Stein wrote:
> Does gfan depend on cddlib? If we remove cddlib, would we then also have to
> remove gfan? From deps:
I'd rather leave cddlib for polyhedra over RDF until there is an
alternative.
--
To post to this group, send an email to sage-devel@googlegroups.com
On Tue, Oct 19, 2010 at 6:35 AM, mhampton wrote:
> I support replacing cddlib with PPL for the default computation of
> exact polyhedra.
>
Does gfan depend on cddlib? If we remove cddlib, would we then also have to
remove gfan? From deps:
$(INST)/$(GFAN): $(BASE) $(INST)/$(MPIR) $(INST)/$(CDD
On Oct 19, 4:37 am, Volker Braun wrote:
> Yes, PALP has some useful toric functionality and I think we should
> definitely keep it around. But I think the long-term goal should be to
> reduce the reliance of the LatticePolytope class on PALP. In
> particular enumerating the lattice points is a pro
I support replacing cddlib with PPL for the default computation of
exact polyhedra.
Eventually I would really like to see lrs as a standard component as
well, because:
1) It is small and compiles on all our supported platforms.
2) David Avis has always been very responsive to any emails about lrs.
Setting SAGE_CHECK=yes just means that after building the pari
library, the self-test routines are also run. It does not affect Sage
after the new spkg is installed.
John
On Tue, Oct 19, 2010 at 1:32 PM, Jan Groenewald wrote:
> Hi
>
> On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wro
Hi
On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wrote:
> env SAGE_CHECK=yes ./sage -f
> http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg
This still caused a segfault for me in dmesg while doctests pass.
Is SAGE_CHE
On Oct 19, 5:35 am, Andrey Novoseltsev wrote:
> As with cddlib, I want to
> keep PALP in Sage for computing lattice points inside polytopes as
> well as nef partitions, but using PPL as a library for computing
> convex hulls and facets will make life much better.
Yes, PALP has some useful toric f
On Oct 19, 5:56 am, Dima Pasechnik wrote:
> Are you saying that PPL cannot work with floating point numbers?
The short answer is no. The PPL can work with floating point types for
some upper-approximations of polyhedral regions. But right now the
Cython wrapper only exposes the core functionality
32 matches
Mail list logo
