update pynac to 0.2.1

[Burcin Erocal]

There is a new pynac version available with patches for #9394, #9834, #9878, #9879, #9881, #9900.

​http://sage.math.washington.edu/home/burcin/pynac/pynac-0.2.1.spkg

Patches from the tickets mentioned above need to be merged to test this.

This package depends on the patches available at #9394, #9878, #9879, #9881, #9900. In turn, the first one of these (#9394) depends on #8568 because of changes in sage/symbolic/random_tests.py. The following patches should be applied before running tests:

• attachment:trac_8568-diff_conversion.take2.patch:ticket:8568​
• attachment:trac_8568-erf-deriv.patch:ticket:8568​
• attachment:trac_8568-fix_doctests.patch:ticket:8568​
• attachment:trac_9394-leading_minus.patch:ticket:9394​
• attachment:trac_9878-zeta_infinity.patch:ticket:9878​
• attachment:trac_9879-hold.patch:ticket:9879​
• attachment:trac_9881-csgn.patch:ticket:9881​
• attachment:trac_9900_conjugate_doctests.patch:ticket:9900​

[Karl-Dieter Crisman]

I'm going to try (!) to review all this soon. Just a point: ​the Pynac website has no mention of this update.

[Karl-Dieter Crisman]

Most of the changesets are pretty obviously related to the tickets in question, and I'll put comments there. Here are a few things which I will put here for archiving which came up in discussion, because a few changesets in Pynac are nonobvious.

> As far as Pynac is concerned:
>
> "Do not generate function.{h,cpp} automatically."  How do I check
> this?  What is the reasoning for this?  How do you test this in the
> Sage library (say, for 13 arguments), as it probably should be?  Why
> do you keep it for (say) 3, but not 4?

You can't check this in the Sage library. The auto generated calls were
something we inherited from GiNaC as a convenience for programming in
C++. Since we use Python, which uses a function call mechanism very
similar to the vector arguments case GiNaC supports, there is no reason
to keep the auto generated functions.

I kept the calls up to 3, since functions implemented in GiNaC use at
least up to 2. I don't know if there is anything which needs 3.

> Are some of these things items you would want to report upstream?    I
> am thinking of the conjugate handling, for instance, or the unsigned
> infinity.  Maybe they come from upstream?

> Changeset 172 - what is that all about?

It just deletes some files from the mercurial repository. They are
generated by autoconf. William just imported everything in the GiNaC
distribution tarball when he started working on pynac. This is just
cleaning up some of that cruft.

Incidentally, we also note that the conjugate handling change came from upstream.

[Karl-Dieter Crisman]

Update for release manager: positive review for all but #9879 and #9900. #9879 awaits a review of the reviewer patch (just because it's somewhat long), and #9900 will be positive review once the reviewer creates a reviewer patch, hopefully sometime tomorrow.

Also, although the Pynac website doesn't mention these changes yet, the changesets ARE available ​here, so it is on the web and not just in Sage :)

[Jean-Pierre Flori]

I only run at the docsets and everything went fine. I'll have a look at #9879 and #9900 later.

[Karl-Dieter Crisman]

Based on the now positively reviewed #9879 and #9900, this should have positive review. Hooray!

[Mitesh Patel]

Is there a special order in which I should merge the Pynac tickets?

[Karl-Dieter Crisman]

I just did them in numerical order when I tried them. Since the ticket #8568 is already closed, I guess that means

• attachment:trac_9394-leading_minus.patch:ticket:9394​
• attachment:trac_9878-zeta_infinity.patch:ticket:9878​
• attachment:trac_9879-hold.patch:ticket:9879​
• attachment:trac_9879-hold-review.patch:ticket:9879​
• attachment:trac_9881-csgn.patch:ticket:9881​
• attachment:trac_9881-csgn-reviewer.patch:ticket:9881​
• attachment:trac_9900_conjugate_doctests-rebase.patch:ticket:9900​
• attachment:trac_9900-reviewer.patch:ticket:9900​

That order should work.

[Mitesh Patel]

Thanks!