[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Uniform vectors: was Questions about floating numbers

From: Keith Wright
Subject: Uniform vectors: was Questions about floating numbers
Date: Wed, 10 Oct 2001 02:27:49 -0400

> From: Dirk Herrmann <address@hidden>
> > > 
> > > 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.

No, no!  I wouldn't shoot you.  I always aim carefully and
shoot only the message.

> > 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.

That would be srfi-4, but note also its anti-srfi, srfi-10, which
proposes a more general syntax.  I find srfi-4 to be unpleasantly
full of special cases while missing e.g. bit vectors.  Why should
there be a special TAGvector-ref for each type of vector, instead
of just letting vector-ref, or at worst uniform-vector-ref, check
the type of its argument?  Anti-virtualization!

> 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++.

Maybe it's named after the Virtual File System in the Linux kernel,
which is done this way.  The word "virtual" has been applied to
many different computery things since at least the sixties.

     -- Keith Wright  <address@hidden>

Programmer in Chief, Free Computer Shop <>
         ---  Food, Shelter, Source code.  ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]