unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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



  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).