mini-gmp and mpq
panozzo at nyu.edu
Sun Feb 18 00:37:40 UTC 2018
> On Feb 17, 2018, at 5:24 PM, Marco Bodrato <bodrato at mail.dm.unipi.it> wrote:
> Il Mer, 14 Febbraio 2018 10:08 pm, Niels Möller ha scritto:
>>> Il Mer, 14 Febbraio 2018 7:53 pm, Marco Bodrato ha scritto:
>>>> It shouldn't be too difficoult to add the mpq layer; at least if you
>>>> need to deal with floats types nor strings.
>> I'm not sure what the use case was. I guess one could add an mpq.c
>> source file to the mini-gmp directory with mpq functions (that seems
> Mee too, I'm not sure about the use case... but a mini-mpq.[ch] couple of
> files seems easy to write. And should be easy to use.
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!
>> But another alternative with less code duplication might be to try to
>> build the existing mpq code, using mini-gmp for the underlying integer
> 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.
>> the code uses very few mpn
>> functions, mpn_cmp, mpn_mul, mpn_tdiv_qr, mpn_get_d, mpn_rshift. Of
>> these, mpn_get_d and mpn_tdiv_qr are not provided by mini-gmp.
> But it also uses macros as MPZ_TMP_INIT, count_trailing_zeros...
> And I don't think it's a good idea to have code in GMP that, if changed,
> can brake a use of mini-gmp.
More information about the gmp-devel