Query: GMP completeness testing

[Brad Chamberlain]

Hi Sergey, Torbjorn, and all --

Thanks for the notes on testing/interoperating with GMP.

Sergey, I think your notion of creating your own interface description 
language and then generating prototypes/wrappers/etc. from it makes a lot 
of sense.  Are you currently working on such a description file, or is it 
something you've learned too late in your work to undertake it?  (what I'm 
really asking is: could I use your description of the routines as input to 
an IDL->Chapel translator rather than creating my own?)

Sergey wrote:

> P.S.  Sam Rawlins mentioned that he wants to test same edge cases that
> GMP  team tests. In my opinion, it is unnecessary. Tests for interface
> between some programming language ang GMP and tests for GMP itself are
> two  different  kinds  of tests. GMP already has extensive set of unit
> tests, so the only thing which needs testing is interfacing code.

I would tend to agree with this -- I think for my purposes, it's less 
important to get the mathematical corner cases than it is the interface 
corner cases.  For example, in my first draft I ran into a problem when 
two of the arguments to a GMP function were intended to be identical -- it 
seemed I was incorrectly inserting a copy where I should not have been or 
something like that.  But once I get the interface correct, it seems 
redundant for me to cover all of the tricky math cases that the GMP team 
has tested since I'm still using their code.

> P.P.S.  Where  Chapel is intended to be used? Am I right thinking that
> is  it  language  mostly  for  supercomputers  with A LOT of CPU's and
> distributed memory?

That's the main target, but it's also suitable for desktop multicore 
programming; and we're investigating its applicability to GPU programming 
and other emerging parallel node architectures.

Torbjorn wrote:

> The source-to-C approach is just intermediate, meaning that you plan to 
> go directly to assembly at some point?

We're taking the source-to-C approach primarily for the purposes of 
portability of our implementation -- it's designed to be usable anywhere 
that supports a C compiler, pthreads, and for distributed memory use, the 
Berkeley GASNet communication library.  If Chapel were to catch on, native 
implementations could be developed for specific platforms, but we don't 
have any concrete plans to create such versions for the time being, so it 
will likely be source-to-C for the forseeable future.

> I cannot see how a particular test written in C would be a good test for
> your interface.  Shouldn't you write some rudimentary tests in Chapel,
> exercising all your newly written interfaces?

My thought was to take such a test and port it to Chapel.  I'm 
sufficiently unfamiliar with GMP that for me to write a test that covered 
the entire interface would require more effort than I currently have time 
for.  Chapel is close enough to C that converting an existing C-based test 
to Chapel and comparing the results would be far less effort and give more 
confidence if it was written by a GMP expert.  From the lack of 
suggestions, it sounds as though there is currently no single test which 
sweeps the entire interface, at least that anyone is aware of?

Thanks again,
-Brad