From: Daniel Hartwig <mandyke@gmail.com>
To: guile-devel <guile-devel@gnu.org>
Subject: Re: propose deprecation of generalized-vector-*
Date: Tue, 19 Feb 2013 07:57:52 +0800 [thread overview]
Message-ID: <CAN3veRcN-NCrjr1piPckrgOTf-SadbdUyQzav46a8bDp2vqgWw@mail.gmail.com> (raw)
In-Reply-To: <1361204702.74716.YahooMailNeo@web120402.mail.ne1.yahoo.com>
On 19 February 2013 00:25, Mike Gran <spk121@yahoo.com> wrote:
> From: Noah Lavine <noah.b.lavine@gmail.com>
>>Hello,
>>>On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llorens@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?
>>
>>
>> I haven't worked with the array functionality, so I might be missing
>> something, but I don't see why this is natural for array-ref.
Right, these are my sentiments also (including the snipped part).
Relaxing array-ref in the proposed way means it could hide programming
errors, etc. Particularly with typed arrays, where previously the
result will reliably be of the given type.
>
> One could imagine a Matlab-like syntax where array-ref has to have
> the same number of indices as the underlying array, but, if an
> index were replaced with a symbol, it would return a slice.
>
> if np is [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
> (array-ref np 1 1) -> 5
> (array-ref np 1 :) -> [4, 5, 6]
> (array-ref np : 1) -> [[2], [5], [8]]
>
> Or maybe that's already in Scheme. I'll admit I've never done matrices
> in scheme.
Yes, but please lets imagine this only and not multiply the purpose of
array-ref. Other languages do that kind of thing a lot with a sort of
“guess what I really meant to do and do that instead”, which leads to
messy documentation, programming errors, and security issues
(Ruby-on-Rails?).
This is certainly a common enough usage of make-shared-array to
justify its own procedure with more helpful syntax. Even I would make
this two procedures, array-slice and array-slice/shared, to decide
between new or shared array.
Regards
next prev parent reply other threads:[~2013-02-18 23:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.153.1351958430.10005.guile-devel@gnu.org>
2012-11-03 16:52 ` propose deprecation of generalized-vector-* Daniel Llorens
2012-11-03 21:10 ` Ludovic Courtès
2013-01-21 16:11 ` Andy Wingo
2013-01-22 14:31 ` Daniel Llorens
2013-01-22 18:31 ` Daniel Llorens
2013-01-22 20:52 ` Andy Wingo
2013-01-22 23:27 ` Daniel Llorens
2013-01-23 9:20 ` Andy Wingo
2013-01-23 14:55 ` Ludovic Courtès
2013-01-23 9:06 ` Andy Wingo
2013-01-23 12:20 ` Daniel Llorens
2013-02-18 15:55 ` Andy Wingo
2013-02-18 16:05 ` Noah Lavine
2013-02-18 16:25 ` Mike Gran
2013-02-18 16:29 ` Noah Lavine
2013-02-18 17:11 ` David Pirotte
2013-02-18 17:17 ` Mike Gran
2013-02-18 23:57 ` Daniel Hartwig [this message]
2013-02-18 23:12 ` Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*) Mark H Weaver
2013-02-21 1:13 ` propose deprecation of generalized-vector-* Daniel Llorens
2013-02-22 0:22 ` Noah Lavine
2013-02-28 19:10 ` Daniel Llorens
2013-03-01 2:42 ` Noah Lavine
2013-03-01 3:46 ` Noah Lavine
2013-03-01 9:01 ` Daniel Llorens
2013-03-01 9:44 ` Andy Wingo
2013-03-04 2:27 ` Noah Lavine
2013-03-08 23:42 ` array operations Daniel Llorens
2013-02-18 15:40 ` propose deprecation of generalized-vector-* Andy Wingo
2013-02-28 23:04 Nelson H. F. Beebe
2013-03-04 12:48 ` Aharon Robbins
[not found] <mailman.191.1348070449.18828.guile-devel@gnu.org>
2012-09-19 17:20 ` Daniel Llorens
-- strict thread matches above, loose matches on Subject: below --
2012-09-18 14:49 Daniel Llorens
2012-09-19 12:02 ` Peter TB Brett
2012-11-02 23:27 ` Ludovic Courtès
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=CAN3veRcN-NCrjr1piPckrgOTf-SadbdUyQzav46a8bDp2vqgWw@mail.gmail.com \
--to=mandyke@gmail.com \
--cc=guile-devel@gnu.org \
/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).