guile-devel
[Top][All Lists]

## Re: Integer conversion proposal

 From: Dirk Herrmann Subject: Re: Integer conversion proposal Date: Sun, 23 Sep 2001 11:07:46 +0200 (MEST)

```On Fri, 21 Sep 2001, Mikael Djurfeldt wrote:

> Proposal:
>
> * Name the conversion functions:
>
>   scm_exact_integer2int
>   scm_exact_integer2long
>   etc

Which target types should we support?  Maybe we could restrict ourselves
to a small set of target types based on the following considerations:

* IIRC, the type 'int' is considered the type that represents a machine's
'natural' word length.  (Correct me if I am wrong).  Thus, we should
provide a conversion to int and uint.

* C99 introduces a typedef that corresponds to the 'largest' supported
integral type.  (I don't know the name of that type any more).  We
should also provide a conversion to this type and the corresponding
unsigned one.

In principle, those two integral types would be sufficient.  All other
conversions could be done manually by the users:

int i = scm_exact_integer2int (integer);
if (i <= MAX_CHAR) {
char c = (char)i;
...
} else user_range_error ();

We could, however, provide more than the above four basic conversions, but
it is difficult to decide over a subset.

In addition, as suggested by Michael, we should provide checking variants
(bool is not a C type, I use it just to make the semantics clear):

bool scm_exact_integer2int_ext (SCM, int*)
etc...

> * Introduce new conversion functions for floats and doubles:
>
>   scm_real2float
>   scm_real2double

Again, we would need checking variants.  Currently, due to the
implementation of inexacts in guile, we know that there can only be an
overflow for scm_real2float, but for symmetry we should also provide a
checking variant for the double case.  This will make it easier to switch
to a different representation of reals later.

Just for clarification:  I assume that these functions will accept any
exact or inexact real number, right?  That is, any number which does not
have an imaginary part could be converted using these functions.

> * Introduce a macro SCM_COERCE_EXACT(N) which returns its argument
>   verbatim for all types except inexact numbers for which an exact
>   value is returned if possible.  (Note that this macro can be made
>   very efficient.)

Just for clarification:  Which input types should SCM_COERCE_EXACT
accept?  Is any typechecking done?  How does the coercion work?  (I'd
suggest rounding plus inexact->exact).

> * For backward compatibility, implement scm_num2int, scm_num2long
>   scm_num2ulong as:
>
>   int
>   scm_num2int (SCM num)
>   {
>     return scm_exact_integer2int (SCM_COERCE_EXACT (num));
>   }
>
>   etc

The question is, should we provide such functions for user convenience?
Maciej's comment about complex numbers indicates that scm_num2int and
friends should be deprecated:  It does not make sense to convert complex
numbers with non-zero imaginary part to int.  However, it seems to me that
scm_real2int (just a better name for scm_num2int) for example might make
sense, given that the coercion behaviour is cleanly documented.

Again, we would need functions that do some overflow checking.

Best regards
Dirk Herrmann

```