[sage-devel] Re: Sage-6.5 Source Fails to Compile

[Richard]

Volker:

Yes, your suggested 'fix' works.

My standard CFLAGS and CXXFLAGS that was failing on zeromq:
CFLAGS=-march=native -O2 -fomit-frame-pointer -pipe -W -Wall
CXXFLAGS=-march=native -O2 -fomit-frame-pointer -pipe -W -Wall

The following work:
CFLAGS=-march=native -O2 -fomit-frame-pointer -pipe
-Wno-error=unused-parameter
CXXFLAGS=-march=native -O2 -fomit-frame-pointer -pipe
-Wno-error=unused-parameter

Thank you.

Richard

On 02/22/15 00:45, Volker Braun wrote:
> Seems to be fixed in the next zeromq
> version: https://github.com/zeromq/libzmq/tree/master/tests
> 
> Can you try
> 
> CXXFLAGS="-Wno-error=unused-parameter"  make
> 
> or maybe just CFLAGS. If it works we can add it as a workaround.
> 
> 
> 
> 
> On Sunday, February 22, 2015 at 4:07:13 AM UTC+1, rich...@pacbell.net wrote:
> 
> I'm trying to compile Sage-6.5 on 64-bit Linux (Gentoo using gcc-4.8.3)
> 
> export MAKE="make -j16"
> make ssl > make.out 2>&1 &
> 
> from the end of make:
> 
> 
> Successfully installed gf2x-1.1.p1
> Deleting temporary build directory
> /dev/shm/sage-6.5/local/var/tmp/sage/build/gf2x-1.1.p1
> Finished installing gf2x-1.1.p1.spkg
> make[2]: Leaving directory '/dev/shm/sage-6.5/build'
> Makefile:391: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/dev/shm/sage-6.5/build'
> 
> real  7m47.094s
> user  32m54.476s
> sys   1m4.133s
> ***
> Error building Sage.
> 
> The following package(s) may have failed to build:
> 
> package: zeromq-4.0.5
> log file: /dev/shm/sage-6.5/logs/pkgs/zeromq-4.0.5.log
> build directory:
> /dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5
> ==
> 
> and from the end of zeromq-4.0.5.log:
> 
> ==
>   CXXlibzmq_la-mailbox.lo
>   CXXlibzmq_la-mechanism.lo
> In file included from mechanism.cpp:22:0:
> mechanism.hpp:49:21: error: unused parameter 'msg_'
> [-Werror=unused-parameter]
>  virtual int encode (msg_t *msg_) { return 0; }
>  ^
> mechanism.hpp:51:21: error: unused parameter 'msg_'
> [-Werror=unused-parameter]
>  virtual int decode (msg_t *msg_) { return 0; }
>  ^
> mechanism.cpp:126:5: error: unused parameter 'name_'
> [-Werror=unused-parameter]
>  int zmq::mechanism_t::property (const std::string name_,
>  ^
> mechanism.cpp:126:5: error: unused parameter 'value_'
> [-Werror=unused-parameter]
> mechanism.cpp:126:5: error: unused parameter 'length_'
> [-Werror=unused-parameter]
> cc1plus: all warnings being treated as errors
> Makefile:799: recipe for target 'libzmq_la-mechanism.lo' failed
> make[5]: *** [libzmq_la-mechanism.lo] Error 1
> make[5]: Leaving directory
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src/src'
> Makefile:485: recipe for target 'all' failed
> make[4]: *** [all] Error 2
> make[4]: Leaving directory
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src/src'
> Makefile:331: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src'
> Failed to build zeromq
> 
> real0m18.111s
> user0m12.670s
> sys 0m1.183s
> 
> 
> Error installing package zeromq-4.0.5
> 
> 
> =
> 
> This is an Intel core i7 based system.
> 
> If any more information about my system or build attempt would be
> helpful in fixing this issue, please ask.
> 
> R
> 

-- 
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] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

[Julien Puydt]

Hi,

Le 22/02/2015 20:34, Franco Saliola a écrit :

Hello sage-devel,

I sent the following email to sage-release, but I think it really belongs
here. I'm looking for ideas on how to debug (or better, how to fix) the
problems with GP/PARI interface that are causing sage to hang.



The symptoms look like what one gets if gprc.expect isn't found : gp and 
pexpect don't agree, so sometimes pexpect stays stuck because it doesn't 
get what it wanted. The recently closed #17796 makes sage more resilient 
to that.


Snark on #sagemath

--
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: Addition of zero in the coercion model

[Jeroen Demeyer]

On 2015-02-22 15:24, Simon King wrote:

Seriously? I didn't know that Sage's coercion model has such special
cases. OK, it makes it possible to get a typical usecase with least effort.
But my impression is that ultimately such special cases cause a lot more
confusion than a clear model in the spirit of "arithmetics across
parents relies on coercion morphisms, which are canonical morphisms in
suitable categories, and the composition of coercion morphisms is a
coercion morphism".


On the other, this special case is consistent with the idea of the 
"univeral 0 object" proposed by John Cremona.


--
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] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

[Jeroen Demeyer]

On 2015-02-22 20:34, Franco Saliola wrote:

  o gp('2 + 3') hangs in sage
What's the contents of ~/.sage/gp-expect.log after doing just this in a 
Sage session?


--
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] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

[François Bissey]

Do you have a system wide pari/gp install?

Francois

On 02/23/15 08:34, Franco Saliola wrote:


Hello sage-devel,

I sent the following email to sage-release, but I think it really
belongs here. I'm looking for ideas on how to debug (or better, how to
fix) the problems with GP/PARI interface that are causing sage to hang.

Thanks,

Franco

-- Forwarded message --
From: *Franco Saliola* mailto:sali...@gmail.com>>
Date: Sat, Feb 21, 2015 at 1:21 PM
Subject: [sage-release] Re: Sage 6.5 released
To: sage-rele...@googlegroups.com 

On Monday, February 16, 2015 at 8:17:30 PM UTC-5, Volker Braun wrote:

As usual, get the "develop" branch or the source tarball from
http://www.sagemath.org/__download-latest.html



Built successfully, but 'make ptest' fails because of what seems to be a
problem with the GP/PARI interface. Any ideas?

Details:

  * machine: Dell T7600 running Ubuntu 14.04.2 LTS
  * build method: git cloned from trac; make and make ptest
  * other notes:
  o gp('2 + 3') hangs in sage
  o turns out this problem exists on 6.4.1 also (so it ain't new)
  * log file:
  o full log file is here:
http://thales.math.uqam.ca/~saliola/misc/ptest.log
  o see below for a list of the failed tests

--
sage -t src/sage/functions/other.py  # Timed out
sage -t src/sage/interfaces/expect.py  # Timed out
sage -t src/doc/de/tutorial/interfaces.rst  # Timed out
sage -t src/doc/en/tutorial/interfaces.rst  # Timed out
sage -t src/doc/en/prep/Quickstarts/Statistics-and-Distributions.rst  # Timed 
out
sage -t src/doc/en/reference/coercion/index.rst  # Timed out
sage -t src/doc/fr/tutorial/interfaces.rst  # Timed out
sage -t src/doc/ru/tutorial/interfaces.rst  # Timed out
sage -t src/sage/calculus/calculus.py  # Timed out
sage -t src/sage/interacts/debugger.py  # Timed out
sage -t src/sage/doctest/forker.py  # Timed out
sage -t src/sage/combinat/partition_tuple.py  # Timed out
sage -t src/sage/interfaces/gp.py  # Timed out
sage -t src/sage/interfaces/interface.py  # Timed out
sage -t src/sage/interfaces/mathematica.py  # Timed out
sage -t src/sage/interfaces/quit.py  # Timed out
sage -t src/sage/interfaces/maxima_abstract.py  # Timed out
sage -t src/sage/interfaces/r.py  # Timed out
sage -t src/sage/interfaces/sage0.py  # Timed out
sage -t src/sage/interfaces/tests.py  # Timed out
sage -t src/sage/lfunctions/dokchitser.py  # Timed out
sage -t src/sage/matrix/matrix0.pyx  # Timed out
sage -t src/sage/matrix/matrix1.pyx  # Timed out
sage -t src/sage/matrix/tests.py  # Timed out
sage -t src/sage/misc/sage_eval.py  # Timed out
sage -t src/sage/misc/misc.py  # Timed out
sage -t src/sage/misc/randstate.pyx  # Timed out
sage -t src/sage/misc/sageinspect.py  # Timed out
sage -t src/sage/modular/buzzard.py  # Timed out
sage -t src/sage/modular/modform/constructor.py  # Timed out
sage -t src/sage/modular/modform/element.py  # Timed out
sage -t src/sage/modular/modform/eis_series.py  # Timed out
sage -t src/sage/modular/modform_hecketriangle/element.py  # Timed out
sage -t src/sage/modular/modform_hecketriangle/readme.py  # Timed out
sage -t src/sage/parallel/decorate.py  # Timed out
sage -t src/sage/quadratic_forms/binary_qf.py  # Timed out
sage -t src/sage/quadratic_forms/qfsolve.py  # Timed out
sage -t src/sage/quadratic_forms/quadratic_form__automorphisms.py  # Timed out
sage -t src/sage/rings/arith.py  # Timed out
sage -t src/sage/rings/complex_double.pyx  # Timed out
sage -t src/sage/rings/complex_number.pyx  # Timed out
sage -t src/sage/rings/finite_rings/element_pari_ffelt.pyx  # Timed out
sage -t src/sage/rings/number_field/number_field_ideal.py  # Timed out
sage -t src/sage/rings/number_field/number_field.py  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_CA_element.pyx  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_CR_element.pyx  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_FM_element.pyx  # Timed out
sage -t src/sage/rings/polynomial/polynomial_ring.py  # Timed out
sage -t src/sage/rings/real_double.pyx  # Timed out
sage -t src/sage/rings/real_mpfr.pyx  # Timed out
sage -t src/sage/schemes/elliptic_curves/BSD.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/ell_number_field.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/gp_simon.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/lseries_ell.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/height.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/period_lattice.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/sha_tate.py  # Timed out
sage -t src/sage/schemes/hyperelliptic_curves/mestre.py  # Timed out
sage -t src/sage/schemes/plane_conics/con_field.py  # Timed out
sage -t src/sage/schemes/plane_conics/con_number_field.py  # Timed 

[sage-devel] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

[Franco Saliola]

Hello sage-devel,

I sent the following email to sage-release, but I think it really belongs
here. I'm looking for ideas on how to debug (or better, how to fix) the
problems with GP/PARI interface that are causing sage to hang.

Thanks,

Franco

-- Forwarded message --
From: Franco Saliola 
Date: Sat, Feb 21, 2015 at 1:21 PM
Subject: [sage-release] Re: Sage 6.5 released
To: sage-rele...@googlegroups.com

On Monday, February 16, 2015 at 8:17:30 PM UTC-5, Volker Braun wrote:
>
> As usual, get the "develop" branch or the source tarball from
> http://www.sagemath.org/download-latest.html
>

Built successfully, but 'make ptest' fails because of what seems to be a
problem with the GP/PARI interface. Any ideas?

Details:

   - machine: Dell T7600 running Ubuntu 14.04.2 LTS
   - build method: git cloned from trac; make and make ptest
   - other notes:
  - gp('2 + 3') hangs in sage
  - turns out this problem exists on 6.4.1 also (so it ain't new)
   - log file:
  - full log file is here:
  http://thales.math.uqam.ca/~saliola/misc/ptest.log
  - see below for a list of the failed tests

--
sage -t src/sage/functions/other.py  # Timed out
sage -t src/sage/interfaces/expect.py  # Timed out
sage -t src/doc/de/tutorial/interfaces.rst  # Timed out
sage -t src/doc/en/tutorial/interfaces.rst  # Timed out
sage -t src/doc/en/prep/Quickstarts/Statistics-and-Distributions.rst
# Timed out
sage -t src/doc/en/reference/coercion/index.rst  # Timed out
sage -t src/doc/fr/tutorial/interfaces.rst  # Timed out
sage -t src/doc/ru/tutorial/interfaces.rst  # Timed out
sage -t src/sage/calculus/calculus.py  # Timed out
sage -t src/sage/interacts/debugger.py  # Timed out
sage -t src/sage/doctest/forker.py  # Timed out
sage -t src/sage/combinat/partition_tuple.py  # Timed out
sage -t src/sage/interfaces/gp.py  # Timed out
sage -t src/sage/interfaces/interface.py  # Timed out
sage -t src/sage/interfaces/mathematica.py  # Timed out
sage -t src/sage/interfaces/quit.py  # Timed out
sage -t src/sage/interfaces/maxima_abstract.py  # Timed out
sage -t src/sage/interfaces/r.py  # Timed out
sage -t src/sage/interfaces/sage0.py  # Timed out
sage -t src/sage/interfaces/tests.py  # Timed out
sage -t src/sage/lfunctions/dokchitser.py  # Timed out
sage -t src/sage/matrix/matrix0.pyx  # Timed out
sage -t src/sage/matrix/matrix1.pyx  # Timed out
sage -t src/sage/matrix/tests.py  # Timed out
sage -t src/sage/misc/sage_eval.py  # Timed out
sage -t src/sage/misc/misc.py  # Timed out
sage -t src/sage/misc/randstate.pyx  # Timed out
sage -t src/sage/misc/sageinspect.py  # Timed out
sage -t src/sage/modular/buzzard.py  # Timed out
sage -t src/sage/modular/modform/constructor.py  # Timed out
sage -t src/sage/modular/modform/element.py  # Timed out
sage -t src/sage/modular/modform/eis_series.py  # Timed out
sage -t src/sage/modular/modform_hecketriangle/element.py  # Timed out
sage -t src/sage/modular/modform_hecketriangle/readme.py  # Timed out
sage -t src/sage/parallel/decorate.py  # Timed out
sage -t src/sage/quadratic_forms/binary_qf.py  # Timed out
sage -t src/sage/quadratic_forms/qfsolve.py  # Timed out
sage -t src/sage/quadratic_forms/quadratic_form__automorphisms.py  # Timed out
sage -t src/sage/rings/arith.py  # Timed out
sage -t src/sage/rings/complex_double.pyx  # Timed out
sage -t src/sage/rings/complex_number.pyx  # Timed out
sage -t src/sage/rings/finite_rings/element_pari_ffelt.pyx  # Timed out
sage -t src/sage/rings/number_field/number_field_ideal.py  # Timed out
sage -t src/sage/rings/number_field/number_field.py  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_CA_element.pyx  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_CR_element.pyx  # Timed out
sage -t src/sage/rings/padics/padic_ZZ_pX_FM_element.pyx  # Timed out
sage -t src/sage/rings/polynomial/polynomial_ring.py  # Timed out
sage -t src/sage/rings/real_double.pyx  # Timed out
sage -t src/sage/rings/real_mpfr.pyx  # Timed out
sage -t src/sage/schemes/elliptic_curves/BSD.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/ell_number_field.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/gp_simon.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/lseries_ell.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/height.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/period_lattice.py  # Timed out
sage -t src/sage/schemes/elliptic_curves/sha_tate.py  # Timed out
sage -t src/sage/schemes/hyperelliptic_curves/mestre.py  # Timed out
sage -t src/sage/schemes/plane_conics/con_field.py  # Timed out
sage -t src/sage/schemes/plane_conics/con_number_field.py  # Timed out
sage -t src/sage/schemes/plane_conics/con_rational_field.py  # Timed out
sage -t src/sage/stats/r.py  # Timed out
sage -t src/sage/structure/parent.pyx  # Timed out
sage -t src/sage/structure/parent_old.pyx  # Timed 

[sage-devel] Re: Addition of zero in the coercion model

[Simon King]

Hi Eric,

On 2015-02-22, Eric Gourgoulhon  wrote:
> Note that the function is_Integer used in sage.structure.coerce.pyx is=20
> *not* the above one: it is defined in lines 134-139 and it returns True for=
> is_Integer(int(0)).=20

Seriously? But when the integer zero is treated in a special way, then why
did "sum(...)" not work in the original post, while "sum(..., P.zero())"
did?

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

[Eric Gourgoulhon]

Le dimanche 22 février 2015 15:24:53 UTC+1, Simon King a écrit :
>
>
> Seriously? I didn't know that Sage's coercion model has such special 
> cases. OK, it makes it possible to get a typical usecase with least 
> effort. 
> But my impression is that ultimately such special cases cause a lot more 
> confusion than a clear model in the spirit of "arithmetics across 
> parents relies on coercion morphisms, which are canonical morphisms in 
> suitable categories, and the composition of coercion morphisms is a 
> coercion morphism". 
>
>
I agree. Actually, I've discovered the quoted lines of 
sage.structure.coerce.pyx while trying to understand why 0+x works while 
QQ(0) + x does not.

Note this: 
>   sage: from sage.rings.integer import is_Integer 
>   sage: is_Integer(int(0)) 
>   False 
>

Note that the function is_Integer used in sage.structure.coerce.pyx is 
*not* the above one: it is defined in lines 134-139 and it returns True for 
is_Integer(int(0)). 

Best regards,

Eric. 

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

[sage-devel] Re: Addition of zero in the coercion model

[Simon King]

Hi Eric,

On 2015-02-22, Eric Gourgoulhon  wrote:
> Yes that's conversion, but both 0+x and x+0 works because, I think, of=20
> lines 979-990 of=20
> sage.structure.coerce.pyx:
> # Allow coercion of 0 even if no coercion from Z
> if is_Integer(x) and not x and type(yp) is not type:
> try:
> return yp(0), y
> except Exception:
> self._record_exception()
>
> if is_Integer(y) and not y and type(xp) is not type:
> try:
> return x, xp(0)
> except Exception:
> self._record_exception()
> ...
> so that both x+0 and 0+x works:

Seriously? I didn't know that Sage's coercion model has such special
cases. OK, it makes it possible to get a typical usecase with least effort.
But my impression is that ultimately such special cases cause a lot more
confusion than a clear model in the spirit of "arithmetics across
parents relies on coercion morphisms, which are canonical morphisms in
suitable categories, and the composition of coercion morphisms is a
coercion morphism".

Note this:
  sage: from sage.rings.integer import is_Integer
  sage: is_Integer(int(0))
  False

I guess that explains why "0+x+y" works on the command line but not in a
python module, and why "sum([x,y])" doesn't work either.

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Version of the documentation

[Bruno Grenet]

Dear all,

The documentation on http://www.sagemath.org/doc/index.html is for Sage 
v6.6.beta0. Shouldn't it be for Sage v6.5?


Cheers,
Bruno

--
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: Addition of zero in the coercion model

[John Cremona]

On 22 February 2015 at 10:00, Eric Gourgoulhon  wrote:
> Hi Simon,
>
> Le dimanche 22 février 2015 00:28:42 UTC+1, Simon King a écrit :
>>
>> Hi Eric,
>>
>> On 2015-02-21, Eric Gourgoulhon  wrote:
>> > It seems that a possible way to have 0 + MyElement work even if ZZ does=
>> >=20
>> > not coerce to MyElement.parent() is to have=20
>> > MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as
>> > an=
>> >=20
>> > argument and return the zero element of your vector space / module for
>> > such=
>> >=20
>> > an argument.  Am I correct?=20
>>
>> That's conversion. It would *not* enable x+0.
>
>
> Yes that's conversion, but both 0+x and x+0 works because, I think, of lines
> 979-990 of
> sage.structure.coerce.pyx:
> # Allow coercion of 0 even if no coercion from Z
> if is_Integer(x) and not x and type(yp) is not type:
> try:
> return yp(0), y
> except Exception:
> self._record_exception()
>
> if is_Integer(y) and not y and type(xp) is not type:
> try:
> return x, xp(0)
> except Exception:
> self._record_exception()
>
>
> Here is the example on free modules of #15916:
>
> sage: M = FiniteRankFreeModule(ZZ, 3, name='M')
> sage: e = M.basis('e')
> sage: x = M([1,-2,3], basis=e) ; x
> Element of the Rank-3 free module M over the Integer Ring
> sage: x.display()
> e_0 - 2 e_1 + 3 e_2
>
> There is conversion of 0 to an element of M, but no coercion of ZZ into M:
>
> sage: M(0)
> Element zero of the Rank-3 free module M over the Integer Ring
> sage: M.has_coerce_map_from(ZZ)
> False
>
> Because of the lines of coerce.pyx listed above, we have:
>
> sage: cm = sage.structure.element.get_coercion_model()
> sage: cm.canonical_coercion(0, x)
> (Element zero of the Rank-3 free module M over the Integer Ring,
>  Element of the Rank-3 free module M over the Integer Ring)
> sage: cm.canonical_coercion(x, 0)
> (Element of the Rank-3 free module M over the Integer Ring,
>  Element zero of the Rank-3 free module M over the Integer Ring)
>
> so that both x+0 and 0+x works:
>
> sage: s = 0 + x ; s
> Element of the Rank-3 free module M over the Integer Ring
> sage: s.display()
> e_0 - 2 e_1 + 3 e_2
> sage: s = x + 0 ; s
> Element of the Rank-3 free module M over the Integer Ring
> sage: s.display()
> e_0 - 2 e_1 + 3 e_2
>
> Because there is "is_Integer(x)" in line 980 of coerce.pyx, this does not
> work for a 0 different from ZZ(0):
>
> sage: zq = QQ(0)
> sage: cm.canonical_coercion(zq, x)
> ...
> TypeError: no common canonical parent for objects with parents: 'Rational
> Field' and 'Rank-3 free module M over the Integer Ring'
>
> Indeed:
> sage: s = zq + x
> ...
> TypeError: unsupported operand parent(s) for '+': 'Rational Field' and
> 'Rank-3 free module M over the Integer Ring'
>
>
> Best regards,
>
> Eric.

My 2p-worth:   this all seems to be happening because of the implicit
automatic conversion from a literal 0 in Sage code to ZZ(0) in
contexts where a different zero exists (that of the parent of the
object to which 0 is going to be added).

Is there a case for having a separate global type or class for 0, to
which a literal 0 is coerced automatically on input, and which coerces
into every structure which has a 0 element?  This seems to make sense
to me (if I simply input 0, or assign x=0, Sage cannot know yet
whether I mean the Integer 0 or something else).  But I am not expert
in coercion and perhaps this would be hard (or impossible, or just
tedious) to implement.

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

[sage-devel] Re: coercion of objects embedded in symbolic expressions

[Burcin Erocal]

On Sun, 22 Feb 2015 03:17:13 -0800 (PST)
Volker Braun  wrote:

> Just to tell you what you already know, the symbolic ring is the
> parent of last resort if there is nothing more specific. So its to be
> expected that you don't have any canonical maps elsewhere.
> 
> Pynac should probably unwind the comparison of two wrapped
> (non-symbolic) python objects to the comparison of the underlying
> python objects. Haven't tried that, though. You have to be careful
> about infinite recursions, the comparison might again coerce into the
> symbolic ring.

Pynac already calls the Python comparison function if both are
pyobjects. In this case, infinity and constants are not pyobjects. They
are a basic class as in mul, add, symbol, etc.

Cheers,
Burcin

P.S. The infinity class was added to pynac by Volker. :)

> On Sunday, February 22, 2015 at 11:02:44 AM UTC+1, Ralf Stephan wrote:
> >
> > Hello,
> > a long standing issue is
> >
> > sage: bool(pi > False
> > sage: bool(SR(3) > False
> >
> > http://trac.sagemath.org/ticket/12967
> > at which I'm having a naive stab (because it interferes with
> > #14801). Maybe I can learn something?
> >
> > In the ticket the problem has been said having to do with Pynac,
> > but I don't think so. It would all work nicely if, instead of the 
> > expression
> > object, its underlying `pyobject` would be compared. But this does
> > not happen because there is no coerce map from `SR` to
> > `InfinityRing`.
> >
> > So, can we somehow have an indirect coercion map that uses not
> > the parent but the parent of something a member function (like
> > `pyobject`) returns? The problem of SR having no canonical map to
> > anything in spite of some expressions being well behaved is the
> > source of much frustration.
> >
> > Regards,
> >

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

[sage-devel] Re: coercion of objects embedded in symbolic expressions

[Volker Braun]

Just to tell you what you already know, the symbolic ring is the parent of 
last resort if there is nothing more specific. So its to be expected that 
you don't have any canonical maps elsewhere.

Pynac should probably unwind the comparison of two wrapped (non-symbolic) 
python objects to the comparison of the underlying python objects. Haven't 
tried that, though. You have to be careful about infinite recursions, the 
comparison might again coerce into the symbolic ring.




On Sunday, February 22, 2015 at 11:02:44 AM UTC+1, Ralf Stephan wrote:
>
> Hello,
> a long standing issue is
>
> sage: bool(pi False
> sage: bool(SR(3) False
>
> http://trac.sagemath.org/ticket/12967
> at which I'm having a naive stab (because it interferes with #14801).
> Maybe I can learn something?
>
> In the ticket the problem has been said having to do with Pynac,
> but I don't think so. It would all work nicely if, instead of the 
> expression
> object, its underlying `pyobject` would be compared. But this does not
> happen because there is no coerce map from `SR` to `InfinityRing`.
>
> So, can we somehow have an indirect coercion map that uses not
> the parent but the parent of something a member function (like `pyobject`)
> returns? The problem of SR having no canonical map to anything
> in spite of some expressions being well behaved is the source of
> much frustration.
>
> Regards,
>

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

[sage-devel] Re: coercion of objects embedded in symbolic expressions

[Eric Gourgoulhon]

Hi, 

Just to tell that no later than two days ago, I had a bug in my code that 
was caused by 
bool(SR(0) < Infinity) returning False. 
I was about to post a message to sage-devel, but thanks to your post, I 
realize this is a known issue. 

Best wishes,

Eric.

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

[sage-devel] coercion of objects embedded in symbolic expressions

[Ralf Stephan]

Hello,
a long standing issue is

sage: bool(pihttp://trac.sagemath.org/ticket/12967
at which I'm having a naive stab (because it interferes with #14801).
Maybe I can learn something?

In the ticket the problem has been said having to do with Pynac,
but I don't think so. It would all work nicely if, instead of the expression
object, its underlying `pyobject` would be compared. But this does not
happen because there is no coerce map from `SR` to `InfinityRing`.

So, can we somehow have an indirect coercion map that uses not
the parent but the parent of something a member function (like `pyobject`)
returns? The problem of SR having no canonical map to anything
in spite of some expressions being well behaved is the source of
much frustration.

Regards,

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

[sage-devel] Re: Addition of zero in the coercion model

[Eric Gourgoulhon]

Hi Simon, 

Le dimanche 22 février 2015 00:28:42 UTC+1, Simon King a écrit :
>
> Hi Eric, 
>
> On 2015-02-21, Eric Gourgoulhon > 
> wrote: 
> > It seems that a possible way to have 0 + MyElement work even if ZZ does= 
> >=20 
> > not coerce to MyElement.parent() is to have=20 
> > MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as 
> an= 
> >=20 
> > argument and return the zero element of your vector space / module for 
> such= 
> >=20 
> > an argument.  Am I correct?=20 
>
> That's conversion. It would *not* enable x+0. 
>

Yes that's conversion, but both 0+x and x+0 works because, I think, of 
lines 979-990 of 
sage.structure.coerce.pyx:
# Allow coercion of 0 even if no coercion from Z
if is_Integer(x) and not x and type(yp) is not type:
try:
return yp(0), y
except Exception:
self._record_exception()

if is_Integer(y) and not y and type(xp) is not type:
try:
return x, xp(0)
except Exception:
self._record_exception()


Here is the example on free modules of #15916 
:

sage: M = FiniteRankFreeModule(ZZ, 3, name='M')
sage: e = M.basis('e')
sage: x = M([1,-2,3], basis=e) ; x
Element of the Rank-3 free module M over the Integer Ring
sage: x.display()
e_0 - 2 e_1 + 3 e_2

There is conversion of 0 to an element of M, but no coercion of ZZ into M:

sage: M(0)
Element zero of the Rank-3 free module M over the Integer Ring
sage: M.has_coerce_map_from(ZZ)
False

Because of the lines of coerce.pyx listed above, we have:

sage: cm = sage.structure.element.get_coercion_model()
sage: cm.canonical_coercion(0, x)
(Element zero of the Rank-3 free module M over the Integer Ring,
 Element of the Rank-3 free module M over the Integer Ring)
sage: cm.canonical_coercion(x, 0)
(Element of the Rank-3 free module M over the Integer Ring,
 Element zero of the Rank-3 free module M over the Integer Ring)

so that both x+0 and 0+x works:

sage: s = 0 + x ; s
Element of the Rank-3 free module M over the Integer Ring
sage: s.display()
e_0 - 2 e_1 + 3 e_2
sage: s = x + 0 ; s
Element of the Rank-3 free module M over the Integer Ring
sage: s.display()
e_0 - 2 e_1 + 3 e_2

Because there is "is_Integer(x)" in line 980 of coerce.pyx, this does not 
work for a 0 different from ZZ(0):

sage: zq = QQ(0)
sage: cm.canonical_coercion(zq, x)
...
TypeError: no common canonical parent for objects with parents: 'Rational 
Field' and 'Rank-3 free module M over the Integer Ring'

Indeed: 
sage: s = zq + x
...
TypeError: unsupported operand parent(s) for '+': 'Rational Field' and 
'Rank-3 free module M over the Integer Ring'


Best regards,

Eric.


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

[sage-devel] Re: Sage-6.5 Source Fails to Compile

[Volker Braun]

Wrong link to zeromq master, should be 
https://github.com/zeromq/zeromq4-1/commit/00aeaddf945cf7bdca33473fdd591a0f874ab2b4

On Sunday, February 22, 2015 at 9:45:26 AM UTC+1, Volker Braun wrote:
>
> Seems to be fixed in the next zeromq version: 
> https://github.com/zeromq/libzmq/tree/master/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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage-6.5 Source Fails to Compile

[Volker Braun]

Seems to be fixed in the next zeromq 
version: https://github.com/zeromq/libzmq/tree/master/tests

Can you try

CXXFLAGS="-Wno-error=unused-parameter"  make

or maybe just CFLAGS. If it works we can add it as a workaround.




On Sunday, February 22, 2015 at 4:07:13 AM UTC+1, rich...@pacbell.net wrote:
>
> I'm trying to compile Sage-6.5 on 64-bit Linux (Gentoo using gcc-4.8.3) 
>
> export MAKE="make -j16" 
> make ssl > make.out 2>&1 & 
>
> from the end of make: 
>
>  
> Successfully installed gf2x-1.1.p1 
> Deleting temporary build directory 
> /dev/shm/sage-6.5/local/var/tmp/sage/build/gf2x-1.1.p1 
> Finished installing gf2x-1.1.p1.spkg 
> make[2]: Leaving directory '/dev/shm/sage-6.5/build' 
> Makefile:391: recipe for target 'all' failed 
> make[1]: *** [all] Error 2 
> make[1]: Leaving directory '/dev/shm/sage-6.5/build' 
>
> real  7m47.094s 
> user  32m54.476s 
> sys   1m4.133s 
> *** 
> Error building Sage. 
>
> The following package(s) may have failed to build: 
>
> package: zeromq-4.0.5 
> log file: /dev/shm/sage-6.5/logs/pkgs/zeromq-4.0.5.log 
> build directory: /dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5 
> == 
>
> and from the end of zeromq-4.0.5.log: 
>
> == 
>   CXXlibzmq_la-mailbox.lo 
>   CXXlibzmq_la-mechanism.lo 
> In file included from mechanism.cpp:22:0: 
> mechanism.hpp:49:21: error: unused parameter 'msg_' 
> [-Werror=unused-parameter] 
>  virtual int encode (msg_t *msg_) { return 0; } 
>  ^ 
> mechanism.hpp:51:21: error: unused parameter 'msg_' 
> [-Werror=unused-parameter] 
>  virtual int decode (msg_t *msg_) { return 0; } 
>  ^ 
> mechanism.cpp:126:5: error: unused parameter 'name_' 
> [-Werror=unused-parameter] 
>  int zmq::mechanism_t::property (const std::string name_, 
>  ^ 
> mechanism.cpp:126:5: error: unused parameter 'value_' 
> [-Werror=unused-parameter] 
> mechanism.cpp:126:5: error: unused parameter 'length_' 
> [-Werror=unused-parameter] 
> cc1plus: all warnings being treated as errors 
> Makefile:799: recipe for target 'libzmq_la-mechanism.lo' failed 
> make[5]: *** [libzmq_la-mechanism.lo] Error 1 
> make[5]: Leaving directory 
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src/src' 
> Makefile:485: recipe for target 'all' failed 
> make[4]: *** [all] Error 2 
> make[4]: Leaving directory 
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src/src' 
> Makefile:331: recipe for target 'all-recursive' failed 
> make[3]: *** [all-recursive] Error 1 
> make[3]: Leaving directory 
> '/dev/shm/sage-6.5/local/var/tmp/sage/build/zeromq-4.0.5/src' 
> Failed to build zeromq 
>
> real0m18.111s 
> user0m12.670s 
> sys 0m1.183s 
>  
> Error installing package zeromq-4.0.5 
>  
> = 
>
> This is an Intel core i7 based system. 
>
> If any more information about my system or build attempt would be 
> helpful in fixing this issue, please ask. 
>
> R 
>
>

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