Re: [gawk-devel] MPFR thoughts

[Neil R. Ormos]

Andrew J. Schorr wrote:
> Eric Pruitt wrote:

>> How often do people post messages on the list
>> praising a particular feature? I find MPFR
>> support useful, and I similarly find the
>> "match" function useful, but it never occurred
>> to me that use of either feature warranted
>> proactive communication.

> OK, so it's clear that at least a few people are
> using the MPFR capability.  On the other hand,
> it required extensive patches to gawk's
> internals to add this feature, and it's been
> painful to support. So my question for those
> people who are using MPFR is: how difficult
> would it be for you to use the gawk-mpfr
> extension library instead? That seems like the
> cleaner way for gawk to support MPFR. It's not
> as easy to use, but it allows us to simplify
> core gawk and the extension API.

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.

Comparing the two,

  print x^4 - 4 * y^4 - 4 * y^2

  print mpfr_sub(mpfr_sub(mpfr_pow(x, 4), mpfr_mul(4, mpfr_pow(y, 4))), 4 * y^2)

the latter involves a lot more typing, a lot more parentheses, reordering of 
operations into a functional form, and is a lot harder to read.  And I think 
the second example itself is missing a couple of function calls. 

The functional notation form also defeats one of the very interesting use cases 
of the existing MPFR functionality--easy testing of whether weird results in a 
calculation arise from insufficient precision in the regular double-precision 
floating-point representation.

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.

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.

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

> [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?