[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: propose deprecation of generalized-vector-*
From: |
Daniel Llorens |
Subject: |
Re: propose deprecation of generalized-vector-* |
Date: |
Thu, 28 Feb 2013 20:10:47 +0100 |
On Feb 22, 2013, at 01:22, Noah Lavine wrote:
> I agree about the speed issue, but I hope it will get better soon. The RTL VM
> will fix some of it, and native compilation will fix more.
That's on Scheme, but there are also many optimization issues related to array
operations. Temporaries, order of traversal, etc.
> I'm actually not very enthusiastic about this, not because you shouldn't be
> able to do this, but because in order to enable the automatic de-ranking, you
> have to have Guile assume which dimensions you want to map over. That's how
> C, C++ and Fortran do it because that's how arrays are actually stored in
> memory, so maybe that is the right way. It just seems too low-level for me -
> I'd rather see an array-slice function that can split along any dimensions.
enclosed-array also let you pick what axes you wanted for the cell. You needed
to specify those axes every time. That feels /more/ low level to me.
The memory order of arrays in Guile is absolutely low level detail, especially
since it can change at any time. However the ¿logical? order of the axes is
not. It's simpler to define the looping operation so that the frame (the axes
one loops over) consists of the axes that come first. It plays well with the
rank extension / matching mechanism that I show at the end and with the view of
an array as a list.
APL used to have an 'axis specifier' that was apparently a total mess. In numpy
there are some functions with an 'axes' argument, but it's 'axis' for others
and some don't have it.
I'm not opposed to being able to choose your axes in some legacy-friendly
standard way, I just don't think it's a problem. You can always loop over other
axes at no cost by transposing before and after. It's something that can be
easily abstracted.
> This gets at the heart of my issue with the array functionality. As far as I
> can tell, in Guile, there is no way to figure out what the rank of a function
> is. That's why you have to be explicit about what you're mapping over.
>
> I suppose the Common Lisp-y approach would be to make an object property
> called 'rank', set it for all of the built-in arithmetic functions, and maybe
> have some way to infer the rank of new functions That might be interesting,
> but I'm skeptical.
Exactly, this is what is needed. Then you can write array functions that can be
extended for arguments of higher rank without the function itself having to
deal with those extra axes that are none of its concern. Otherwise you need to
give axis indications left and right. I've suffered this in numpy. This
information belongs with the function.
> Thanks a lot for starting the conversation. I would like to see Guile provide
> enough array functionality for serious scientific computing, and it sounds
> like you want the same thing. I don't really know what's missing yet, though,
> because I haven't tried to write a program that would use it.
It's a problem, because one needs at the very least mapping and reductions to
write any kind of numeric program. Guile has absolutely nothing for array
reductions and the mapping is very low level.
> I think the idea of splitting arrays is great. My only concern is making it
> part of array-ref. I still think that's a really bad idea, because it
> introduces a new class of errors that are really easy to make - accidentally
> getting an array when you expected whatever was inside the array. I'm coming
> at this as a user of Matlab and Fortran. In those languages, this isn't a
> problem, because operations automatically map over arrays, so having an array
> where you expected a value doesn't lead to new errors. But in Scheme,
> operations *don't* automatically map, so getting an array could lead to an
> exception at some point later in a program when really the error was that you
> didn't give enough indices to array-ref.
In my experience the kind of rank errors you describe are unlikely to happen,
because in most programs the ranks of arrays are static. It's a bit like
function arity, the general case is important and must be supported, but most
functions have fixed arity, and that reveals many optimization opportunities.
If the rank of an array is known, then the rank of the array-ref result is also
known. The Guile compiler seems to ignore all of this right now, but it
probably shouldn't.
I've implemented the idea of assigning rank to functions and then extending
these over arrays of higher rank. At this point I'm mostly interested in having
the basic mechanism right, so the code is probably a bit rough.
I wrote some description of how it works in the README. Please have a look and
let me know what you think. You can find it at:
https://gitorious.org/guile-ploy
I also wanted to write a bit about passing arrays between C/C++ and Guile, but
it's really a different matter, so maybe some other time. The problem here is
that each library has its own calling convention and has different constraints
on the kind of arrays it takes, so it's not something that the ffi can handle
transparently.
Regards,
Daniel
- Re: propose deprecation of generalized-vector-*, (continued)
Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*), Mark H Weaver, 2013/02/18
Re: propose deprecation of generalized-vector-*, Daniel Llorens, 2013/02/20
Re: propose deprecation of generalized-vector-*, Nelson H. F. Beebe, 2013/02/28