[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ratio implementation
Re: ratio implementation
Thu, 18 Sep 2003 23:09:46 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Bill Schottstaedt wrote:
Looks straightforward, but I may not get around to it right away.
Should I wait for Dirk's type-related changes?
Just for your information: I have submitted a patch which does the first
part: Introducing scm_tc7_number and turning bignums, reals and complex
numbers from smobs into subtypes of scm_tc7_number. The patch, however,
is quite simplistic and does not yet optimize the way the subtypes of
scm_tc7_number are allocated. It should nevertheless provide the
type-system infrastructure for easy integration of the fraction type.
> A ratio is exact, while a real is not. Thus, I'd say that ratio? is
> not really necessary. There should be no reason to add anything eyond
> R5RS for ratios.
Ok -- "exact?" used to return #f for 3/4 -- hence the confusion.
>> An alternative would be to make "rational?" rational.
> That would violate R5RS, wouldn't it?
I don't think so. You are allowed to make rational? be the same
as real?, but you can also distinguish them. My druthers would
be for rational? to return #t for a ratio, #f for a float.
Why have it at all if it is just a synonym for "real?"?
Just a side note: We should in guile distinguish between the internal
representation of values, and their mathematical meaning. For example,
fixnums and bignums are two representation of integer types. They
should, however, also report #t when queried about being rational, real
or complex, since they are elements of all these sets. When introducing
exact rationals, which are represented internally as a pair of two exact
integer values, we should not name them rationals, but, for example,
The reason I mention this is that I want to avoid a macro SCM_RATIONAL_P
to be introduced: The meaning of such a macro would not be clear, since
it might either be expected to return the equivalent of rational? or
just return true if an object was detected with an internal
representation of a fraction.
A nice set of macros to check for numbers of a specific internal
representation could be (names are just given as examples):
SCM_FIXNUM_P (currently named SCM_INUMP)
SCM_BIGNUM_P (currently named SCM_BIGP)
SCM_FLOATNUM_P (currently named SCM_REALP, which is confusing)
SCM_FLOATCPLXNUM_P (currently named SCM_COMPLEXP)
while a nice set of macros for testing for a mathematical meaning could
be (names are probably acceptable):
In the long term, we should rethink our current set of confusing names.
For the short term, we should at least avoid to introduce more confusing
terms, especially when introducing the new internal representation of