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] |
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