Peter Bruin on Sat, 01 Feb 2014 22:16:27 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: bb_field.{sub,div}


Hi Bill,

>> While experimenting with some more linear algebra over finite fields,
>> I noticed that the bb_field structure did not have subtraction and
>> division.  Of course they can be emulated using the other functions,
>> but it would still nice to have them, if only for completeness.
>
> But then the price is paid by whoever need to provide a new bb_field
> instance.

Yes, but there are always one-line implementations of the form

sub(x, y) = add(x, neg(y))
div(x, y) = mul(x, inv(y))

which are trivial to write and can be used until it makes sense to
implement a "real" replacement.

Just out of curiosity, are you actually expecting new bb_field instances
(using Zech logarithms, maybe)?

> It was a design goal of the blackbox interface to require only a
> minimal set of methods to be provided.

I understand that my proposal would change (i.e. enlarge) the interface
and that this should only be done for good reasons.  Also, I do agree
that a minimalistic design is a valuable goal on its own, and I don't
think this interface should become _much_ larger.

I am only proposing to add these methods because it seems to me that
their (potential) usefulness outweighs the small effort needed to
implement them.  At the moment the burden is on the person writing new
routines _using_ the bb_field interface to manually insert the above
identities every time they are needed.

> I am not in favor of adding methods before there are a practical use
> for them.

At least for subtraction there is one (and at the moment admittedly only
one).  Also, I did not make the patch for abstract reasons, but because
I was writing a function gen_matinvimage() (doing as the name suggests)
that would profit from both sub() and div().

Last week I also wrote a bb_field implementation of Strassen's matrix
multiplication algorithm (for personal use; as far as I understand it is
considered to be outside the scope of PARI).  Subtraction (not division,
though) is also quite helpful for that.  So at least from my experience
it would be user-friendly to provide sub() and div() even if there are
currently no direct uses inside the PARI library.

Cheers,

Peter