Hi, On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llor...@bluewin.ch> 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/
