Re: pari-2.2.5.alpha released

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

On Tue, Mar 04, 2003 at 01:01:33PM +0100, Karim BELABAS wrote:
> It's an interesting, but (relatively) long and complicated patch, for which I
> had the following (off-list, unfortunately) lightweight counter-proposal
> [ from Bill, I'm suming it up ]:
> 
> ===========================================================================
> Have a t_TAG wrapper type whose codeword0 is standard, codeword1 is a
> pointer to
> 
> struct pari_tag {
>   const char *name; /* Tag name, e.g "ell", "nf", ... */
>   ...
> }
> 
> and the rest are mantissa GENs [ or long if we add the necessary
> information to 'struct pari_tag' ].
> 
> GP input/output is done via '@', e.g nf@[....], where [....] is the current
> nf object [ exactly as is currently output by nfinit ]. This way, tagged
> object are copy-paste compatible.
> 
> The type-checking routines [ checknf & al ] simply check the tag, then
> discard it. This way all routines can accept and use tagged objects, without
> any modification at this point.
> 
> If some routine [ e.g output ] wants to do some specialized processing, they
> can check for a tag and act accordingly. Extensions can be dealt with by adding
> info to struct pari_tag.

t_EXT is a general framework which makes it *easy* to implement such
custom types.

> Then we could compare and see. I'm not sure yet whether
> both mechanisms conflict orserve orthogonal purposes.

My t_EXT patch *comes* with a precooked EXT-type which implements
about 90% of this functionality ("transparent wrapper with additional
info").  One needs to inherit from this type, then replace the output
routine with one which prepends "nf@" to the stringified form.

My patch does not cover the "input routine" (one which converts a
string nf@[data] to the internal type).  But why not use Nf([data])
instead of nf@[data]?  This is how other type are implemented, and
would not require any change to the parser.

Basically, the only part which may take more than 10 minutes to
implement is a change to checknf() - but this check is not 

> It would be easier if there were a definite application, which would
> use your mechanism.

I really hesitate: there are so many things lacking from PARI which
require addition of a new type.  My patch will not magically enable
them all, but will make it quite easy (with the possible exception of
"h", which would require actual coding of the arithmetic rules) to
implement them:

  a) See above;

  b) Sparse vectors;

  c) Prime list as an array;

  d) Long vectors (longer than 16M on 32-bit machines);

  e) SMALLVEC should have been implemented via this mechanism;

  f) Bit vectors;

  g) Associative arrays (with the index an arbitrary PARI value, as in
     DATA[1 + 2* I]);

  h) Complex algebraic numbers (represented by a pair
     [polynomial_equation, floating_approximation]);

  i) Foreign math library's types which do not survive translation to
     a native PARI type;

  j) Foreign math library's types which are expensive to convert to
     PARI native types and back;

This is just immediately comes to my mind...

> I started working on it then went on to other things (checking the gmp kernel
> in particular...). 2.2.5 was long overdue, and I simply ran out of time. It's
> still in my 'URGENT' stack (together with about 100 other issues
> unfortunately)

As far I'm concerned, my 'URGENT' stack depends on the inclusion of
this patch.  And if I address some of my 'URGENT' stuff, it may happen
that your 'URGENT' stack becomes shorter.  ;-)

> > BTW, now when GMP kernel has made it in, is not it a good time to
> > include my edit of using typedef PARIWORD *GEN instead of long*?  Let
> > me recall that it required pfind, which is available, e.g., on
> >
> >  ilyaz.org/software/perl/scripts/
> 
> Same problem here [ more acute: the patched version contained bugs that needed
> to be fixed ]

Do you know bugs which appear in the PARIWORD==long mode?  I *know*
bugs in this mode which are *fixed* by this patch (wrong prototypes etc)!

The fact that only part of the functionality works in
PARIWORD=longlong is not very fortunate; on the other hand, the patch
does not decrease the choice that the user has.  On the gripping hand,
the "global changes" needed to be done for this patch make it very hard
to fix things *before the patch is applied*.

I have ideas for another pass of by automated tool which would edit
the PARI sources to remove most of the gcc -Wall warnings.  My hope is
addressing the remaining warnings would fix the majority of test
failures.  But again: the nature of this patch (a *lot* of tiny fixes
done by an automated tool) is such that inclusion of it is more or
less mandatory for developing of consequent fixes - two consequent
patches are too interdependent.

Thanks for your attention,
Ilya