Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[Christian Nassau]

On 19.07.20 00:34, rrbold wrote:

Hi Christian and John,

Christian, your first sentence puts the finger on the correct spot:   
I take the position that a graded abelian group is not an abelian 
group.   It is a sequence of abelian groups.


For any category C, one can consider Gr(C), the category of graded 
objects in C, which has objects the functions from your grading 
monoid, frequently the natural numbers, to Obj(C), and morphisms the 
sequences of morphisms of C.   There is no need for C to have a direct 
sum or categorical coproduct which will allow you to combine these

into a single object in C, in order to consider such things.

Mathematically, consider singular n-cochains on a space X with values 
in a module M.   These are functions from the set Top(\Delta_n,X) of 
continuous maps \Delta_n --> X into the module M, i.e., elements of 
Set(Top(\Delta_n,X),M), given the natural module structure inherited 
from M.    If n \neq k, then there is no sensible relation between 
the  zero function Top(\Delta_n, X) --> M and the zero function 
Top(\Delta_k,X).    Only inductive generalization or habit would 
suggest that sending all the elements of Top(\Delta_n,X)  to zero \in 
M means you should also do this to all the elements in the entirely 
different set Top(Delta_k,X).


The fact that this causes difficulties in the programming is a hint 
that we make an error in thinking of graded objects as their direct 
sum.    I think it is better to take the mathematically sensible 
solution, and accept that there is a different 0 in each degree of a 
graded module.



Hi Bob,

I think treating graded objects as sequences/disjoint unions of their 
homogeneous components is a perfectly legitimate point of view, and Sage 
could and should strive to make it possible to follow that philosophy in 
user code. I also stand by my suggestion that this is already *almost* 
possible, using the A[n] in place of A. Essentially you would just need 
to redefine the Sq function or whatever you use to generate a Steenrod 
operation:


   sage: def Sq(*R):
   : A = SteenrodAlgebra(2)
   : a = A.Sq(*R)
   : return A[a.degree()].monomial(R)
   :
   sage: Sq(1,1)+Sq(4)
   milnor[(1, 1)] + milnor[(4,)]

This way, your Sq(R) live in different parents depending on their 
degree, and the association element -> parent -> degree allows to 
recover the degree from all elements.


When you try to add those Sq(R) from different degrees, you also get the 
expected errors:


   sage: Sq(1,1)+Sq(5)
   ---
   TypeError Traceback (most recent
   call last)
   ...
   TypeError: unsupported operand parent(s) for +: 'Vector space
   spanned by (Sq(1,1), Sq(4)) over Finite Field of size 2' and 'Vector
   space spanned by (Sq(2,1), Sq(5)) over Finite Field of size 2'

Using that approach in practice would need some (minor) fixes to Sage, 
but these are not nearly as radical as suggesting multiple zeroes in the 
SteenrodAlgebra itself:


TODOs:

  1)  missing multiplication A[n] * A[m] -> A[n+m]

  2)  A[n].zero().degree() should be n

  3)  the printing of A[n] and of its elements is a bit unexpected: I 
would support changing this to the usual printing with respect to the 
basis that is chosen in the usual SteenrodAlgebra


  4)  missing cast from A to A[n]

Best,
Christian

PS: the different approaches to gradings seem to mirror the distinction 
between classical and quantum physics. The enlightened quantum 
perspective just acepts as a fact of nature that elements of a graded 
module usually exist in a superposition of pure states, i.e. that they 
might have no fixed degree (for inhomogeneous elements) or every degree 
(the zero element). I find this mostly just as good in my programming.


In practical terms this just shifts the responsibilities a bit: the 
result of a computation (e.g. multiplication) will not in general know 
its degree; therefore the piece of user code that triggered the 
multiplication must keep a memory of the grading that it's workign at.


PPS: among illuminated minds, no posting is complete without a hint of 
self-contradiction, so I feel obliged to disclose that in my Steenrod 
Tcl library I actually made a similar choice about the representation of 
matrices as lists of lists of entries, and here my choice was clearly 
wrong and has given me a lot of headachesever since: the point is that I 
cannot recover the M from a matrix of dimensions 0xM or Mx0 ...



Best,
Bob (rrb - old)





On Saturday, July 18, 2020 at 5:57:21 PM UTC-4, Christian Nassau wrote:

Hi Sverre,

I don't think it's a good idea to have different zeroes in an
algebraic structure that is also categorized as an abelian group,
unless you take the point that a "graded abelian group" should not
be an "abelian group".

But let me als

Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[Christian Nassau]

On 19.07.20 01:01, John H Palmieri wrote:



On Saturday, July 18, 2020 at 2:57:21 PM UTC-7, Christian Nassau wrote:

Hi Sverre,

I don't think it's a good idea to have different zeroes in an
algebraic structure that is also categorized as an abelian group,
unless you take the point that a "graded abelian group" should not
be an "abelian group".

But let me also point out that something similar to what you want
already exists: you can take a homogeneous component of the
Steenrod algebra and look at its zero:

sage: A=SteenrodAlgebra(2)
sage: A[18]
Vector space spanned by (Sq(0,1,0,1), Sq(3,0,0,1), Sq(1,1,2),
Sq(4,0,2), Sq(2,3,1), Sq(5,2,1), Sq(8,1,1), Sq(11,0,1),
Sq(0,6), Sq(3,5), Sq(6,4), Sq(9,3), Sq(12,2), Sq(15,1),
Sq(18)) over Finite Field of size 2
sage: A[18].zero() == A.zero()
True
sage: A[18].zero() == A[17].zero()
False

This suggests that "A[18].zero().degree()" could give 18, and the
fact that it currently gives a ValueError might be considered a bug.


It could equally well give zero. Should A[18] remember that it's in 
degree 18, or should is just be an ungraded module?


I don't think zero makes much sense here. The suggestion seems to be to 
have in Sage an A[n] that represents homotopy classes of maps from a 
fixed suspension of HF2 to HF2. If this is the goal then elements of 
A[n] should always have x.degree() = n, and we would also need a 
multiplication A[n] * A[m] -> A[n+m]. Currently that product map does 
not exist in Sage:


   sage: A=SteenrodAlgebra(2)
   sage: A[3].an_element() * A[4].an_element()
   ---
   TypeError Traceback (most recent
   call last)


   TypeError: unsupported operand parent(s) for *: 'Vector space
   spanned by (Sq(0,1), Sq(3)) over Finite Field of size 2' and 'Vector
   space spanned by (Sq(1,1), Sq(4)) over Finite Field of size 2'

Also, a quick test suggests that the M[n] notation is not part of a 
general framework in Sage, and that degrees of inhomogeneous elements 
are handled somewhat liberally in other places.  This might just reflect 
a "cultural" difference between topologists and combinatorialists, of 
course:


   sage: S=SymmetricFunctions(QQ)
   sage: S.an_element().degree()
   2
   sage: for x in S.an_element().monomials():
   : print (x, x.degree())
   :
   s[] 0
   s[1] 1
   s[2] 2
   sage: S.zero().degree()
   0
   sage: S.graded_algebra() is S
   True






--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7d4b8529-56ff-d40b-da5d-99186f109ae0%40nullhomotopie.de.

Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[Christian Nassau]

Hi Sverre,

I don't think it's a good idea to have different zeroes in an algebraic 
structure that is also categorized as an abelian group, unless you take 
the point that a "graded abelian group" should not be an "abelian group".


But let me also point out that something similar to what you want 
already exists: you can take a homogeneous component of the Steenrod 
algebra and look at its zero:


   sage: A=SteenrodAlgebra(2)
   sage: A[18]
   Vector space spanned by (Sq(0,1,0,1), Sq(3,0,0,1), Sq(1,1,2),
   Sq(4,0,2), Sq(2,3,1), Sq(5,2,1), Sq(8,1,1), Sq(11,0,1), Sq(0,6),
   Sq(3,5), Sq(6,4), Sq(9,3), Sq(12,2), Sq(15,1), Sq(18)) over Finite
   Field of size 2
   sage: A[18].zero() == A.zero()
   True
   sage: A[18].zero() == A[17].zero()
   False

This suggests that "A[18].zero().degree()" could give 18, and the fact 
that it currently gives a ValueError might be considered a bug.


Best,
Christian


On 18.07.20 23:35, Sverre Lunøe-Nielsen wrote:

Hi,

Thank you for your comments so far.  I feel I need to expand some more 
on the issue of zero elements which is the central thing for the 
problem we are adressing.


It is mathematically equivalent to think of a graded k-algebra A as either

1) a direct sum A = \bigosum_i A_i, together with a graded k-linear 
map from

   the graded tensor product A\tensor_k A --> A,

or

2) a sequence of k-vectorspaces {A_i}_i, together with a set of 
structure maps

   \{ A_i \tensor_R A_j --> A_{i+j} \}_{i,j}.

(In both cases the structure maps should satisfy usual algebraic 
conditions.)


Similar for graded A-modules.

The implementation of the SteenrodAlgebra package takes the approach 
of 1), and never speaks about the zero element z_i \in A_i for any i.  
Rather, they are all identified in A via the canonical injection A_i 
--> A.  It is tradition not to worry too much about this since you can 
"figure it out" if you have to, and know how you ended up with a zero.


However, it is arguably better, specially when writing software, to 
avoid this simplifaction since it leads to a corner case which has to 
be dealt with over and over again.  A great share of the bugs I have 
corrected in the package I have been editing have been caused by the 
wrongful assumption that all elements have an integer degree.  Having 
not to worry about this would make our code cleaner, and so will all 
future code building on it.


I was being rather vague about making proposals for change in the 
SteenrodAlgebra package in my last post, so to be clear let me propose 
a specific change and invite anyone to share their opinion on it:


Change SteenrodAlgebra such that _all_ homogeneous elements have a 
well defined degree.  For the user, this means in particular that when 
constructing the zero element, its degree must be given:


    sage: A = SteenrodAlgebra(p=2)
    sage: z = A.zero(degree=2)
    sage: Sq(1)*Sq(1) == z
    True
    sage: Sq(2)*Sq(1)*Sq(1) == z
    False

This involves adding the degree as internal data to zero elements, and 
change the behaviour of degree() such that it raises an exception only 
for inhomogeneous elements.


I hope I have clearified that I am not seeking a strange new 
definition of graded module or algebra, and that I am merely wanting 
to discuss the possibility of changing the implementation of 
SteenrodAlgebra.


E.g. are there perhaps unwanted software ramifications that our 
proposal would bring about?


Regards,

Sverre





On Saturday, July 18, 2020 at 11:31:43 PM UTC+2, John H Palmieri wrote:



On Saturday, July 18, 2020 at 2:31:01 AM UTC-7, Sverre
Lunøe-Nielsen wrote:

Dear list,

I have been involved in preparing a package by M. Catanzaro
and R. Bruner lately, which implements finitely presented
modules over the mod `p` Steenrod algebra.

We have encountered a conflict regarding how to present graded
objects, and I am writing to the list to get other people's
opinion on how to proceed on this matter.

Briefly, the issue is that the Steenrod algebra allows
inhomogeneous elements and our graded modules do not. Thus,
the Steenrod algebra has a single zero element with no well
defined degree, while our modules could potentially have one
zero element for each degree.

My wish is to allow degreewise zero elements in our graded
modules, so that x.degree() would return an integer for every
element x.  But because the unique zero in the Steenrod
algebra has no well defined degree, I am forced to let
degree() treat all zero elements in our modules the same way
and return ``None``.

A more precise description of the issue is found in the Sphinx
note below.

My questions to the list are: Has similar issues been
discussed and/or resolved before?  And more specificly: What
acceptable changes could be made to the Steenrod algebra
package to achieve what I wa

Re: [sage-devel] Graded modules over the Steenrod algebra: The degree of zero elements

[Christian Nassau]

Hi Sverre,

I ran into similar problems in my "yacop" package 
(https://github.com/cnassau/yacop-sage), which also deals with graded 
modules over the Steenrod algebra.


I think when I began, Sage didn't even have its own category of graded 
things, so I ended up inventing my own category of "Yacop graded 
objects". I later had a look at what Sage is offering and it seemed to 
lack some important features that I need, so I have stuck with my own 
inventions ever since.


One missing thing is inspection of the grading module: if your code gets 
a tri-graded, potentially very big module it's desirable to provide a 
way to locate the non-zero tridegree's efficiently. My solution was that 
a graded module can advertise the "bounding box" for (a subset of) its 
elements, so that the non-zero pieces can be located quickly.


More importantly, once you're dealing with graded modules you might want 
to operate *on* the grading by taking a suspension or truncation of the 
module. I implemented this by providing two new functors "supension" and 
"truncation".


My solution is probably not very robust and well-tested, but you could 
take a look at my code for inspiration. Here is a sample session, using 
the docker image based on Sage 8.2:


   ~$ docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix
   --rm -it cnassau/yacop-sage
   ┌┐
   │ SageMath version 8.2, Release Date: 2018-05-05 │
   │ Type "notebook()" for the browser-based notebook interface.    │
   │ Type "help()" for help.    │
   └┘
   ┌┐
   │ Imported package Yacop (version 2.0)   │
   └┘
   sage: from yacop.modules.dickson import DicksonAlgebra
   sage: D=DicksonAlgebra(2,3)
   sage: D
   Dickson algebra D(3) for prime 2
   sage: for g in D.graded_basis(tmax=10):
   : print g, g.t, g.degree()
   :
   d4 4 region(e = 0, s = 0, t = 4)
   1 0 region(e = 0, s = 0, t = 0)
   d4*d6 10 region(e = 0, s = 0, t = 10)
   d6 6 region(e = 0, s = 0, t = 6)
   d7 7 region(e = 0, s = 0, t = 7)
   d4**2 8 region(e = 0, s = 0, t = 8)

Here's how you take suspensions and truncations:

   sage: suspension(D,t=8)
   suspension (8,0,0) of Dickson algebra D(3) for prime 2
   sage: from yacop.modules.functors import truncation
   sage: truncation(D,tmax=10)
   truncation to region(-Infinity < t <= 10) of Dickson algebra D(3)
   for prime 2


Finally, to come back to your original question, here is the degree of zero:


   sage: D.zero().degree()
   ---
   ValueError    Traceback (most recent
   call last)
   ...
   ValueError: degree of zero is undefined

I think if you end up needed a different zero in each grading, you're 
doing something wrong. After all, your code can always know what the 
expected degree of an element (eg. some Sq(R)*whatever) is; you probably 
should just not rely on the idea that that degree can be recovered from 
the product.


Best,
Christian


On 18.07.20 11:31, Sverre Lunøe-Nielsen wrote:

Dear list,

I have been involved in preparing a package by M. Catanzaro and R. 
Bruner lately, which implements finitely presented modules over the 
mod `p` Steenrod algebra.


We have encountered a conflict regarding how to present graded 
objects, and I am writing to the list to get other people's opinion on 
how to proceed on this matter.


Briefly, the issue is that the Steenrod algebra allows inhomogeneous 
elements and our graded modules do not.  Thus, the Steenrod algebra 
has a single zero element with no well defined degree, while our 
modules could potentially have one zero element for each degree.


My wish is to allow degreewise zero elements in our graded modules, so 
that x.degree() would return an integer for every element x.  But 
because the unique zero in the Steenrod algebra has no well defined 
degree, I am forced to let degree() treat all zero elements in our 
modules the same way and return ``None``.


A more precise description of the issue is found in the Sphinx note below.

My questions to the list are: Has similar issues been discussed and/or 
resolved before?  And more specificly: What acceptable changes could 
be made to the Steenrod algebra package to achieve what I want?


Regards,

Sverre Lunøe-Nielsen


.. NOTE::
Our implementation treats a graded module as the disjoint union, 
rather than a
direct sum, of vectorspaces of homogeneous elements.  Elements are 
therefore
always homogeneous, which also implies that sums between elements of 
different

degrees are not allowed.  This also means that acting by an inhomogeneous
element of the Steenrod algebra

Re: [sage-devel] Re: doctesting of external packages

[Christian Nassau]

On 02.02.2017 22:51, Volker Braun wrote:
I would recommend the import statements. Then you can paste the 
doctest into Sage and it just works. Thats a big plus IMHO. Explicit 
is better than implicit.

Thanks, that sounds like sage advice! I have followed that path now.

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] doctesting of external packages

[Christian Nassau]

Dear Sage Colleagues,

The recently merged changes for ticket 20729 have unfortunately broken 
the doctesting of an external package that I'm working on. A minor 
nuisance is that symbolic links are apparently no longer resolved, but 
that is something that I could circumvent (or propose a fix). More 
serious to me is that I currently see no way to fix my code without 
littering it with additional import statements:


suppose I have this structure (starting from sage-root)

  testpkg/__init__.py

  testpkg/testfile.py

where testfile.py is

--
"""
DOCTEST::

   sage: myfunc()
   hello

"""

def myfunc():
   print "hello"

--

With 7.6.b1 the command "./sage -t testpkg" no longer imports the file 
(because of the "__init__.py" in the same directory) and the test fails 
with "NameError: name 'myfunc' is not defined".


So my questions, probably, are these:

  1) is that new behaviour really intended?

  2) what should/can a package author do to still test his files?

With regards to 2) it seems I could add an extra "from testpkg.testfile 
import myfunc" at the beginning of the test, but doing this for all 
global symbols in every file strikes me as a nightmare solution. Is 
there maybe a better way to fix this?


I can also see that the doctesting code checks a certain flag 
"force_lib" and sage accepts a corresponding "--force_lib" argument for 
doctesting. Might it be a good idea to add a command line option 
"--force_code" as the opposite of "--force_lib"?


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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Problems installing sage on opensuse leap 42.1

[Christian Nassau]

Hi Arrigo,

Accordiing to the log the problem seems to be a missing "g++". Are you 
sure you have gcc installed?


On 08.10.2016 09:27, Arrigo Gosparini wrote:

./configure: line 1592: g++: command not found


HTH,
C.

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] memory leak

[Christian Nassau]

I also found valgrind not very helpful here, but good old 
code-dissection leads me to believe that the problem might originate in 
the polynomial evaluation in the _richcmp_ routine in


src/sage/rings/number_field/number_field_element.pyx

That's because the following code shows the same leak:

x = polygen(ZZ)
K = NumberField(x**3 - 2, 'cbrt2', embedding=RR(1.2599))
w = K.gen()
wp = w.polynomial()
app = K._get_embedding_approx(3)
import resource
print resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
for _ in range(2): test = wp(app)
print resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
for _ in range(2): test = wp(app)
print resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
for _ in range(2): test = wp(app)
print resource.getrusage(resource.RUSAGE_SELF).ru_maxrss

HTH,
Christian


On 23.03.2016 17:17, Vincent Delecroix wrote:

Hello,

Some friend just sent an e-mail to me mentioning a memory leak. Here 
is a minimal example


sage: x = polygen(ZZ)
sage: K = NumberField(x**3 - 2, 'cbrt2', embedding=RR(1.2599))
sage: w = K.gen()
sage: import resource
sage: resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
180720
sage: for _ in range(1): test = w > 1
sage: resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
183452
sage: for _ in range(1): test = w > 1
sage: resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
184552
sage: for _ in range(1): test = w > 1
sage: resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
185832

The memory usage should *not* grow at all but it does very fast. I am 
new to valgrind and was not able to get anything from it. Any help 
appreciated.


Vincent



--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage-6.10.rc1 binaries test

[Christian Nassau]

2/  The Jupyter notebook opened with ./sage -n jupyter starts with an 
error message


Failed to retrieve MathJax from '/nbextensions/mathjax/MathJax.js'


Indeed, the package(s) seem to contain a couple of problematic symlinks 
here (I know I shouldn't use "cp -r", but this conveniently listed the 
problems for me):


el-capitan:sage-6.10.rc1-OSX_10.11.2-x86_64 cn$ cp -r SageMath ~
cp: SageMath/local/share/jupyter/kernels/sagemath/doc: No such file or 
directory
cp: SageMath/local/share/jupyter/kernels/sagemath/logo-64x64.png: No 
such file or directory
cp: SageMath/local/share/jupyter/kernels/sagemath/logo.svg: No such file 
or directory
cp: SageMath/local/share/jupyter/nbextensions/jsmol: No such file or 
directory
cp: SageMath/local/share/jupyter/nbextensions/mathjax: No such file or 
directory


For example SageMath/local/share/jupyter/kernels/sagemath/doc points to
/Users/buildslave-sage/slave/binary_pkg/build/source/SageMath/jc4b6yulaujayb9sr94ia88eourzeqip0oidma/src/doc/output/html/en

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage bdist changes (OSX El Capitan) Jupiter Notebook doesn't work

[Christian Nassau]

On 26.11.2015 10:31, Volker Braun wrote:
Yes, thats because Apple decided (in their infinite wisdom) to not 
include openssl headers in El Capitan, so we can't link against OSX's 
openssl library even though it is present on the system.


It seems Xcode comes equipped with its own version of the headers:
/Applications/Xcode.app/Contents//Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-migrator/sdk/MacOSX.sdk/usr/include/openssl

Would it make sense to try building against those, as a fallback solution?


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage on OS X: El Capitan

[Christian Nassau]

On 25.10.2015 01:03, Volker Braun wrote:
I've used that ticket to build relocatable OSX 10.11 binaries and 
uploaded them to http://files.sagemath.org/osx/intel/index.html. They 
work except you can't compile stuff on top of these binaries since the 
library install names are still wrong. In any case feel free to test 
and report back...


I get a segfault on startup, probably because my (virtual) processor is 
a plain core2duo and mpir is expecting something more sophisticated:


Program received signal SIGILL, Illegal instruction.
0x00010ac310b0 in __gmpf_set_d ()
   from 
/Volumes/sage-6.10.beta1-x86_64-Darwin/sage/local/lib/libmpir.16.dylib



--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] El Capitan SIGSEGV upon compiling sage 6.9

[Christian Nassau]

Hi Alejandro,

You need at least 6.10.beta0 to compile on OSX10.11 - your issues seem 
similar to those of #19370 where this was fixed.


HTH,
Christian

On 22.10.2015 18:52, Alejandro Erickson wrote:
I get an error that I don't see much information about when compiling 
on El Capitan.  The short of it is:

|
cd ../..&&sage-logger './sage --docbuild --no-pdf-links all html 
'logs/dochtml.log


UnhandledSIGSEGV:A segmentation fault occurred inSage.
Thisprobably occurred because a *compiled*component of Sagehas a bug
init andisnotproperly wrapped withsig_on(),sig_off().
Sagewill now terminate.

/Users/alejo/sage/build/bin/sage-logger:line 
32:6366Segmentationfault:11./sage --docbuild --no-pdf-links all html

make[2]:***[doc-html]Error139
make[1]:***[all]Error2
|

I'll list what I have tried, and then some full logs.  I have Mac OS 
10.11 El Capitan with SIP turned off (running in rootless mode). 
 Precompiled sage works fine for me, and so does sage 6.5 that I built 
on a previous system. I moved /opt/local to /opt/local_TMP.  I tried 
to upgrade sage 6.5 with

|
sage -upgrade
|
but the gave an error installing python2-2.7.9.  I then downloaded and 
tried to build sage 6.9 (with make) and got the SIGSEGV error.


Command line output (same as install.log?) attached.

Your help is much appreciated.
--
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.
For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage on OS X: El Capitan

[Christian Nassau]

On 21.10.2015 21:11, John H Palmieri wrote:
The latest beta version of Sage should build on OS X 10.11. It has a 
serious limitation: you can't move the installation once it has been 
built. I don't know if anyone is working on fixing this, or on a 
proposed stopgap (http://trac.sagemath.org/ticket/19410) which 
basically forces the Mac installation (when you do "sage --bdist") to 
be in a particular directory.


I might be inclined to put some work into the #19410 (which I proposed), 
if there were some sort of consensus that this is the way to go (i.e.: 
forbid relocation, use a fixed install diectory). I'm more or less a 
complete Mac newbie and got started on this issue purely out of idle 
curiosity - I'm not at all sure whether experienced Mac users agree that 
this solution a) will work and b) is the right one.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Failing doctests in sage/dev if $HOME/.sage is a symlink with trailing slash

[Christian Nassau]

On 09/23/2014 12:23 PM, Clemens Heuberger wrote:

My $HOME/.sage is a symbolic link with a trailing slash:

~ $ ls -ld .sage
lrwxrwxrwx 1 cheuberg lsci 11 Sep 23 10:25 .sage -> /tmp/.sage/

When running make ptestlong (sage 6.4.beta3) with this configuration, I get
quite a number of failing doctests (see below for details) and several files are
created or overwritten (see below for details).


I'm not sure if this observation helps or is related, but I too was once 
struck by a leading slash problem:

   http://trac.sagemath.org/ticket/14018

My solution[*] was to change the link from "/whatever" to "///whatever": 
I'd be curious to know if this "fix" also works for you.


HTH,
Christian

[*] this is based on this quote from IEEE Std 1003.1, 2004 Edition:

   A pathname consisting of a single slash shall resolve to the root
   directory of the process. A null pathname shall not be successfully
   resolved. A pathname that begins with two successive slashes may be
   interpreted in an implementation-defined manner, although more than
   two leading slashes shall be treated as a single slash.

​ 
http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap04.html#tag_04_11


Somewhere my "/whatever" became "//whatever" and that, being 
"implementation defined" was no longer recognized as "/whatever".


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Error building Sage: Error installing package pynac-0.3.2

[Christian Nassau]

I think you're seeing the same problem as described here:
https://groups.google.com/forum/#!topic/sage-support/H-SI3700rGc

Building Sage as root seems to be currently unsupported; I'd try to 
build from a regular user account instead.


HTH,
Christian

On 09/13/2014 06:05 PM, s m h wrote:

   #In The Name of God#
Hi, I have this error while buildig Sage 6.3 Source file 
(sage-6.3.tar.gz). After I have extracted it (using tar -xvf) and 
after I started building sage using 'make', after about 2 hours of 
building process, the following is shown:



make[3]: Entering directory 
`/root/svmh/SAGE/sage-6.3/local/var/tmp/sage/build/pynac-0.3.2/src'

make[3]: *** No targets specified and no makefile found.  Stop.
make[3]: Leaving directory 
`/root/svmh/SAGE/sage-6.3/local/var/tmp/sage/build/pynac-0.3.2/src'

Error building pynac.

real0m1.151s
user0m0.544s
sys0m0.192s

Error installing package pynac-0.3.2

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
  /root/svmh/SAGE/sage-6.3/logs/pkgs/pynac-0.3.2.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/root/svmh/SAGE/sage-6.3/local/var/tmp/sage/build/pynac-0.3.2 and type 
'make' or whatever is appropriate.

Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd '/root/svmh/SAGE/sage-6.3/local/var/tmp/sage/build/pynac-0.3.2' 
&& '/root/svmh/SAGE/sage-6.3/sage' --sh)

When you are done debugging, you can type "exit" to leave the subshell.

make[2]: *** 
[/root/svmh/SAGE/sage-6.3/local/var/lib/sage/installed/pynac-0.3.2] 
Error 1

make[2]: Leaving directory `/root/svmh/SAGE/sage-6.3/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/svmh/SAGE/sage-6.3/build'

real174m32.146s
user151m49.696s
sys10m2.788s
***
Error building Sage.

The following package(s) may have failed to build:

package: pynac-0.3.2
log file: /root/svmh/SAGE/sage-6.3/logs/pkgs/pynac-0.3.2.log
build directory: 
/root/svmh/SAGE/sage-6.3/local/var/tmp/sage/build/pynac-0.3.2


The build directory may contain configuration files and other potentially
helpful information. WARNING: if you now run 'make' again, the build
directory will, by default, be deleted. Set the environment variable
SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

make: *** [build] Error 1
=
Related log file is also attached. MyOS is "kali linux 1.08" and the 
output of 'uname -r' is "3.14-kali1-amd64". Please help me how should 
I solve this problem? Should I debug it and how? Any other useful 
comment would be appreciated.

Yours truly,
S M H

Enter Cookie as format:
(ex: name=val;) separate with ';'

OKCancel
--
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.
For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] not trusted anymore ?

[Christian Nassau]

On 09/12/2013 02:17 PM, Frédéric Chapoton wrote:

Hello,

it seems (the patchbot has told me) that I am not a default trusted 
user. That must be the reason why the patchbot dos not look at my patches.


Hi Frederic,

I doubt you have been blacklisted. My own patchbot "rosinante" is 
currently not running because of 1) connectivity issues (no dsl) and 2) 
Sage issues (ATLAS doesn't compile). Back when it was running it 
occasionally broke on one of your tickets because of UTF-8 characters in 
the ticket title. It might help to remove french accents from titles 
(and possibly other ticket fields) and see if a patchbot then picks up 
your tickets.


Just my 0.02€,
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] atlas tuning

[Christian Nassau]

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 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] atlas tuning

[Christian Nassau]

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 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] atlas tuning

[Christian Nassau]

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 always failed this 
way. Here's my cpuinfo:



processor: 0
vendor_id: AuthenticAMD
cpu family: 16
model: 2
model name: AMD Athlon(tm) 7750 Dual-Core Processor
stepping: 3
microcode: 0x183
cpu MHz: 1350.000
cache size: 512 KB
physical id: 0
siblings: 2
core id: 0
cpu cores: 2
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 5
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl 
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm 
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs 
hw_pstate npt lbrv svm_lock

bogomips: 5411.58
TLB size: 1024 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor: 1
vendor_id: AuthenticAMD
cpu family: 16
model: 2
model name: AMD Athlon(tm) 7750 Dual-Core Processor
stepping: 3
microcode: 0x183
cpu MHz: 1350.000
cache size: 512 KB
physical id: 0
siblings: 2
core id: 1
cpu cores: 2
apicid: 1
initial apicid: 1
fpu: yes
fpu_exception: yes
cpuid level: 5
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl 
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm 
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs 
hw_pstate npt lbrv svm_lock

bogomips: 5411.58
TLB size: 1024 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate



--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] atlas tuning

[Christian Nassau]

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...


I've also got an ATLAS build problem with sage-5.12: it builds on one 
(virtual) machine but not on its host, even though both are running the 
same operating system, OpenSuse 12.3. This also seems to be related to 
tuning issues:


I see "Cannot detect CPU throttling." in the virtual machine's build 
log, where all is fine.


I see this in the failed log:

It appears you have cpu throttling enabled, which makes timings
unreliable and an ATLAS install nonsensical.  Aborting.
See ATLAS/INSTALL.txt for further information
Ignoring CPU throttling by user override!


There are also seemingly more serious statements, like these:
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 cf_algorithm.og
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: 
cannot find rpath-link /waste/cn/sage-5.12.beta0/local/lib: No such 
file or directory

libatlas.a(ATL_SetAtomicCount_mut.o): In function `ATL_SetAtomicCount':
ATL_SetAtomicCount_mut.c:(.text+0x0): multiple definition of 
`ATL_SetAtomicCount'
libatlas.a(ATL_SetAtomicCount_arch.o):ATL_SetAtomicCount_arch.c:(.text+0x0): 
first defined here
libatlas.a(ATL_ResetAtomicCount_mut.o): In function 
`ATL_ResetAtomicCount':
ATL_ResetAtomicCount_mut.c:(.text+0x0): multiple definition of 
`ATL_ResetAtomicCount'

libatlas.a(ATL_ResetAtomicCount_amd64.o):(.text+0x0): first defined here
libatlas.a(ATL_DecAtomicCount_mut.o): In function `ATL_DecAtomicCount':
ATL_DecAtomicCount_mut.c:(.text+0x0): multiple definition of 
`ATL_DecAtomicCount'

libatlas.a(ATL_DecAtomicCount_amd64.o):(.text+0x0): first defined here
libatlas.a(ATL_FreeAtomicCount_mut.o): In function `ATL_FreeAtomicCount':
ATL_FreeAtomicCount_mut.c:(.text+0x0): multiple definition of 
`ATL_FreeAtomicCount'
libatlas.a(ATL_FreeAtomicCount_arch.o):ATL_FreeAtomicCount_arch.c:(.text+0x0): 
first defined here

collect2: error: ld returned 1 exit status


The full build log is at

   http://nullhomotopie.de/sage512build.log.gz

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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Are the patchbots down?

[Christian Nassau]

I've just restarted my patchbot, but I don't know how long it will
remain up since that machine (running OpenSuse 12.3) currently suffers
from pretty regular kernel oopses.

By the way, about half the time the patchbot reports a startup-speed
regression for the core package and refuses to test other tickets. I
wonder if that makes sense? After all, what's the point of reference for
the base package itself?

Cheers,
Christian

Am 28.06.2013 03:24, schrieb Volker Braun:
> Same here, my desktop dropped off the net and will probably have to wait
> until I'm back home.
> 
> 
> On Thursday, June 27, 2013 5:40:48 PM UTC-4, Dima Pasechnik wrote:
> 
> On 2013-06-27, Simon King > wrote:
> > Hi!
> >
> > Is there currently a problem with the patchbots on trac?
> 
> arando patchbot is down, as it is a box in my office, and after work on
> power grid it failed to come back online properly.
> So it's probably will take me to fix it face-to-face, something that's
> not going to happen before 2nd week of August. Sorry.
> 
> Dima
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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

[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.

Re: [sage-devel] Re: Running integral twice breaks pexpect to maxima?

[Christian Nassau]

On 03/01/2013 11:34 AM, Jan Groenewald wrote:
Something is weird there though. The way I see it looking for 
"Principal Value" is commented out.

Sage only looks for [Dd]ivergent.So when maxima gives this:

0 jan@muizenberg:/var/autofs/misc/home/jan$sage --maxima
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/sockets.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/defsystem.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/cmp.fas"
Maxima 5.29.1 http://maxima.sourceforge.net
using Lisp ECL 12.12.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) defint(1/x^3,x,-1,3);
Principal Value
   4
(%o1)  -
   9
Sage should not be finding "Divergent" string and returning divergent 
(but Sage does).


Well in my test the second call to maxima_eval returns the error

   ECL says: Error executing code in Maxima: defint: integral is divergent.

That explains the Sage error message but is also way out of my area of 
expertise...


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.

Re: [sage-devel] Re: Running integral twice breaks pexpect to maxima?

[Christian Nassau]

On 03/01/2013 11:14 AM, Jan Groenewald wrote:

Hi

If you look a few lines before, the if statement is there; so I don't 
think it is that.


You're right, of course... I should go back to sleep.

Sorry for the noise,
C.

--
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] Running integral twice breaks pexpect to maxima?

[Christian Nassau]

Looks like the comment sign in line 738 is the culprit: the code raises 
an unconditional exception since the "if" has been commented out.  If 
true you could just remove the "#", see if it works, create a patch and 
open a ticket for this.


I wonder why it works the first time, though...

Cheers,
Christian

On 03/01/2013 08:39 AM, Jan Groenewald wrote:

Sage 5.7 on Ubuntu 12.04.2

sage: integral(e^(-abs(x))/cosh(x),x,-infinity,infinity)
2*log(2)
sage: integral(e^(-abs(x))/cosh(x),x,-infinity,infinity)
---
ValueErrorTraceback (most recent call 
last)

...

...
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.pyc 
in sr_integral(self, *args)
737 # in pexpect interface, one looks for this - e.g. 
integrate(1/x^3,x,-1,3) gives a principal value

738 #if "divergent" in s or 'Principal Value' in s:
--> 739 raise ValueError, "Integral is divergent."
740 elif "Is" in s: # Maxima asked for a condition
741 j = s.find('Is ')

ValueError: Integral is divergent.
sage:

It runs fine in maxima repeatedly...

0 jan@muizenberg:/var/autofs/misc/home/jan$sage --maxima
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/sockets.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/defsystem.fas"
;;; Loading #P"/usr/lib/sagemath/local/lib/ecl/cmp.fas"
Maxima 5.29.1 http://maxima.sourceforge.net
using Lisp ECL 12.12.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) integral(e^(-abs(x))/cosh(x),x,-infinity,infinity);
  1
(%o1) integral(---, x, - infinity, infinity)
abs(x)
   e   cosh(x)
(%i2)  integral(e^(-abs(x))/cosh(x),x,-infinity,infinity);
  1
(%o2) integral(---, x, - infinity, infinity)
abs(x)
   e   cosh(x)
(%i3)

Regards,
Jan
--
.~.
  /V\ Jan Groenewald
 /( )\ www.aims.ac.za 
 ^^-^^
--
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.




--
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] compilation fails for 5.7 and 5.8.beta0 [SOLVED]

[Christian Nassau]

Not that anybody is likely to be bitten by this problem except me, but 
for completeness sake this is the story: I had written a build-script 
that unpacked the sage tarball and then did this:


   cd //root/of/the/new/sage/release ; make install

This consistently failed: for some strange reason polybori didn't 
install its header files! After a few dozen futile attempts to debug the 
scons build-script I tried this instead:


   cd /root/of/the/new/sage/release ; make install

And this works, of course...

I had already learned earlier (see ticket #14018) that two slashes at 
the beginning of a path can have special meaning, so I suppose I somehow 
deserve the trouble I got...


--
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] compilation fails for 5.7 and 5.8.beta0

[Christian Nassau]

On 02/21/2013 07:38 PM, Christian Nassau wrote:

I've exported MAKE="make -j5" for this build - can this be the/a problem?


Actually all of local/include/polybori was missing, even though 
spkg/installed contained "polybori-0.8.2.p0".


I have now re-installed that package with "sage -f polybori-0.8.2.p0" 
and a "make ssl" seems to run through.


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] compilation fails for 5.7 and 5.8.beta0

[Christian Nassau]

Hi folks,

I can't compile both new releases on my OpenSuse 12.2 machine: these are 
the fatal errors from the install log:



egrep fatal install.log
/waste/cn/sage-5.7/spkg/build/python-2.7.3.p5/src/Modules/_curses_panel.c:17:19: 
fatal error: panel.h: No such file or directory
/waste/cn/sage-5.7/spkg/build/python-2.7.3.p5/src/Modules/_curses_panel.c:17:19: 
fatal error: panel.h: No such file or directory
/waste/cn/sage-5.7/spkg/build/python-2.7.3.p5/src/Modules/_curses_panel.c:17:19: 
fatal error: panel.h: No such file or directory
//waste/cn/sage-5.7/local/include/csage/pb_wrap.h:2:38: fatal error: 
polybori/BoolePolynomial.h: No such file or directory
/waste/cn/sage-5.7/local/include/csage/pb_wrap.h:2:38: fatal error: 
polybori/BoolePolynomial.h: No such file or directory


I've exported MAKE="make -j5" for this build - can this be the/a problem?

The full install.log of the 5.8.beta0 build can be found here:

http://nullhomotopie.de/install.log.gz

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.

Re: [sage-devel] patchbot trouble

[Christian Nassau]

Am 28/01/13 20:00, schrieb Robert Bradshaw:

On Mon, Jan 28, 2013 at 6:58 AM, Christian Nassau
 wrote:

Dear patchbot-technicians,

For the past two days I had a local patchbot running and now it has eaten up
all of the disk space and stopped.

(I admit that there wasn't much space to begin with, just something around
6G.)

As a consequence, most of the failures that were reported on
http://patchbot.sagemath.org/ticket/?machine=openSUSE%20/12.2/x86_64/3.4.11-2.16-desktop/jehova
seem to be system problems: the "log" and "shortlog" files, for example, are
mostly empty. Can somebody remove these reports from the Sage server?

Unfortunately there isn't a good way to remove these except for
editing the database manually...


And since I plan to restart the beast I have a couple of questions:

   - what is the size requirement of a long-running patchbot? (assuming the
size eventually stabilizes)

As Volker says, it's about 100GB (around 300MB/open ticket). No need
to back it up or anything though.


   - what if I hacked my local patchbot to automatically remove the sage
clones after every test, not just the closed tickets. would that be a big
disadvantage? would it even break the patchbot?

No, it just means that you'll have to re-compile the branches each
time a patch is added/updated. If you're running with the latest
patchbot http://trac.sagemath.org/sage_trac/ticket/13950 (needs
review) you can pass the keep_open_branches = false in your
configuration file. Perhaps with a large ccache and cython caching
http://trac.sagemath.org/sage_trac/ticket/13031 this would be
mittigated enough to not need that at all (though cloning still takes
a while). Eventually, with git, this is the direction to move.

- Robert


Thanks to both of you for your feedback!

I have now restarted the patchbot (from #13950) on a folder with about 
230G space available.


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] patchbot trouble

[Christian Nassau]

Dear patchbot-technicians,

For the past two days I had a local patchbot running and now it has 
eaten up all of the disk space and stopped.


(I admit that there wasn't much space to begin with, just something 
around 6G.)


As a consequence, most of the failures that were reported on
http://patchbot.sagemath.org/ticket/?machine=openSUSE%20/12.2/x86_64/3.4.11-2.16-desktop/jehova
seem to be system problems: the "log" and "shortlog" files, for example, 
are mostly empty. Can somebody remove these reports from the Sage server?


And since I plan to restart the beast I have a couple of questions:

  - what is the size requirement of a long-running patchbot? (assuming 
the size eventually stabilizes)


  - what if I hacked my local patchbot to automatically remove the sage 
clones after every test, not just the closed tickets. would that be a 
big disadvantage? would it even break the patchbot?


Cheers,
Christian


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@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: category subclassing problem

[Christian Nassau]

Hi Simon,

Thanks for this little expose - I'm just beginning to warm up to the
category framework so this is very helpful.

Cheers,
Christian

--
http://www.nullhomotopie.de

-- 
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...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] category subclassing problem

[Christian Nassau]

Hi Nicolas,

Thanks a lot for these hints! I need to implement a category of 
multi-graded modules/algebras over a Hopf algebra (the Steenrod algebra, 
specifically), so I thought subclassing AlgebrasWithBasis would be a 
good idea... I've now followed your example instead, and it all seems to 
work.


(I did notice that there already is a category for graded modules, but 
it seems to be largely empty. I suppose that framework is still in the 
making.)


Cheers,
Christian

On 05/21/2011 06:43 PM, Nicolas M. Thiery wrote:

Hi Christian,

On Fri, May 20, 2011 at 10:10:37AM +0200, Christian Nassau wrote:

I would like to create a new category that's derived from
AlgebrasWithBasis, but I get an infinite recursion when I ask for the
CartesianProducts:

Here's a simple example:

class MyAlgebrasWithBasis(AlgebrasWithBasis):
   def __init__(self,R):
 AlgebrasWithBasis.__init__(self,R)


Is your intention to create a subcategory of AlgebrasWithBasis? That
is a category whose objects are algebras with basis, possibly endowed
with more structure? If yes, the idiom is:


 class AlgebrasWithBasis(Category_over_base_ring):

@cached_method
def super_categories(self):
return [AlgebrasWithBasis(self.base_ring())]

...

Otherwise, please describe precisely your use case to see what we
should do with it (fix the issue, raise a better warning, ...). Note
that at this point, the hierarchy of classes for categories is
basically flat:

 Category
  - Sets
  - Semigroups
  - Fields
  - ...
  - Category_over_base_ring
- Modules
- Algebras
- ...

Best,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/



--
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...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] category subclassing problem

[Christian Nassau]

I would like to create a new category that's derived from
AlgebrasWithBasis, but I get an infinite recursion when I ask for the
CartesianProducts:

Here's a simple example:

   class MyAlgebrasWithBasis(AlgebrasWithBasis):
  def __init__(self,R):
AlgebrasWithBasis.__init__(self,R)

Now this works:

   print AlgebrasWithBasis(GF(5)).CartesianProducts
   

but this doesn't:

   print MyAlgebrasWithBasis(GF(5)).CartesianProducts
   RuntimeError: maximum recursion depth exceeded

Curiously, it works for the DualObjects:

   print MyAlgebrasWithBasis(GF(5)).DualObjects
   

I think this is a problem with CovariantConstructionCategory.__classget__
but I have no idea how to fix this. (I'm using Sage 4.7.rc1 here.) Is
there a workaround I could use?

Cheers,
Christian

--
http://www.nullhomotopie.de

-- 
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...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: typo in patch of ticket #6396: primes_of_degree_one is broken for relative extensions

[Christian Nassau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob Beezer wrote:
> On Aug 23, 4:15 am, John Cremona  wrote:
>> Now gmail
>> automatically hides quoted text, replacing it by a tiny link "show
>> quoted text".  
> 
> [...] to toggle it on and back off again.  I find the email versions of the
> posts extremely hard to follow though when viewed in an email client
> (Thunderbird in my case).

For thunderbird there is a convenient add-on "quote-collapse" that will
hide all quotes per default:

   https://addons.mozilla.org/en-US/thunderbird/addon/347

Actually, I only installed it after subscribing to sage-devel, on
account of the excessive quoting that's going on here... ;-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkqRlcgACgkQQRLeu79NGBPfcwCeKQbM2VUf6lPZDHWcbCFEErMb
79UAnRNicKkgvWzyebKbnIjjyMsoW6aq
=o7QZ
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---