[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5790: Rational conversion clean-up (issue 573570043 by address
From: |
dak |
Subject: |
Re: Issue 5790: Rational conversion clean-up (issue 573570043 by address@hidden) |
Date: |
Tue, 25 Feb 2020 02:35:56 -0800 |
On 2020/02/25 08:07:14, hanwenn wrote:
> LGTM
>
> (I wonder if we should bite the bullet and use uint64_t iso. U64.)
Just for the record: the big bullet would be a Simple_smob wrapper class
around Guile's rational data type. Showstopper in the current setup:
Moments in data structures contain rationals and would need to get
heap-marked, but the Midi data structures are not memory-managed by
Scheme. Even the non-showstopper parts would be quite a bit of work.
Workaround/migration strategy could be a variant adding itself into a
doubly-linked list of data structures to be marked outside of the normal
Scheme mechanisms and handled by construction/destruction and reference
counting, with the obvious memory overhead.
The alternative would be to base our implementation of rationals not on
U64 but on GNU mp. There is
-- C Function: void scm_to_mpz (SCM val, mpz_t rop)
Assign VAL to the multiple precision integer ROP. VAL must be an
exact integer, otherwise an error will be signalled. ROP must have
been initialized with ‘mpz_init’ before this function is called.
When ROP is no longer needed the occupied space must be freed with
‘mpz_clear’. *Note (gmp)Initializing Integers::, for details.
-- C Function: SCM scm_from_mpz (mpz_t val)
Return the ‘SCM’ value that represents VAL.
but that sounds like slowing down things more. Maybe we should collect
this JFTR in some actual issue.
https://codereview.appspot.com/573570043/