[sage-devel] Re: Error building Sage

[Quentin Hillebrand]

Thank you very much, it's working perfectly.

And I am the one who's sorry for not asking in English in the first place.

Le jeudi 28 février 2019 07:02:49 UTC+9, John H Palmieri a écrit :
>
> Please try this:
>
> ./sage -f zlib
> ./sage -f python2 python3
> make
>
> and see if that fixes the problem. (Apologies for not responding in 
> French.)
>
>
>
> On Wednesday, February 27, 2019 at 1:52:02 PM UTC-8, Quentin Hillebrand 
> wrote:
>>
>> En compilant avec make j'obtiens j'obtiens une erreure lors de la 
>> construction de pip-18.0.
>>
>> Je suis sur un MacBook Pro avec macOS Mojave Version 10.14.3.
>>
>> Merci d'avance de votre attention
>>
>

-- 
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: Proposal: Add ascii_art representation to factor

[Travis Scrimshaw]

And to have this behavior, you simply need to implement the methods 
_ascii_art_ and _unicode_art_ respectively. For a simple _ascii_art_, see 
combinat/shuffle.py. Maybe combinat/plane_partition.py is another decent 
example, but there are a bunch of examples in the combinat folder.

Best,
Travis


On Thursday, February 28, 2019 at 3:46:21 AM UTC+10, vdelecroix wrote:
>
> ascii_art and unicode_art are distinct functions. 
>
> Le 27/02/2019 à 16:02, Juan Nicolas Pardo Martin a écrit : 
> > I was thinking about that too, however you only do so in environments 
> where is supported or make a parameter to ascii_art allow Unicode or an 
> entirely new method 
> > 
> > From: Volker Braun 
> > Sent: Wednesday, 27 February 2019 00:39 
> > To: sage-devel 
> > Subject: [sage-devel] Re: Proposal: Add ascii_art representation to 
> factor 
> > 
> > Unicode has superscripts btw, would be neat to make use of that: 
> > x⁴⁵⁶⁷⁸⁹ 
> > 
> > 16 = 2⁴ 
> > 
>

-- 
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] Re: Inequalities in Z/nZ

[John H Palmieri]

On Wednesday, February 27, 2019 at 3:14:53 PM UTC-8, Nils Bruin wrote:
>
> On Wednesday, February 27, 2019 at 2:17:06 PM UTC-8, John H Palmieri wrote:
>>
>> Why does Sage allow inequalities in Z/nZ?
>>
>
> I'm pretty sure that it's a historical artifact from Python 2, where 
> inequality relations exist between nearly all objects, because "cmp" is 
> 3-valued. None of the usual axioms are required or enforced. It had a nice 
> consequence that "sort" would work on almost every list; possibly with 
> deterministic results.
>
> Python 3 remedied this horrible wart in Python 2, setting a nice example 
> for sage to move away from having mathematically unmotivated inequalities.
> With "cmp" stamped out, and the only mechanism for implementing relations 
> being "richcmp", where "==" and "<" use different code paths, we can reopen 
> https://trac.sagemath.org/ticket/3936 and fix this stuff (gradually). Yay!
>

Okay, I thought it came from the Python 2 philosophy. It would be nice to 
change this. See 
https://stackoverflow.com/questions/54894845/how-to-fix-an-error-with-function-mod-in-sagemath
 
for a case with < in Z/nZ which confused at least one user.

-- 
John

-- 
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] Re: Inequalities in Z/nZ

[Nils Bruin]

On Wednesday, February 27, 2019 at 2:17:06 PM UTC-8, John H Palmieri wrote:
>
> Why does Sage allow inequalities in Z/nZ?
>

I'm pretty sure that it's a historical artifact from Python 2, where 
inequality relations exist between nearly all objects, because "cmp" is 
3-valued. None of the usual axioms are required or enforced. It had a nice 
consequence that "sort" would work on almost every list; possibly with 
deterministic results.

Python 3 remedied this horrible wart in Python 2, setting a nice example 
for sage to move away from having mathematically unmotivated inequalities.
With "cmp" stamped out, and the only mechanism for implementing relations 
being "richcmp", where "==" and "<" use different code paths, we can reopen 
https://trac.sagemath.org/ticket/3936 and fix this stuff (gradually). Yay!

-- 
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] Inequalities in Z/nZ

[John H Palmieri]

Why does Sage allow inequalities in Z/nZ?

sage: Z3 = Integers(3)
sage: a = Z3(4)
sage: b = Z3(2)
sage: a < b
True
sage: a < 3
False

While < may make sense in the set {0, 1, 2, ..., n-1}, it doesn't make 
sense in the ring Z/nZ:

sage: Z3(1) < Z3(2)
True
sage: 1+Z3(1) < 1+Z3(2)
False
sage: 2*Z3(1) < 2*Z3(2)
False

Is this current inequality checking actually useful for anything? Should it 
be removed?

-- 
John

-- 
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] Re: Error building Sage

[John H Palmieri]

Please try this:

./sage -f zlib
./sage -f python2 python3
make

and see if that fixes the problem. (Apologies for not responding in French.)



On Wednesday, February 27, 2019 at 1:52:02 PM UTC-8, Quentin Hillebrand 
wrote:
>
> En compilant avec make j'obtiens j'obtiens une erreure lors de la 
> construction de pip-18.0.
>
> Je suis sur un MacBook Pro avec macOS Mojave Version 10.14.3.
>
> Merci d'avance de votre attention
>

-- 
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] Error building Sage

[Quentin Hillebrand]

En compilant avec make j'obtiens j'obtiens une erreure lors de la 
construction de pip-18.0.

Je suis sur un MacBook Pro avec macOS Mojave Version 10.14.3.

Merci d'avance de votre attention

-- 
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.
Found local metadata for pip-18.0
Using cached file 
/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/upstream/pip-18.0.tar.gz
pip-18.0

Setting up build directory for pip-18.0
Finished extraction
No patch files found in ../patches

Host system:
Darwin MacBook-Pro-de-Quentin.local 18.2.0 Darwin Kernel Version 18.2.0: Thu 
Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

No record that 'pip' was ever installed; skipping uninstall
Traceback (most recent call last):
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/lib/python3.6/runpy.py",
 line 193, in _run_module_as_main
"__main__", mod_spec)
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/lib/python3.6/runpy.py",
 line 85, in _run_code
exec(code, run_globals)
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0/src/src/pip/__main__.py",
 line 16, in 
from pip._internal import main as _main  # isort:skip # noqa
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0/src/src/pip/_internal/__init__.py",
 line 20, in 
from pip._vendor.urllib3.exceptions import DependencyWarning
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0/src/src/pip/_vendor/urllib3/__init__.py",
 line 8, in 
from .connectionpool import (
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0/src/src/pip/_vendor/urllib3/connectionpool.py",
 line 36, in 
from .response import HTTPResponse
  File 
"/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0/src/src/pip/_vendor/urllib3/response.py",
 line 3, in 
import zlib
ModuleNotFoundError: No module named 'zlib'

Error building / installing pip3


real0m0.218s
user0m0.152s
sys 0m0.054s

Error installing package pip-18.0

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the log file
  /Users/quentin/Documents/M1/Projet_Integre/sage-8.6/logs/pkgs/pip-18.0.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0
 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 
'/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/local/var/tmp/sage/build/pip-18.0'
 && '/Users/quentin/Documents/M1/Projet_Integre/sage-8.6/sage' --sh)
When you are done debugging, you can type "exit" to leave the subshell.

[sage-devel] Re: Should valgrind work when running doctests?

[Steven Trogdon]

I believe 

./sage -t --long --valgrind "doctest"

is broken. Please see https://trac.sagemath.org/ticket/27381 for a fix.

On Monday, February 25, 2019 at 10:36:47 PM UTC-6, Steven Trogdon wrote:
>
> Running ./sage --valgrind works with a resulting sage prompt. However,
>
> ./sage -t --long --valgrind src/sage/combinat/tableau.py
>
> does not work. The ~/.sage/valgrind/sage-memcheck. file reads
>
> ==8525== Memcheck, a memory error detector
> ==8525== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==8525== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==8525== Command: python 
> /64bitdev/storage/sage-git_develop/sage/local/bin/sage-runtests --serial 
> --long --timeout=172800 --memlimit=3300 
> --stats_path=/home/volj/27/strogdon/.sage/timings2.json 
> --optional=dochtml,memlimit,mpir,python2,sage src/sage/combinat/tableau.py
> ==8525== Parent PID: 8495
> ==8525==
> ==8525== FATAL: can't open suppressions file 
> "/64bitdev/storage/sage-git_develop/sage/local/lib/valgrind/sage.supp"
>
> So, the *.supp files which. I believe,  are under 
> local/share/sage/ext/valgrind/ cannot be found.
>

-- 
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: Proposal: Add ascii_art representation to factor

[Vincent Delecroix]

ascii_art and unicode_art are distinct functions.

Le 27/02/2019 à 16:02, Juan Nicolas Pardo Martin a écrit :

I was thinking about that too, however you only do so in environments where is 
supported or make a parameter to ascii_art allow Unicode or an entirely new 
method

From: Volker Braun
Sent: Wednesday, 27 February 2019 00:39
To: sage-devel
Subject: [sage-devel] Re: Proposal: Add ascii_art representation to factor

Unicode has superscripts btw, would be neat to make use of that:
x⁴⁵⁶⁷⁸⁹

16 = 2⁴



--
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: python3 status report

[John Cremona]

On Sun, 27 Jan 2019, 13:39 Vincent Delecroix, <20100.delecr...@gmail.com>
wrote:

> Le 27/01/2019 à 14:32, Simon King a écrit :
> > Hi Frédéric,
> >
> > On 2019-01-27, Frédéric Chapoton  wrote:
> >> (2) the most badly failing file is "explain_pickle" with 70 failing
> >> doctests. Hopefully, this will be treated very carefully by Erik M. Bray
> >>
> >> (3) after that, we still have problems with graph, where
> generic_graph.py
> >> has 50 failing doctests. But good progress was made by David Coudert,
> >
> > Is there an apparent common reason for most of these failing tests? Such
> > as code that makes assumptions on sorting (which, IIRC, is different in
> > Python 2 and Python 3)?
> >
> >> *STATEMENT *: I would to advocate that **every developer switch to
> python3
> >> NOW**.
> >
> > How?
> >
> > To make my question more precise: For production I would like to
> > keep a python 2 installation of Sage. So, given my existing Sage
> > installation, what would be the easiest way to create a second
> > installation with python 3 that is automatically configured to work
> > well with "git trac"? I guess it is some kind of git clone. Also I
> > don't know what make target is needed.
>
> You need a different clone of your git repo, let say sage-py3. In that
> clone, do
>
>  $ make configure
>  $ ./configure --with-python=3
>
> Then, unless you rerun configure, every call to make will take care
> of the Python 3 switch automatically.
>

Not quite: doing make distclean will take you back to the python2 default
and you'll need to run configure again.  This just happened to me. (I have
a bad habit of doing make distclean; make whenever anything mysterious
happens).



> See also https://wiki.sagemath.org/Python3-compatible%20code
>
> 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.
>

-- 
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: Scalar field on manifold not completely initialized?

[Richard_L]

+1 for "_SAGE_FUNC". The user should not have to think about the Maxima 
pre-defined name space unless s/he wants to use a Maxima function:

"When I use a word, it means what I choose it to mean, neither more nor 
less."
 -- Humpty-Dumpty 

On Tuesday, February 26, 2019 at 10:33:23 AM UTC-8, Nils Bruin wrote:
>
>
>
>
> It's actually very easy: Just as we prefix the print name of a variable 
> with "_SAGE_VAR_" before feeding it to Maxima in textual form, we can 
> prefix user-defined functions with, say, "_SAGE_FUNC_" by default. For 
> functions that should be translated into a meaningful name in maxima we 
> should of course do that, and we already have infrastructure for that. We 
> could easily tweak the standard translation to do a little more to avoid 
> name clashes.
>
> An argument against it is that error messages emanating from maxima are 
> almost indecipherable because of the name mangling. However, that already 
> happens now with the variable names. I don't think doing the same thing 
> with function names is going to make things that much worse.
>
> TIcket #13071 is a different issue, by the way. The issue still does exist 
> and possible fixes are outlined on the ticket.
>  
>

-- 
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] Re: .an_element() != 0?

[Kwankyu Lee]

On Wednesday, February 27, 2019 at 11:25:38 PM UTC+9, Daniel Krenn wrote:
>
> Can I savely assume that S.an_element() of something S (within SageMath) 
> returns an element different from S.zero() if possible (meaning if there 
> are nonzero elements in S)? 
>

The purpose of S.an_element() is to get an element whose parent is S -- 
zero is completely legitimate.  

-- 
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: Proposal: Add ascii_art representation to factor

[Juan Nicolas Pardo Martin]

I was thinking about that too, however you only do so in environments where is 
supported or make a parameter to ascii_art allow Unicode or an entirely new 
method 

From: Volker Braun
Sent: Wednesday, 27 February 2019 00:39
To: sage-devel
Subject: [sage-devel] Re: Proposal: Add ascii_art representation to factor

Unicode has superscripts btw, would be neat to make use of that:
x⁴⁵⁶⁷⁸⁹

16 = 2⁴
-- 
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.

-- 
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] .an_element() != 0?

[Vincent Delecroix]

Le 27/02/2019 à 15:29, Jeroen Demeyer a écrit :

On 2019-02-27 15:25, Daniel Krenn wrote:

Can I savely assume that S.an_element() of something S (within SageMath)
returns an element different from S.zero() if possible (meaning if there
are nonzero elements in S)?


Personally, I wouldn't assume anything.



Neither do I. The specification of an_element is supposed to be:

  Return an element if the parent is not empty and raises an
  EmptySetError otherwise

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] .an_element() != 0?

[Jeroen Demeyer]

On 2019-02-27 15:25, Daniel Krenn wrote:

Can I savely assume that S.an_element() of something S (within SageMath)
returns an element different from S.zero() if possible (meaning if there
are nonzero elements in S)?


Personally, I wouldn't assume anything.

--
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] .an_element() != 0?

[Daniel Krenn]

Can I savely assume that S.an_element() of something S (within SageMath)
returns an element different from S.zero() if possible (meaning if there
are nonzero elements in S)?

-- 
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] Re: `ModuleElement` is forced though `Element` should be enough by the category framework

[Kwankyu Lee]

>
>
> In particular, Jeroen, concerning the strange rule that _lmul_ not being 
> implemented means that it returns None: I seem to recall (but I am not 
> 100% sure) that P._get_action_(Q) (or some other method name, I don't 
> recall) could test what happens if P.zero()._lmul_(Q.zero()) or similar 
> things are doing, and depending on the result would conclude that an 
> action does not exist or does exist, for general elements of P and Q. 
>

You seem to refer to this part of the code of `detect_element_action(...)`: 

cdef Element x
if X_el is None or (parent(X_el) is not X):
x = an_element(X)
else:
x = X_el
if x is None:
raise RuntimeError("an_element() for %s returned None" % X)
if Y_el is None or (parent(Y_el) is not Y):
y = an_element(Y)
else:
y = Y_el
if y is None:
if isinstance(Y, Parent):
raise RuntimeError("an_element() for %s returned None" % Y)
else:
return # don't know how to make elements of this type...
if isinstance(x, ModuleElement) and isinstance(y, Element):
# Elements defining _lmul_ and _rmul_
try:
return (RightModuleAction if X_on_left else LeftModuleAction)(Y, 
X, y, x)
except CoercionException as msg:
_record_exception()   


>

-- 
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] `ModuleElement` is forced though `Element` should be enough by the category framework

[Kwankyu Lee]

On Wednesday, February 27, 2019 at 3:26:08 PM UTC+9, Jeroen Demeyer wrote:
>
> On 2019-02-26 23:44, Kwankyu Lee wrote: 
> > It could be possible to hammer the coercion model to behave more nicely 
> > with the category framework, at least with respect to the issue that I 
> > raised. 
>
> By the way, why is it an issue in the first place? Is there any reason 
> why you don't want to inherit from ModuleElement? 
>

No. I was just annoyed several times by my failed attempts to implement 
scalar multiplication using Element. 

-- 
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] Re: Proposal: Add ascii_art representation to factor

[Samuel Lelievre]

Nice suggestion! Now tracked at #27377:

- Sage Trac ticket 27377
  Provide ascii_art and unicode_art for factorizations
  https://trac.sagemath.org/ticket/27377

-- 
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] Note on libpflll during Sage 8.6 install

[Dima Pasechnik]

On Tue, Feb 26, 2019 at 2:36 PM E. Madison Bray  wrote:
>
> On Mon, Feb 11, 2019 at 6:07 PM Randall  wrote:
> >
> > A couple of comments relating to my attempts to build Sage 8.6 on openSuse 
> > Leap 15.0 system. (64 bit Intel Core X980s)
> >
> > 1. The fplll build failed due to non-shareable segments in the libqd file, 
> > but I had to reinstall the libqd and libqd development files using yast2. 
> > It is standard policy of openSuse to NOT include the development headers 
> > even when the program might be installed. I have no idea where the previous 
> > libqd came from but after reinstalling it, the Sage 8.6 make was able to 
> > successfully build fplll and move on.
> >
> > 2. During build of linuxbox, during the config check, I noticed that the 
> > script complained about tinyxml2 missing. Sure enough, I checked in yast2 
> > and it had not been installed. What Sage needs is for all the prerequisite 
> > libraries and compilers and linkers to be collated together, as a 
> > pre-compile script checking for these dependencies can be done, and then 
> > installed, before attempting to do the actual Sage x.y install. I realize 
> > that this is a big task, but surely looking through all the build logs 
> > might give some idea of what external libraries are needed.
>
> Hi Randall,
>
> Thank you for the report.  Unfortunately I don't really understand
> either of your points (which may be why no one responded before now
> either).  If you feel there is a bug somewhere please report it here
> or as a Trac ticket.
>
> Regarding linbox (which I think is what you meant by "linuxbox") the
> optional use of tinyxml2 appears to just be for compiling some
> benchmark tests that are not used at runtime, so it's acceptable for
> it to not be found.
>
https://repology.org/project/sagemath/versions
does not list openSuse

Thus I read this as a report on building from source, and the remark about libqd
as a remark about libgd, which conflicts with a system-provided libgd.
(I've just added libgd to the list on #27330).

I agree that building from source instructions should be improved.
Ideally, please open a trac ticket and post your documentation fix
there.

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

Re: [sage-devel] flushing stdout during doctests

[John Cremona]

On Wed, 27 Feb 2019 at 09:16, Jeroen Demeyer  wrote:

> On 2019-02-26 17:52, John Cremona wrote:
> > I am testing a new version of the standard spkg eclib, see
> > https://trac.sagemath.org/ticket/27360.  I am getting doctesting
> > failures caused *only* because of changes in output buffering resulting
> > in the tail end of the output of one command appearing at the beginning
> > of the output of the next.
>
> Since this is I/O related, it might make a difference if you redirect
> stdout and/or stderr to a file. For example, doing
>
> ./sage -t somefile.py 2>err.log
>
> instead of
>
> ./sage -t somefile.py
>
> Do you happen to have the *exact* command line that you used to run tests?
>

I did

./sage -t src/sage/libs/eclib

from the SAGE_ROOT directory.  No redirection.

I note that the file mwrank.pyx in that directory has in a few places in
the code the lines
   if verb:
sys.stdout.flush()
sys.stderr.flush()

which looks like dealing with the same issue (since there will have been
side-effect output iff verb)

I'll be uploading a branch to review very soon.  There were a few small
changes resulting from the default precision changing from 50 digits to 150
bits.  (I know that 166 bits is closer.)  There is some stupidity here, as
noted in comments, since in some cases a value is computed in eclib to
higher precision but is converted to a float later.  I don't think this
happens anywhere that matters:  no code or doctest changes were required
outside sage/libs/eclib.



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

-- 
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] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

[Simon Brandhorst]

This is now 
#27374 

On Wednesday, February 27, 2019 at 9:53:35 AM UTC+1, Simon Brandhorst wrote:
>
> -
> SystemError Traceback (most recent call last)
>  in ()
> > 1 classify_ord_pe(L,Integer(2),Integer(2),"results/order4.txt","w")
>
> /home/simon/.sage/temp/k3/8598/K3_aut_classification.sageqIg9CK.py in 
> classify_ord_pe(L, p, e, file_name, rw)
> 252 print(" ")
> 253 cofix = cofixed[k].twist(-_sage_const_1 )
> --> 254 for Aa in k3_prime_power(fix.genus(), p, e):
> 255 A, a, Oa = Aa
> 256 actsg = MaximalK3surfaceAut(A, cofix, a, Oa)
>
> /home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
> k3_prime_power(genus, prime, e)
> 138 signatures += [[ranks_E[k]]*(weights[k]//_sage_const_2 
> ) for k in range(_sage_const_1 ,n)]
> 139 signatures[-_sage_const_1 ][_sage_const_0 ] -= 
> _sage_const_1
> --> 140 for act in 
> prime_power_actions(genus,prime,ranks,signatures):
> 141 yield act
> 142 
>
> /home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
> prime_power_actions(genus, p, ranks, signatures)
> 276 # recurse
> 277 # print(R)
> --> 278 for N in prime_power_actions(R, p, 
> ranks[:-_sage_const_1 ], R_signatures):
> 279 N, fN, GN = N
> 280 ext = extensions(M, fM, N, fN, GM, GN, 
> glue_order, p)
>
> /home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
> prime_power_actions(genus, p, ranks, signatures)
> 240 if G.is_even() and not M.is_even():
> 241 continue
> --> 242 GM = Oq_equiv(M, fM, p**e)
> 243 DM = M.discriminant_group()
> 244 M_max_glue_group = (M.span((fM**(p**(e-_sage_const_1 
> )) - fM**_sage_const_0 ).inverse())
>
> /home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in Oq_equiv(M, 
> fM, order)
> 514 """
> 515 if order==_sage_const_1  or order==_sage_const_2 :
> --> 516 return M.image_in_Oq()
> 517 elif prod(M.signature_pair()) == _sage_const_0 :
> 518 #
>
> This looks like a bug to me but I am not enough of an expert to decide.
> /home/simon/sage/local/lib/python2.7/site-packages/sage/modules/free_quadratic_module_integer_symmetric.pyc
>  
> in image_in_Oq(self)
>1443 generated by 5 elements
>1444 """
> -> 1445 Oq = self.discriminant_group().orthogonal_group()
>1446 sig = self.signature_pair()
>1447 if sig[0]*sig[1]==0 or self.rank()==2:
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/misc/cachefunc.pyx 
> in sage.misc.cachefunc.CachedMethodCaller.__call__ 
> (build/cythonized/sage/misc/cachefunc.c:10232)()
>1948 return cache[k]
>1949 except KeyError:
> -> 1950 w = self._instance_call(*args, **kwds)
>1951 cache[k] = w
>1952 return w
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/misc/cachefunc.pyx 
> in sage.misc.cachefunc.CachedMethodCaller._instance_call 
> (build/cythonized/sage/misc/cachefunc.c:9717)()
>1824 True
>1825 """
> -> 1826 return self.f(self._instance, *args, **kwds)
>1827 
>1828 cdef fix_args_kwds(self, tuple args, dict kwds):
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/modules/torsion_quadratic_module.pyc
>  
> in orthogonal_group(self, gens, check)
>1196 gens = [matrix(g) for g in _isom_fqf(self)]
>1197 ambient = AbelianGroupGap(self.invariants()).aut()
> -> 1198 gens = [ambient(g) for g in gens]
>1199 gens = tuple(g for g in gens if g != ambient.one())
>1200 return FqfOrthogonalGroup(ambient, gens, self, check=check)
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/structure/parent.pyx 
> in sage.structure.parent.Parent.__call__ 
> (build/cythonized/sage/structure/parent.c:9171)()
> 897 if mor is not None:
> 898 if no_extra_args:
> --> 899 return mor._call_(x)
> 900 else:
> 901 return mor._call_with_args(x, args, kwds)
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.pyx
>  
> in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ 
> (build/cythonized/sage/structure/coerce_maps.c:4547)()
> 160 print(type(C), C)
> 161 print(type(C._element_constructor), 
> C._element_constructor)
> --> 162 raise
> 163 
> 164 cpdef Element _call_with_args(self, x, args=(), kwds={}):
>
> /home/simon/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.pyx
>  
> in 

Re: [sage-devel] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

[Jeroen Demeyer]

On 2019-02-27 10:31, Simon Brandhorst wrote:

Okay. But I cannot reproduce the error consistently. Post anyways?


Yes. The traceback is clear enough.

--
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] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

[Simon Brandhorst]

Okay. But I cannot reproduce the error consistently. Post anyways?

-- 
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] flushing stdout during doctests

[Jeroen Demeyer]

On 2019-02-26 17:52, John Cremona wrote:

I am testing a new version of the standard spkg eclib, see
https://trac.sagemath.org/ticket/27360.  I am getting doctesting
failures caused *only* because of changes in output buffering resulting
in the tail end of the output of one command appearing at the beginning
of the output of the next.


Since this is I/O related, it might make a difference if you redirect 
stdout and/or stderr to a file. For example, doing


./sage -t somefile.py 2>err.log

instead of

./sage -t somefile.py

Do you happen to have the *exact* command line that you used to run tests?

--
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: flushing stdout during doctests

[Jeroen Demeyer]

On 2019-02-27 09:58, John Cremona wrote:

The problem went away after I did "make distclean; make build".

Originally what I did after checking out a new branch was
(1) put the new tarball into upstream/
(2) edit the file build/pkgs/eclib/package-version.txt
(3) issue the magic command which updates the checksum
(4) ./sage -i eclib [causes the new eclib to be built OK]
(5) make build  [rebuilds some cython files which depend on eclib]
(6) run tests

Surely that should work, so whatever is deciding what needs doing in
step (5) is possibly not getting it quite right.


First of all, yes that should work. Technically, you don't even need 
step (4) since the build system will detect that the version changed of 
eclib.


However, I would be quite surprised if build issues would affect the 
buffering of the output.


--
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] flushing stdout during doctests

[John Cremona]

On Wed, 27 Feb 2019 at 08:56, Jeroen Demeyer  wrote:

> On 2019-02-26 17:52, John Cremona wrote:
> > I am testing a new version of the standard spkg eclib, see
> > https://trac.sagemath.org/ticket/27360.  I am getting doctesting
> > failures caused *only* because of changes in output buffering resulting
> > in the tail end of the output of one command appearing at the beginning
> > of the output of the next.
>
> It would be helpful if you could post the branch that you tried on Trac
> such that others can reproduce this.
>

Sorry, I just saw this request after sending just now.  Since the problem
went away after a rebuild I don't think that would help.

I am now working on adapting the doctests, several of which need rather
trivial changes due to the different precision handling.

John


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

-- 
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: flushing stdout during doctests

[Jeroen Demeyer]

On 2019-02-27 08:35, Frédéric Chapoton wrote:

This problem is also seen in the python3 patchbot report, as can be
found here :

https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-141-generic/atlas/2019-02-24%2011:31:45?short


In Python 3, the situation is different because Python implements its 
own buffering for I/O. In contrast, Python 2 relies on the I/O 
implementation of the C library.


--
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: flushing stdout during doctests

[John Cremona]

The problem went away after I did "make distclean; make build".

Originally what I did after checking out a new branch was
(1) put the new tarball into upstream/
(2) edit the file build/pkgs/eclib/package-version.txt
(3) issue the magic command which updates the checksum
(4) ./sage -i eclib [causes the new eclib to be built OK]
(5) make build  [rebuilds some cython files which depend on eclib]
(6) run tests

Surely that should work, so whatever is deciding what needs doing in step
(5) is possibly not getting it quite right.

John

On Wed, 27 Feb 2019 at 07:35, Frédéric Chapoton 
wrote:

> This problem is also seen in the python3 patchbot report, as can be found
> here :
>
>
> https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-141-generic/atlas/2019-02-24%2011:31:45?short
>
> Frederic
>
> Le mardi 26 février 2019 17:52:39 UTC+1, John Cremona a écrit :
>>
>> I am testing a new version of the standard spkg eclib, see
>> https://trac.sagemath.org/ticket/27360.  I am getting doctesting
>> failures caused *only* because of changes in output buffering resulting in
>> the tail end of the output of one command appearing at the beginning of the
>> output of the next.  For example if you do
>>
>> sage: E = mwrank_EllipticCurve([0,0,1,-7,6])
>> sage: EQ = mwrank_MordellWeil(E)
>> sage: EQ.search(2)
>>
>> as in src/sage/libs/eclib/interface.py near the end, then the last of
>> those commands causes eclib (which is a C++ library) to output some
>> progress to stdout.  In that files there are several examples of that sort,
>> causing output to stdout as a side-effect.  In 8.7.beta5 (and all previous
>> versions including many previous versions of eclib) all is well, but after
>> building the new eclib version (which makes no relevant changes whatsoever)
>> I find that half of the last line of the side-effect output is not being
>> sent to the output stream until the next doctest is run, with the result
>> that both test fail since the output is not what was expected.
>>
>> I based my working branch on 8.7.beta5 which works fine.  I tried adding
>> some sys.stdout.flush() commands in the code and/or the doctests but it
>> makes no difference -- presumably eclib's stdout is not the same channel as
>> python's.
>>
>> Any suggestions other than "you must have made some change in eclib which
>> caused this"?  Since I didn't!?
>>
>> John
>>
>>
>> --
> 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.
>

-- 
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] flushing stdout during doctests

[Jeroen Demeyer]

On 2019-02-26 17:52, John Cremona wrote:

I am testing a new version of the standard spkg eclib, see
https://trac.sagemath.org/ticket/27360.  I am getting doctesting
failures caused *only* because of changes in output buffering resulting
in the tail end of the output of one command appearing at the beginning
of the output of the next.


It would be helpful if you could post the branch that you tried on Trac 
such that others can reproduce this.


--
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] During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

[Jeroen Demeyer]

Please create a Trac ticket for this.

--
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] During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

[Simon Brandhorst]

-
SystemError Traceback (most recent call last)
 in ()
> 1 classify_ord_pe(L,Integer(2),Integer(2),"results/order4.txt","w")

/home/simon/.sage/temp/k3/8598/K3_aut_classification.sageqIg9CK.py in 
classify_ord_pe(L, p, e, file_name, rw)
252 print(" ")
253 cofix = cofixed[k].twist(-_sage_const_1 )
--> 254 for Aa in k3_prime_power(fix.genus(), p, e):
255 A, a, Oa = Aa
256 actsg = MaximalK3surfaceAut(A, cofix, a, Oa)

/home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
k3_prime_power(genus, prime, e)
138 signatures += [[ranks_E[k]]*(weights[k]//_sage_const_2 
) for k in range(_sage_const_1 ,n)]
139 signatures[-_sage_const_1 ][_sage_const_0 ] -= _sage_const_1
--> 140 for act in 
prime_power_actions(genus,prime,ranks,signatures):
141 yield act
142 

/home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
prime_power_actions(genus, p, ranks, signatures)
276 # recurse
277 # print(R)
--> 278 for N in prime_power_actions(R, p, 
ranks[:-_sage_const_1 ], R_signatures):
279 N, fN, GN = N
280 ext = extensions(M, fM, N, fN, GM, GN, 
glue_order, p)

/home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in 
prime_power_actions(genus, p, ranks, signatures)
240 if G.is_even() and not M.is_even():
241 continue
--> 242 GM = Oq_equiv(M, fM, p**e)
243 DM = M.discriminant_group()
244 M_max_glue_group = (M.span((fM**(p**(e-_sage_const_1 )) 
- fM**_sage_const_0 ).inverse())

/home/simon/.sage/temp/k3/8598/prime_power.sage5OzLUx.py in Oq_equiv(M, fM, 
order)
514 """
515 if order==_sage_const_1  or order==_sage_const_2 :
--> 516 return M.image_in_Oq()
517 elif prod(M.signature_pair()) == _sage_const_0 :
518 #

This looks like a bug to me but I am not enough of an expert to decide.
/home/simon/sage/local/lib/python2.7/site-packages/sage/modules/free_quadratic_module_integer_symmetric.pyc
 
in image_in_Oq(self)
   1443 generated by 5 elements
   1444 """
-> 1445 Oq = self.discriminant_group().orthogonal_group()
   1446 sig = self.signature_pair()
   1447 if sig[0]*sig[1]==0 or self.rank()==2:

/home/simon/sage/local/lib/python2.7/site-packages/sage/misc/cachefunc.pyx 
in sage.misc.cachefunc.CachedMethodCaller.__call__ 
(build/cythonized/sage/misc/cachefunc.c:10232)()
   1948 return cache[k]
   1949 except KeyError:
-> 1950 w = self._instance_call(*args, **kwds)
   1951 cache[k] = w
   1952 return w

/home/simon/sage/local/lib/python2.7/site-packages/sage/misc/cachefunc.pyx 
in sage.misc.cachefunc.CachedMethodCaller._instance_call 
(build/cythonized/sage/misc/cachefunc.c:9717)()
   1824 True
   1825 """
-> 1826 return self.f(self._instance, *args, **kwds)
   1827 
   1828 cdef fix_args_kwds(self, tuple args, dict kwds):

/home/simon/sage/local/lib/python2.7/site-packages/sage/modules/torsion_quadratic_module.pyc
 
in orthogonal_group(self, gens, check)
   1196 gens = [matrix(g) for g in _isom_fqf(self)]
   1197 ambient = AbelianGroupGap(self.invariants()).aut()
-> 1198 gens = [ambient(g) for g in gens]
   1199 gens = tuple(g for g in gens if g != ambient.one())
   1200 return FqfOrthogonalGroup(ambient, gens, self, check=check)

/home/simon/sage/local/lib/python2.7/site-packages/sage/structure/parent.pyx 
in sage.structure.parent.Parent.__call__ 
(build/cythonized/sage/structure/parent.c:9171)()
897 if mor is not None:
898 if no_extra_args:
--> 899 return mor._call_(x)
900 else:
901 return mor._call_with_args(x, args, kwds)

/home/simon/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.pyx
 
in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ 
(build/cythonized/sage/structure/coerce_maps.c:4547)()
160 print(type(C), C)
161 print(type(C._element_constructor), 
C._element_constructor)
--> 162 raise
163 
164 cpdef Element _call_with_args(self, x, args=(), kwds={}):

/home/simon/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.pyx
 
in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ 
(build/cythonized/sage/structure/coerce_maps.c:4439)()
155 cdef Parent C = self._codomain
156 try:
--> 157 return C._element_constructor(x)
158 except Exception:
159 if print_warnings: