unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Daniel Llorens <daniel.llorens@bluewin.ch>
To: guile-devel@gnu.org
Subject: Re: propose deprecation of generalized-vector-*
Date: Wed, 19 Sep 2012 19:20:49 +0200	[thread overview]
Message-ID: <A3C1EAA7-6707-4596-B964-1C59242ECB68@bluewin.ch> (raw)
In-Reply-To: <mailman.191.1348070449.18828.guile-devel@gnu.org>


On Sep 19, 2012, at 18:00, guile-devel-request@gnu.org wrote:

> Date: Wed, 19 Sep 2012 13:02:25 +0100
> From: Peter TB Brett <peter@peter-b.co.uk>
> To: guile-devel@gnu.org
> Subject: Re: propose deprecation of generalized-vector-*

 ...

> It seems to me that array-length should return the first non-unity
> dimension. This is the approach taken by e.g. MATLAB's length()
> function. It would give it a distinct utility compared to
> array-dimensions (which is analogous to MATLAB's size() function).
> 
> WDYT?
> 
>                        Peter

That is not exactly what length() does in Matlab:

> >> help length
>  LENGTH   Length of vector.
>     LENGTH(X) returns the length of vector X.  It is equivalent
>     to MAX(SIZE(X)) for non-empty arrays and 0 for empty ones.

The notion of rank in Matlab is rather sui generis. There are no rank 1 objects as such, only row or column vectors. Even size(0) gives [1 1]. So there's constant confusion when you want a simple vector X, because Matlab gives you a column or a row and you need to know which one you've got, even though the things you want to do with X don't depend on that at all. That leads to superfluous use of (:) and .'   .

The above definition of length() is meant to paper over the row/column distinction. Octave says:

> octave:1> help length
> `length' is a built-in function
> 
>  -- Built-in Function:  length (A)
>      Return the `length' of the object A.  For matrix objects, the
>      length is the number of rows or columns, whichever is greater (this
>      odd definition is used for compatibility with MATLAB).

Guile is strict about rank, so this problem doesn't exist. Wouldn't you agree?

----

Going back to the two definitions I proposed, and after giving it some thought, I favor the first

  (array-length a) = (car (array-dimensions a))

more strongly than before, for these reasons:

1. Utility. I do the equivalent of (car (array-dimensions a)) much more often than either (fold * 1 (array-dimensions a)) or what Matlab length() does. An array is often also a list of objects, e.g. a list of n points in R^m is an [n m] shape array, or a list of n transformation matrices is an [n m m] shape array [*].

Of course this is because of the way I use arrays in my own code. I'd be interested in reading about what other people do.
 
2. Efficiency. (car (array-dimensions a)) deserves a shortcut, since it's a waste to construct a list only to take its car. You can say that of the other axes, but the first axis is used more often.

[*] This is very common in J and K, the descendants of APL. In fact K's 'arrays' don't even need to be rectangular. But I think J can be a good model for Guile arrays. J has an operator '#' (tally) which is basically what I propose for array-length. The only difference is that in J (# scalar) gives 1, and this seems irregular. It maybe better to make (array-length #0(0)) an error.

Here's an implementation with this behavior.

    SCM array_length(SCM a)
    {
        scm_t_array_handle h;
        scm_array_get_handle(a, &h);
        if (scm_array_handle_rank(&h)==0) {
            scm_array_handle_release(&h);
            scm_error_scm(scm_from_locale_symbol("out-of-range"), SCM_BOOL_F,
                          scm_from_locale_string("no items for rank 0 array"), SCM_EOL, a);
        }
        scm_t_array_dim const * dims = scm_array_handle_dims(&h);
        SCM l = scm_from_size_t(dims->ubnd-dims->lbnd+1);
        scm_array_handle_release(&h);
        return l;
    }




       reply	other threads:[~2012-09-19 17:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.191.1348070449.18828.guile-devel@gnu.org>
2012-09-19 17:20 ` Daniel Llorens [this message]
2013-02-28 23:04 propose deprecation of generalized-vector-* Nelson H. F. Beebe
2013-03-04 12:48 ` Aharon Robbins
     [not found] <mailman.153.1351958430.10005.guile-devel@gnu.org>
2012-11-03 16:52 ` 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
2013-02-21  1:13               ` 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-02-18 15:40           ` Andy Wingo
  -- 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=A3C1EAA7-6707-4596-B964-1C59242ECB68@bluewin.ch \
    --to=daniel.llorens@bluewin.ch \
    --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).