Re: [sage-devel] Re: SIGSEGV in Maxima

Le vendredi 11 août 2017 11:22:24 UTC+2, Eric Gourgoulhon a écrit : > > Hi, > > Le vendredi 11 août 2017 08:12:42 UTC+2, David Roe a écrit : >> >> Note that this is changed in https://trac.sagemath.org/ticket/23592 >> > > This is not the same part of manifolds code: #23592 >

[sage-devel] Re: SIGSEGV in Maxima

On Sunday, August 13, 2017 at 12:56:44 PM UTC-7, Emmanuel Charpentier wrote: > > The difficulty is general, and bound to a very simple fact : when z is > complex (iL e. not known to be real), z^(1/3) denotes *some* quantity whose > cube is z, with no way to specify which. This ambiguity is lift

[sage-devel] Re: SIGSEGV in Maxima

The difficulty is general, and bound to a very simple fact : when z is complex (iL e. not known to be real), z^(1/3) denotes *some* quantity whose cube is z, with no way to specify which. This ambiguity is lifted when z is known real, where one can specify that, by *convention*, z^(1/3) (or $\s

[sage-devel] Re: SIGSEGV in Maxima

On 2017-08-12, rjf wrote: > seems to me that asking for the "sign" of b^(1/3) in the complex domain > is nonsense. After thinking about this some more, I think maybe you're right -- SIGNDIFF-SPECIAL, which is doing the c^3 - b*c --> c - (b*c)^(1/3) that leads into trouble, should maybe inhibit t

[sage-devel] Re: SIGSEGV in Maxima

On Saturday, August 12, 2017 at 4:50:28 PM UTC-7, rjf wrote: > > seems to me that asking for the "sign" of b^(1/3) in the complex domain > is nonsense. There are 3 cube roots. Let q be one of them; it doesn't > matter which. > then - (1+sqrt(3)*i)*q/2are the other two. Yes, two. because th

[sage-devel] Re: SIGSEGV in Maxima

On 2017-08-12, rjf wrote: > seems to me that asking for the "sign" of b^(1/3) in the complex domain > is nonsense. sign(c - (b*c)^(1/3)) actually was encountered when Maxima was trying to find the sign of some other expression. When domain = complex, SIGNDIFF-SPECIAL alternates between sign(c -

[sage-devel] Re: SIGSEGV in Maxima

seems to me that asking for the "sign" of b^(1/3) in the complex domain is nonsense. There are 3 cube roots. Let q be one of them; it doesn't matter which. then - (1+sqrt(3)*i)*q/2are the other two. Yes, two. because there are two sqrt(3). If you cannot deal with all 3 of them in Sage, th

[sage-devel] Re: SIGSEGV in Maxima

On 2017-08-11, Richard_L wrote: > That's a bit puzzling. In the Sage code, line 36 defines the manifold over > the real field. That is supposed to be inherited by the chart in line 39: > > M = Manifold(1*3,'R^3',field='real',start_index=1) > U = M.open_subset('U') > > Rho. = U.chart("r12:(0,+oo)

[sage-devel] Re: SIGSEGV in Maxima

Clearly Robert has found a bug in maxima. Here's a little test further to my earlier "puzzle": If I write in sage as follows: #$is (equal(-(_SAGE_VAR_r13^2*_SAGE_VAR_r23-_SAGE_VAR_r23^3)/((-_SAGE_VAR_r23^4)+2*_SAGE_VAR_r13^2*_SAGE_VAR_r23^2-_SAGE_VAR_r13^4+_SAGE_VAR_r12^4),0))$ var('r12 r13 r23'

Re: [sage-devel] Re: SIGSEGV in Maxima

Le vendredi 11 août 2017 15:30:08 UTC+2, Richard_L a écrit : > > Eric, > I will be happy to test as soon as source code is modified. Just let me > know. > For sure I will. Thanks. Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsu

[sage-devel] Re: SIGSEGV in Maxima

Le vendredi 11 août 2017 16:21:45 UTC+2, Richard_L a écrit : > > That's a bit puzzling. In the Sage code, line 36 defines the manifold over > the real field. That is supposed to be inherited by the chart in line 39: > > M = Manifold(1*3,'R^3',field='real',start_index=1) > U = M.open_subset('U') >

[sage-devel] Re: SIGSEGV in Maxima

That's a bit puzzling. In the Sage code, line 36 defines the manifold over the real field. That is supposed to be inherited by the chart in line 39: M = Manifold(1*3,'R^3',field='real',start_index=1) U = M.open_subset('U') Rho. = U.chart("r12:(0,+oo) r13:(0,+oo) r23:(0,+oo)") One therefore expe

Re: [sage-devel] Re: SIGSEGV in Maxima

Eric, I will be happy to test as soon as source code is modified. Just let me know. - Richard On Friday, August 11, 2017 at 2:22:24 AM UTC-7, Eric Gourgoulhon wrote: > > Hi, > > Le vendredi 11 août 2017 08:12:42 UTC+2, David Roe a écrit : >> >> Note that this is changed in https://trac.sagemat

Re: [sage-devel] Re: SIGSEGV in Maxima

Hi, Le vendredi 11 août 2017 08:12:42 UTC+2, David Roe a écrit : > > Note that this is changed in https://trac.sagemath.org/ticket/23592 > This is not the same part of manifolds code: #23592 deals with comparison of points (sage.manifolds.point.ManifoldP

Re: [sage-devel] Re: SIGSEGV in Maxima

Note that this is changed in https://trac.sagemath.org/ticket/23592 David On Fri, Aug 11, 2017 at 2:00 AM, Ralf Stephan wrote: > No, from testing it appears equality proofs are needed by 10 doctests > in src/sage/manifolds/differentiable/metric.py > so my idea does not work. > > -- > You receive

[sage-devel] Re: SIGSEGV in Maxima

No, from testing it appears equality proofs are needed by 10 doctests in src/sage/manifolds/differentiable/metric.py so my idea does not work. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving email

[sage-devel] Re: SIGSEGV in Maxima

I think another problem here is that Maxima is called at all. It happens because the manifolds code naively compares two symbolic expressions via '='. This invokes the full equality proof machinery, which is probably not intended: /home/rllozes/sage-8.0/local/lib/python2.7/site-packages/sage/

[sage-devel] Re: SIGSEGV in Maxima

On 2017-08-10, Richard_L wrote: > The following string sent to maxima causes a seg-fault and core dump: > '#$is > (equal(-(_SAGE_VAR_r13^2*_SAGE_VAR_r23-_SAGE_VAR_r23^3)/((-_SAGE_VAR_r23^4)+2*_SAGE_VAR_r13^2*_SAGE_VAR_r23^2-_SAGE_VAR_r13^4+_SAGE_VAR_r12^4),0))$' > Looks like domain:complex a

[sage-devel] Re: SIGSEGV during symbolic substitution on long expressions

Hi, Just providing a feedback. With the pynac you provided, the substitution passes thru without segfault. I noticed the different ordering. Maybe that is the cause for slightly different float coefficients (after expansion) between the old and new codes acting upon my expressions. If you a

[sage-devel] Re: SIGSEGV during symbolic substitution on long expressions

Hi, I posted an updated spkg at http://www.infres.enst.fr/~flori/sage/pynac-0.2.4.spkg This is by no mean an official or definitive package, but it should at least include the mentioned fix. I'm not even sure it is installable or functional. You can simply install it by typing ./sage -i <...>/pyn

[sage-devel] Re: SIGSEGV during symbolic substitution on long expressions

Hi Jean-Pierre, Well, this is first time it try to patch something. All links to pynac spkg seem to be broken on #9880. The ticket is a bit confusing for me to know how can I get the right pynac src or pynac-0.2.1.p0.spkg (?) On sage-4.6.2 the patches were applied with success, but during re-

[sage-devel] Re: SIGSEGV during symbolic substitution on long expressions

This really seems like #9880. The order/copmpare functions in Pynac have been worked on like forever in that ticket but is hopefully nearing completion. Could you try install a new aversion of pynac described there (I mean on ticket 9880) and try your example ? I really do not have the time to buil

[sage-devel] Re: sigsegv in show() command

On Fri, May 1, 2009 at 6:53 AM, mabshoff wrote: > > > > On Apr 30, 10:19 pm, William Stein wrote: >> On Thu, Apr 30, 2009 at 10:15 PM, mabshoff wrote: > > > >> > I think figsize is meant as a scaling factor since otherwise there is >> > no way you can exceed 2^15 as a limit of the png size :)

[sage-devel] Re: sigsegv in show() command

On Apr 30, 10:19 pm, William Stein wrote: > On Thu, Apr 30, 2009 at 10:15 PM, mabshoff wrote: > > I think figsize is meant as a scaling factor since otherwise there is > > no way you can exceed 2^15 as a limit of the png size :) > > I think figsize is the width and height in inches, for som

[sage-devel] Re: sigsegv in show() command

On Thu, Apr 30, 2009 at 10:15 PM, mabshoff wrote: > > > > On Apr 30, 9:55 pm, Minh Nguyen wrote: >> Hi Michael, > > Hi Minh, > > > >> > please open a ticket. I think you might be using figsize wrong, i.e. >> > it isn't supposed to be a list or at least it isn't in MPL. >> >> If I do p.show(figs

[sage-devel] Re: sigsegv in show() command

On Apr 30, 9:55 pm, Minh Nguyen wrote: > Hi Michael, Hi Minh, > > please open a ticket. I think you might be using figsize wrong, i.e. > > it isn't supposed to be a list or at least it isn't in MPL. > > If I do p.show(figsize=[500,500]) then *boom* and I know I'm doing > something wrong as

[sage-devel] Re: sigsegv in show() command

Hi Michael, On Fri, May 1, 2009 at 4:41 AM, mabshoff wrote: > > > > On Apr 30, 9:28 pm, Minh Nguyen wrote: >> Hi folks, > > Hi, > >> I received the following segmentation fault when trying to use the >> show command with complex_plot(): >> >> [mv...@sage ~]$ sage >>

[sage-devel] Re: sigsegv in show() command

On Apr 30, 9:47 pm, Robert Bradshaw wrote: > On Apr 30, 2009, at 9:41 PM, mabshoff wrote: > > please open a ticket. I think you might be using figsize wrong, i.e. > > it isn't supposed to be a list or at least it isn't in MPL. If I pass > > figsize=2 in for example it works. What might happe

[sage-devel] Re: sigsegv in show() command

On Apr 30, 2009, at 9:41 PM, mabshoff wrote: > On Apr 30, 9:28 pm, Minh Nguyen wrote: >> Hi folks, > > Hi, > >> I received the following segmentation fault when trying to use the >> show command with complex_plot(): >> >> [mv...@sage ~]$ sage >> --

[sage-devel] Re: sigsegv in show() command

On Apr 30, 9:28 pm, Minh Nguyen wrote: > Hi folks, Hi, > I received the following segmentation fault when trying to use the > show command with complex_plot(): > > [mv...@sage ~]$ sage > -- > | Sage Version 3.4.1, Release Dat

[sage-devel] Re: SIGSEGV

Hello John, I have rerun massif with a larger example and I might have spoken too early: http://sage.math.washington.edu/home/mabshoff/massif.10927.ps http://sage.math.washington.edu/home/mabshoff/massif.10927.txt I think I somehow cause an overflow, the graph doesn't look particularly correct.

[sage-devel] Re: SIGSEGV

On Sep 19, 2007, at 6:26 PM, John Voight wrote: > > Hi Robert! > > Thanks very much for your message. > >>> That's probably what is going on. My Cython routine creates and >>> returns a list of integers: it's begins as a cdef int[], and >>> apparently it doesn't like it when I just return that,

[sage-devel] Re: SIGSEGV

Hi Robert! Thanks very much for your message. > > That's probably what is going on. My Cython routine creates and > > returns a list of integers: it's begins as a cdef int[], and > > apparently it doesn't like it when I just return that, so I just do > > something silly like > > return [ self

[sage-devel] Re: SIGSEGV

On Sep 19, 2007, at 1:56 PM, John Voight wrote: >> If there are places in you code where you create some temporary >> object >> you should delete it after you are done with it - that might help the >> situation. We can also use a heap & stack profiler to have a closer >> look. > > That's probab

[sage-devel] Re: SIGSEGV

On Sep 19, 10:08 pm, John Voight <[EMAIL PROTECTED]> wrote: > Hi Michael, > > > John's code doesn't leak memory, Sage doesn't outright leak any memory > > (well, more than usual, the is still some "possibly lost" and "still > > reachable". After about an hour on sage.math we are approaching abou

[sage-devel] Re: SIGSEGV

> Check out http://sage.math.washington.edu/home/mabshoff/massif.10502.ps > - the output is from the massif heap profiler. > > The big 100 mb chunk is from libpari and unavoidable. OK, and the other chunks (PyObject_Malloc) don't look like they're growing very much, right? I can save on creating

[sage-devel] Re: SIGSEGV

On Sep 19, 10:56 pm, John Voight <[EMAIL PROTECTED]> wrote: > > If there are places in you code where you create some temporary object > > you should delete it after you are done with it - that might help the > > situation. We can also use a heap & stack profiler to have a closer > > look. > > T

[sage-devel] Re: SIGSEGV

On 9/19/07, John Voight <[EMAIL PROTECTED]> wrote: > > > sage: time enumerate_totallyreal_fields(8,14^8) > > > and after about an hour I got the error message. > > > > What is RAM usage like? It's possible it ran out. > > The RAM required for the algorithm is trivial. In the cases I'm > runnin

[sage-devel] Re: SIGSEGV

> If there are places in you code where you create some temporary object > you should delete it after you are done with it - that might help the > situation. We can also use a heap & stack profiler to have a closer > look. That's probably what is going on. My Cython routine creates and returns a

[sage-devel] Re: SIGSEGV

> More precisely -- what is the RAM *usage*?? Not the theoretical > requirement. SAGE caching already computed fields -- these > are supposed to be weakref's, so get cleaned up when they aren't > referenced, but I've had problems with that.In particular, > if you comment out the three lines

[sage-devel] Re: SIGSEGV

Hi Michael, > John's code doesn't leak memory, Sage doesn't outright leak any memory > (well, more than usual, the is still some "possibly lost" and "still > reachable". After about an hour on sage.math we are approaching about > 1GB of memory consumption. I am not sure how much longer the > comp

[sage-devel] Re: SIGSEGV

Hi Will, > Hey, that code is really pretty. Mind if I include it in Sage soon? That > would make it easier for other people to try it out and contribute back. Thanks! I'd be thrilled. Still working hard on optimization, so since it's only a "secondary" algorithm so to speak, I'd like to wai

[sage-devel] Re: SIGSEGV

On 9/19/07, mabshoff <[EMAIL PROTECTED]> wrote: > > John's code doesn't leak memory, Sage doesn't outright leak any memory > (well, more than usual, the is still some "possibly lost" and "still > reachable". After about an hour on sage.math we are approaching about > 1GB of memory consumption. I a

[sage-devel] Re: SIGSEGV

Hi Will, > Hey, that code is really pretty. Mind if I include it in Sage soon? That > would make it easier for other people to try it out and contribute back. Thanks! I'd be thrilled. Still working hard on optimization, so since it's only a "secondary" algorithm so to speak, I'd like to wai

[sage-devel] Re: SIGSEGV

Well, to summarize: John's code doesn't leak memory, Sage doesn't outright leak any memory (well, more than usual, the is still some "possibly lost" and "still reachable". After about an hour on sage.math we are approaching about 1GB of memory consumption. I am not sure how much longer the comput

[sage-devel] Re: SIGSEGV

On Sep 19, 6:46 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > On 9/19/07, John Voight <[EMAIL PROTECTED]> wrote: > > > Thanks Michael, Hello, > > > The bug only pops up after about an hour of computation. The code is > > http://www.cems.uvm.edu/~voight/tr_data.spyx > > http://www.cems.uv

[sage-devel] Re: SIGSEGV

On 9/19/07, John Voight <[EMAIL PROTECTED]> wrote: > Thanks Michael, > > The bug only pops up after about an hour of computation. The code is > http://www.cems.uvm.edu/~voight/tr_data.spyx > http://www.cems.uvm.edu/~voight/totallyreal.py > and what I ran was > sage: load tr_data.spyx > sa

[sage-devel] Re: SIGSEGV

Thanks Michael, The bug only pops up after about an hour of computation. The code is http://www.cems.uvm.edu/~voight/tr_data.spyx http://www.cems.uvm.edu/~voight/totallyreal.py and what I ran was sage: load tr_data.spyx sage: load totallyreal.py sage: time enumerate_totallyreal_fields(

[sage-devel] Re: SIGSEGV

John Voight wrote: > Hello all-- > Hello John, > I got the following message today: > > > Unhandled SIGSEGV: A segmentation fault occured in SAGE. > This probably occured because a *compiled* component > of SAGE has a bug in it (typic