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

[Ralf Stephan]

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 Expression.__nonzero__(). Please cc me 
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: Sage 8.1 eats memory while 7.5.1 did not

[Ralf Stephan]

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 SAGE_ROOT/local/bin/pip install guppy I 
got

pip is configured with locations that require TLS/SSL, however the ssl 
module in Python is not available.
Collecting guppy
  Could not fetch URL https://pypi.python.org/simple/guppy/: There was a 
problem confirming the ssl certificate: Can't connect to HTTPS URL because 
the SSL module is not available. - skipping
  Could not find a version that satisfies the requirement guppy (from 
versions: )
No matching distribution found for guppy

How did you install guppy?

-- 
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: Errors in GAP small groups library

[David Roe]

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 installed):

g = Gap(use_workspace_cache=False, max_workspace_size=None)
g.eval('SetUserPreference("HistoryMaxLines", 30)')
for pkg in ['GAPDoc', 'ctbllib', 'factint', 'gapdoc', 'grape', 'design',
'toric', 'laguna']:
g.load_package(pkg, verbose=True)
g.save_workspace()
g.quit()

Thanks for the help Dima: my calculations are running smoothly again!
David

On Sat, Feb 17, 2018 at 12:57 AM, David Roe  wrote:

> 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 https://groups.google.com/
> forum/#!topic/sage-support/60HHHL8Bw_8, which I interpret as suggesting
> that CRISP is using LoadDynamicModule. However, searching on
> https://github.com/bh11/crisp, I don't see any calls to that function.
> Is there something else that could be responsible?  Is there a way to use
> CRISP through gap.eval in Sage?
> David
>
> On Fri, Feb 16, 2018 at 11:40 PM, Dima Pasechnik 
> wrote:
>
>> 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:
>> https://www.gap-system.org/pub/gap/gap48/tar.bz2/gap4r8p6_
>> 2016_11_12-14_25.tar.bz2
>> untar it, and copy its pkg/ directory to $SAGEROOT/local/gap/latest/
>>  start Sage's gap by ./sage --gap
>> and do
>> gap> LoadAllPackages();
>> gap> NormalSubgroups(SmallGroup(1458,1180));
>> [ , Group([ f1, f2, f3^2*f4, f5,
>> f6, f7 ]), Group([ f2, f3^2*f4, f4, f5, f6, f7 ]),
>>   Group([ f1, f3^2*f4, f4, f5, f6, f7 ]), Group([ f1, f2*f4*f6, f3^2*f4,
>> f5, f6, f7 ]), Group([ f1, f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]),
>>   Group([ f1, f3^2*f4, f5, f6, f7 ]), Group([ f3^2*f4, f4, f5, f6, f7 ]),
>> Group([ f2*f4*f6, f3^2*f4, f5, f6, f7 ]),
>>   Group([ f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]), Group([ f2, f3^2*f4, f5,
>> f6, f7 ]), Group([ f1, f3^2*f4, f5*f6^2, f7 ]), Group([ f3^2*f4, f5, f6, f7
>> ]),
>>   Group([ f2*f3^2*f4, f3^2*f4^2, f5*f6^2, f6, f7 ]), Group([ f3^2*f4^2,
>> f5*f6^2, f6, f7 ]), Group([ f2*f3*f6*f7, f5*f6^2, f6, f7 ]),
>>   Group([ f2^2*f4*f6^2, f5*f6^2, f6, f7 ]), Group([ f2*f3^2*f4, f5*f6^2,
>> f6, f7 ]), Group([ f5*f6^2, f6, f7 ]), Group([ f3^2*f4, f5*f6^2, f7 ]),
>>   Group([ f3^2*f4^2, f5^2*f6^2, f7 ]), Group([ f5^2*f6^2, f7 ]), Group([
>> f5*f6^2, f7 ]), Group([ f7 ]), Group([  ]) ]
>>
>> --- it works.
>> Note that LoadAllPackages() is necessary, as apparently the GAP code uses
>> one of these packages for these
>> computation without telling us.
>>
>> So this is a sort of bug, yes, in our way of packaging GAP packages (and
>> it's a sort of GAP's bug to call a code from a package
>> without loading it explicitly...)
>> I don't know what package it is yet.
>> It's very early Sat. morning here, I'll have a look at it over the
>> weekend.
>>
>>
>> On Saturday, February 17, 2018 at 3:12:25 AM UTC, 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: gap_console()
>>> ...
>>> gap> NormalSubgroups(SmallGroup(1458,1180));
>>> Error, List Element: [4] must have an assigned value in
>>>   if map[d] > max  then
>>> elm := id;
>>> else
>>> if not IsBound( map[d] )  then
>>> Error( " lies not in group defined by " );
>>> fi;
>>> ll := LeadingExponentOfPcElement( pa, elm );
>>> lr := lc[d];
>>> exp[map[d]] := ll / lr mod ros[d];
>>> elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm
>>> );
>>> fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from
>>> ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap
>>> ) at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
>>> ExponentsOfPcElement( ocr.modulePcgs, x ) at
>>> /home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
>>> ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/
>>> onecohom.gi:339 called from
>>> ocr.listToCocycle( lc ) at /home/roed/sage/local/gap/latest/lib/
>>> grplatt.gi:1926 called from
>>> opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/
>>> grplatt.gi:1932 called from
>>> ...  at line 2 of *stdin*
>>>
>>> Similar problems are occurring with other groups and some other
>>> functions.
>>>

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

[Ralf Stephan]

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 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: How should ordering of constants be defined?

[Ralf Stephan]

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.


Actually Constants.__eq__ is never called here. Pi is an expression not a 
constant. With expression relations ultimately Expression.__nonzero__ does 
all the work. It calls OP(pi.pyobject(), pi.pyobject()) with OP = 
operator.le. This calls Expression._richcmp_(pi, pi, Py_LT) (why?) which 
consults Pynac. Pynac checks if LHS-RHS is trivially zero which it is and 
returns True. No floating point involved, just symbolics.

> So on Python 3 we get: 

>
> sage: bool(pi <= pi) 
> TypeError Traceback (most recent call 
> last) 
> ... 
> TypeError: '<=' not supported between instances of 'Pi' and 'Pi' 
>

This baffles me and I would like to know why the computation differs from 
the above.

-- 
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: Errors in GAP small groups library

[David Roe]

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
https://groups.google.com/forum/#!topic/sage-support/60HHHL8Bw_8, which I
interpret as suggesting that CRISP is using LoadDynamicModule. However,
searching on https://github.com/bh11/crisp, I don't see any calls to that
function.  Is there something else that could be responsible?  Is there a
way to use CRISP through gap.eval in Sage?
David

On Fri, Feb 16, 2018 at 11:40 PM, Dima Pasechnik  wrote:

> 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:
> https://www.gap-system.org/pub/gap/gap48/tar.bz2/
> gap4r8p6_2016_11_12-14_25.tar.bz2
> untar it, and copy its pkg/ directory to $SAGEROOT/local/gap/latest/
>  start Sage's gap by ./sage --gap
> and do
> gap> LoadAllPackages();
> gap> NormalSubgroups(SmallGroup(1458,1180));
> [ , Group([ f1, f2, f3^2*f4, f5,
> f6, f7 ]), Group([ f2, f3^2*f4, f4, f5, f6, f7 ]),
>   Group([ f1, f3^2*f4, f4, f5, f6, f7 ]), Group([ f1, f2*f4*f6, f3^2*f4,
> f5, f6, f7 ]), Group([ f1, f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]),
>   Group([ f1, f3^2*f4, f5, f6, f7 ]), Group([ f3^2*f4, f4, f5, f6, f7 ]),
> Group([ f2*f4*f6, f3^2*f4, f5, f6, f7 ]),
>   Group([ f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]), Group([ f2, f3^2*f4, f5,
> f6, f7 ]), Group([ f1, f3^2*f4, f5*f6^2, f7 ]), Group([ f3^2*f4, f5, f6, f7
> ]),
>   Group([ f2*f3^2*f4, f3^2*f4^2, f5*f6^2, f6, f7 ]), Group([ f3^2*f4^2,
> f5*f6^2, f6, f7 ]), Group([ f2*f3*f6*f7, f5*f6^2, f6, f7 ]),
>   Group([ f2^2*f4*f6^2, f5*f6^2, f6, f7 ]), Group([ f2*f3^2*f4, f5*f6^2,
> f6, f7 ]), Group([ f5*f6^2, f6, f7 ]), Group([ f3^2*f4, f5*f6^2, f7 ]),
>   Group([ f3^2*f4^2, f5^2*f6^2, f7 ]), Group([ f5^2*f6^2, f7 ]), Group([
> f5*f6^2, f7 ]), Group([ f7 ]), Group([  ]) ]
>
> --- it works.
> Note that LoadAllPackages() is necessary, as apparently the GAP code uses
> one of these packages for these
> computation without telling us.
>
> So this is a sort of bug, yes, in our way of packaging GAP packages (and
> it's a sort of GAP's bug to call a code from a package
> without loading it explicitly...)
> I don't know what package it is yet.
> It's very early Sat. morning here, I'll have a look at it over the weekend.
>
>
> On Saturday, February 17, 2018 at 3:12:25 AM UTC, 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: gap_console()
>> ...
>> gap> NormalSubgroups(SmallGroup(1458,1180));
>> Error, List Element: [4] must have an assigned value in
>>   if map[d] > max  then
>> elm := id;
>> else
>> if not IsBound( map[d] )  then
>> Error( " lies not in group defined by " );
>> fi;
>> ll := LeadingExponentOfPcElement( pa, elm );
>> lr := lc[d];
>> exp[map[d]] := ll / lr mod ros[d];
>> elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm );
>> fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from
>> ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap
>> ) at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
>> ExponentsOfPcElement( ocr.modulePcgs, x ) at
>> /home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
>> ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/
>> onecohom.gi:339 called from
>> ocr.listToCocycle( lc ) at /home/roed/sage/local/gap/latest/lib/
>> grplatt.gi:1926 called from
>> opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/
>> grplatt.gi:1932 called from
>> ...  at line 2 of *stdin*
>>
>> Similar problems are occurring with other groups and some other functions.
>>
>> In the interest of finishing my calculation, I tried the following in an
>> attempt to have Sage use a functional GAP:
>>
>> sage: import sage.interfaces.gap
>> sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
>> sage: gap.eval('1+1')
>>
>> which hangs.  Similarly, I tried copying my functional gap installation
>> to $SAGE_LOCAL/gap/ and updating the "latest" symlink; this allows
>> gap_console() to function correctly but gap.eval() still hangs.
>>
>> I don't tend to work with spkgs very often, so I feel like there's
>> probably something simple I'm overlooking.  Any help in installing a
>> functioning gap would be appreciated.  I'm also happy to help investigate
>> what's wrong with our process for installing the small groups library.
>> David
>>
> --
> You received this message because you are subscribed to the 

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

[Dima Pasechnik]

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:
https://www.gap-system.org/pub/gap/gap48/tar.bz2/gap4r8p6_2016_11_12-14_25.tar.bz2
untar it, and copy its pkg/ directory to $SAGEROOT/local/gap/latest/
 start Sage's gap by ./sage --gap
and do
gap> LoadAllPackages();
gap> NormalSubgroups(SmallGroup(1458,1180));
[ , Group([ f1, f2, f3^2*f4, f5, 
f6, f7 ]), Group([ f2, f3^2*f4, f4, f5, f6, f7 ]), 
  Group([ f1, f3^2*f4, f4, f5, f6, f7 ]), Group([ f1, f2*f4*f6, f3^2*f4, 
f5, f6, f7 ]), Group([ f1, f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]), 
  Group([ f1, f3^2*f4, f5, f6, f7 ]), Group([ f3^2*f4, f4, f5, f6, f7 ]), 
Group([ f2*f4*f6, f3^2*f4, f5, f6, f7 ]), 
  Group([ f2^2*f4*f6^2, f3^2*f4, f5, f6, f7 ]), Group([ f2, f3^2*f4, f5, 
f6, f7 ]), Group([ f1, f3^2*f4, f5*f6^2, f7 ]), Group([ f3^2*f4, f5, f6, f7 
]), 
  Group([ f2*f3^2*f4, f3^2*f4^2, f5*f6^2, f6, f7 ]), Group([ f3^2*f4^2, 
f5*f6^2, f6, f7 ]), Group([ f2*f3*f6*f7, f5*f6^2, f6, f7 ]), 
  Group([ f2^2*f4*f6^2, f5*f6^2, f6, f7 ]), Group([ f2*f3^2*f4, f5*f6^2, 
f6, f7 ]), Group([ f5*f6^2, f6, f7 ]), Group([ f3^2*f4, f5*f6^2, f7 ]), 
  Group([ f3^2*f4^2, f5^2*f6^2, f7 ]), Group([ f5^2*f6^2, f7 ]), Group([ 
f5*f6^2, f7 ]), Group([ f7 ]), Group([  ]) ]

--- it works.
Note that LoadAllPackages() is necessary, as apparently the GAP code uses 
one of these packages for these
computation without telling us.

So this is a sort of bug, yes, in our way of packaging GAP packages (and 
it's a sort of GAP's bug to call a code from a package
without loading it explicitly...)
I don't know what package it is yet.
It's very early Sat. morning here, I'll have a look at it over the weekend.
 

On Saturday, February 17, 2018 at 3:12:25 AM UTC, 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: gap_console()
> ...
> gap> NormalSubgroups(SmallGroup(1458,1180));
> Error, List Element: [4] must have an assigned value in
>   if map[d] > max  then
> elm := id;
> else
> if not IsBound( map[d] )  then
> Error( " lies not in group defined by " );
> fi;
> ll := LeadingExponentOfPcElement( pa, elm );
> lr := lc[d];
> exp[map[d]] := ll / lr mod ros[d];
> elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm );
> fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from 
> ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap ) 
> at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
> ExponentsOfPcElement( ocr.modulePcgs, x ) at 
> /home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
> ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/onecohom.gi:339 
> called from
> ocr.listToCocycle( lc ) at /home/roed/sage/local/gap/latest/lib/
> grplatt.gi:1926 called from
> opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/
> grplatt.gi:1932 called from
> ...  at line 2 of *stdin*
>
> Similar problems are occurring with other groups and some other functions.
>
> In the interest of finishing my calculation, I tried the following in an 
> attempt to have Sage use a functional GAP:
>
> sage: import sage.interfaces.gap
> sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
> sage: gap.eval('1+1')
>
> which hangs.  Similarly, I tried copying my functional gap installation to 
> $SAGE_LOCAL/gap/ and updating the "latest" symlink; this allows 
> gap_console() to function correctly but gap.eval() still hangs.
>
> I don't tend to work with spkgs very often, so I feel like there's 
> probably something simple I'm overlooking.  Any help in installing a 
> functioning gap would be appreciated.  I'm also happy to help investigate 
> what's wrong with our process for installing the small groups library.
> David
>

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

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

[David Roe]

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 built from
> source.
> > In particular (using gap_console to get more traceback)
> >
> > sage: gap_console()
> > ...
> > gap> NormalSubgroups(SmallGroup(1458,1180));
> > Error, List Element: [4] must have an assigned value in
> >   if map[d] > max  then
> > elm := id;
> > else
> > if not IsBound( map[d] )  then
> > Error( " lies not in group defined by " );
> > fi;
> > ll := LeadingExponentOfPcElement( pa, elm );
> > lr := lc[d];
> > exp[map[d]] := ll / lr mod ros[d];
> > elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm
> );
> > fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from
> > ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap
> )
> > at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
> > ExponentsOfPcElement( ocr.modulePcgs, x ) at
> > /home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
> > ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/
> onecohom.gi:339
> > called from
> > ocr.listToCocycle( lc ) at
> > /home/roed/sage/local/gap/latest/lib/grplatt.gi:1926 called from
> > opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/
> grplatt.gi:1932
> > called from
> > ...  at line 2 of *stdin*
> >
> > Similar problems are occurring with other groups and some other
> functions.
> >
> > In the interest of finishing my calculation, I tried the following in an
> > attempt to have Sage use a functional GAP:
> >
> > sage: import sage.interfaces.gap
> > sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
> > sage: gap.eval('1+1')
> >
> > which hangs.  Similarly, I tried copying my functional gap installation
> to
> > $SAGE_LOCAL/gap/ and updating the "latest" symlink; this allows
> > gap_console() to function correctly but gap.eval() still hangs.
> >
>
> I'm not sure if this helps, but in 7.6,
>
> gap> NormalSubgroups(SmallGroup(158,1));
> [ Group([  ]), Group([ f2 ]),  ]
>
> and
>
> gap> SmallGroup(1458,1180);
> 
>
> work (but gap> NormalSubgroups(SmallGroup(1458,1180)); fails, as
> stated). Moreover
>
> sage: sage: import sage.interfaces.gap
> : sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
> : sage: gap.eval('1+1')
> :
> '2'


> doesn't hang.
>

What version of GAP do you have there?  I installed gap-4.6.10; maybe I
should try 4.6.8 to be compatible with Sage
David


>
>
> > I don't tend to work with spkgs very often, so I feel like there's
> probably
> > something simple I'm overlooking.  Any help in installing a functioning
> gap
> > would be appreciated.  I'm also happy to help investigate what's wrong
> with
> > our process for installing the small groups library.
> > David
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at 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.
>

-- 
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] Errors in GAP small groups library

[David Joyner]

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: gap_console()
> ...
> gap> NormalSubgroups(SmallGroup(1458,1180));
> Error, List Element: [4] must have an assigned value in
>   if map[d] > max  then
> elm := id;
> else
> if not IsBound( map[d] )  then
> Error( " lies not in group defined by " );
> fi;
> ll := LeadingExponentOfPcElement( pa, elm );
> lr := lc[d];
> exp[map[d]] := ll / lr mod ros[d];
> elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm );
> fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from
> ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap )
> at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
> ExponentsOfPcElement( ocr.modulePcgs, x ) at
> /home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
> ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/onecohom.gi:339
> called from
> ocr.listToCocycle( lc ) at
> /home/roed/sage/local/gap/latest/lib/grplatt.gi:1926 called from
> opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/grplatt.gi:1932
> called from
> ...  at line 2 of *stdin*
>
> Similar problems are occurring with other groups and some other functions.
>
> In the interest of finishing my calculation, I tried the following in an
> attempt to have Sage use a functional GAP:
>
> sage: import sage.interfaces.gap
> sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
> sage: gap.eval('1+1')
>
> which hangs.  Similarly, I tried copying my functional gap installation to
> $SAGE_LOCAL/gap/ and updating the "latest" symlink; this allows
> gap_console() to function correctly but gap.eval() still hangs.
>

I'm not sure if this helps, but in 7.6,

gap> NormalSubgroups(SmallGroup(158,1));
[ Group([  ]), Group([ f2 ]),  ]

and

gap> SmallGroup(1458,1180);


work (but gap> NormalSubgroups(SmallGroup(1458,1180)); fails, as
stated). Moreover

sage: sage: import sage.interfaces.gap
: sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
: sage: gap.eval('1+1')
:
'2'

doesn't hang.


> I don't tend to work with spkgs very often, so I feel like there's probably
> something simple I'm overlooking.  Any help in installing a functioning gap
> would be appreciated.  I'm also happy to help investigate what's wrong with
> our process for installing the small groups library.
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at 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] Errors in GAP small groups library

[David Roe]

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 Element: [4] must have an assigned value in
  if map[d] > max  then
elm := id;
else
if not IsBound( map[d] )  then
Error( " lies not in group defined by " );
fi;
ll := LeadingExponentOfPcElement( pa, elm );
lr := lc[d];
exp[map[d]] := ll / lr mod ros[d];
elm := LeftQuotientPowerPcgsElement( pcgs, map[d], exp[map[d]], elm );
fi; at /home/roed/sage/local/gap/latest/lib/pcgsind.gi:1411 called from
ExponentsOfPcElement( NumeratorOfModuloPcgs( pcgs ), elm, pcgs!.depthMap )
at /home/roed/sage/local/gap/latest/lib/pcgsmodu.gi:931 called from
ExponentsOfPcElement( ocr.modulePcgs, x ) at
/home/roed/sage/local/gap/latest/lib/onecohom.gi:264 called from
ocr.moduleMap( n ) at /home/roed/sage/local/gap/latest/lib/onecohom.gi:339
called from
ocr.listToCocycle( lc ) at /home/roed/sage/local/gap/latest/lib/
grplatt.gi:1926 called from
opr( Zero( vs ), k ) at /home/roed/sage/local/gap/latest/lib/grplatt.gi:1932
called from
...  at line 2 of *stdin*

Similar problems are occurring with other groups and some other functions.

In the interest of finishing my calculation, I tried the following in an
attempt to have Sage use a functional GAP:

sage: import sage.interfaces.gap
sage: sage.interfaces.gap.gap_cmd = "/home/roed/gap4r8/bin/gap.sh"
sage: gap.eval('1+1')

which hangs.  Similarly, I tried copying my functional gap installation to
$SAGE_LOCAL/gap/ and updating the "latest" symlink; this allows
gap_console() to function correctly but gap.eval() still hangs.

I don't tend to work with spkgs very often, so I feel like there's probably
something simple I'm overlooking.  Any help in installing a functioning gap
would be appreciated.  I'm also happy to help investigate what's wrong with
our process for installing the small groups library.
David

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

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

[François Bissey]

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 in favour of some in
SAGE_LOCAL/lib/

François

> On 17/02/2018, at 12:32, Luca De Feo  wrote:
> 
> Hello,
> 
> I'm having trouble compiling 8.2.beta5 on Arch. Compiling with `make
> build -k`: flint and r fail, because of some weird missing symbol in
> libguile-2.2
> 
>make: symbol lookup error: /usr/lib/libguile-2.2.so.1: undefined
> symbol: GC_move_disappearing_link
> 
> I don't even understand where Guile is supposed to be used. I can
> compile flint alone without problems. Any ideas?
> 
> I'm attaching the logs.
> 
> Cheers,
> Luca
> 
> -- 
> 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: How should ordering of constants be defined?

[Volker Braun]

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 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 enough for it. 
>
> However, on Python 3 <= will explicitly call __le__ if it's defined 
> and raise a TypeError otherwise.  Or at the very least __lt__ must be 
> implemented, and with __eq__ and __lt__ defined it's possible to 
> derive the other comparison operators. 
>
> So on Python 3 we get: 
>
> sage: bool(pi <= pi) 
> TypeError Traceback (most recent call 
> last) 
> ... 
> TypeError: '<=' not supported between instances of 'Pi' and 'Pi' 
>
> So I could define __lt__ between Constants and fix this.  The question 
> is how it should be defined.  That is, to what level of precision? 
> For the constants we have defined, taking their float values should be 
> good enough for comparison between constants.  But I'm not sure if 
> that's good enough in general...? 
>
> Thanks, 
> E 
>

-- 
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] [Crypto] S-box Linear Approximation Matrix scaling

[Samuel Lelievre]

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: S.linear_approximation_matrix(scaled=True)

to get the scaled matrix, and

sage: S.linear_approximation_matrix(scaled=False)

to get the unscaled matrix.

-- 
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] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

[Eric Gourgoulhon]

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 should be some warnings if it 
is not installed?
This is new in 8.2.beta5.
 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[robert . pollack]

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 ()
> 1 (x**Integer(4)-Integer(1)).factor()
 
/ext/sage/sage-8.1/src/sage/rings/polynomial/polynomial_element.pyx in 
sage.rings.polynomial.polynomial_element.Polynomial.factor 
(build/cythonized/sage/rings/polynomi
al/polynomial_element.c:39428)()
   4127 # polynomial instead.
   4128 Rpari = R.pari_polynomial("y")
-> 4129 G = list(Rpari.nffactor(f))
   4130 
# PARI's nffactor() ignores the unit, _factor_pari_helper()
   4131 # adds back the unit of the factorization.
 
cypari2/auto_gen.pxi in cypari2.gen.Gen_auto.nffactor()
 
cypari2/handle_error.pyx in cypari2.handle_error._pari_err_handle()
 
PariError: inconsistent concatenation t_VEC (2 elts) , t_COL (2 elts)

-- 
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] How should ordering of constants be defined?

[Erik Bray]

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 enough for it.

However, on Python 3 <= will explicitly call __le__ if it's defined
and raise a TypeError otherwise.  Or at the very least __lt__ must be
implemented, and with __eq__ and __lt__ defined it's possible to
derive the other comparison operators.

So on Python 3 we get:

sage: bool(pi <= pi)
TypeError Traceback (most recent call last)
...
TypeError: '<=' not supported between instances of 'Pi' and 'Pi'

So I could define __lt__ between Constants and fix this.  The question
is how it should be defined.  That is, to what level of precision?
For the constants we have defined, taking their float values should be
good enough for comparison between constants.  But I'm not sure if
that's good enough in general...?

Thanks,
E

-- 
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] [Crypto] S-box Linear Approximation Matrix scaling

[Rusydi H. Makarim]

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
for the first time. Together with the paper, SageMath can be a companion
educational tool for introducing the concept of linear and differential
cryptanalysis. In that respect i think its more beneficial to change its
description in the documentation rather than changing the function.

Regards,
Rusydi

On 16-02-18 15:55, Friedrich Wiemer wrote:
> 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 Fourier coefficients.
> In fact, the matrix is computed using the Fourier-Walsh transform for
> each component function and then scales the resulting matrix
> accordingly. On the other side, this scaling is then for other methods
> reversed (e.g. in the `nonlinearity` and `linearity` method).
>
> Of course, my argument is basically only personal taste, but my
> feeling is that containing the /unscaled/ Fourier coefficients is,
> what one would assume when only looking at the API and not at the
> documentation.
> So, I propose to change this, but would like to hear your opinions on
> 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.

-- 
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] [Crypto] S-box Linear Approximation Matrix scaling

[Friedrich Wiemer]

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 Fourier coefficients.
In fact, the matrix is computed using the Fourier-Walsh transform for each 
component function and then scales the resulting matrix accordingly. On the 
other side, this scaling is then for other methods reversed (e.g. in the 
`nonlinearity` and `linearity` method).

Of course, my argument is basically only personal taste, but my feeling is 
that containing the *unscaled* Fourier coefficients is, what one would 
assume when only looking at the API and not at the documentation.
So, I propose to change this, but would like to hear your opinions on 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] Re: Sage 8.1 eats memory while 7.5.1 did not

[Dima Pasechnik]

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 the original example, removing '*I'  from the line "disk = ..." still 
produces a leak.
So there are >1 leaks...
 

-- 
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] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

[Jeroen Demeyer]

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 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] "cannot find cimported module 'gmpy2'" when building Sage 8.2.beta5

[Eric Gourgoulhon]

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 module 'gmpy2'
sage/rings/complex_number.pyx: cannot find cimported module 'gmpy2'
sage/rings/integer.pyx: cannot find cimported module 'gmpy2'
sage/rings/complex_mpc.pyx: cannot find cimported module 'gmpy2'
sage/rings/rational.pyx: cannot find cimported module 'gmpy2'
sage/rings/real_double.pyx: cannot find cimported module 'gmpy2'
sage/rings/real_mpfr.pyx: cannot find cimported module 'gmpy2'

The build is successful though, as if it was mere warnings and not true 
errors.  
I don't have this issue with Sage 8.2.beta4.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
cd . && export\
SAGE_ROOT=/doesnotexist   \
SAGE_SRC=/doesnotexist\
SAGE_SRC_ROOT=/doesnotexist   \
SAGE_DOC_SRC=/doesnotexist\
SAGE_BUILD_DIR=/doesnotexist  \
SAGE_PKGS=/home/eric/sage/8.2.beta5/build/pkgs\
&& sage-python23 -u setup.py --no-user-cfg build install
Discovering Python/Cython source code
Discovered Python/Cython sources, time: 0.04 seconds.
running build
Generating auto-generated sources
Building interpreters for fast_callable
running build_cython
Enabling Cython debugging support
Updating Cython code
sage/rings/complex_double.pyx: cannot find cimported module 'gmpy2'
sage/rings/complex_number.pyx: cannot find cimported module 'gmpy2'
sage/rings/integer.pyx: cannot find cimported module 'gmpy2'
sage/rings/complex_mpc.pyx: cannot find cimported module 'gmpy2'
sage/rings/rational.pyx: cannot find cimported module 'gmpy2'
sage/rings/real_double.pyx: cannot find cimported module 'gmpy2'
sage/rings/real_mpfr.pyx: cannot find cimported module 'gmpy2'
Finished Cythonizing, time: 1.70 seconds.
running build_py
running build_ext
Executing 0 commands (using 1 thread)
Time to execute 0 commands: 0.11 seconds.
Total time spent compiling C/C++ extensions: 0.15 seconds.
running install
running install_lib
running install_egg_info
Removing 
/home/eric/sage/8.2.beta5/local/lib/python2.7/site-packages/sage-8.2.beta5-py2.7.egg-info
Writing 
/home/eric/sage/8.2.beta5/local/lib/python2.7/site-packages/sage-8.2.beta5-py2.7.egg-info
Cleaning up stale installed files
- cleaning build/lib.linux-x86_64-2.7
- cleaning /home/eric/sage/8.2.beta5/local/lib/python2.7/site-packages
Finished cleaning, time: 0.11 seconds.
if [ "$UNAME" = "CYGWIN" ]; then \
sage-rebase.sh "$SAGE_LOCAL" 2>/dev/null;\
fi

real0m3.255s
user0m2.624s
sys 0m0.452s

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

[Eric Gourgoulhon]

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 is currently for Ubuntu 16.04. Let me encourage people taking part in 
this thread to update it to Ubuntu 17.10 and possibly 18.04. 

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

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

[Thierry Dumont]

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

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

[Andy Howell]

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 the output of
>
> $ ldd /usr/lib/gcc/x86_64-linux-gnu/7.2.0/cc1
>
> on your system. If libmpfr appears twice, it is really a bug in Ubuntu.
>
Looks OK here:

ldd /usr/lib/gcc/x86_64-linux-gnu/7.2.0/cc1
    linux-vdso.so.1 =>  (0x7fff551a7000)
    libisl.so.15 => /usr/lib/x86_64-linux-gnu/libisl.so.15
(0x7f92bab37000)
    libmpc.so.3 => /usr/lib/x86_64-linux-gnu/libmpc.so.3
(0x7f92ba91f000)
    libmpfr.so.4 => /usr/lib/x86_64-linux-gnu/libmpfr.so.4
(0x7f92ba6ba000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
(0x7f92ba43a000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f92ba236000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f92ba019000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f92b9cc3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f92b98e3000)
    /lib64/ld-linux-x86-64.so.2 (0x7f92baebd000)

Andy

-- 
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: Sage 8.1 eats memory while 7.5.1 did not

[Simon King]

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" 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: Sage 8.1 eats memory while 7.5.1 did not

[Dima Pasechnik]

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 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 at 11:03:11 AM UTC, Marco Caliari wrote:
>>>
>>> Hi, the following script
>>>
>>> def test(m,c,precision):
>>> M = 3*m
>>> RRR = RealField(prec = precision)
>>> coef02 = [RRR(1/i) for i in [1..M+1]]
>>> g = coef02[M]
>>> for i in [M-1..2,step=-1]:
>>> g = x*g+coef02[i]
>>> ME = 32
>>> disk = [exp (2*pi.n(precision)*I*i/ME) for i in range(ME)]
>>> epsilon1 = max([abs(g(x=z)) for z in disk])
>>> return
>>> m = 40
>>> for c in [1/2..10,step=1/2]:
>>> for ell in [1..10]:
>>> test(m,c,165)
>>>
>>> Indeed, comparing the objects on the heap that weren't there before the 
>> loop I find:
>>
>> [(, 1),
>>  (, 1),
>>  (, 1),
>>  (, 1),
>>  (, 1),
>>  (, 3),
>>  (, 3),
>>  (, 3),
>>  (, 28),
>>  (, 6200),
>>  (, 2),
>>  (, 1457000)]
>>
>> The real numbers mostly seem to be approximations to pi. Using 
>> objgraph.show_backrefs I'm not getting anything useful. We're definitely 
>> leaking but I wasn't able to identify a cache that's keeping references. Is 
>> that any change that we're doing something wrong with an INCREF/DECREF ?
>>
>

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

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

[Vincent Delecroix]

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 = 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 at 11:03:11 AM UTC, Marco Caliari wrote:


Hi, the following script

def test(m,c,precision):
 M = 3*m
 RRR = RealField(prec = precision)
 coef02 = [RRR(1/i) for i in [1..M+1]]
 g = coef02[M]
 for i in [M-1..2,step=-1]:
 g = x*g+coef02[i]
 ME = 32
 disk = [exp (2*pi.n(precision)*I*i/ME) for i in range(ME)]
 epsilon1 = max([abs(g(x=z)) for z in disk])
 return
m = 40
for c in [1/2..10,step=1/2]:
 for ell in [1..10]:
 test(m,c,165)

Indeed, comparing the objects on the heap that weren't there before the

loop I find:

[(, 1),
  (, 1),
  (, 1),
  (, 1),
  (, 1),
  (, 3),
  (, 3),
  (, 3),
  (, 28),
  (, 6200),
  (, 2),
  (, 1457000)]

The real numbers mostly seem to be approximations to pi. Using
objgraph.show_backrefs I'm not getting anything useful. We're definitely
leaking but I wasn't able to identify a cache that's keeping references. Is
that any change that we're doing something wrong with an INCREF/DECREF ?





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

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

[Jeroen Demeyer]

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 /usr/lib/gcc/x86_64-linux-gnu/7.2.0/cc1

on your system. If libmpfr appears twice, it is really a bug in Ubuntu.

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

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

[Jeroen Demeyer]

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 => /usr/lib/x86_64-linux-gnu/libmpc.so.3
(0x7fcb73efb000)
 libmpfr.so.4 => /usr/lib/x86_64-linux-gnu/libmpfr.so.4
(0x7fcb73c96000)
 libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
(0x7fcb73a15000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fcb73811000)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fcb735f4000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fcb7329e000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcb72ebe000)
 /lib64/ld-linux-x86-64.so.2 (0x7fcb74499000)
 libmpfr.so.6 => /usr/lib/x86_64-linux-gnu/libmpfr.so.6
(0x7fcb72c3e000)


To expand on what François said: this is already problematic because it 
links to two different versions of libmpfr. So it has nothing to do with 
Sage, your system compiler is broken. If your GCC package up-to-date in 
Ubuntu?



Do you mean that I will have compile problems when working on my own programs, 
without sage?


Yes, although most programs can be compiled without hitting that bug. In 
Sage, only giac breaks as far as I know.


--
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: Sage 8.1 eats memory while 7.5.1 did not

[Marco Caliari]

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 at 11:03:11 AM UTC, Marco Caliari wrote:
>>
>> Hi, the following script
>>
>> def test(m,c,precision):
>> M = 3*m
>> RRR = RealField(prec = precision)
>> coef02 = [RRR(1/i) for i in [1..M+1]]
>> g = coef02[M]
>> for i in [M-1..2,step=-1]:
>> g = x*g+coef02[i]
>> ME = 32
>> disk = [exp (2*pi.n(precision)*I*i/ME) for i in range(ME)]
>> epsilon1 = max([abs(g(x=z)) for z in disk])
>> return
>> m = 40
>> for c in [1/2..10,step=1/2]:
>> for ell in [1..10]:
>> test(m,c,165)
>>
>> Indeed, comparing the objects on the heap that weren't there before the 
> loop I find:
>
> [(, 1),
>  (, 1),
>  (, 1),
>  (, 1),
>  (, 1),
>  (, 3),
>  (, 3),
>  (, 3),
>  (, 28),
>  (, 6200),
>  (, 2),
>  (, 1457000)]
>
> The real numbers mostly seem to be approximations to pi. Using 
> objgraph.show_backrefs I'm not getting anything useful. We're definitely 
> leaking but I wasn't able to identify a cache that's keeping references. Is 
> that any change that we're doing something wrong with an INCREF/DECREF ?
>

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