[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: propose deprecation of generalized-vector-*
From: |
Andy Wingo |
Subject: |
Re: propose deprecation of generalized-vector-* |
Date: |
Mon, 18 Feb 2013 16:55:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
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/
Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*), Mark H Weaver, 2013/02/18
Re: propose deprecation of generalized-vector-*, Daniel Llorens, 2013/02/20