At 10:09 AM 11/7/2001 -0500, Jason Gloudon wrote:
>On Tue, Nov 06, 2001 at 05:22:27PM -0500, Dan Sugalski wrote:
>
> > A variable with a numeric value can be taken in one of three ways:
> >
> > *) As an integer. Which means either platform-native or bigint
> > *) As a float. Which means either platform-native or bigfloat
> > *) As a generic number. Which means platform native int or float,
> bigint or
> > bigfloat, or (possibly) a complex number.
>
>Ok, so shouldn't there be a get_float vtable operator ?
Nope. get_number should cover it. (Actually a get_integer's not needed, as
there's full overlap with get_number)
>It would be helpful if the current target ranges of values for the types of
>vtable functions (int_type, float_type, num_type, string_type) could be
>enumerated again, the last version I saw:
>
> base_type: A unique identifier attached to the package. 0-INTVAL_MAX
> int_type: 0, 1, 2, 3 for "same as you", native int, bigint, object
> float_type: 0, 1, 2, 3 for "same as you", native float, bigfloat, object
> num_type: 0, 1, 2, 3, 4, 5 for "same as you", native int, bigint, native
> float, bigfloat, object
> string_type: 0, 1, 2, 3, 4 for "same as you", native string, unicode,
> other, object
>
>does not match with the code generated for the vtables. For example, the NUM
>vtable functions are being generated with 5 variants, but the above indicates
>at least 6, and with what you've said about possibly complex numbers, this
>could be 7.
Yeah, we're out of sync. It's a communication issue as much as anything
else. I'll get things straightened out.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
