| Date: Thu, 20 Nov 2003 21:15:43 -0800 (PST)
 | From: bear <xxxxxx@sonic.net>
 |
 | On Thu, 20 Nov 2003, Aubrey Jaffer wrote:
 |
 | > | Date: Thu, 20 Nov 2003 11:58:30 -0800 (PST)
 | > | From: bear <xxxxxx@sonic.net>
 | >
 | >Uniform arrays are just that -- uniform!  If you want to mix exact and
 | >inexact numbers in an array, just make its type be vector.
 |
 | Okay.  That's a decision.  Good.  So let's make it explicit.  I have
 | three specific suggestions for making that clear in your SRFI.
 |
 | First, I'd suggest that if you have an inexact number, you can store
 | it in a uniform array of inexact numbers, and retrieve an inexact
 | number from the location where you stored it.  But since there is a
 | chance that the number you retrieve won't be equal? to the number you
 | stored, this document needs to say so.  This doesn't have to be an
 | error -- in fact I'm pretty sure it shouldn't be -- but you need to
 | say so explicitly.
 |
 | Second, I'd suggest that if you have an exact number, and an
 | exact-number typed array, then any operation involving the array that
 | would result in a roundoff, wraparound, or truncation of that number
 | or the array contents ought to be an error.  You shouldn't be able to
 | store an exact number and then retrieve from that location a number
 | that's not equal?  to the one you stored, nor add two exact numbers
 | from an array and get an answer that's not the answer you'd get if you
 | added two exact numbers from a vector.  In specifying representation
 | you are not giving implementors any "wiggle room" to switch to
 | different representation in order to give exact results where they are
 | otherwise required, so you need to be explicit that operations which
 | don't *allow* exact results within the specified representation type
 | (overflow, wraparounds, roundoffs, etc) are errors.
 |
 | Finally, I'd suggest that if you have an inexact number, and you try
 | to store it in an array of an exact numeric type, or vice versa, that
 | should be an error.  If people want automatic type conversions on
 | store, they're easy to implement on top of the arrays you've
 | specified, any problems they introduce needn't be your fault and
 | needn't be behavior users can't get around.

Thanks for the suggestions.  Does this specify them:

 * All the elements of arrays of type au8, au16, au32, au64, as8,
   as16, as32, or as64 are exact.

 * All the elements of arrays of type ar32, ar64, ac32, or ac64 are
   inexact.

 * The value retrieved from an exact array element will equal (=) the
   value stored in that element.

 * Assigning a non-integer to array-type au8, au16, au32, au64, as8,
   as16, as32, or as64 is an error.

 * Assigning number larger than can be represented in array-type au8,
   au16, au32, au64, as8, as16, as32, or as64 is an error.

 * Assigning a negative number to array-type au8, au16, au32, or au64
   is an error.

 * Assigning an inexact number to array-type au8, au16, au32, au64,
   as8, as16, as32, or as64 is an error.

 * When assigning an exact number to array-type ar32, ar64, ac32, or
   ac64, the procedure may report a violation of an implementation
   restriction.

 * Assigning a non-real number (eg. real? returns #f) to an ar64 or
   ar32 array is an error.

 * An implementation may reduce the precision of a number assigned to
   an inexact array.

 |
 | >Two's-complement integers are in widespread use and well understood.
 | >The type-checking enforced by uniform-arrays has proven to be a
 | >benefit to debugging large-data-set numerical algorithms.
 |
 | Hmm, that brings up another question -- at the point where it becomes
 | useful for the programmer to *know* individual bits of representation
 | such as whether the number is represented as twos-complement, you're
 | dealing with a hardware interface -- frequently, that means type
 | punning based on bit patterns being interpretable as varying numbers
 | of different types.

There is no hardware exposed.  Inexacts are stored in whatever form
the implementation uses.  Exacts are stored twos-complement.  The
semantics of twos-complement representation are not
hardware-dependent.

 | One thing I haven't seen addressed with make-shared-array is whether
 | you're going to allow type punning.  IOW, can two arrays of different
 | types share storage?  Can I have, say, an array of au64's that shares
 | space with an array of 8 times as many au8's and with an array of 64
 | times as many at1, and manipulate the contents of the au64 array by
 | frobbing with its individual bits-n-bytes through the at1 and at8
 | interfaces?

Make-shared-array returns an array with the same type as its first
argument.

 | That could be very useful for implementing hardware interfaces and
 | FFI's, but I don't think the operation is sufficiently described and I
 | can't tell for sure here whether it's a functionality you intended to
 | provide.

That would expose endianness and data formats.  SRFI-47 does not do
that.

 | > Assigning a non-integer to array-type u8, u16, u32, u64, s8, s16,
 | > s32, or s64 is an error.
 |
 | > Assigning a negative number to array-type u8, u16, u32, or u64 is an
 | > error.
 |
 | > Assigning a non-real number to a r64 or r32 array is an error.
 |
 | By non-real, you mean to say, complex or imaginary?  Or do you mean to
 | say, integral or rational?

No.  (real? <number>) ==> #f

 | According to R5RS, some real numbers are integers, and some are not
 | integers.  Some real numbers are exact and some are inexact.  So
 | for compatibility with the rest of the language, could you please
 | describe these specifically as exact and inexact, rather than just
 | giving a hardware type?  The problem is that in some
 | implementations you have such things as exact floats or inexact
 | rationals or integers, and people will want to store 'em in your
 | typed arrays.

I believe the new restrictions language above does this:

 * All the elements of arrays of type au8, au16, au32, au64, as8,
   as16, as32, or as64 are exact.

 * All the elements of arrays of type ar32, ar64, ac32, or ac64 are
   inexact.

 | > Uniform arrays don't favor interpreters over compilers, they can just
 | > make the performance difference negligible.
 |
 | I think the same may be said of optional declarations.  At least I'm
 | not sure why it wouldn't be so.

Declarations enforced by an interpreter add additional overhead; they
go slower.

Thanks for the suggestions.