Re: array language (was: lush vs matlab)

Ralf Juengling <[email protected]>
Newsgroups gmane.lisp.lush.devel
Message-ID <[email protected]>
On Thu, 3 Nov 2005, Yann LeCun wrote:

> I'll add my two centimes to your two pfennigs.
> [...]

> (a la Matlab) would be nice. That's very easy to do.
> A simpler array-slicing-and-dicing syntax (a la Matlab)
> rather than all the calls to select/narrow/etc would also
> be nice and easy to implement.
>

Yes, I agree. And I you might want to have special syntax
for more things than just certain kinds of array accesses.
I think it might be fruitful to discuss separately these
two issues, at least for a while:

1. We need a larger and well designed set of "primitives"
    for array manipulation
2. We want to map these primitives onto special syntax

Regarding the first issue, I just presented some ideas in
form of PSU Lush. Some of the new functions in the array API
are not generally useful enough to be kept (idx-select-all,
idx-shift*), I think, while I also see more functions that
need to be added (e.g., an array-put, counter part of
array-take, and more sophisticated array-take).

Regarding the syntax issue, being a Lisp newbie, I have
made no attempts in that direction so far. But I already
got enough of a sense for Lisp, I think, to arrive at the
opinion that we should add very little new syntax to the
"Lisp syntax space". Another idea that we might want to
explore instead is to design a small "embedded array
language", that would be encapsulated just as C code is
encapsulated in Lush. For a start we would translate this
array language into lisp. In the more distant future we
would write an "array operations optimizing compiler"...

You get the idea. :-)
Woddaja think?

Ralf












> We just need a few more inspired volunteers....
>
>  -- Yann
>
>
> On Wednesday 02 November 2005 08:20 pm, Ralf Juengling wrote:
>> I want to pick up on a few things here and will respond in
>> several postings.
>>
>> On Wed, 2 Nov 2005, Yann LeCun wrote:
>>> In my mind, the void that Lush fills is that of an open-source,
>>> convenient, and flexible language for "numerical" research,
>>> prototyping, and rapid development.  This is a space that Matlab,
>>> pynum, and a few others are attempting to fill, but they all have
>>> problems and limitations. For example Matlab (besides being non open
>>> source) is not really designed as a full-fledged programming language,
>>> and limits the size and complexity of projects that can be developed
>>> with it.
>>
>> I strongly agree, this is what I hoped to get when I installed
>> lush. I have been using matlab for a few years now and have good
>> and bad things to say about it. It's very strengths are
>>
>> - comes with an ide featuring an integrated source level debugger
>> - has a compact API (many commands do a variety of things) which
>>    makes it easy to learn
>> - good visualization capabilities for 1d and 2d data, including
>>    facilities for creating publication quality figures
>> - the universal data type are arrays; once this is absorbed by a
>>    user, matlab is an excellent rapid prototyping environment
>> - very good documentation (online and offline); once you grabbed
>>    the basic concepts, you can work with matlab without ever
>>    looking into a manual again (using the online help)
>> - there's a rich set of toolboxes
>> - everybody uses it (share code with your friends and colleagues)
>>
>> its weak points are
>> - poor as a language (OO model is lousy; it has no other high-level
>>    data types like hash tables; no module system)
>> - lousy performance if you cannot express your problem in terms of
>>    a few array operations
>> - awkward to interface with C code (although that it's possible
>>    at all and well documented is a pro)
>> - no memory mapped files mechanism
>> - closed source
>> - expensive
>>
>>
>> That said, there are very few points where lush beats matlab
>> currently. These are cost, performance and the ability to
>> interface with c and c++ code (did I forget anything?)
>>
>> so advertising lush as a matlab alternative (on the lush homepage)
>> is misleading--at least for now. But this is what we should be aiming
>> at, I think: making lush a serious alternative to environments like
>> matlab, scilab, octave, python+scipy, etc.
>>
>> To that end, my own current priorities (whishlist) are:
>> - an ide with graphcial source level debugger (like eclipse)
>> - better visualization tools (interfacing vtk?)
>>
>> and on the language side:
>> - lexical scoping
>> - a module system (i.e., namespaces)
>> - compiler support for the whole language
>>
>> I'm also not so sure about Ogre; we might get to a more powerful
>> and well designed GUI toolkit faster by interfacing to one of the
>> major GUI systems (Qt, wxWidgets, GTK, GnuStep, etc.).
>>
>> my two pfennigs,
>> ralf
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App Server.
>> Download it for free - -and be entered to win a 42" plasma tv or your very
>> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>> _______________________________________________
>> Lush-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/lush-users
>
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.