Proposal: deprecate low-level numeric predicates

Proposal: deprecate low-level numeric predicates

[Mark H Weaver]

Daniel Llorens <dll@bluewin.ch> writes:
> I tried to look into SCM_VALIDATE_REAL per the comment, I didn't get
> far.

Yes, SCM_VALIDATE_REAL (defined in validate.h) requires that the tested
value be an inexact real, i.e. floating-point.  It will reject exact
integers or exact rationals.  It really ought to be deprecated in
master, and replaced with a new validator that uses scm_is_real.

SCM_REALP and SCM_COMPLEXP should also be deprecated.  It is very
confusing that these macros do not correspond to `real?' and `complex?'.
They should be replaced with renamed versions to reflect the fact that
they are testing for particular low-level numeric representations.
Maybe SCM_DOUBLE_P and SCM_COMPLEX_DOUBLE_P.  In the future, Guile will
support additional representations for inexact reals, for example
arbitrary-precision floating-point numbers.

SCM_NUMBERP, SCM_NUMP, and SCM_INEXACTP ought to be deprecated, and
replaced with internal versions.  They check only for representations
supported by the core implementation, and do not properly support GOOPS
numeric classes (part of an upcoming patch series I'm working on).

SCM_VALIDATE_NUMBER ought to be changed to use scm_is_number, in order
to support GOOPS numeric classes.

What do you think?

    Mark

Re: Proposal: deprecate low-level numeric predicates

[Andy Wingo]

On Tue 01 Mar 2011 20:20, Mark H Weaver <mhw@netris.org> writes:

> Daniel Llorens <dll@bluewin.ch> writes:
>> I tried to look into SCM_VALIDATE_REAL per the comment, I didn't get
>> far.
>
> Yes, SCM_VALIDATE_REAL (defined in validate.h) requires that the tested
> value be an inexact real, i.e. floating-point.  It will reject exact
> integers or exact rationals.  It really ought to be deprecated in
> master, and replaced with a new validator that uses scm_is_real.

Indeed.  Its only mention in Guile is

  bytevectors.c:1667:/* FIXME: SCM_VALIDATE_REAL rejects integers, etc. grrr */

I think it's OK to deprecate in stable-2.0, actually, using the same
mechanism as SCM_VALIDATE_INUM.

> SCM_REALP and SCM_COMPLEXP should also be deprecated.  It is very
> confusing that these macros do not correspond to `real?' and `complex?'.
> They should be replaced with renamed versions to reflect the fact that
> they are testing for particular low-level numeric representations.
> Maybe SCM_DOUBLE_P and SCM_COMPLEX_DOUBLE_P.

Sounds good to me too.

> SCM_NUMBERP, SCM_NUMP, and SCM_INEXACTP ought to be deprecated, and
> replaced with internal versions.

OK, but in master only please.

>  They check only for representations
> supported by the core implementation, and do not properly support GOOPS
> numeric classes (part of an upcoming patch series I'm working on).

I'm a little concerned about the impact goops numbers would have on
making type dispatch slower, like

    (cond
      ((symbol? x) ...)
      ((number? x) ...))

How many different kinds of numbers are we talking about?  Would be nice
to avoid having number? call a generic function.  Dunno.

> SCM_VALIDATE_NUMBER ought to be changed to use scm_is_number

Sure.  Anyone who really cares about speed will check for particular
number types.  In master only please, though, at least for now.

Andy
-- 
http://wingolog.org/

Strategy for supporting GOOPS based numeric types

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:
>> SCM_NUMBERP, SCM_NUMP, and SCM_INEXACTP ought to be deprecated, and
>> replaced with internal versions.
>
> OK, but in master only please.

Yes, of course, makes sense :)

>>  They check only for representations
>> supported by the core implementation, and do not properly support GOOPS
>> numeric classes (part of an upcoming patch series I'm working on).
>
> I'm a little concerned about the impact goops numbers would have on
> making type dispatch slower, like
>
>     (cond
>       ((symbol? x) ...)
>       ((number? x) ...))
>
> How many different kinds of numbers are we talking about?

The sky's the limit.  Ideas of numeric types that might make sense to
implement are: arbitrary-precision floats, complex numbers with
arbitrary component types (these two I've already implemented),
fixed-point, decimal floats, intervals, or even "infinite-precision
reals" which lazily compute as many digits as you want on demand.

The point is, it seems to me that no matter how many representations we
add, there are good reasons why some people might want others.  I'd like
Guile to support experimental new representations of numbers.

> Would be nice to avoid having number? call a generic function.  Dunno.

Yes, I agree completely.  The solution I adopted in my preliminary patch
set is to allocate SCM_VTABLE_FLAG_GOOPS_3 for that purpose, and make it
a "Class flag" (see "{Class flags}" in goops.h).

#define SCM_VTABLE_FLAG_GOOPS_NUMBER SCM_VTABLE_FLAG_GOOPS_3
[...]
#define SCM_CLASSF_NUMBER        SCM_VTABLE_FLAG_GOOPS_NUMBER

That flag is automatically set for any class that is a subclass of
<number> (directly or indirectly).  So then I have a fast macro
SCM_GNUMBERP that's implemented as follows:

#define SCM_GNUMBERP(x) \
  (SCM_STRUCTP (x) && (SCM_STRUCT_VTABLE_FLAGS (x) & SCM_CLASSF_NUMBER))

scm_number_p is implemented as:

  return scm_from_bool (SCM_NUMBERP (x) || SCM_GNUMBERP (x));

The other numeric type predicates are implemented by dispatching into
GOOPS if and only if SCM_GNUMBERP is true.  For example, scm_real_p:

  if (SCM_I_INUMP (x) || SCM_REALP (x) || SCM_BIGP (x) || SCM_FRACTIONP (x))
    return SCM_BOOL_T;
  else if (SCM_GNUMBERP (x) && SCM_LIKELY (SCM_UNPACK (g_scm_real_p)))
    return scm_call_generic_1 (g_scm_real_p, x);
  else
    return SCM_BOOL_F;

Maybe there's a better way to do this, but at least this strategy only
slows things down noticeably when the object being tested is a GOOPS
object whose class is a subclass of <number>.

Another strategy would be to add a field of flags to the class VTABLE
which contains one flag for each numeric type predicate.

Thoughts?  Better ideas welcome :)

    Best,
     Mark

Re: Strategy for supporting GOOPS based numeric types

[Andy Wingo]

Hi Mark,

On Thu 10 Mar 2011 00:28, Mark H Weaver <mhw@netris.org> writes:

> #define SCM_GNUMBERP(x) \
>   (SCM_STRUCTP (x) && (SCM_STRUCT_VTABLE_FLAGS (x) & SCM_CLASSF_NUMBER))
>
> scm_number_p is implemented as:
>
>   return scm_from_bool (SCM_NUMBERP (x) || SCM_GNUMBERP (x));

It's a late reply, but I just wanted to mention that I like this
approach.  Happy hacking!

Andy
-- 
http://wingolog.org/