Re: propose deprecation of generalized-vector-*

[Andy Wingo]

Hi,

On Wed 23 Jan 2013 13:20, Daniel Llorens <address@hidden> writes:

> In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
> In [4]: a[1]
> Out[4]: array([4, 5, 6])
> In [5]: a[1, 1]
> Out[5]: 5
>
> array-ref can be extended very simply to do that. It accumulates on the
> position as it is done now, but if the index list comes up short it
> makes a shared array with the remaining axes instead of giving a rank
> error. So it shouldn't be any slower than array_ref.

It could make sense, yes.  What do others think?  What happens for
array-set!?  Care to propose a patch?

>> FWIW this is not the case.  Vectors hold SCM objects, whereas uniform
>> vectors hold unpacked machine values.
>
> Ok, I think I understand that. Still I don't see where the vref field
> for the srfi4 types is set. The conversions seem to be done in
> bytevector.c, can you point this out?

Uniform vectors are just bytevectors.  The only difference between the
different kinds of uniform vectors is a "type" field indicating the
"natural" type of the object.  The type field is set when a bytevector
is created, and is used in the generic array-ref functionality, and in
the printer.

One consequence is that you can (s8vector-ref #u8(#xff) 0) => -1.

> I've also noticed
>
> scheme@(guile-user)> (f64vector-ref #s64(1 2 3) 0)
> $1 = #.#

Here you are interpreting an int64 as a double, which should work, but
this printed result is really bizarre and looks like a bug in our number
printer.  Mark? :)

> scheme@(guile-user)> (c64vector-ref #f64(1 2 3) 0)
> $3 = 1.0+2.0i

This is as expected.  You are aliasing a double vector as a double
complex vector.  These are purely bit-level conversions, not type
casting.

Andy
-- 
http://wingolog.org/