This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: numbers.[ch]


On 2 Oct 1998, Jim Blandy wrote:

> > If there is interest, I could take a closer look which functions could be
> > made static in numbers.c and provide a patch.
> 
> Yes, that would be very helpful.  I haven't looked at that at all.
> 
> Keep in mind that people using the Guile library will want to
> manipulate bignums themselves, so constructors and accessors at some
> level need to be visible.  The ability to do arithmetic on them isn't
> really enough --- there ought to be a way to convert between bignums
> and strings of digits in base 256 (one byte == one digit) and back.

OK, so here are my first results.

1) the macro SCM_NUM2DBL is defined in numbers.h, but never used throughout
   libguile/*[ch]

2) the same is true for the struct scm_dblproc 

3) the following functions are named in contrast to the type_one2type_two
   convention:

   scm_number_to_string, 
   scm_string_to_number, 
   scm_exact_to_inexact,
   scm_inexact_t~o_exact

4) the following r5rs functions are provided as extern in numbers.h, but the
   marked ones lack a gh_ counterpart. I don't know if all these should have a
   gh_ counterpart, since I'm not sure if it is part of the idea of the gh_
   interface to provide all r*rs functions on the C level.
   However, if these functions were to be added to the gh_ interface, some
   care has to be taken: The implementation of some of the functions leaves
   the parameter handling to the evaluator. min, max, sum and others for
   example are only implemented for two parameters, and expect the evaluator
   to implement the loop for an arbitrary number of arguments.
   Is this a performance issue or a keep-code-size-small issue?

     scm_exact_p
   * scm_odd_p
   * scm_even_p
   * scm_abs
   * scm_quotient
   * scm_remainder
   * scm_modulo
   * scm_gcd
   * scm_lcm
   * scm_number_to_string
   * scm_string_to_number
     scm_number_p
   * scm_real_p
   * scm_integer_p
     scm_inexact_p
   * scm_num_eq_p
   * scm_less_p
   * scm_gr_p
   * scm_leq_p
   * scm_geq_p
   * scm_zero_p
   * scm_positive_p
   * scm_negative_p
   * scm_max
   * scm_min
   * scm_sum
   * scm_difference
   * scm_product
   * scm_divide
   * scm_truncate
   * scm_round
   * scm_exact_to_inexact
   * scm_make_rectangular
   * scm_make_polar
   * scm_real_part
   * scm_imag_part
   * scm_magnitude
   * scm_angle
   * scm_inexact_to_exact

5) in addition to scm_truncate, a function scm_trunc is declared in
   numbers.h. However, the #ifdef structure guarantees that only one of these
   functions will be defined. Their return and parameter types differ:

   extern double scm_truncate SCM_P ((double x));
   extern SCM scm_trunc SCM_P ((SCM x));

6) the following functions are declared extern in numbers.h and are used
   (besides in numbers.c) from somewhere else in libguile.

   scm_bigcomp - used in eq.c. Here, a SCM object is testet to be a bignum and
      in that case scm_bigcomp is called for comparison. Should (in my
      opinion) be hidden in numbers.c, although this might lead to a small
      runtime penalty.

   scm_floequal
   scm_bigequal
   scm_bigprint - referenced in smob.c. Bignums and floats are realized as
      smobs, but are required to be initialized as the first smob types. This
      could as well be done in numbers.c without runtime penalty.

   scm_floprint - referenced in smob.c (see scm_bigprint) and in unif.c. Can't
      tell much about the code in unif.c.

   scm_istr2int
   scm_istring2number - both used in read.c. There appeared to be some
      inefficiency in the reader: As soon as it realizes that a number is to
      be read, it first determines the length of that number token and then
      calls scm_istr2int or scm_istring2number, which again perform syntax
      checking on each character. Maybe the reader should, as soon as a number
      is to be expected, do syntax checking and conversion in one run?

   iint2str - used in print.c

   scm_num2ulong
   scm_num2long
   scm_ulong2num
   scm_long2num
   scm_num2dbl
   scm_big2dbl
   scm_makdbl - used in a couple of places

   scm_long_long2num
   num2long
   scm_num2long_long - used in unif.c

   scm_init_numbers - needed for init.c

7) The following functions are used to implement bignums and are only used
   within numbers.c. To hide the bignum implementation details, these
   functions should be made static within numbers.c. However, in order to
   allow bignum handling from user code, some bignum interface could be
   exposed, but how this could be done in a clean way is not clear to me yet.

   scm_mkbig
   scm_big2inum
   scm_adjbig
   scm_normbig
   scm_copybig
   scm_long2big
   scm_long_long2big
   scm_2ulong2big
   scm_ulong2big
   scm_addbig
   scm_mulbig
   scm_divbigdig
   scm_divbigint
   scm_divbigbig
   scm_dbl2big

8) The following two functions are used in numbers.c only, but only one of
   them is defined (depending on the #ifdef structure.) I don't quite
   understand what they are doing (strange conversion code and comments
   are for wimps).

   scm_pseudolong
   scm_longdigs

9) scm_istr2flo is only used within istring2number.

10) The following functions are not part of r*rs, but are declared in
   numbers.h, defined in numbers.c and made visible at the scheme level.
   Probably they should be put into different modules like 'bitlogic' and
   'math' or so.

   scm_logand
   scm_logior
   scm_logxor
   scm_logtest
   scm_logbit_p
   scm_lognot
   scm_ash
   scm_bit_extract
   scm_logcount

   scm_integer_expt
   scm_integer_length
   scm_asinh
   scm_acosh
   scm_atanh
   scm_sys_expt
   scm_sys_atan2

Best regards, 
Dirk Herrmann