Mark H Weaver <m...@netris.org> writes: > Don't worry about this. I have a patch set that (among other things) > reimplements scm_i_big2dbl in a much more robust way, with proper > rounding, and without using such low-level GMP accessors. I posted this > patch set to guile-devel on 7 Oct, "[PATCH] Improvements to exact > rationals et al". I will resubmit it soon.
Nice! I take it you mean http://lists.gnu.org/archive/html/guile-devel/2011-10/msg00004.html? Please let me know when you post a new revision. I'm not subscribed to any guile lists. > ni...@lysator.liu.se (Niels Möller) writes: >> 4. mini-gmp has no mp_set_memory_functions. > No, it's much worse than that. If most of the memory being allocated > are bignums, then GC might not be run until the heap is quite large. Will that be a problem in the cases where mini-gmp is relevant? I imagine bignums will usually be at most a dozen limbs, so the storage for limbs should just be a small factor larger than the storage for the mpz_t structs (which are allocated in scheme objects, I assume). > It would be good if you could duplicate the `mp_set_memory_functions' > interface in mini-gmp. I'll consider doing that, then. Are there any alternatives? I guess it should be possible (but maybe inconvenient) to examine the allocation count of each constructed bignum object and inform the gc. I imagine the bignum objects in guile are immutable once created? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
