On Mon, Aug 19, 2013 at 12:09 PM, Volker Braun wrote:
> Both sagecell.sagemath.org and trac.sagemath.org live on the same IP, so
> they can't both use SSL. Which is a pity, we need https to avoid broken
Hi Volker,
I just invested in getting a dedicated rack in the "state-of-the-art"
UW 4545 data
Both sagecell.sagemath.org and trac.sagemath.org live on the same IP, so
they can't both use SSL. Which is a pity, we need https to avoid broken
"transparent" proxies and we should be using SSL with trac too. But two
name-based vhosts with SSL is generally a bad idea, though it can be hacked
ar
On 19 August 2013 19:26, Keshav Kini wrote:
> John Cremona writes:
>> [...] and then you will not have the silly
>> situation that (in 5.11)
>>
>> sage: G = Graph([]); G
>> Graph on 0 vertices
>> sage: G.is_connected()
>> True
>> sage: G.connected_components()
>> []
>> as to me it seems contradic
John Cremona writes:
> [...] and then you will not have the silly
> situation that (in 5.11)
>
> sage: G = Graph([]); G
> Graph on 0 vertices
> sage: G.is_connected()
> True
> sage: G.connected_components()
> []
> as to me it seems contradictory to have a graph claiming to be
> connected but havin
On Monday, August 19, 2013 5:57:01 PM UTC+1, Dima Pasechnik wrote:
> it should be possible to tell Sage to use Atlas from the previous build,
> just as one is able to use a system-wide Atlas.
It is, just point SAGE_ATLAS_LIB at the directory containing the ATLAS
libraries.
--
You received
On 2013-08-19, John Cremona wrote:
> My atlas build did finish ok in 5h++ so I am letting the rest of the
> build finish before seeing what the new spkg does.
>
> real 322m12.706s
> user 303m50.211s
> sys 21m50.834s
> Successfully installed atlas-3.10.1.p3
>
> OK, it has now finished and Sage runs
Le 19/08/2013 18:20, John Cremona a écrit :
> On 19 August 2013 17:12, Julien Puydt wrote:
>> Le 19/08/2013 18:09, John Cremona a écrit :
>>> This sounds very like the number theory analogue, is 1 prime or
>>> composite -- to which the answer is "neither".
>>
>> Here you surprise me: I have always
On 19 August 2013 17:12, Julien Puydt wrote:
> Le 19/08/2013 18:09, John Cremona a écrit :
>> This sounds very like the number theory analogue, is 1 prime or
>> composite -- to which the answer is "neither".
>
> Here you surprise me: I have always seen "prime" exclude invertible
> elements!
Read
Le 19/08/2013 17:51, Nathann Cohen a écrit :
> There is a discussion on theology going on at #15060, about whether we
> should consider whether the empty graph is connected or not. We
> already had one about deciding whether the empty graph is a tree or
> not, and Karl-Dieter supposed that other di
On Monday, August 19, 2013 5:07:32 PM UTC+1, Nicolas M. Thiéry wrote:
> Exception RuntimeError: 'maximum recursion depth exceeded' in
> ignored
Would anyone have any clue on what might be the cause or how to debug
> this?
>
Obviously you are deleting something in the remove callback
Le 19/08/2013 18:09, John Cremona a écrit :
> This sounds very like the number theory analogue, is 1 prime or
> composite -- to which the answer is "neither".
Here you surprise me: I have always seen "prime" exclude invertible
elements!
Snark on #sagemath
--
You received this message because yo
PS Note that if you ever did decide to have a method
G.is_disconnected() then I would want that to be False also for the
emtpy graph, just as 1 is not composite.
On 19 August 2013 17:07, Jernej Azarija wrote:
> Hello!
>
> As you can check here
> http://mathoverflow.net/questions/120536/is-the-emp
This sounds very like the number theory analogue, is 1 prime or
composite -- to which the answer is "neither". That's like counting
te number of connected components: 0 for the empty graph, 1 for a
connected graph (nonempty!) and 2 or more for disconnected graphs.
You really don't want to spoil t
Hi!
The functorial construction ticket #10963 is almost done. However,
since very recently (Sage 5.11?), some errors started to appear when
running the tests in parallel:
sage -tp 8 sage/categories/*.py
...
Exception RuntimeError: 'maximum recursion depth exceeded' in
ign
Hello!
As you can check here
http://mathoverflow.net/questions/120536/is-the-empty-graph-a-tree
the big shot guys agree that the empty graph is to be considered
disconnected. So YES in general, mathematicians appear to be depressed
persons.
On Mon, Aug 19, 2013 at 5:51 PM, Nathann Cohen w
Le 19/08/2013 17:08, William Stein a écrit :
> Hi,
>
> For anybody reading this thread, a reminder about how to use the
> systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
> building Sage:
>
> apt-get install libatlas3gf-base liblapack-dev
> cd /usr/lib/
>
On 19 August 2013 16:08, William Stein wrote:
> Hi,
>
> For anybody reading this thread, a reminder about how to use the
> systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
> building Sage:
>
> apt-get install libatlas3gf-base liblapack-dev
> cd /usr/lib/
>
Hell everybody !!
There is a discussion on theology going on at #15060, about whether we
should consider whether the empty graph is connected or not. We
already had one about deciding whether the empty graph is a tree or
not, and Karl-Dieter supposed that other discussions of this kind
alr
Hi,
For anybody reading this thread, a reminder about how to use the
systemwide ATLAS (at least on Ubuntu 12.04 LTS). Just do this before
building Sage:
apt-get install libatlas3gf-base liblapack-dev
cd /usr/lib/
ln -s libatlas.so.3gf libatlas.so
ln -s libcbla
I am worried about that message "Architecture configured as HAMMER
(32)" since wikipedia tells me that Hammer was the name of an AMD
processor released in 2003. The actual cpuinfo is
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD Opteron(tm) Processor 6380
stepping : 0
micro
My atlas build did finish ok in 5h++ so I am letting the rest of the
build finish before seeing what the new spkg does.
real 322m12.706s
user 303m50.211s
sys 21m50.834s
Successfully installed atlas-3.10.1.p3
OK, it has now finished and Sage runs fine. But it would be nice not
to have to wait ano
On 08/19/2013 09:26 PM, Volker Braun wrote:
Different ATLAS versions have different routines so the architectural
defaults for one version don't necessarily match another version.
If you don't want top performance then you can always set
SAGE_ATLAS_ARCH=fast or SAGE_ATLAS_ARCH=base when compilin
On 08/19/2013 04:25 PM, Volker Braun wrote:
Yes, shoud be fixed by http://trac.sagemath.org/ticket/15045
Confirmed: the build with
sage -f
http://boxen.math.washington.edu/home/vbraun/spkg/atlas-3.10.1.p4.spk
has just succeeded.
Thanks,
Christian
--
You received this message because y
Yes, shoud be fixed by http://trac.sagemath.org/ticket/15045
On Monday, August 19, 2013 2:47:41 PM UTC+1, Christian Nassau wrote:
>
> On 08/19/2013 03:30 PM, Volker Braun wrote:
> > Can you post the ATLAS bulid log, not the whole log that has
> > everything munged together?
>
> Here it is: ht
On Monday, August 19, 2013 3:05:02 PM UTC+1, John Cremona wrote:
> I could try that (though my log file has no occurrence of
> ATL_SetAtomicCount). Would that mean to kill the build under way with
> Ctrl-C and then install the alternative spkg as above?
>
The new spkg is not faster in any way
On 19 August 2013 15:05, John Cremona wrote:
> On 19 August 2013 14:43, Volker Braun wrote:
>> On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
>>>
>>> I don't know how to extract that from the munged version (which is
>>> still being written to).
>>
>>
>> $SAGE_ROOT/logs/pkgs/atl
On 19 August 2013 14:43, Volker Braun wrote:
> On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
>>
>> I don't know how to extract that from the munged version (which is
>> still being written to).
>
>
> $SAGE_ROOT/logs/pkgs/atlas-3.10.1.p3.log
>
Here's mine (so far): http://ferm
On 08/19/2013 03:30 PM, Volker Braun wrote:
Can you post the ATLAS bulid log, not the whole log that has
everything munged together?
Here it is: http://nullhomotopie.de/atlas-3.10.1.p3.log.gz
Cheers,
Christian
--
You received this message because you are subscribed to the Google Groups
"sag
On Monday, August 19, 2013 2:33:52 PM UTC+1, John Cremona wrote:
> I don't know how to extract that from the munged version (which is
> still being written to).
>
$SAGE_ROOT/logs/pkgs/atlas-3.10.1.p3.log
> > Also, please try
> anything!
>
I meant:
sage
-f http://boxen.math.washington.ed
On 19 August 2013 14:30, Volker Braun wrote:
> Can you post the ATLAS bulid log, not the whole log that has everything
> munged together?
I don't know how to extract that from the munged version (which is
still being written to).
>
> Also, please try
>
anything!
John
> On Monday, August 19, 2
On 19 August 2013 14:23, Volker Braun wrote:
> Without the new atlas you won't be able to use AVX so that shiny new CPU
> will not get even close to maximum floating point performance.
>
> If you just want to compile Sage quickly then use an atlas that you compile
> once (or your OS version) and s
Can you post the ATLAS bulid log, not the whole log that has everything
munged together?
Also, please try
On Monday, August 19, 2013 1:30:01 PM UTC+1, Christian Nassau wrote:
>
> The full build log is at
>
> http://nullhomotopie.de/sage512build.log.gz
>
> Cheers,
> Christian
>
--
You
Different ATLAS versions have different routines so the architectural
defaults for one version don't necessarily match another version.
If you don't want top performance then you can always set
SAGE_ATLAS_ARCH=fast or SAGE_ATLAS_ARCH=base when compiling Sage, this will
use some generic setting
On 8/19/13 8:18 AM, Jason Grout wrote:
The ATLAS FAQ indicates that auto-tuning is usually worse than using
architecture defaults: http://math-atlas.sourceforge.net/faq.html#ArchDef
("usually" may be an overstatement. The FAQ indicates that you should
test to see if architecture defaults are
Without the new atlas you won't be able to use AVX so that shiny new CPU
will not get even close to maximum floating point performance.
If you just want to compile Sage quickly then use an atlas that you compile
once (or your OS version) and set SAGE_ATLAS_LIB when building Sage.
--
You re
On 19 August 2013 13:18, Jeroen Demeyer wrote:
> On 08/19/2013 02:01 PM, John Cremona wrote:
>>
>> That seems a real killer to me. Nice new machine, lots of cores able
>> to build Sage-5.11 in about 20 minutes, suddenly goes up to infinity
>> with 5.12.beta1?
>
> Just to understand you better and
On 8/19/13 7:18 AM, Jeroen Demeyer wrote:
I believe (but I welcome other opinions) that, if this new ATLAS is
better in other respects, the ATLAS build time doesn't really matter.
But auto-tuning surely doesn't need to be done every time on every
machine. I thought there was an easy way to s
On 08/19/2013 02:34 PM, Jeroen Demeyer wrote:
This looks like http://trac.sagemath.org/ticket/15045
Two questions:
1. Can you give details on the CPU please?
2. Is this a reproducible problem, does it occur every time you try to
build ATLAS?
So far I tried to build two or three times, and it
On 08/19/2013 02:30 PM, Christian Nassau wrote:
g++ -g -c cf_algorithm.cc -Wall -fno-implicit-templates -I. -I.. -I.
-I/waste/cn/sage-5.12.beta0/local
-I/waste/cn/sage-5.12.beta0/local/include -DHAVE_CONFIG_H
-I/waste/cn/sage-5.12.beta0/local/include
-I/waste/cn/sage-5.12.beta0/local/include -o
On 08/19/2013 01:36 PM, John Cremona wrote:
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening? It's frustrating since even though I am using
make -j32 the tuning code is taking forever.
On 08/19/2013 02:01 PM, John Cremona wrote:
That seems a real killer to me. Nice new machine, lots of cores able
to build Sage-5.11 in about 20 minutes, suddenly goes up to infinity
with 5.12.beta1?
Just to understand you better and not judging you: why is it a "real
killer"? Why does it matter
On 19 August 2013 12:56, Jeroen Demeyer wrote:
> On 08/19/2013 01:36 PM, John Cremona wrote:
>>
>> What would make atlas suddenly decide to start running its tuning code
>> (building 5.12.beta1) on a machine which a few days ago built 5.11
>> without that happening?
>
> The ATLAS update at #14754.
On 08/19/2013 01:36 PM, John Cremona wrote:
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening?
The ATLAS update at #14754.
--
You received this message because you are subscribed to th
On 08/19/2013 07:36 PM, John Cremona wrote:
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening? It's frustrating since even though I am using
make -j32 the tuning code is taking forever.
What would make atlas suddenly decide to start running its tuning code
(building 5.12.beta1) on a machine which a few days ago built 5.11
without that happening? It's frustrating since even though I am using
make -j32 the tuning code is taking forever...
Would killing the make and rerunning it sa
45 matches
Mail list logo
