Re: Questions about floating numbers, rethink and bug report

[Dirk Herrmann]

On Tue, 9 Oct 2001, Keith Wright wrote:

> > From: Dirk Herrmann <address@hidden>
> > 
> > On Sun, 7 Oct 2001, Keith Wright wrote:
> > 
> > > Bug.
> > >     guile> #E3  ==>    3
> > >     guile> #e3
> > >     ERROR: read:uniform-vector list not found
> > > 
> > > This violates both R5RS 7.1 ``Case is insignificant'' and 
> > > >     The codes for indicating exactness (which can, incidentally, be
> > > >  applied to all numerical values) are:
> > > >
> > > >   * `#e', `#E' -- the number is exact
> > 
> > Some uniform vector is taking the #e prefix.  More details can be found in
> > ice-9/arrays.scm and unif.c and ramap.c.
> 
> And in read.c, where |scm_get_hash_procedure| should be changed to
> do a case-insensitive comparison so that the same bug does not just
> move to a new letter.  The "#i(" prefix to double precision uniform
> arrays is a goofy choice of letter (in my FORTRAN opinion), and conflicts
> with the "inexact prefix" from RnRS in the same way "#e(" for
> unsigned long integer (goofy) conflicts with the "exact prefix".
>   ... and the prototype 1/3 suggested for a double precision looks
> like an exact rational to me.  Surely the prototype for double
> precision should be 1.0d0 (the R5RS way of writing a double
> constant)!?

Don't shoot the messenger.  I don't use unif.c and ramap.c.

> Why do we need eleven different prefix letters for different types of
> uniform vector anyway?  Is there not an stunning algorithm that,
> given a _single_ code for uniform-array and a list of objects all
> of the same type, computes the common type?  So #u(#t #t #f #t)
> is a bit vector and #u(3.14 2.71) is floating point.

Note that there is already a SRFI about that issue, and IMO the right
thing would be to adopt those ideas.

> >                                           I think this is a bug and should
> > be fixed.  It would do good to revamp the whole uniform vector stuff.  
> > Doesn't anybody have an opinion on my suggestion to virtualize the vector
> > interface (whine :-)?
> 
> Missed it.  Was that on this list?  How long ago?  Virtualize?
> Is that part of a plan to make them more automatic, or is it
> a new implementation technique for the status quo language?

It was on guile-devel, sorry.  I get all these email messages unfiltered
into my inbox and sometimes do not realize which list they went to.  

Virtualizing, BTW, is an implementation technique - in some sense.  The
term comes (at least that's what I assume) from the concept of virtual
functions in C++.  The idea is as follows:  Assume you have a set of types
(like in our example above, a set of vector types:  bool-vectors, integer
vectors, ...) which all are to be accessed by similar functions with the
same signature (like scm_vector_ref (SCM vect, SCM idx)).  The functions,
however, require different implementations depending on the actual type of
the object.  Then, you can use a common function scm_vector_ref (SCM vect,
SCM idx), which dispatches to the appropriate function based on the
dynamic type of vect, like scm_bool_vector_ref if vect happens to be a
bool-vector.  This mechanism of dispatching based on the dynamic type of
an object for some function is called virtualizing.  It is commonly
implemented by providing a set of function pointers for each of the types,
for example:

struct scm_t_vector_virtual_functions {
  size_t (*length) (SCM vect);
  SCM (*ref) (SCM vect, size_t idx);
  SCM (*set) (SCM vect, size_t idx, SCM obj);
};

You then have a structure like the above for each vector type.  The
function scm_vector_length could then be implemented like:

SCM scm_vector_length (SCM vect)
{
  scm_t_vector_virtual_functions *funcs;

  SCM_VALIDATE_VECTOR (1, vect);  /* type check - it's a vector */
  funcs = get_the_function_table_for_vector (vect);  /* This has to
                  extract the type information from vect and somehow
                  find the appropriate table of functions. */
  return (*funcs->length) (vect);
}

As soon as you know how the get_the_function_table_for_vector part is
done, you can easily add additional vector types to the system - each one
has only to provide it's own set of virtual functions.

Best regards,
Dirk Herrmann