Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Converting an array into a list

9 views
Skip to first unread message

Amit Kumar

unread,
Oct 7, 1998, 3:00:00 AM10/7/98
to
hi,

I'm a newbie, first of all, so please treat the question as such.
Is there a trivial way of converting a matrix into a list? ie, if we have a
matrix #2A((a b) (c d)), is there a simple way of getting the list
((a b) (c d)), short of scanning the entire matrix element by element and
writing to a list?

I'm not a regular to this list, so I'd *really* appreciate it if you could
reply to this mail at am...@usc.edu

bye...
Amit

________ office ________________ work _________________ home _________
o 237 SAL, USC o 224 SAL, USC o 727, W 30th St o
o LA, CA, 90089 o LA, CA, 90089 o LA, CA, 90007 o
o (213)-740-6747 o (213)-740-7287 o (213)-747-4560 o
----------------------------<am...@usc.edu>----------------------------


Barry Margolin

unread,
Oct 7, 1998, 3:00:00 AM10/7/98
to
In article <Pine.GSO.4.02.981007...@pollux.usc.edu>,

Amit Kumar <am...@usc.edu> wrote:
>I'm a newbie, first of all, so please treat the question as such.
>Is there a trivial way of converting a matrix into a list? ie, if we have a
>matrix #2A((a b) (c d)), is there a simple way of getting the list
>((a b) (c d)), short of scanning the entire matrix element by element and
>writing to a list?

No, there's no built-in function to do this transformation. You can
convert a one-dimensional array (a vector) to a list with COERCE, but it
doesn't generalize to multiple dimensions.

The interesting thing is that the inverse transformation *is* available.
The above list is precisely the format required for the :INITIAL-ELEMENTS
parameter to MAKE-ARRAY.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

Erik Naggum

unread,
Oct 7, 1998, 3:00:00 AM10/7/98
to am...@usc.edu
* Amit Kumar <am...@pollux.usc.edu>

| I'm a newbie, first of all, so please treat the question as such. Is
| there a trivial way of converting a matrix into a list? ie, if we have a
| matrix #2A((a b) (c d)), is there a simple way of getting the list ((a b)
| (c d)), short of scanning the entire matrix element by element and
| writing to a list?

well, the Lisp printer already does this, so we could be clever and do

(read-from-string (write-to-string <matrix>) t t :start 3)

3 is OK as a constant because: (1) you're not going to use it on
one-dimensional arrays, anyway, because (coerce <vector> 'list) already
does that, (2) you're not going to use it on matrices of more than 9
dimensions, and (3) you know full well this is a clever hack to get past
a roadblock on your way to a better world, not a lasting solution.

also note that this is not efficient in _any_ way. to get an efficient
and lasting solution, you need to traverse the matrix and cons up your
own lists of elements. (tip of the day: start from the far end -- you'll
avoid the need to reverse the lists you're building.)

#:Erik

Kent M Pitman

unread,
Oct 8, 1998, 3:00:00 AM10/8/98
to
Erik Naggum <er...@naggum.no> writes:

> | Is there a trivial way of converting a matrix into a list?
>

> well, the Lisp printer already does this, so we could be clever and do
>
> (read-from-string (write-to-string <matrix>) t t :start 3)

This doesn't work if the elements are not re-readable. Make sure to
bind *print-readably* around this, or to use :readably t as a keywoard
arg to write-to-string.

It's not as hard as you might think to write this in a fully general
way. It took me about 3 minutes to come up with the code below, which
might be all you need. (I admit I just kind of guessed about how the
row-major thing generalizes to multiple dimensions, but it seems to
work in the few tests I did (shown)--and I was especially pleased it
worked for zero-arity arrays as well. Nevertheless, don't think I put
any major thought into this, so use this code at your own risk. No
warranty expressed or implied, and all that.)

CL-USER 15 >
(defun hack (a &optional (dims (array-dimensions a)) (start 0))
(if (not dims)
(row-major-aref a start)
(let ((dim1 (first dims)) (more-dims (rest dims)))
(loop repeat dim1
for j from start by (apply #'* more-dims)
collect (hack a more-dims j)))))
HACK

CL-USER 16 > (hack #(A B C))
(A B C)

CL-USER 17 > (hack #2A((A B C) (D E F)))
((A B C) (D E F))

CL-USER 18 > (hack #3A(((A B C) (D E F)) ((G H I) (J K L))))
(((A B C) (D E F)) ((G H I) (J K L)))

CL-USER 19 > (hack #0AFOO)
FOO

CL-USER 20 > (hack "fred")
(#\f #\r #\e #\d)

CL-USER 21 > (hack #*)
NIL

CL-USER 22 > (hack #*1010)
(1 0 1 0)


Chris Riesbeck

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <sfwaf37...@world.std.com>, Kent M Pitman
<pit...@world.std.com> wrote:

>(defun hack (a &optional (dims (array-dimensions a)) (start 0))
> (if (not dims)
> (row-major-aref a start)
> (let ((dim1 (first dims)) (more-dims (rest dims)))
> (loop repeat dim1
> for j from start by (apply #'* more-dims)
> collect (hack a more-dims j)))))

Jeepers, Kent, here I tell my Lisp students to pay attention
to the programming style of people like Pitman and Margolin, and
then you write

(not dims)

instead of (null dims).


One too many postings on the advantages of ambiguity, perhaps? :O)

Kent M Pitman

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
ries...@ils.nwu.edu (Chris Riesbeck) writes:

> Jeepers, Kent, here I tell my Lisp students to pay attention
> to the programming style of people like Pitman and Margolin, and
> then you write
>
> (not dims)
>
> instead of (null dims).

Hmm. It's a fair criticism. In my own defense, an earlier version
of this did its induction based on 1-arity arrays rather than 0,
and had to special-case the 0-arity thing, and so I felt it was
conceptually more proper to think of it using NOT since in that
case it wasn't receding toward an empty list. But you're right,
when I rewrote it to base itself from 0-arity and not have the
special case, I should have revised it to use NULL.

As a rule, though, I do tend to be a little less stuffy about the
NOT/NULL issue than some people are in Lisp because I believe in
the pun and would argue vociferously against removing it. I regard
the NOT/NULL thing as a "view" issue, not merely as two overloaded
datatypes sharing the same representation, and so there are times
I do view an empty list as a boolean. But I do agree that in the
case of a recursion involving a receding list it's good to use NULL
to emphasize the "process" surrounding the view, and in that case
I try not to prefer NULL to NOT. A case where I definitely am not
manic about it is that I don't usually use
(IF (NOT (NULL X)) ...)
I mostly just use (IF X ...) because there I'm using the boolean
"view" of "if there is more there" and not the list view of
"if there are elements there". It's a subtle point, but my key
meta-rule about style is to never reduce it to wired rules. Always
think about what you're trying to say and whether you're saying
things in a way that is appropriate to the situation. Style can't
be reduced to religious dogma with no choices, IMO. If you do
that, you might as well just change the language to disallow
the pun in the first place, and personally I think that would be
a horrible loss.

Besides, if you're telling your students they can rely on me for
style all the time, that's probably bad. They should be told to
rely on us most of the time, but that like everyone else we are
occasionally fallible and occasionally prone to have our own
personalities. It's good to have role models and people you can
often learn from, it's bad to have deities and paragons. That's
why I like Clinton--didn't you know it would come down to this?--
he does some good things and every now and then he reminds you that
you have to think for yourself and can't always be imitating every
aspect of "the people in charge". The last thing I'd want is a
leader who someone could assert I could and SHOULD totally
emulate. It would be scary to have people believing such a
claim, and it would be scary to be led by someone so confident
that they were always right.

Paolo Amoroso

unread,
Oct 17, 1998, 3:00:00 AM10/17/98
to
On Thu, 15 Oct 1998 20:57:09 GMT, Kent M Pitman <pit...@world.std.com>
wrote:

> Besides, if you're telling your students they can rely on me for


> style all the time, that's probably bad. They should be told to
> rely on us most of the time, but that like everyone else we are

"Don't believe everything we tell you. (Just most.)"
"Worry less about _what_ to believe and more about _why_."

(Peter Norvig and Kent Pitman; from "Tutorial on Good Lisp Programming
Style"; slides for the Lisp Users and Vendors Conference, August 10, 1993)

As usual, Kent is always right :-) Chris, tell your students to get this
excellent resource. It's available at:

http://www.norvig.com/luv-slides.ps


Paolo
--
Paolo Amoroso <amo...@mclink.it>

0 new messages