Re: [sage-devel] Re: Adding support for discrete differential geometry for SAGE?

[Thierry]

Hi,

this looks great. One important point that might be missing in the
discussion, especially if you do not have any code written yet, would be
to review existing optimized libraries, that could be interfaced within
Sage, instead of reinventing the wheel, see e.g.
https://doc.sagemath.org/html/en/tutorial/interfaces.html
https://doc.sagemath.org/html/en/thematic_tutorials/cython_interface.html

To mention a few libraries of possible interest:

https://www.cgal.org/
https://polymake.org/
https://dgtal.org/

Ciao,
Thierry




On Tue, Jul 21, 2020 at 10:23:14PM -0700, Siddharth Bhat wrote:
> Hi,
> 
> I've posted two "meta-tickets" with list out the basic discrete 
> differential geometric objects I would be interested to add first. I tried 
> to model it after the SageManifolds meta-ticket 
> 
> 
> 1. Discrete Exterior calculus 
> : 
> https://trac.sagemath.org/ticket/30196#ticket
> 2. Discrete Meshes and duals : 
> https://trac.sagemath.org/ticket/30197#ticket 
> 
> I'm not sure I did this right :) So, should I:
> 1. break out _each_ of the bullet points into a separate ticket
> 2. start working on the "most basic" of them? (For example, let's say 
> adding discrete k-forms)
> 3. Submit code, have it reviewed
> 4. Have code accepted
> 5. Pick new bullet point, goto step 2?
> 
> Thanks a lot,
> ~Siddharth
> 
> 
> On Monday, 20 July 2020 15:05:51 UTC+5:30, Eric Gourgoulhon wrote:
> >
> > Hi,
> >
> > Le lundi 20 juillet 2020 01:17:39 UTC+2, Travis Scrimshaw a écrit :
> >>
> >> Hi Siddharth,
> >>That sounds like a good idea.
> >>
> >
> > +1 !
> >
> > What you will need to do is create a number of tickets to add in the 
> >> corresponding functionality. Once you have a proposal (which you can ask 
> >> questions on said tickets), it will be reviewed, where suggestions and 
> >> comments will be given on possible design decisions.
> >>
> >
> > If not done already, have a look at the Sage Developer's Guide 
> > . FWIW, a kind of summary 
> > adapted to smooth manifolds development is here 
> > .
> >
> > 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/854a399f-21d9-4ead-b70f-fab1fbadd4a0o%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200723075047.sx4im3kzfz4jfio7%40metelu.net.

Re: [sage-devel] Re: Adding support for discrete differential geometry for SAGE?

[Siddharth Bhat]

Hello,

those libraries are very cool! I was unaware of their existence, thanks a 
lot for the pointers.
My only worry is that these libraries as far as I can tell are 
"computational", not "symbolic", so we may lose some nice symbolic analysis 
if we don't reimplement the algorithms
in terms of SAGE objects.

How is this generally dealt with? I assume other components of SAGE also 
face the dichotomy of
(i) use external library that is fast and well tested, but computational
(ii) implement within SAGE to be able to perform symbolic computation

On Thursday, 23 July 2020 at 13:20:51 UTC+5:30 Thierry 
(sage-googlesucks@xxx) wrote:

> Hi,
>
> this looks great. One important point that might be missing in the
> discussion, especially if you do not have any code written yet, would be
> to review existing optimized libraries, that could be interfaced within
> Sage, instead of reinventing the wheel, see e.g.
> https://doc.sagemath.org/html/en/tutorial/interfaces.html
> https://doc.sagemath.org/html/en/thematic_tutorials/cython_interface.html
>
> To mention a few libraries of possible interest:
>
> https://www.cgal.org/
> https://polymake.org/
> https://dgtal.org/
>
> Ciao,
> Thierry
>
>
>
>
> On Tue, Jul 21, 2020 at 10:23:14PM -0700, Siddharth Bhat wrote:
> > Hi,
> > 
> > I've posted two "meta-tickets" with list out the basic discrete 
> > differential geometric objects I would be interested to add first. I 
> tried 
> > to model it after the SageManifolds meta-ticket 
> > 
> > 
> > 1. Discrete Exterior calculus 
> > : 
> > https://trac.sagemath.org/ticket/30196#ticket
> > 2. Discrete Meshes and duals <
> https://trac.sagemath.org/ticket/30197#ticket>: 
> > https://trac.sagemath.org/ticket/30197#ticket 
> > 
> > I'm not sure I did this right :) So, should I:
> > 1. break out _each_ of the bullet points into a separate ticket
> > 2. start working on the "most basic" of them? (For example, let's say 
> > adding discrete k-forms)
> > 3. Submit code, have it reviewed
> > 4. Have code accepted
> > 5. Pick new bullet point, goto step 2?
> > 
> > Thanks a lot,
> > ~Siddharth
> > 
> > 
> > On Monday, 20 July 2020 15:05:51 UTC+5:30, Eric Gourgoulhon wrote:
> > >
> > > Hi,
> > >
> > > Le lundi 20 juillet 2020 01:17:39 UTC+2, Travis Scrimshaw a écrit :
> > >>
> > >> Hi Siddharth,
> > >> That sounds like a good idea.
> > >>
> > >
> > > +1 !
> > >
> > > What you will need to do is create a number of tickets to add in the 
> > >> corresponding functionality. Once you have a proposal (which you can 
> ask 
> > >> questions on said tickets), it will be reviewed, where suggestions 
> and 
> > >> comments will be given on possible design decisions.
> > >>
> > >
> > > If not done already, have a look at the Sage Developer's Guide 
> > > . FWIW, a kind of 
> summary 
> > > adapted to smooth manifolds development is here 
> > > .
> > >
> > > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/854a399f-21d9-4ead-b70f-fab1fbadd4a0o%40googlegroups.com
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/426155c4-944f-41e8-8b13-e13e08efd4fbn%40googlegroups.com.

[sage-devel] Bug or oversight ? install_scripts doesn't install script for singular or mwrank

[Emmanuel Charpentier]

The install-script() utility did install gap and maxima scripts invoking 
sage with the relevant switches and arguments. However, it did not install 
scripts for singular or mwrank (which used to be available the same way).

A cursory look at install_scripts source shows that have_program can find 
Sage's maxima and gap, but not singular nor mwrank. The reason seems that 
$SAGE_LOCAL/bin has both maxima and gap, but neither singular nor mwrank.

However, both can be invoked from the command line : 

charpent@zen-book-flip:~$ sage --singular
 SINGULAR /  Development
 A Computer Algebra System for Polynomial Computations   /   version 
4.1.1
   0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \   Feb 2018
FB Mathematik der Universitaet, D-67653 Kaiserslautern\
> quit;
Auf Wiedersehen.
charpent@zen-book-flip:~$ sage --mwrank
Program mwrank: uses 2-descent (via 2-isogeny if possible) to
determine the rank of an elliptic curve E over Q, and list a
set of points which generate E(Q) modulo 2E(Q).
and finally saturate to obtain generating points on the curve.
For more details see the mwrank documentation.
For details of algorithms see the author's book.

Please acknowledge use of this program in published work, 
and send problems to john.crem...@gmail.com.

Version compiled on Apr  5 2020 at 08:01:18 by GCC 9.3.0
using NTL bigints but no multiprecision floating point
Using multiprecision floating point with 50 bits precision.
Enter curve: 
charpent@zen-book-flip:~$ 


Is that an oversight or is there a good reason not to install the relevant 
binaries-or-scripts in $SAGE_LOCAL/bin ? Or at least as 
command-line-invocable scripts ?

Same question for other command-line-invocable optional binaries, such as 
Macaulay2

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0c8563e0-6b15-4d7a-b8ac-ccb6f19791c0o%40googlegroups.com.

[sage-devel] Re: Bug or oversight ? install_scripts doesn't install script for singular or mwrank

[Matthias Koeppe]

On Thursday, July 23, 2020 at 3:13:22 AM UTC-7, Emmanuel Charpentier wrote:
>
> The install-script() utility did install gap and maxima scripts invoking 
> sage with the relevant switches and arguments. However, it did not 
> install scripts for singular or mwrank (which used to be available the 
> same way).
>
> A cursory look at install_scripts source shows that have_program can find 
> Sage's maxima and gap, but not singular nor mwrank. The reason seems that 
> $SAGE_LOCAL/bin has both maxima and gap, but neither singular nor mwrank.
>

If Sage did not install singular or mwrank in $SAGE_LOCAL/bin, these 
programs were available in your system, typically in /usr/bin or 
/usr/local/bin.

Could you clarify how you are using install_script, in particular into what 
directory you were hoping scripts to be installed, and for what use?



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0f827c95-b77d-43ca-9798-1c4c288e0e4fo%40googlegroups.com.

[sage-devel] continued_fraction seems to leak memory

[Spencer Dembner]

When using continued_fraction to compute denominators of continued fraction 
convergents, I'm encountering what seems to be a memory leak. I'm running 
SageMath 9.0 on Windows 10 64-bit. If I run the following, 

for i in [250,..,260]:
if i%1000 == 0:
print(i);
print(get_memory_usage());
C = continued_fraction(sqrt(i));
C.denominator(100);

then I see memory usage steadily climbing as I iterate through the loop. On 
the other hand, if I initialize sqrt(i) as an algebraic number, memory 
usage is essentially stable:

for i in [250,..,260]:
if i%1000 == 0:
print(i);
print(get_memory_usage());
if sqrt(i) not in QQ:
K. = QuadraticField(i);
C = continued_fraction(sqrti);
C.denominator(100);

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c131816-ea20-493f-9149-f85987e98ad7o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Vincent Delecroix]

Thanks for your report.

Actually, it does not seem to have much to do with continued
fractions but rather with the symbolic ring

sage[4]: for i in [250,..,300]:
...: if i%1000 == 0:
...: print(i);
...: print(get_memory_usage())
...: _ = RIF(sqrt(i))

Le 23/07/2020 à 18:30, Spencer Dembner a écrit :

When using continued_fraction to compute denominators of continued fraction
convergents, I'm encountering what seems to be a memory leak. I'm running
SageMath 9.0 on Windows 10 64-bit. If I run the following,

for i in [250,..,260]:
 if i%1000 == 0:
 print(i);
 print(get_memory_usage());
 C = continued_fraction(sqrt(i));
 C.denominator(100);

then I see memory usage steadily climbing as I iterate through the loop. On
the other hand, if I initialize sqrt(i) as an algebraic number, memory
usage is essentially stable:

for i in [250,..,260]:
 if i%1000 == 0:
 print(i);
 print(get_memory_usage());
 if sqrt(i) not in QQ:
 K. = QuadraticField(i);
 C = continued_fraction(sqrti);
 C.denominator(100);



--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e78346c1-db3b-e28b-f522-ebe760f9b4b4%40gmail.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Spencer Dembner]

Yup- what you wrote gives me the same result as far as climbing memory 
usage.

On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:
>
> Thanks for your report. 
>
> Actually, it does not seem to have much to do with continued 
> fractions but rather with the symbolic ring 
>
> sage[4]: for i in [250,..,300]: 
> ...: if i%1000 == 0: 
> ...: print(i); 
> ...: print(get_memory_usage()) 
> ...: _ = RIF(sqrt(i)) 
>
> Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
> > When using continued_fraction to compute denominators of continued 
> fraction 
> > convergents, I'm encountering what seems to be a memory leak. I'm 
> running 
> > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
> > 
> > for i in [250,..,260]: 
> >  if i%1000 == 0: 
> >  print(i); 
> >  print(get_memory_usage()); 
> >  C = continued_fraction(sqrt(i)); 
> >  C.denominator(100); 
> > 
> > then I see memory usage steadily climbing as I iterate through the loop. 
> On 
> > the other hand, if I initialize sqrt(i) as an algebraic number, memory 
> > usage is essentially stable: 
> > 
> > for i in [250,..,260]: 
> >  if i%1000 == 0: 
> >  print(i); 
> >  print(get_memory_usage()); 
> >  if sqrt(i) not in QQ: 
> >  K. = QuadraticField(i); 
> >  C = continued_fraction(sqrti); 
> >  C.denominator(100); 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ba34b454-5695-4d6c-a570-f9d5d0b28292o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Dave Morris]

Is this the issue that was reported in Trac #27185 
 (defect: sqrt memory leak)?

On Thursday, July 23, 2020 at 3:12:07 PM UTC-6, Spencer Dembner wrote:
>
> Yup- what you wrote gives me the same result as far as climbing memory 
> usage.
>
> On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:
>>
>> Thanks for your report. 
>>
>> Actually, it does not seem to have much to do with continued 
>> fractions but rather with the symbolic ring 
>>
>> sage[4]: for i in [250,..,300]: 
>> ...: if i%1000 == 0: 
>> ...: print(i); 
>> ...: print(get_memory_usage()) 
>> ...: _ = RIF(sqrt(i)) 
>>
>> Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
>> > When using continued_fraction to compute denominators of continued 
>> fraction 
>> > convergents, I'm encountering what seems to be a memory leak. I'm 
>> running 
>> > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
>> > 
>> > for i in [250,..,260]: 
>> >  if i%1000 == 0: 
>> >  print(i); 
>> >  print(get_memory_usage()); 
>> >  C = continued_fraction(sqrt(i)); 
>> >  C.denominator(100); 
>> > 
>> > then I see memory usage steadily climbing as I iterate through the 
>> loop. On 
>> > the other hand, if I initialize sqrt(i) as an algebraic number, memory 
>> > usage is essentially stable: 
>> > 
>> > for i in [250,..,260]: 
>> >  if i%1000 == 0: 
>> >  print(i); 
>> >  print(get_memory_usage()); 
>> >  if sqrt(i) not in QQ: 
>> >  K. = QuadraticField(i); 
>> >  C = continued_fraction(sqrti); 
>> >  C.denominator(100); 
>> > 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1da0986d-2243-4125-89ad-2a011be99dc7o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Spencer Dembner]

It may be related, but I don't think it's exactly the same issue. For 
example, the following, involving no square root, still leaks memory:

for i in [1,..,2]:
if i%100 == 0:
print(i);
print(get_memory_usage());
C = continued_fraction(pi^i);
C.denominator(100);








On Thursday, July 23, 2020 at 4:27:46 PM UTC-5, Dave Morris wrote:
>
> Is this the issue that was reported in Trac #27185 
>  (defect: sqrt memory leak)?
>
> On Thursday, July 23, 2020 at 3:12:07 PM UTC-6, Spencer Dembner wrote:
>>
>> Yup- what you wrote gives me the same result as far as climbing memory 
>> usage.
>>
>> On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:
>>>
>>> Thanks for your report. 
>>>
>>> Actually, it does not seem to have much to do with continued 
>>> fractions but rather with the symbolic ring 
>>>
>>> sage[4]: for i in [250,..,300]: 
>>> ...: if i%1000 == 0: 
>>> ...: print(i); 
>>> ...: print(get_memory_usage()) 
>>> ...: _ = RIF(sqrt(i)) 
>>>
>>> Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
>>> > When using continued_fraction to compute denominators of continued 
>>> fraction 
>>> > convergents, I'm encountering what seems to be a memory leak. I'm 
>>> running 
>>> > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
>>> > 
>>> > for i in [250,..,260]: 
>>> >  if i%1000 == 0: 
>>> >  print(i); 
>>> >  print(get_memory_usage()); 
>>> >  C = continued_fraction(sqrt(i)); 
>>> >  C.denominator(100); 
>>> > 
>>> > then I see memory usage steadily climbing as I iterate through the 
>>> loop. On 
>>> > the other hand, if I initialize sqrt(i) as an algebraic number, memory 
>>> > usage is essentially stable: 
>>> > 
>>> > for i in [250,..,260]: 
>>> >  if i%1000 == 0: 
>>> >  print(i); 
>>> >  print(get_memory_usage()); 
>>> >  if sqrt(i) not in QQ: 
>>> >  K. = QuadraticField(i); 
>>> >  C = continued_fraction(sqrti); 
>>> >  C.denominator(100); 
>>> > 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f29436f8-a4c0-4fc2-86b1-5960ad257a19o%40googlegroups.com.

[sage-devel] Re: Bug or oversight ? install_scripts doesn't install script for singular or mwrank

[John H Palmieri]

On Thursday, July 23, 2020 at 9:31:07 AM UTC-7, Matthias Koeppe wrote:
>
> On Thursday, July 23, 2020 at 3:13:22 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> The install-script() utility did install gap and maxima scripts invoking 
>> sage with the relevant switches and arguments. However, it did not 
>> install scripts for singular or mwrank (which used to be available the 
>> same way).
>>
>> A cursory look at install_scripts source shows that have_program can 
>> find Sage's maxima and gap, but not singular nor mwrank. The reason 
>> seems that $SAGE_LOCAL/bin has both maxima and gap, but neither singular 
>> nor mwrank.
>>
>
> If Sage did not install singular or mwrank in $SAGE_LOCAL/bin, these 
> programs were available in your system, typically in /usr/bin or 
> /usr/local/bin.
>
> Could you clarify how you are using install_script, in particular into 
> what directory you were hoping scripts to be installed, and for what use?
>
>
>
I think the problem, or at least one problem, with Singular is that 
install_scripts checks for "singular" whereas it should check for 
"Singular".


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/05093587-8c13-4070-a700-71e9652e58d9o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Dave Morris]

I think this last example is related to trac #27536 
 (conversion of mathematical 
constant such as pi to RDF leaks memory).  There is still a memory leak 
(but smaller, I think) if pi^i is replaced with pi, but I don't see a 
memory leak if pi^i is replaced with RDF.pi().  I also don't see a leak 
with RDF.pi()^i, but I quickly get a RecursionError ("maximum recursion 
depth exceeded").  I know almost nothing about memory leaks, but I just 
wanted to point out that I noticed some related issues that might possibly 
provide an explanation (and certainly seem to be relevant to a complete 
solution).

On Thursday, July 23, 2020 at 3:39:09 PM UTC-6, Spencer Dembner wrote:
>
> It may be related, but I don't think it's exactly the same issue. For 
> example, the following, involving no square root, still leaks memory:
>
> for i in [1,..,2]:
> if i%100 == 0:
> print(i);
> print(get_memory_usage());
> C = continued_fraction(pi^i);
> C.denominator(100);
>
>
>
>
>
>
>
>
> On Thursday, July 23, 2020 at 4:27:46 PM UTC-5, Dave Morris wrote:
>>
>> Is this the issue that was reported in Trac #27185 
>>  (defect: sqrt memory leak)?
>>
>> On Thursday, July 23, 2020 at 3:12:07 PM UTC-6, Spencer Dembner wrote:
>>>
>>> Yup- what you wrote gives me the same result as far as climbing memory 
>>> usage.
>>>
>>> On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:

 Thanks for your report. 

 Actually, it does not seem to have much to do with continued 
 fractions but rather with the symbolic ring 

 sage[4]: for i in [250,..,300]: 
 ...: if i%1000 == 0: 
 ...: print(i); 
 ...: print(get_memory_usage()) 
 ...: _ = RIF(sqrt(i)) 

 Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
 > When using continued_fraction to compute denominators of continued 
 fraction 
 > convergents, I'm encountering what seems to be a memory leak. I'm 
 running 
 > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
 > 
 > for i in [250,..,260]: 
 >  if i%1000 == 0: 
 >  print(i); 
 >  print(get_memory_usage()); 
 >  C = continued_fraction(sqrt(i)); 
 >  C.denominator(100); 
 > 
 > then I see memory usage steadily climbing as I iterate through the 
 loop. On 
 > the other hand, if I initialize sqrt(i) as an algebraic number, 
 memory 
 > usage is essentially stable: 
 > 
 > for i in [250,..,260]: 
 >  if i%1000 == 0: 
 >  print(i); 
 >  print(get_memory_usage()); 
 >  if sqrt(i) not in QQ: 
 >  K. = QuadraticField(i); 
 >  C = continued_fraction(sqrti); 
 >  C.denominator(100); 
 > 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/99c77db7-5eea-43e2-aa23-2f10dadfc8feo%40googlegroups.com.

[sage-devel] assume() seems to break integrate() in some cases

[Dan Swenson]

When I do:

t.integrate(t, 0, 4*a - a^2) # LaTeX: \int_{0}^{4a - a^2} t dt


I get the correct answer:

1/2*a^4 - 4*a^3 + 8*a^2


But if I first make some assumptions, then the integral fails to evaluate:

assume(a, 'real')
assume(a > 1)
assume(a < 3) # now 0 < a < 4, so 4*a - a^2 > 0
t.integrate(t, 0, 4*a - a^2) # hangs, eventually produces RuntimeError


(To me, the assumptions should make the problem easier, if anything.  But 
instead apparently they make it harder...)

I also get a RuntimeError if, under the above assumptions, I do:

bool(4*a - a^2 > 0)


So maybe the integrate() function is trying to determine which endpoint is 
greater, and that's causing it to hang?  (The top endpoint is greater under 
the given assumptions, but you have to do a bit of algebra to figure that 
out.)  Indeed, a workaround is to first do: assume(4*a - a^2 > 0). 

I have posted a version of this question at 
https://ask.sagemath.org/question/52382/assumption-seems-to-break-integrate-is-this-a-bug/
 
, and there user @eric_g suggests another workaround: 
.integrate(algorithm='sympy').

So, does that mean that this is a problem with Maxima?

I noticed the behavior in Sage 8.6, and @eric_g confirms the behavior in 
Sage 9.2.beta5.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4e77ae06-7f8f-4405-888d-cd1f9aba6ae6o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Nils Bruin]

On Thursday, July 23, 2020 at 3:30:48 PM UTC-7, Dave Morris wrote:
>
> I think this last example is related to trac #27536 
>  (conversion of mathematical 
> constant such as pi to RDF leaks memory).  There is still a memory leak 
> (but smaller, I think) if pi^i is replaced with pi, but I don't see a 
> memory leak if pi^i is replaced with RDF.pi().  I also don't see a leak 
> with RDF.pi()^i, but I quickly get a RecursionError ("maximum recursion 
> depth exceeded").  I know almost nothing about memory leaks, but I just 
> wanted to point out that I noticed some related issues that might possibly 
> provide an explanation (and certainly seem to be relevant to a complete 
> solution).
>
> That could well play a role too, but there are actually objects leaking on 
the python heap, which is not happening with  trac #27536. 
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/53762ffc-ad69-4a0c-8013-9a9904660df1o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Nils Bruin]

On Thursday, July 23, 2020 at 2:39:09 PM UTC-7, Spencer Dembner wrote:
>
> It may be related, but I don't think it's exactly the same issue. For 
> example, the following, involving no square root, still leaks memory:
>
> for i in [1,..,2]:
> if i%100 == 0:
> print(i);
> print(get_memory_usage());
> C = continued_fraction(pi^i);
> C.denominator(100);
>
> It's showing the same behaviour in that there are loads of 
sage.rings.real_mpfi.RealIntervalFieldElement elements piling up, so I 
think it's quite likely that the root cause is something similar to Trac 
#27185 

.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2d083fe7-0975-40ae-b07a-1f49679c8b8fo%40googlegroups.com.

[sage-devel] Re: cryptominisat does not buld on Ubuntu 20.04

[Andrey Novoseltsev]

For the record: NOT installing system libboost-dev allowed cryptominisat to 
be installed in Sage. Good enough solution for me, but the reason I was 
installing libboost-dev was ./configure recommendation...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5056b33c-bf13-4cc6-85fa-751ad99f7765o%40googlegroups.com.

Re: [sage-devel] build errors on void linux

[Nicolo' Piazzalunga]

By the way, I noticed that there is no "latest" tag on the Docker image. 
Perhaps the voidlinux people could add this.


Note that Void Linux is a rolling release.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/644db04f-41fa-11b8-3a6f-4c3d1996587c%40gmail.com.

[sage-devel] Re: Bug or oversight ? install_scripts doesn't install script for singular or mwrank

[Emmanuel Charpentier]

Indeed... Hence the question : What is the "standard" name of (s|S)ingular 
in Unix ? Would "Singular" be an acceptable name or the command-line script 
?

BTW, Singular may have another naming problem : the Jupyter kernel 
installs, but czn't be used :

charpent@zen-book-flip:~$ sage -n jupyter
┌┐
│ SageMath version 9.2.beta5, Release Date: 2020-07-12   │
│ Using Python 3.7.3. Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
Please wait while the Sage Jupyter Notebook server starts...
[I 08:13:51.909 NotebookApp] Using MathJax: nbextensions/mathjax/MathJax.js
[I 08:13:52.427 NotebookApp] Serving notebooks from local directory: 
/home/charpent
[I 08:13:52.427 NotebookApp] The Jupyter Notebook is running at:
[I 08:13:52.427 NotebookApp] 
http://localhost:/?token=7c6b68af04f05f965b5d6e7fe684f793b950c380a857db23
[I 08:13:52.427 NotebookApp] Use Control-C to stop this server and shut 
down all kernels (twice to skip confirmation).
[C 08:13:52.476 NotebookApp] 

To access the notebook, open this file in a browser:
file:///run/user/1000/jupyter/nbserver-342480-open.html
Or copy and paste one of these URLs:

http://localhost:/?token=7c6b68af04f05f965b5d6e7fe684f793b950c380a857db23
[I 08:14:01.238 NotebookApp] Creating new notebook in 
[I 08:14:03.439 NotebookApp] Kernel started: 
8418e993-2a40-46fb-bc34-b0634fae837f
/usr/bin/python: No module named jupyter_kernel_singular
[I 08:14:06.427 NotebookApp] KernelRestarter: restarting kernel (1/5), new 
random ports
/usr/bin/python: No module named jupyter_kernel_singular
[I 08:14:09.442 NotebookApp] KernelRestarter: restarting kernel (2/5), new 
random ports
/usr/bin/python: No module named jupyter_kernel_singular
[I 08:14:12.455 NotebookApp] KernelRestarter: restarting kernel (3/5), new 
random ports
/usr/bin/python: No module named jupyter_kernel_singular
[I 08:14:15.471 NotebookApp] KernelRestarter: restarting kernel (4/5), new 
random ports
/usr/bin/python: No module named jupyter_kernel_singular
[W 08:14:18.484 NotebookApp] KernelRestarter: restart failed
[W 08:14:18.485 NotebookApp] Kernel 8418e993-2a40-46fb-bc34-b0634fae837f 
died, removing from map.
[W 08:15:03.605 NotebookApp] Timeout waiting for kernel_info reply from 
8418e993-2a40-46fb-bc34-b0634fae837f
[E 08:15:03.609 NotebookApp] Error opening stream: HTTP 404: Not Found 
(Kernel does not exist: 8418e993-2a40-46fb-bc34-b0634fae837f)

I have no clue about this one...

Le jeudi 23 juillet 2020 23:54:53 UTC+2, John H Palmieri a écrit :
>
>
>
> On Thursday, July 23, 2020 at 9:31:07 AM UTC-7, Matthias Koeppe wrote:
>>
>> On Thursday, July 23, 2020 at 3:13:22 AM UTC-7, Emmanuel Charpentier 
>> wrote:
>>>
>>> The install-script() utility did install gap and maxima scripts 
>>> invoking sage with the relevant switches and arguments. However, it did 
>>> not install scripts for singular or mwrank (which used to be available 
>>> the same way).
>>>
>>> A cursory look at install_scripts source shows that have_program can 
>>> find Sage's maxima and gap, but not singular nor mwrank. The reason 
>>> seems that $SAGE_LOCAL/bin has both maxima and gap, but neither singular 
>>> nor mwrank.
>>>
>>
>> If Sage did not install singular or mwrank in $SAGE_LOCAL/bin, these 
>> programs were available in your system, typically in /usr/bin or 
>> /usr/local/bin.
>>
>> Could you clarify how you are using install_script, in particular into 
>> what directory you were hoping scripts to be installed, and for what use?
>>
>>
>>
> I think the problem, or at least one problem, with Singular is that 
> install_scripts checks for "singular" whereas it should check for 
> "Singular".
>
>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c8e015a5-ef48-4552-9150-8a429793f06ao%40googlegroups.com.