mini-gmp and mpq

[Daniele Panozzo]

Hi Niels,

> On Feb 18, 2018, at 3:51 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> 
> "Marco Bodrato" <bodrato at mail.dm.unipi.it> writes:
> 
>> Mee too, I'm not sure about the use case... 
> 
> We ought to have some idea about that before adding code.
> 
> Daniele, can you explain?

My use case is for a simple, fall-back solution to deploy gmp on windows (even at the cost of performance). Right now it is hard to compile GMP on windows, and using precompiled binaries for continuous integration is a pain (https://github.com/libigl/libigl/pull/701). I would like to have the option to use a smaller and stand-alone pair of .h/.cpp as a default, and use the “real” gmp as an optional dependency. In this way, the code is much easier to deploy (and still usable for simple cases) and a user will only have to install gmp if required for performance reasons.

Having a small mini-mpq that depends on mini-gmp sounds perfect for my use case!

Thanks,
Daniele

> 
>> Is code duplication always bad? If mini-gmp is a library for prototype,
>> embedded, fallback purposes, then it can contain a specially crafted,
>> compact and easy to use mpq layer.
> 
> I was thinking that if many of the mpq functions are written with simple
> code on top of mpz_ and mpn_ interface provided by both gmp and
> mini-gmp, reuse would make sense.
> 
> But I might be mistaken, e.g, mpq/aors.c look a lot more more complex
> than in your sketch of mini-mpq.c.
> 
> Regards,
> /Niels
> 
> -- 
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.