From: Daniel Llorens <daniel.llorens@bluewin.ch>
To: Daniel Hartwig <mandyke@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: vectors are something else
Date: Fri, 12 Apr 2013 09:23:09 +0200 [thread overview]
Message-ID: <C1DE5ABB-7DD5-403B-B3EB-54C6D5CE7E48@bluewin.ch> (raw)
In-Reply-To: <CAN3veRcB6cm5T7oFQ5UAVYt18njuaPb=qaMTuf3mCS=bUU8RpQ@mail.gmail.com>
On Apr 12, 2013, at 01:53, Daniel Hartwig wrote:
> On 11 April 2013 07:07, Daniel Llorens <daniel.llorens@bluewin.ch> wrote:
>>
>> After the array-map patches, I've gone through the vector/array implementation and there's some stuff I'd like to fix. In stable-2.0 today:
>>
>> (define a (make-typed-array ''f64 0 '(1 2))
>> a
>> => #1f64@1(0.0 0.0)
>>
>> so far so good.
>>
>> (uniform-vector? a)
>> => #t
>>
>> (f64vector-ref? a)
>> => #t
>>
>> so far so good.
>>
>> (uniform-vector-ref a 0)
>> => 0.0
>>
>> This is a bug, since the valid indices are 1 and 2. This bug is in scm_c_generalized_vector_ref (and elsewhere):
>
> For a vector, the valid indices are as specified by r5rs:
>
> The _valid indexes_ of a vector are the exact non-negative
> integers less than the length of the vector. The first element in a
> vector is indexed by zero, and the last element is indexed by one less
> than the length of the vector.
>
> which applies even when accessing arrays as vectors. Offset indexing
> is a feature of the array interface only.
Right. I want [0]
(vector-ref #@1(1 2 3 4) 1) => 2
to fail with a type error, which is consistent with r5rs.
However my proposal is also to produce the same type error when the argument is a rank-1 array with base!=0 or inc!=1. These may be indexed from 0, but can only be produced by using the array interface, and use the array implementation internally. E.g. now you can do [1]
(vector-ref (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2) 0) => 1
which is 'correct' (and that object cannot be told apart from a plain vector using r5rs functions)
even though [2]
(vector? (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2)) => #f
Forbidding [1] will break some programs. Yesterday it broke a program of mine where I was using vector-ref on an array which was a row in a rank 2 array. I think we have license to do this anyway because of [2] and because that's how the typed vectors work too (bitvector-, bytevector-).
The other option is to make [1] #t. But then, vector- is just an alias of array-. Might as well have (vector-ref #@1(1 2 3 4) 1) work properly.
This discussion came up months ago when the generalized-vector interface was deprecated. At that time, Andy Wingo wanted to keep [1] working or at least I that's what I understood. My motivation try this again now is to simplify the implementation of arrays.
Currently there is a chain of 4 function calls for a single use of array-ref (and I may have missed some). This is unacceptable. Also the vector and uniform-vector functions are all branched on whether the argument is internally a 'vector' or 'srfi4-vector' or not, which is the source of the inconsistencies I reported in the previous post.
I'll send a patchset later today with at least the interface changes.
Regards,
Daniel
next prev parent reply other threads:[~2013-04-12 7:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 23:07 vectors are something else Daniel Llorens
2013-04-11 7:29 ` Daniel Llorens
2013-04-11 23:53 ` Daniel Hartwig
2013-04-12 7:23 ` Daniel Llorens [this message]
2013-04-12 10:15 ` Daniel Hartwig
2013-04-12 10:41 ` Daniel Hartwig
2013-04-12 21:43 ` Mark H Weaver
[not found] <mailman.1287634.1365761713.854.guile-devel@gnu.org>
2013-04-12 12:37 ` Daniel Llorens
2013-04-12 14:06 ` Daniel Hartwig
2013-04-13 0:40 ` Daniel Llorens
[not found] <mailman.197.1365782461.8676.guile-devel@gnu.org>
2013-04-12 23:12 ` Daniel Llorens
[not found] <mailman.1288755.1365813667.854.guile-devel@gnu.org>
2013-04-15 11:29 ` Daniel Llorens
2013-04-15 12:28 ` Daniel Hartwig
2013-04-15 14:08 ` Daniel Llorens
2013-04-15 14:17 ` Daniel Hartwig
2013-04-16 2:00 ` Mark H Weaver
2013-04-16 4:10 ` Daniel Llorens
2013-04-16 6:19 ` Mark H Weaver
2013-04-16 8:31 ` Daniel Llorens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C1DE5ABB-7DD5-403B-B3EB-54C6D5CE7E48@bluewin.ch \
--to=daniel.llorens@bluewin.ch \
--cc=guile-devel@gnu.org \
--cc=mandyke@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).