Re: [gawk-devel] MPFR thoughts

[arnold]

Hi.

"Neil R. Ormos" <ormos-gnulists17@ormos.org> wrote:

> As I understand the documentation for the gawk-mpfr extension library,
> writing code using the library is quite a bit more difficult than it
> is using the "-M" functionality where the MPFR operations overload the
> regular Gawk numeric operations.

This is a cogent argument.  You make some other good points, which I
acknowledge but won't quote.

> If someone is writing a big program from scratch, it may not be that much
> of an impediment to construct it to use the functional forms from the
> beginning--some might urge that the problem analysis reguired to write
> the problem in functional form is required anyway.  But the functional
> form does not lend itself to quick prototyping and exploration as does
> the current -M operator overloading does.

Acknowledged.

> And if someone were writing a big program from scratch so as to justify
> the effort of using the MPFR extension library, I wonder if gawk would
> be the language of choice.

I believe not. I think someone who wants to do serious MP calculations
would use a language with serious support, like numpy/scipy or R.

> Perhaps someone could write a preprocessor that would reliably convert
> regular inline expressions into the functional format required by the
> gawk-mpfr library.

That could be done in gawk itself, by modifying the pretty printing
code.  I don't think though that I'd actually do this.  I *might*
accept a patch to do it.

> > [MPFR extension library] allows us to simplify
> > core gawk and the extension API.
>
> Could the problem of simplicity be materially improved by requiring
> users to select either:
>   (a) the -M MPFR features; or 
>   (b) access to extensions; 
> in any one run of Gawk?

No.  The complexity of MPFR comes from the fact that the gawk code base
has on the order of 85 special cases to handle MPFR versus non-MPFR.
The feature reaches its tentacles into every part of the code.

After over a decade, there are still bugs in it, and the issue is
the cost in *my* time to maintain it.  I firmly believe that the
amount of use the feature sees by legitimate users is essentially
neglible, and thus the ROI for the feature isn't worthwhile.

I have no way to prove this, of course, except by deprecating the
feature and seeing what happens.  Nobody has volunteered to maintain
the feature, so (unless that changes) I will proceed as planned.

Thanks,

Arnold