On 2014-09-29 22:58, Volker Braun wrote:
I propose to remove the SAGE_UPGRADING variable and make it act like it
would be always yes (instead of no, which is the current default).
Right now, we sabotage make to not rebuild dependencies of rebuilt
packages. So you don't have to wait long for your
See http://trac.sagemath.org/ticket/17072
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email
I also agree with the removal, with the issue of ATLAS.
Maybe we should switch to openblas (IIRC Clément Pernet said it is more
state of the art nowadays) :)
On Tuesday, September 30, 2014 9:15:59 AM UTC+2, Jeroen Demeyer wrote:
See http://trac.sagemath.org/ticket/17072
--
You received
+1. I have had
export SAGE_UPGRADING='yes'
in my .bashrc for a long time now.
John
On 30 September 2014 00:02, William A Stein wst...@uw.edu wrote:
On Mon, Sep 29, 2014 at 3:01 PM, Dima Pasechnik dimp...@gmail.com wrote:
On 2014-09-29, Volker Braun vbraun.n...@gmail.com wrote:
I propose to
It is certainly on intel and making strides on arm. It covers a few other
archs through inheritance from gotoblas2 but it doesn't support power7,
never mind power8. I can discuss those more in details for anyone interested.
François
On 30/09/2014, at 21:15, Jean-Pierre Flori jpfl...@gmail.com
On 2014-09-30 08:24, Jeroen Demeyer wrote:
I certainly agree with this, but it should be said that make will take
a longer time when changing packages. For example, you will see ATLAS
being rebuilt very frequently (it has many dependencies and if one of
those changes, ATLAS will get rebuilt).
On
On Tuesday, September 30, 2014 10:51:05 AM UTC+2, Jeroen Demeyer wrote:
On 2014-09-30 08:24, Jeroen Demeyer wrote:
I certainly agree with this, but it should be said that make will take
a longer time when changing packages. For example, you will see ATLAS
being rebuilt very frequently
Hello,
Let's for sanity's sake suppose that == among all vertex labels of
FinitePosets is an equivalence relation. Let's moreover suppose that
hashing respects this equivalence relation.
Thanks,
Then the problem seems to be that in the unique representation
I think we have a SnapPy (or whatever it is called now) interface, but do
we have one for this? (Well, no. But *should* we?)
http://regina.sourceforge.net/
It uses Python for scripting... and has been around for quite a while.
Just curious. Feel free to open a ticket if you would use this!
Otherwise, maybe it can be fixed on the relabel function level (once
again,
I don't know how it works).
I don't see how. I tried many times, and each time I was sent back to
this design problem: the default value of the list of vertices is not
properly defined, and good a good
On Friday, September 26, 2014 4:25:58 PM UTC+2, Nils Bruin wrote:
It would be good if mpmath used a different approach when it's known a
hypergeometric function is a polynomial, but it's a little orthogonal to
what happens in sage. By the time we hit mpmath, we're doing multiprecision
kcrisman:
I think we have a SnapPy (or whatever it is called now) interface, but do
we have one for this? (Well, no. But *should* we?)
http://regina.sourceforge.net/
It uses Python for scripting... and has been around for quite a while.
Just curious. Feel free to open a ticket if you
Hi Nathann,
Whoo hoo. First of all, you put my wrong e-mail address and I am not
reading sage-devel all the time. Second of all, I did not write the poset
code.
As far as I know, it was written by Peter Jipsen and Franco Saliola. I used
the poset code in the new class LinearExtensions in
13 matches
Mail list logo
