[sage-devel] Re: sage computer network

2013-03-04 Thread William Stein 
On Mon, Mar 4, 2013 at 1:16 PM, William Stein  wrote:
> On Mon, Mar 4, 2013 at 1:06 PM, William Stein  wrote:
>> Hi,
>>
>> I don't know why (yet), but the network connection from the room where
>> the sagemath.org website (and all sage.math computers) are hosted to
>> the outside world seems to have vanished.   I'm aware of this, and
>> have written to the sysadmins in the server room to ask what happened.
>
> Hi -- quick followup -- the network switch for my entire rack has
> died, which is why all the computers aren't available.  The sysadmins
> are currently putting an old backup switch in place.

The switch has been replaced, and everything should work now.

>
> (A "switch" is the box that all the ethernet cables plug into.)
>
> William
>
>>
>>
>>  -- William
>>
>> --
>> William Stein
>> Professor of Mathematics
>> University of Washington
>> http://wstein.org
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] strange behavior of sage

2013-03-04 Thread Dan Drake 
On Mon, 04 Mar 2013 at 02:00PM -0800, Dan Drake wrote:
> sage: preparse('len(t) = 4')
> '__tmp__=var("t"); len = symbolic_expression(Integer(4)).function(t)'

Hmm. If you try the same with one of Python's basic keywords (like
"else"), it fails because Python won't let you assign such a thing. So
no problems there. But "len" is a built-in function [1] and can be
redefined. Should the preparser print a warning when one does that?
Something like 

Warning: you are redefining one of Python's built-in functions. Use
"restore('len')" to restore the usual function.

That allows the user to have symbolic functions with names like "max"
while informing them that doing so may mess up other things.

Thoughts?

Dan


References:
[1]  http://docs.python.org/2/library/functions.html

--
---  Dan Drake
-  http://math.pugetsound.edu/~ddrake
---


signature.asc
Description: Digital signature

Re: [sage-devel] strange behavior of sage

2013-03-04 Thread Dan Drake 
To see what is really happening:

sage: preparse('len(t) = 4')
'__tmp__=var("t"); len = symbolic_expression(Integer(4)).function(t)'


Dan

--
---  Dan Drake
-  http://math.pugetsound.edu/~ddrake
---

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] strange behavior of sage

2013-03-04 Thread Dan Drake 
On Mon, 04 Mar 2013 at 01:36PM -0800, luisfe wrote:

> {{{
> sage: t=(1,2,3)
> sage: type(t)
> tuple
> sage: len(t)
> 3
> sage: len(t)=4
> sage: t
> t
> sage: type(t)
> sage.symbolic.expression.Expression
> }}}

Looks like some of our preparsing to make symbolic stuff work nicer: try this:

f(t) = sin(t)^2 + 2

which automatically does "var('t')". You are defining a symbolic
function called "len" which takes one variable, and the function is
constant (4).

Should our preparser reject reserved Python keywords? The current
behavior strikes me as strange and unexpected.

Dan

--
---  Dan Drake
-  http://math.pugetsound.edu/~ddrake
---


signature.asc
Description: Digital signature

[sage-devel] Re: strange behavior of sage

2013-03-04 Thread Timo Kluck 
Op maandag 4 maart 2013 22:36:33 UTC+1 schreef luisfe het volgende:
>
> Hi,
>
> Can any one enlight me about what is going on here?
>
> {{{
> sage: t=(1,2,3)
> sage: type(t)
> tuple
> sage: len(t)
> 3
> sage: len(t)=4
> sage: t
> t
> sage: type(t)
> sage.symbolic.expression.Expression
> }}}
>
It goes on with:
{{{
sage: len
t |--> 4
}}}
In other words, you did a function definition for the function `len`, just 
like
{{{
sage: f(x) = x^2
sage: f
x | --> x^2
}}}

Best, Timo

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] strange behavior of sage

2013-03-04 Thread luisfe 
Hi,

Can any one enlight me about what is going on here?

{{{
sage: t=(1,2,3)
sage: type(t)
tuple
sage: len(t)
3
sage: len(t)=4
sage: t
t
sage: type(t)
sage.symbolic.expression.Expression
}}}

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: sage computer network

2013-03-04 Thread kcrisman 
If anyone still wants to do Sage remotely, http://sagecell.sagemath.org/ 
still works :)

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: sage computer network

2013-03-04 Thread William Stein 
On Mon, Mar 4, 2013 at 1:06 PM, William Stein  wrote:
> Hi,
>
> I don't know why (yet), but the network connection from the room where
> the sagemath.org website (and all sage.math computers) are hosted to
> the outside world seems to have vanished.   I'm aware of this, and
> have written to the sysadmins in the server room to ask what happened.

Hi -- quick followup -- the network switch for my entire rack has
died, which is why all the computers aren't available.  The sysadmins
are currently putting an old backup switch in place.

(A "switch" is the box that all the ethernet cables plug into.)

William

>
>
>  -- William
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] sage computer network

2013-03-04 Thread William Stein 
Hi,

I don't know why (yet), but the network connection from the room where
the sagemath.org website (and all sage.math computers) are hosted to
the outside world seems to have vanished.   I'm aware of this, and
have written to the sysadmins in the server room to ask what happened.


 -- William

-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: patchbot timeout

2013-03-04 Thread Jeroen Demeyer 
On 2013-03-04 21:17, Travis Scrimshaw wrote:
> Hey,
>I think it's because trac and sagemath.org is down.

Yep, the whole Sage cluster seems down, I wonder what happened...

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: patchbot timeout

2013-03-04 Thread Travis Scrimshaw 
Hey,
   I think it's because trac and sagemath.org is down.

Best,
Travis


On Monday, March 4, 2013 3:02:04 PM UTC-5, Charles Bouillaguet wrote:
>
> Hi all, 
>
> I am running a patchbot on my (mostly idle) machine, and I witnessed this 
> : 
>
>
> Traceback (most recent call last): 
>File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
> 687, in  
>  main(args) 
>File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
> 671, in main 
>  patchbot.test_a_ticket(ticket) 
>File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
> 463, in test_a_ticket 
>  self.report_ticket(ticket, status=status[state], log=log, 
> plugins=plugins_results) 
>File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
> 588, in report_ticket 
>  print post_multipart("%s/report/%s" % (self.server, ticket['id']), 
> fields, files) 
>File "/scratch/sage-5.8.beta2/local/bin/patchbot/http_post_file.py", 
> line 16, in post_multipart 
>  return urllib2.urlopen(r).read() 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 126, 
> in urlopen 
>  return _opener.open(url, data, timeout) 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 400, 
> in open 
>  response = self._open(req, data) 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 418, 
> in _open 
>  '_open', req) 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 378, 
> in _call_chain 
>  result = func(*args) 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 
> 1207, in http_open 
>  return self.do_open(httplib.HTTPConnection, req) 
>File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 
> 1177, in do_open 
>  raise URLError(err) 
> urllib2.URLError:  
>
> Maybe the timeout should be made longer ? 
>
> Cheers, 
> -- 
> Charles Bouillaguet 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] patchbot timeout

2013-03-04 Thread Charles Bouillaguet 

Hi all,

I am running a patchbot on my (mostly idle) machine, and I witnessed this :


Traceback (most recent call last):
  File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
687, in 

main(args)
  File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
671, in main

patchbot.test_a_ticket(ticket)
  File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
463, in test_a_ticket
self.report_ticket(ticket, status=status[state], log=log, 
plugins=plugins_results)
  File "/scratch/sage-5.8.beta2/local/bin/patchbot/patchbot.py", line 
588, in report_ticket
print post_multipart("%s/report/%s" % (self.server, ticket['id']), 
fields, files)
  File "/scratch/sage-5.8.beta2/local/bin/patchbot/http_post_file.py", 
line 16, in post_multipart

return urllib2.urlopen(r).read()
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 126, 
in urlopen

return _opener.open(url, data, timeout)
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 400, 
in open

response = self._open(req, data)
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 418, 
in _open

'_open', req)
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 378, 
in _call_chain

result = func(*args)
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 
1207, in http_open

return self.do_open(httplib.HTTPConnection, req)
  File "/scratch/sage-5.8.beta2/local/lib/python/urllib2.py", line 
1177, in do_open

raise URLError(err)
urllib2.URLError: 

Maybe the timeout should be made longer ?

Cheers,
--
Charles Bouillaguet

--
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Fix GCC + MPIR race condition (#14168) needs review

2013-03-04 Thread Jeroen Demeyer 
If the GCC spkg has been installed and MPIR (or MPFR, MPC, ZLIB) gets
rebuilt, then GCC doesn't work properly during the "install" phase of
MPIR, because GCC uses the MPIR libraries.

Since a system GCC might also use the Sage libraries, we should ensure
in all cases that nothing gets built in parallel with ZLIB, MPIR, MPFR, MPC.

This is a *blocker* and needs review:
http://trac.sagemath.org/sage_trac/ticket/14168

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Strange behaviour of __rdiv__ ?

2013-03-04 Thread Eric Gourgoulhon 
Sorry the previous message has been set before completion:

We get
sage: 3+a, 3-a, 3*a
(5, 1, 6)
as expected, but
sage: 3/a
generates the following error:
TypeError Traceback (most recent call last)
 in ()
> 1 Integer(3)/a
...
TypeError: descriptor 'category' of 'sage.structure.sage_object.SageObject' 
object needs an argument

This was experienced with Sage 5.7 and Sage 5.4. 
Needless to say, it works with plain Python. 

It seems that the method A.__rdiv__ is not called, but that 
RingElement.__div__ is called instead. 
What could be the reason of this difference of behaviour with respect to 
__radd__, __rsub__ and __rmul__ ? 
Thank you for your help. 

Eric.

Le lundi 4 mars 2013 16:29:28 UTC+1, Eric Gourgoulhon a écrit :
>
> Hi, 
>
> In Sage, the reflected division operator, __rdiv__, seems not to behave as 
> the other reflected operators, __radd__, __rsub__ and __rmul__: it 
> generates an error in the following example: consider the simple class:
>  
> class A(SageObject):
> def __init__(self, x):
> self.x = x
>
> def __radd__(self, other):
> return other + self.x
> 
> def __rsub__(self, other):
> return other - self.x
> 
> def __rmul__(self, other):
> return other * self.x
> 
> def __rdiv__(self, other):
> return other / self.x
>
> We get:
> sage: a = A(2)
> sage: 3+a ; 3-a; 3*a
> (5, 1, 6)
> as expe
>
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Strange behaviour of __rdiv__ ?

2013-03-04 Thread Eric Gourgoulhon 
Hi, 

In Sage, the reflected division operator, __rdiv__, seems not to behave as 
the other reflected operators, __radd__, __rsub__ and __rmul__: it 
generates an error in the following example: consider the simple class:
 
class A(SageObject):
def __init__(self, x):
self.x = x

def __radd__(self, other):
return other + self.x

def __rsub__(self, other):
return other - self.x

def __rmul__(self, other):
return other * self.x

def __rdiv__(self, other):
return other / self.x

We get:
sage: a = A(2)
sage: 3+a ; 3-a; 3*a
(5, 1, 6)
as expe


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: splitting dynamics functionality in morphism.py into separate files

2013-03-04 Thread Ben Hutz 
I took a quick look at 8335 and it doesn't look like there would be any 
conflict in the changesets.

On Monday, March 4, 2013 4:29:08 AM UTC-5, Jean-Pierre Flori wrote:
>
>
>
> On Sunday, March 3, 2013 7:57:11 PM UTC+1, Ben Hutz wrote:
>>
>> As some of you are aware the (arithmetic) dynamical systems community has 
>> been working on dynamical system functionality for Sage. As the initial 
>> ticket has been reviewed (#13130) I've opened tickets for the remaining 
>> (completed) functionality: 
>> 14217, 
>> 14218 , 
>> 14219
>> .
>>
>> I've opened the three tickets at once and up-loaded the patches even 
>> though they are not quite ready for review to make the case for splitting 
>> morphism.py into several files. The reason is that morphism.py is getting 
>> crowded. With just 13130 it is still a nice compact file, but it seems like 
>> it is getting overloaded with (14127,14218,14219), especially since there 
>> remains quite a bit of dynamics functionality that has been published 
>> recently, but not implemented as patches (beyond these 3 tickets). I know 
>> that some history is lost as code when moved around, but I propose doing 
>> the split now (as part of #14217) before more dynamics functionality is 
>> added to morphism.py. This would also leave morphism.py as a more generic 
>> file without the dynamics specific functionality it in.
>>
>> If this is reasonable, I'd like some input on where to move these files.
>>
>> The maximum change would be an "affine_space" and a "projective_space" 
>> folder in sage\schemes\ each with point and polynomial morphism files for 
>> rings/field/finite_fields (so a total of 12 new files and 2 folders) and 
>> some rearrangement of where the affine/projective functionality lives (it 
>> in currently in schemes/generic).
>>
> Not sure it is related, but finite field lattices may be finally merged in 
> #8335.
> It would be great if the two changesets were not completely conflicting.
>
>>
>> The minimum I propose would be making 4 new files in schemes/generic one 
>> each for affine/projective points/morphisms.
>>
>> I think the major division makes sense as there are plans for a 
>> significant amount of  dynamics functionality. But, as this proposal is 
>> more than just implementing a couple functions, I am seeking the 
>> input/experience of sage-devel.
>>
>> I look forward to your input.
>>
>> Sincerely,
>>   Ben Hutz
>>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: How reliable is patchbot's startup_time plugin?

2013-03-04 Thread Christian Nassau 
Am 04.03.2013 12:41, schrieb Simon King:
> The patchbot situation is:
> - The current topmost patchbot report is openSUSE/.../jehova. It seems
>   that it is still using the old version of the second patch, as there
>   is a mismatch. Here, the startup_time plugin complains with 90%
>   confidence about a 0.1% increase.

That is my machine: I'm always automatically installing the official
patchbot package using

./sage -i patchbot

According to "spkg/installed" this is currently "patchbot-1.2.5".

I don't know how to answer questions about the individual patches that
have been applied. Does this help?

> patchbot@jehova:/plethora/patchbot/sage-5.8.beta2/devel/sage-14214> hg 
> qapplied
> trac_14159_weak_value_triple_dict.patch
> trac_14159_use_cdef_get.patch
> trac12951_cached_extension.patch
> trac_14214-cython_homset.patch
> trac_14214-backup_cache.patch

Cheers,
Christian

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: How reliable is patchbot's startup_time plugin?

2013-03-04 Thread Simon King 
Hi Jeroen,

On 2013-03-04, Jeroen Demeyer  wrote:
> On 2013-03-04 12:01, Simon King wrote:
>>   +With 99.3% confidence, startup time decreased by at least 0.1%
>>   +With 99.4% confidence, startup time increased by at least 0.1%
>
>> Since the code didn't change in between, how significant is it then?
> Are you really really sure that the code didn't change? Because if it
> really didn't change, I would indeed consider the startup_time plugin
> broken (this also shows how hard it will be to do #12720 right).

In comment 6, I first see the second patch mentioned, namely:
 "Apply trac_14214-cython_homset.patch trac_14214-backup_cache.patch"
Later, the second patch was changed precisely once, namely in comment 8.

The change of the patch, namely removal of an example, as explained in
comment 7.

The patchbot situation is:
- The current topmost patchbot report is openSUSE/.../jehova. It seems
  that it is still using the old version of the second patch, as there
  is a mismatch. Here, the startup_time plugin complains with 90%
  confidence about a 0.1% increase.
- Fedora/.../volker-dektop.stp.dias.ie seems to have the current patch
  version. The startup_plugin complains with 98% confidence about a
  0.25% increase.
- Fedora/,../volker-desktop.stp.dias.ie also has a report with a
  mismatch in the second patch (hence, it is supposed to be the same
  patch as in openSUSE/.../jehova!). The startup_time plugin reports
  with 97% confidence about a 0.25% *decrease*.

I don't know if we can find out "post mortem" what patches were really
applied.

I can only conclude indirectly: The second patch saw precisely
two versions, hence, a "mismatch" means that the patchbot was using the
old version, and (see above) with *the same* old patch version one patchbot
reports a speed-up and another patchbot reports a slow-down.

And one patchbot reports a speed-up with the old patch but a slow-down
with the new patch. But I am sure that the only change consisted in
removing a test from sage/modules/vector_space_homspace.py

Cheers,
Simon


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] How reliable is patchbot's startup_time plugin?

2013-03-04 Thread Jeroen Demeyer 
On 2013-03-04 12:01, Simon King wrote:
>   +With 99.3% confidence, startup time decreased by at least 0.1%
>   +With 99.4% confidence, startup time increased by at least 0.1%

> Since the code didn't change in between, how significant is it then?
Are you really really sure that the code didn't change? Because if it
really didn't change, I would indeed consider the startup_time plugin
broken (this also shows how hard it will be to do #12720 right).

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] How reliable is patchbot's startup_time plugin?

2013-03-04 Thread Simon King 
Hi!

At some point, the startup_time plugin showed
  -With 25% confidence, startup time increased by at least 0.25%
  -With 44% confidence, startup time increased by at least 0.1%
  +With 82% confidence, startup time decreased by at least 0.5%
  +With 97% confidence, startup time decreased by at least 0.25%
  +With 99.3% confidence, startup time decreased by at least 0.1%
Hence, we had a significant speed-up of 0.25% of startup time.

But then I changed the second patch. The change was in a docstring,
hence, the code did not change. However, the plugin now gives
  -With 25% confidence, startup time increased by at least 0.25%
  -With 44% confidence, startup time increased by at least 0.1%
  +With 85% confidence, startup time increased by at least 0.5%
  +With 98% confidence, startup time increased by at least 0.25%
  +With 99.4% confidence, startup time increased by at least 0.1%
Hence, we now have a significant slow-down by 0.25% of startup time.

Since the code didn't change in between, how significant is it then?

Cheers,
Simon


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-algebra] Boundary cases

2013-03-04 Thread Jean-Pierre Flori 


On Monday, March 4, 2013 10:35:35 AM UTC+1, David Kohel wrote:
>
>
> In a ring of characteristic 0, it seems that 0^0 (= 1) is well-defined. 
> In my view this is correct.  It makes it much simpler to define the 
> matrix (e.g. FF a finite field): 
>
> G = matrix([ [ a^i for a in FF ] for i in range(k) ]) 
>
> However, in finite fields or any of the the following rings, 0^0 
> gives an error: 
>
> FF. = FiniteField(32) 
> FF = FiniteField(31) 
> PF. = PolynomialRing(FF) 
>
> The correct behaviour can be faked in an isomorphic ring which 
> is a quotient of something in characteristic zero: 
>
> PZ. = PolynomialRing(ZZ) 
> R = PZ.quotient_ring([x-1,31]) 
>
> Here R(0)^0 (= 1) is fine.  Is there any objection to reporting this 
> as a bug and fixing it? 
>
> I think most of these were caught by 
http://trac.sagemath.org/sage_trac/ticket/13786 and its dependencies which 
are merged in the 5.8 beta series.
Could you test the latest beta and report a bug if needed?

Best,
JP

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Fwd: [sage-algebra] Boundary cases

2013-03-04 Thread David Kohel 


In a ring of characteristic 0, it seems that 0^0 (= 1) is well-defined.
In my view this is correct.  It makes it much simpler to define the
matrix (e.g. FF a finite field):

G = matrix([ [ a^i for a in FF ] for i in range(k) ])

However, in finite fields or any of the the following rings, 0^0
gives an error:

FF. = FiniteField(32)
FF = FiniteField(31)
PF. = PolynomialRing(FF)

The correct behaviour can be faked in an isomorphic ring which
is a quotient of something in characteristic zero:

PZ. = PolynomialRing(ZZ)
R = PZ.quotient_ring([x-1,31])

Here R(0)^0 (= 1) is fine.  Is there any objection to reporting this
as a bug and fixing it?

--David


--
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: splitting dynamics functionality in morphism.py into separate files

2013-03-04 Thread Jean-Pierre Flori 


On Sunday, March 3, 2013 7:57:11 PM UTC+1, Ben Hutz wrote:
>
> As some of you are aware the (arithmetic) dynamical systems community has 
> been working on dynamical system functionality for Sage. As the initial 
> ticket has been reviewed (#13130) I've opened tickets for the remaining 
> (completed) functionality: 
> 14217, 
> 14218 , 
> 14219
> .
>
> I've opened the three tickets at once and up-loaded the patches even 
> though they are not quite ready for review to make the case for splitting 
> morphism.py into several files. The reason is that morphism.py is getting 
> crowded. With just 13130 it is still a nice compact file, but it seems like 
> it is getting overloaded with (14127,14218,14219), especially since there 
> remains quite a bit of dynamics functionality that has been published 
> recently, but not implemented as patches (beyond these 3 tickets). I know 
> that some history is lost as code when moved around, but I propose doing 
> the split now (as part of #14217) before more dynamics functionality is 
> added to morphism.py. This would also leave morphism.py as a more generic 
> file without the dynamics specific functionality it in.
>
> If this is reasonable, I'd like some input on where to move these files.
>
> The maximum change would be an "affine_space" and a "projective_space" 
> folder in sage\schemes\ each with point and polynomial morphism files for 
> rings/field/finite_fields (so a total of 12 new files and 2 folders) and 
> some rearrangement of where the affine/projective functionality lives (it 
> in currently in schemes/generic).
>
Not sure it is related, but finite field lattices may be finally merged in 
#8335.
It would be great if the two changesets were not completely conflicting.

>
> The minimum I propose would be making 4 new files in schemes/generic one 
> each for affine/projective points/morphisms.
>
> I think the major division makes sense as there are plans for a 
> significant amount of  dynamics functionality. But, as this proposal is 
> more than just implementing a couple functions, I am seeking the 
> input/experience of sage-devel.
>
> I look forward to your input.
>
> Sincerely,
>   Ben Hutz
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.