On 2014-09-26 11:46, Peter Bruin wrote:
At the moment it is not clear to me that starting to track the
development version is the best decision. It's called development
version for a reason...
1) I think the new functionality that it provides (#16931) is very cool
and a good reason to use it.
2) There are precedents: for a long time, we have been using a
development version PARI 2.4.x.
3) Using only stable versions will just postpone these issues: some time
in the future, the next stable PARI will come out, and we would probably
have exactly the same issues and discussions as we have now.
4) There is a large amount of time between major stable PARI releases,
in the order of years. Why wait for such a long time to have new
functionality? Also, the longer we wait, the more work the upgrade will be.
Or we find a different way to solve the respective problems that allows
us to get rid of these patches.
Of course that is possible, but more convoluted in my opinion. I think
the PARI patches are the "right" solution. Let me also mention that they
just add new functionality, they don't break any existing code (in fact,
the opposite is true).
My opinion is that any new patch needs a very good reason to be
included, and that we should try hard to avoid (the appearance of) a
fork; the number theory world is too small for that.
2 patches isn't a fork, maybe I should have avoided that word.
To be honest, I tend to agree with this argument. Once you start
defining arithmetic with infinity, you are asking for trouble because
there isn't one set of semantics that is valid in all or even most
cases; you are also forced to either introduce NaN or accept that
arithmetic operations may throw errors, etc.
My patch only implements the non-controversial cases, anything else is
still an error. Defining arithmetic is not all or nothing.
On the
positive side, the functionality of these scripts is gradually being
moved into the PARI library.
That would of course be the ideal solution, but don't hold your breath
for that...
In this case I would prefer to make a few simple changes to Simon's code
instead of introducing arithmetic with infinity just to fix this problem.
I can see other uses for this arithmetic with infinity and it doesn't
break any existing code, so why not? As I said on pari-dev, if you're
introducing a new object which has essentially no functionality at all,
then why introduce that object in the first place?
That would by my question too. Why write a new function for something
that doesn't seem to be _that_ widely useful, and can easily be
implemented in two lines (ispower() followed by ispseudoprime())?
Because it's convenient to have it as one function and it "completes the
square" with isprime(), ispseudoprime() and isprimepower(). Also, it can
be implemented somewhat more efficiently than ispower()+ispseudoprime(),
but that's of minor concern.
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
