Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Topic: Mathematica and Lisp
Replies: 16   Last Post: Mar 7, 2013 3:58 AM

 Messages: [ Previous | Next ]
 Richard Fateman Posts: 286 Registered: 12/7/04
Re: Mathematica and Lisp
Posted: Mar 3, 2013 10:57 PM

On 3/3/2013 5:57 AM, Bob Hanlon wrote:
> "@@@ ?"
>
> The operator @@@ has been used and explained multiple times on this
> newsgroup and is documented in the Mathematica help.

/I'm a touch typist.
So I'm happy with examples like this ---

? Apply
which works

But

? @@@

returns Information::nomatch

To use your method I must remove at least one hand from the keyboard,
scramble around to find
the mouse and then hit f1 and then return my hand to the keyboard in
order to get the documentation.
This is a bad design. I've mentioned it previously. But that's really
a different point. There are
many 3-character non-alphabet sequences. How many of them "mean"
anything to you?

As for @@@ being explained multiple times in this newsgroup, maybe you
should wonder why
(a) it should have to be explained even once
(b) why it should have to be explained multiple times.

Maybe it is not the most useful operation? Maybe it is not the most
euphonious operator?
see this excellent and very short clip

from "Mars Attacks".

RJF

/
>
> Select @@@ then hit function key F1 and the search results includes a
> link to the help page for the Apply function. The summary under the
> link for Apply includes "f @@@ expr replaces heads at level 1 of expr
> by f." Looking under Details and Options on the Apply help page is
> the statement "f@@@expr is equivalent to Apply[f, expr, {1}]". For
> example,
>
> data = Array[a, {3, 2}]
>
> {{a[1, 1], a[1, 2]}, {a[2, 1], a[2, 2]}, {a[3, 1], a[3, 2]}}
>
> f @@@ data
>
> {f[a[1, 1], a[1, 2]], f[a[2, 1], a[2, 2]], f[a[3, 1], a[3, 2]]}
>
> f @@@ data == (f @@ # & /@ data) ==
> Apply[f, data, 1] == Apply[f, data, {1}]
>
> True
>
>
> Bob Hanlon
>
>
> On Sun, Mar 3, 2013 at 2:22 AM, Richard Fateman <fateman@cs.berkeley.edu> wrote:

>> On 3/2/2013 12:44 AM, Bill Rowe wrote:
>> ...
>>
>> <snip>
>> I mostly agree with you!
>>

>>> I agree Mathematica is different in a great many ways. And I can
>>> see how someone experienced in say C or another language would
>>> see Mathematica as strange and unusual. But I really don't see
>>> the problem of understanding Mathematica symbols, precedence
>>> etc. as being any different than learning pointers are other
>>> aspects of C. It is simply a matter of study and using
>>> Mathematica just as it is a case of study and using C to learn
>>> pointers etc.
>>>

>> C is not my favorite programming language .. see
>> www.cs.berkeley.edu/~fateman/papers/software.pdf
>>
>> Nevertheless one can almost argue that if you know about
>> how computers work on the assembly language level you have
>> a modest chance of mapping C constructs to assembler-like
>> code "in your head". I've taught this as part of an
>> undergraduate course in "Machine Structures".
>>
>> For EF, the number of unfamiliar operators and the
>> number of distinct precedences is substantial.
>>
>> There is a table in the virtual book documentation "operation precedence"
>> in the section Operator Input Forms.
>>
>> There are roughly
>> 69 different precedence categories listed.
>>
>> In some precedence classes there are many forms.
>> For example in the category 4th from the bottom there are these
>> operators which, being in the same class, would be parsed from
>> left to right (or is it right to left?) anyway, here they are.
>>
>> =, :=, ^=, ^:=, =. ->,
>> and also the matchfix
>> /: =
>> /: :=
>>
>> While some of the operators have no built-in meaning, and some are
>> pretty obscure, they are all part of the syntax. There are also quite
>> a few multi-character operators, some of which are new to me.. @@@ ?
>>
>> This is an attempt to document one of reasons I think EF is NOT just
>> as easy to learn as any other language. I've previous mentioned other
>> reasons which can be grouped generally under the category "semantics".
>>
>> RJF
>>
>>
>>
>>
>>
>>

Date Subject Author
3/3/13 Richard Fateman
3/5/13 David Bailey
3/5/13 Richard Fateman
3/6/13 David Bailey
3/7/13 Richard Fateman
3/5/13 Bill Rowe
3/5/13 Richard Fateman
3/6/13 David Park
3/6/13 Richard Fateman
3/7/13 Christoph Lhotka
3/7/13 Murray Eisenberg
3/7/13 Noqsi