[sage-devel] Re: How should ordering of constants be defined?

On Saturday, February 17, 2018 at 8:22:13 AM UTC+1, Ralf Stephan wrote: > > This baffles me and I would like to know why the computation differs from > the above. > Ah ok, _richcmp_ is Py2 specific. Then we want to do the symbolic check before the inexact ones by changing

[sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

On Friday, February 16, 2018 at 10:05:02 AM UTC+1, Dima Pasechnik wrote: > > guppy.hpy() finds 149 objects > dict of sympy.core.assumptions.ManagedProperties > on the heap > The solution of the original issue did not involve sympy so I was trying to reproduce this, but when trying to

Re: [sage-devel] Re: Errors in GAP small groups library

I realized that I ran sage: gap.eval('LoadAllPackages();') which broke libgap. For anyone else reading this, the following fixed the problem (taken from gap_reset_workspace, with sonata and guava removed due to "Warning: this should never happen" and braid removed because I don't have it

[sage-devel] Re: How should ordering of constants be defined?

On Saturday, February 17, 2018 at 8:22:13 AM UTC+1, Ralf Stephan wrote: > > IThis calls Expression._richcmp_(pi, pi, Py_LT) > Py_LE of course. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: How should ordering of constants be defined?

I'm afraid the issue is more complicated. On Friday, February 16, 2018 at 5:04:30 PM UTC+1, Erik Bray wrote: > > On Python 2 this works: > > sage: bool(pi <= pi) > True > > This works fine because the Constant class implements __eq__, and so > if asking if pi <= pi that's good enough for it.

Re: [sage-devel] Re: Errors in GAP small groups library

Thanks, that helps a lot. After some experimentation, it seems like gap> LoadPackage("CRISP"); is sufficient. However, when I try to do it from sage I get the following: sage: gap.eval('LoadPackage("CRISP");') Warning: this should never happen and sage hangs. Googling leads me to

[sage-devel] Re: Errors in GAP small groups library

The problem is in the packages loaded (or not) by Sage's GAP vs by GAP's GAP. Namely, if I start Sage's gap by ./sage --gap and do gap> LoadAllPackages(); gap> NormalSubgroups(SmallGroup(1458,1180)); I'd get your error Now, if I take GAP's source for 4.8.6:

Re: [sage-devel] Errors in GAP small groups library

On Fri, Feb 16, 2018 at 10:44 PM, David Joyner wrote: > On Fri, Feb 16, 2018 at 10:12 PM, David Roe wrote: > > I'm trying to use GAP's small groups library (after installing > gap_packages) > > and getting strange errors that don't occur in GAP when

Re: [sage-devel] Errors in GAP small groups library

On Fri, Feb 16, 2018 at 10:12 PM, David Roe wrote: > I'm trying to use GAP's small groups library (after installing gap_packages) > and getting strange errors that don't occur in GAP when built from source. > In particular (using gap_console to get more traceback) > > sage:

[sage-devel] Errors in GAP small groups library

I'm trying to use GAP's small groups library (after installing gap_packages) and getting strange errors that don't occur in GAP when built from source. In particular (using gap_console to get more traceback) sage: gap_console() ... gap> NormalSubgroups(SmallGroup(1458,1180)); Error, List

Re: [sage-devel] Error compiling Sage: undefined symbol GC_move_disappearing_link

We have already seen that before, in the last month I think. Your version of make is compiled with guile support. The compilation breaks because “make" itself breaks. flint and R use LD_LIBRARY_PATH in their build system and make loses touch with some of the libraries it has been compiled with

[sage-devel] Re: How should ordering of constants be defined?

Comparing two named real constants by float value sounds good to me. In general, when comparing general symbolic expressions, there are some numerical tests with increcasing accuracy iirc... On Friday, February 16, 2018 at 5:04:30 PM UTC+1, Erik Bray wrote: > > Hi, > > In working on the

Re: [sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

How about adding an optional argument "scaled", defaulting to True: Then if S is an S-box, for instance sage: from sage.crypto.sbox import SBox sage: S = SBox(7,6,0,4,2,5,1,3) one could call sage: S.linear_approximation_matrix() or sage:

Re: [sage-devel] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

Le vendredi 16 février 2018 14:22:39 UTC+1, Jeroen Demeyer a écrit : > > > They are warnings, not errors. In this case, you can ignore them since > you probably don't have gmpy2 installed (it is not a standard package). > > Thanks for your answer. If this is not a standard package, why there

[sage-devel] Possibly bug in factoring over Cyclotomic fields

The following code crashes (in Sage 8.1 and on CoCalc): sage: K=CyclotomicField(20) sage: R.=PolynomialRing(K) sage: (x^4-1).factor() --- PariError Traceback (most recent call last) in ()

[sage-devel] How should ordering of constants be defined?

Hi, In working on the Python 3 port of Sage I ran into a problem with constants defined in sage.symbolic.constants (there are only a few). On Python 2 this works: sage: bool(pi <= pi) True This works fine because the Constant class implements __eq__, and so if asking if pi <= pi that's good

Re: [sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

Hi Friedrich, The way it is defined in the code is consistent with the paper mentioned in the documentation (H. Heys paper on tutorial of differential and linear cryptanalysis) which, I believe, is used by many cryptanalysis researchers or students to learn differential and linear cryptanalysis

[sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

I recently stumbled across the fact that the implementation of SBox().linear_approximation_matrix() returns *scaled* Fourier coefficients. While the documentation says exactly this, i.e., "[the matrix] encodes the bias[es]", my personal intuition is that this matrix should contain the actual

[sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

On Friday, February 16, 2018 at 9:53:10 AM UTC, Simon King wrote: > > On 2018-02-16, Vincent Delecroix <20100.d...@gmail.com > > wrote: > > I isolated a leak in > > > > a = pi * I * RR.one() > > For the record: a = I*RR.one() leaks, a=pi*I resp. a=pi*RR.on() doesn't > leak. > > in

Re: [sage-devel] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

On 2018-02-16 14:05, Eric Gourgoulhon wrote: The build is successful though, as if it was mere warnings and not true errors. They are warnings, not errors. In this case, you can ignore them since you probably don't have gmpy2 installed (it is not a standard package). -- You received this

[sage-devel] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

Hi, After a successful build of Sage 8.2.beta5 (from a fresh git clone, on Ubuntu 16.04), I'm getting the following messages after each command "./sage -b" or "make" issued from the Sage root directory (see full log attached for details): sage/rings/complex_double.pyx: cannot find cimported

Re: [sage-devel] SAGE 8.1 will not compile under Ubuntu 17.10: error installing giac-1.2.3.47.p0

Hi, Le jeudi 15 février 2018 23:59:09 UTC+1, Andy Howell a écrit : > > > I had problems under 17.04. I think I was missing the fortran compiler. > After installing that, it built fine. > > This list of prerequisites to build Sage on Ubuntu is at https://wiki.sagemath.org/prerequisitesUbuntu This

Re: [sage-devel] SAGE 8.1 will not compile under Ubuntu 17.10: error installing giac-1.2.3.47.p0

I have an Ubuntu 17.10, and 8.2 beta 5 compiles without anay problems. May be I must say that I upraded from one version to another with git pull origin develop just issuing make after the git command. But I don't think this could hide some problem. Yours t.d. -- You received this message

Re: [sage-devel] SAGE 8.1 will not compile under Ubuntu 17.10: error installing giac-1.2.3.47.p0

On 02/16/2018 02:40 AM, Jeroen Demeyer wrote: > On 2018-02-15 23:59, Andy Howell wrote: >> I think you may have something else wrong with your system. I too >> upgraded from 17.04 to 17.10. I built 8.2beta 3 with no problems. I'm >> compiling beta 5 right now. > > It would be interesting to see

[sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

On 2018-02-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > I isolated a leak in > > a = pi * I * RR.one() For the record: a = I*RR.one() leaks, a=pi*I resp. a=pi*RR.on() doesn't leak. -- You received this message because you are subscribed to the Google Groups "sage-devel"

[sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

guppy.hpy() finds 149 objects dict of sympy.core.assumptions.ManagedProperties on the heap Not sure where sympy is called here. While doing max() ? On Friday, February 16, 2018 at 7:55:33 AM UTC, Marco Caliari wrote: > > Maybe it was clear, but the offending part is > > g = coef02[M] > for i

Re: [sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

I isolated a leak in a = pi * I * RR.one() I opened #24745 (https://trac.sagemath.org/ticket/24745) Vincent On 16/02/2018 08:55, Marco Caliari wrote: Maybe it was clear, but the offending part is g = coef02[M] for i in [M-1..2,step=-1]: g = x*g+coef02[i] Something like P =

Re: [sage-devel] SAGE 8.1 will not compile under Ubuntu 17.10: error installing giac-1.2.3.47.p0

On 2018-02-15 23:59, Andy Howell wrote: I think you may have something else wrong with your system. I too upgraded from 17.04 to 17.10. I built 8.2beta 3 with no problems. I'm compiling beta 5 right now. It would be interesting to see the output of $ ldd

Re: [sage-devel] SAGE 8.1 will not compile under Ubuntu 17.10: error installing giac-1.2.3.47.p0

On 2018-02-15 22:37, Harald Helfgott wrote: First, here is the output of /usr/lib/gcc/x86_64-linux-gnu/7.2.0$ ldd cc1 linux-vdso.so.1 => (0x7fff8af56000) libisl.so.15 => /usr/lib/x86_64-linux-gnu/libisl.so.15 (0x7fcb74113000) libmpc.so.3 =>

[sage-devel] Re: Sage 8.1 eats memory while 7.5.1 did not

Maybe it was clear, but the offending part is g = coef02[M] for i in [M-1..2,step=-1]: g = x*g+coef02[i] Something like P = PolynomialRing(RRR,"x") g = P(coef02[2:]) works without any problem. On Friday, 9 February 2018 14:44:23 UTC+1, Nils Bruin wrote: > > On Friday, February 9, 2018