pynac-0.3.3

[Ralf Stephan]

Hello,

since there seems no permanent maintainer of Pynac I propose

to do the next release of Pynac. I have already transferred the

source/history as planned to github at:

https://github.com/rwst/pynac

Benjamin Hackl has also made a pull request there for the issue

in #15846 and I'm planning to at least fix some infinity comparison

issues that look easy to fix.

So this is not a hostile but a pragmatic takeover. 8P

Questions would be if you want this transferred to github/sage

and what's needed before the bitbucket can be closed.

Oh, and I'm posting this here because my earlier posting to pynac-devel

was not even moderated.

Regards,

[kcrisman]

since there seems no permanent maintainer of Pynac I propose

to do the next release of Pynac. I have already transferred the

source/history as planned to github at:

https://github.com/rwst/pynac

Ralf, this sounds like a fine idea.  Burcin, I'm sure you have no objections?

One thing I would definitely make sure of is to try to update with the upstream Ginac source as possible.  One reason I never took Pynac over is because I knew I wouldn't have time to sync with (useful) changes upstream, but I think in general we want to do that (also to report there, of course).

 

Benjamin Hackl has also made a pull request there for the issue

in #15846 and I'm planning to at least fix some infinity comparison

issues that look easy to fix.

So this is not a hostile but a pragmatic takeover. 8P

:-)

 

Oh, and I'm posting this here because my earlier posting to pynac-devel

was not even moderated.

Huh! 

[Ralf Stephan]

On Wednesday, April 8, 2015 at 2:55:27 PM UTC+2, kcrisman wrote:

One thing I would definitely make sure of is to try to update with the upstream Ginac source as possible.

Agree. It looks like the last version sync was GiNaC-1.6.2/Pynac-0.2.3

in 2011-May, with one last isolated commit by Alexei Sheplyakov transferred 2012-Feb-28.

 

 One reason I never took Pynac over is because I knew I wouldn't have time to sync with (useful) changes upstream, but I think in general we want to do that (also to report there, of course).

Since the reports there in the past were before the last sync that date would

be relevant for backports too. 

[Burcin Erocal]

On Wed, 8 Apr 2015 05:55:27 -0700 (PDT)
kcrisman <kcri...@gmail.com> wrote:

> > since there seems no permanent maintainer of Pynac I propose
> > to do the next release of Pynac. I have already transferred the
> > source/history as planned to github at:
> > https://github.com/rwst/pynac
> >
> >
> Ralf, this sounds like a fine idea. Burcin, I'm sure you have no
> objections?

It's great that someone is willing to take over maintenance of pynac.
I'd be happy to answer any questions that might come up (about the
historical baggage at least).

I had registered pynac as an organization on github a while ago. I just
sent Ralf an invitation to be an admin. If you're thinking of switching
altogether, it would be good to move the existing issues over from
bitbucket and the web site repository. Write to me personally with an
ssh public key to get access to the web site.

> One thing I would definitely make sure of is to try to update with
> the upstream Ginac source as possible. One reason I never took Pynac
> over is because I knew I wouldn't have time to sync with (useful)
> changes upstream, but I think in general we want to do that (also to
> report there, of course).
>
> > Benjamin Hackl has also made a pull request there for the issue
> > in #15846 and I'm planning to at least fix some infinity comparison
> > issues that look easy to fix.
> >
> > So this is not a hostile but a pragmatic takeover. 8P
> >
> >
> :-)
>
>
> > Oh, and I'm posting this here because my earlier posting to
> > pynac-devel was not even moderated.
> >
>
> Huh!

The pending message list for pynac-devel is empty right now. I don't
recall getting any notices about pending messages. I'll add Ralf as an
admin to the group as well.

Thanks a lot for working on pynac!

Cheers,
Burcin

[Ralf Stephan]

On Wednesday, April 8, 2015 at 9:04:01 PM UTC+2, Burcin Erocal wrote:
> I had registered pynac as an organization on github a while ago. I just
> sent Ralf an invitation to be an admin.

Also there is now
https://github.com/pynac/pynac
with a branch containing the first commits syncing it with current GiNaC.

> If you're thinking of switching
> altogether, it would be good to move the existing issues over from
> bitbucket and the web site repository. Write to me personally with an
> ssh public key to get access to the web site.

The website may take a while but I'll chang the repo link soon.

> The pending message list for pynac-devel is empty right now. I don't
> recall getting any notices about pending messages. I'll add Ralf as an
> admin to the group as well.

Ah thanks.

[Ralf Stephan]

Pynac-0.3.3 will sync to current GiNaC which has a few consequences in the doctests.

Before releasing 0.3.3 it might be good to look at potential changes, in order to check

if they fit into Sage (and possibly revert them before release of 0.3.3).

The following changed behaviour leads to a few fails:

sage: a,b = var('a b')
sage: abs(sqrt(x))
sqrt(abs(x))
sage: sqrt(abs(x)^2)
sqrt(x*conjugate(x))
sage: abs(x)^2
x*conjugate(x)
sage: A = abs((a+I*b))^2
sage: A
(a + I*b)*(conjugate(a) - I*conjugate(b))
sage: A.canonicalize_radical()
a^2 + b^2
sage: imag(A)
0
sage: imag(A.canonicalize_radical())
2*imag_part(a)*real_part(a) + 2*imag_part(b)*real_part(b)
sage:  f = sqrt(abs(x)^2); f.canonicalize_radical()
x

Reason is probably these commits:
https://github.com/pynac/pynac/commit/b645d3c200e74531f735d786259d043cbffe758a

https://github.com/pynac/pynac/commit/565d0c3307b708cc266d27d3d1344e6de9fbc513

So, do we want this?

[kcrisman]

The following changed behaviour leads to a few fails:

sage: a,b = var('a b')
sage: abs(sqrt(x))
sqrt(abs(x))
sage: sqrt(abs(x)^2)
sqrt(x*conjugate(x))
sage: abs(x)^2
x*conjugate(x)

What does Maxima do with these?  I know that there has been endless discussion of what to do with things involving abs, square, and sqrt.

 

sage: A = abs((a+I*b))^2
sage: A
(a + I*b)*(conjugate(a) - I*conjugate(b))
sage: A.canonicalize_radical()
a^2 + b^2

Given the history of radcan I wouldn't necessarily worry about this, though what the previous behavior is would be worth looking at.

 

sage: imag(A)
0
sage: imag(A.canonicalize_radical())
2*imag_part(a)*real_part(a) + 2*imag_part(b)*real_part(b)
sage:  f = sqrt(abs(x)^2); f.canonicalize_radical()
x

Reason is probably these commits:
https://github.com/pynac/pynac/commit/b645d3c200e74531f735d786259d043cbffe758a

https://github.com/pynac/pynac/commit/565d0c3307b708cc266d27d3d1344e6de9fbc513

This one looks worth doctesting, actually, if there is a way to get Py/Ginac's assumption framework operating.

[Ralf Stephan]

On Thursday, April 9, 2015 at 5:19:54 PM UTC+2, kcrisman wrote:

The following changed behaviour leads to a few fails:

sage: a,b = var('a b')
sage: abs(sqrt(x))
sqrt(abs(x))
sage: sqrt(abs(x)^2)
sqrt(x*conjugate(x))
sage: abs(x)^2
x*conjugate(x)

What does Maxima do with these?  I know that there has been endless discussion of what to do with things involving abs, square, and sqrt.

(%i1) abs(sqrt(x));
(%o1)                               sqrt(x)
(%i2) sqrt(abs(x)^2);
(%o2)                               abs(x)
(%i3) abs(x)^2;
                                       2
(%o3)                                 x

 

sage: A = abs((a+I*b))^2
sage: A
(a + I*b)*(conjugate(a) - I*conjugate(b))
sage: A.canonicalize_radical()
a^2 + b^2

Given the history of radcan I wouldn't necessarily worry about this, though what the previous behavior is would be worth looking at.

sage: A

abs(a + I*b)^2

sage: A.canonicalize_radical()

abs(a + I*b)^2

[Vincent Delecroix]

Hello,

I found

sage: abs(sqrt(x))
sqrt(abs(x))

much better than

(%i1) abs(sqrt(x));
(%o1) sqrt(x)

We discussed in #15605 that variables in the symbolic ring should be
thougt as complex variables (if not specified otherwise). The maxima
version is wrong when x is real negative.

What is the answer to

sage: sqrt(abs(x)**2) == abs(x)
sage: abs(x**2)
sage: (-1)^(2/3) # see ticket 15605

Vincent

[Julien Puydt]

Le Thu, 09 Apr 2015 18:38:24 +0200,

I can't help but notice that under the convention that sqrt is a
function from non-negative reals to non-negative reals, what maxima
does makes perfect sense.

Snark on #sagemath

[Vincent Delecroix]

True. Let me add that I did not say that maxima is wrong but that maxima
is wrongly used in Sage. (perhaps implicitly)

[Francois Bissey]

Comments below

> On 10/04/2015, at 04:21, Ralf Stephan <gtr...@gmail.com> wrote:
>
>
>
> On Thursday, April 9, 2015 at 5:19:54 PM UTC+2, kcrisman wrote:
> The following changed behaviour leads to a few fails:
>
> sage: a,b = var('a b')
> sage: abs(sqrt(x))
> sqrt(abs(x))
> sage: sqrt(abs(x)^2)
> sqrt(x*conjugate(x))
> sage: abs(x)^2
> x*conjugate(x)
>
> What does Maxima do with these? I know that there has been endless discussion of what to do with things involving abs, square, and sqrt.
>
> (%i1) abs(sqrt(x));
> (%o1) sqrt(x)
> (%i2) sqrt(abs(x)^2);
> (%o2) abs(x)
> (%i3) abs(x)^2;
> 2
> (%o3) x

That last one is only true if `x` is real. ginac’s answer doesn’t make this
assumption and is more generic than maxima here.

François

[Vincent Delecroix]

The first one is true if `x` is real and non-negative... but

(%i4) abs(sqrt(-x));
(%o4) sqrt(- x)

is true if `x` is real and non-positive...

Vincent

[Eric Gourgoulhon]

Hi,

Le jeudi 9 avril 2015 17:05:38 UTC+2, Ralf Stephan a écrit :

The following changed behaviour leads to a few fails:

sage: sqrt(abs(x)^2)
sqrt(x*conjugate(x))

So, do we want this?

I am a little bit worried to see this: whatever x (real positive, negative or complex), sqrt(abs(x)^2) should *always* return abs(x).
Maxima is correct in this respect:
(%i1) sqrt(abs(x)^2);
(%o1)                               abs(x)

Eric.

[Ralf Stephan]

The answer to Vincent's question:

sage: bool(sqrt(abs(x)**2) == abs(x))
False
sage: abs(x**2)
x*conjugate(x)
sage: (-1)^(2/3)
1

On Friday, April 10, 2015 at 12:58:00 AM UTC+2, Eric Gourgoulhon wrote:

sage: sqrt(abs(x)^2)
sqrt(x*conjugate(x))

So, do we want this?

I am a little bit worried to see this: whatever x (real positive, negative or complex), sqrt(abs(x)^2) should *always* return abs(x).

These two results seem controversial. So, is this enough to revert? Don't the

benefits outweigh the odd outlyer? 

[Jean-Pierre Flori]

I would say to stick with GiNaC behavior within Pynac if we can deal with such behaviors at the Sage level.
That would ease maintenance of Pynac, don't you think?
(I already posted a reply but it seems to have gone wild.)

[kcrisman]

>>
>> (%i1) abs(sqrt(x));
>> (%o1)                               sqrt(x)
>> (%i2) sqrt(abs(x)^2);
>> (%o2)                               abs(x)
>> (%i3) abs(x)^2;
>>                                         2
>> (%o3)                                 x
>
> That last one is only true if `x` is real. ginac’s answer doesn’t make this
> assumption and is more generic than maxima here.

The first one is true if `x` is real and non-negative... but

(%i4) abs(sqrt(-x));
(%o4)                              sqrt(- x)

is true if `x` is real and non-positive...

I suspect that rjf would have some comments along the lines of the current discussion mistaking a symbolic *expression* for a symbolic *function*.  Sage in general usually "wants" a function but a lot of the other software deals with expressions.  I'd be interested in an Axiom or Sympy perspective on this. 

[Ralf Stephan]

On Friday, April 10, 2015 at 10:28:27 AM UTC+2, Jean-Pierre Flori wrote:

I would say to stick with GiNaC behavior within Pynac if we can deal with such behaviors at the Sage level.
That would ease maintenance of Pynac, don't you think?

 Right, especially since changing the domain to real reverts to the previous behaviour:

sage: x=var('x', domain='real')
sage: abs(x**2)
x^2
sage: abs(x)**2
x^2
sage: abs(sqrt(x))
sqrt(abs(x))
sage: a,b = var('a b', domain='real')

sage: A = abs((a+I*b))^2
sage: A

(a + I*b)*(a - I*b)
sage: imag(A.canonicalize_radical())
0

[Ralf Stephan]

http://trac.sagemath.org/ticket/18155