Re: [sage-devel] Sage & Pari

[Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>]

* Jeroen Demeyer [2011-07-26 11:12]:
> On 2011-07-25 21:57, Karim Belabas wrote:
> > We badly need feedback at a higher level, from developpers or would-be
> > developpers, regarding the features they think are lacking in Pari, and
> > are preventing them from developping in Pari the way they would like to.
> I'm sorry to say this (I would certainly like it the other way) but it
> has happened at least twice to me that I wrote some code for PARI (not
> adding huge new features but some smaller things) and that the response
> from the developers was not really positive.  So I personally do not
> feel very welcome.

I guess it is a misunderstanding: I take a *long* time to process
emails, with maybe 1 day a week at most where I can work on PARI. And I
tend to forget about things when too many items accumulate. This was not
a negative response, only a lack of immediate response until I get the
time to seriously look at what was proposed. (I answer quickly when the
matter is simple and I'm not overloaded with other stuff.)

Bill can testify that maybe 30 to 50 of *his* patches are still in
limbo. We're trying to change our model so that I act less like a
bottleneck. So many things, so little time...

In the meantime, the safe way of making sure that something is not
forgotten is to also send a report to the Bug Tracking System (possibly
with the "wishlist" flag).

I didn't search the mailing lists, but I only remember this from you:

- gcmp1(t_SER) patch, which took a long time to integrate [ Needed to
  change the semantics of t_SER, which were supposed never to be
  *exactly* equal to anything. Had to be done in a consistent way, lots
  of checking involved ]

- polcyclo(, root of unity) patch : the current behavious follows the
  documentation. It would be nice to remove the "avoid roots of unity" 
  restriction, although the function is getting highly complicated for
  such a simple functionnality. I was hoping for a better solution but
  the patch is not rejected, only in limbo because it never made it to
  the Bug Tracking System (my fault).

- addprimes(true primes) suggestion. Was finally implemented this year.

- ask for a way to trap "inverse modulo" errors [ we have a git branch
  implementing this, almost but not quite ready for release ]

- rnfeltabstorel() inconsistency bug report: not directly a problem, but
  those "rnf" functions are very problematic (inefficient and badly
  documented); this is a just a specific instance.

- Gram-Schmidt orthogonalization: we have at least 3 functions for this,
  none of which can be safely exported. Should have made it to the BTS :-(

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`