* Proposal: deprecate low-level numeric predicates
@ 2011-03-01 19:20 Mark H Weaver
2011-03-09 21:59 ` Andy Wingo
0 siblings, 1 reply; 4+ messages in thread
From: Mark H Weaver @ 2011-03-01 19:20 UTC (permalink / raw)
To: guile-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Proposal: deprecate low-level numeric predicates
2011-03-01 19:20 Proposal: deprecate low-level numeric predicates Mark H Weaver
@ 2011-03-09 21:59 ` Andy Wingo
2011-03-09 23:28 ` Strategy for supporting GOOPS based numeric types Mark H Weaver
0 siblings, 1 reply; 4+ messages in thread
From: Andy Wingo @ 2011-03-09 21:59 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guile-devel
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/
^ permalink raw reply [flat|nested] 4+ messages in thread* Strategy for supporting GOOPS based numeric types
2011-03-09 21:59 ` Andy Wingo
@ 2011-03-09 23:28 ` Mark H Weaver
2011-03-26 22:20 ` Andy Wingo
0 siblings, 1 reply; 4+ messages in thread
From: Mark H Weaver @ 2011-03-09 23:28 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-26 22:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-01 19:20 Proposal: deprecate low-level numeric predicates Mark H Weaver
2011-03-09 21:59 ` Andy Wingo
2011-03-09 23:28 ` Strategy for supporting GOOPS based numeric types Mark H Weaver
2011-03-26 22:20 ` Andy Wingo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).