Re: Re: Comparison between Mathematica and other
- To: mathgroup at smc.vnet.net
- Subject: [mg92568] Re: [mg92562] Re: Comparison between Mathematica and other
- From: Murray Eisenberg <murray at math.umass.edu>
- Date: Mon, 6 Oct 2008 04:12:57 -0400 (EDT)
- Organization: Mathematics & Statistics, Univ. of Mass./Amherst
- References: <200809301133.HAA21932@smc.vnet.net> <gc7frc$en0$1@smc.vnet.net> <200810051006.GAA11498@smc.vnet.net>
- Reply-to: murray at math.umass.edu
Still, I would avoid such a highly condensed bit of code and would
probably first try something more like the following:
complexGreater[z_, w_] :=
(Re[z] > Re[w]) || (Re[z] == Re[w] && Im[z] > Im[w])
evalGreater[edata1_, edata2_] :=
complexGreater[First@edata1, First@edata2]
esys = Eigensystem[RandomReal[{-1, 1}, {6, 6}]]
Transpose[Sort[Transpose[esys], evalGreater]]
That separates the data and operation upon the data from the definition
of the underlying comparison functions. And yes, in complexGreater I'd
put in the redundant parentheses, or at least the second pair.
Once I did that, I _might_ condense the whole thing if I were going to
do it just once, but certainly not if it were going to be re-used.
Then, of course, I'd define a function...
sortByEigenvalues[esys_]:=
Transpose[Sort[Transpose[esys], evalGreater]]
and then probably redo it so as to eliminate the need for evalGreater:
sortByEigenvalues[esys_]:=
Transpose[Sort[Transpose[esys],complexGreater[First@#1,First@#2]&]]
I'd still surely want to keep the complexGreater function, as that seems
a separate "chunk".
One thing I would still _not_ want to do would be to use the #1[[1]] and
#2[[1]] forms, which my eye finds too difficult to understand at a
glance -- too hard to separate the argument number from the Part number.
AES wrote:
>>>> Transpose[
>>>> Sort[Transpose[Eigensystem[RandomReal[{-1, 1}, {6, 6}]]],
>>>>
>>>> Re[#2[[1]]] < Re[#1[[1]]] ||
>>>> Re[#2[[1]]] == Re[#1[[1]]] && Im[#2[[1]]] < Im[#1[[1]]] &]]
>>>>
>>>> I think this also is a good example of the use of functional programming,
>>>> and it helped me to get in to it.
>>>> In Mathematica we are thus able to sort any kind of "objects" with any
>>> kind
>>>> of sorting criteria, thanks to the generality of the language.
>
> I'm really not attempting to re-open the functional vs procedural
> programming battle here, but I'd offer a couple or three observations on
> the above:
>
> 1) Commands like Sort[ ], Transpose[ ], Re[ ] are evidently "functions"
> and I suppose these functions contain massive levels of sophisticated
> functional programming (and pattern matching) in their internals -- --
> but just using them as functions doesn't, it seems to me, really
> constitute hard-core "functional programming" by those users who do
> this.
>
> Their names are ordinary English or mathematical terms; what they do (or
> are likely to do) will seem obvious to even the most unsophisticated
> user; and they can be readily used even by unsophisticated (or entirely
> procedurally oriented) users, at least in their default modes, without
> even knowing what functional programming is -- that is, without such
> users learning (or having to remember) any kind of arcane symbols or
> functional programming notations or structures, and especially any
> symbols and notations that are not used in and familiar from, say,
> elementary algebra or calculus.
>
> Just using -- or even defining for yourself -- a named function (macro,
> subroutine, whatever) doesn't seem to me "functional programming" at any
> very meaningful level; and doing this certainly doesn't depend on the
> "generality" of Mathematica as a language. These same capabilities are
> certainly present, and commonplace, in what I believe are labeled as
> crudely "procedural languages" (FORTRAN, BASIC, etc).
>
> 2) Now it's certainly true that if you want to modify the default
> behavior of Sort[ ], you do indeed have to be able to do (or more likely
> copy and modify) what I'd agree is some very modest level of procedural
> programming, as well illustrated in the example above:
>
> Re[#2[[1]]] < Re[#1[[1]]] ||
> Re[#2[[1]]] == Re[#1[[1]]] && Im[#2[[1]]] < Im[#1[[1]]] &]]
>
> But even I (a resolutely procedural type) would have little trouble with
> this particular example, since the level of 'arcanity' is really pretty
> limited: The "#n" notation for arguments is familiar from TeX (and what
> other languages?); the "||" and "&&" notations are familiar from
> low-level logic classes; and the "==" and "[[ ]]" notations are pretty
> basic Mathematica. The only 'arcane' thing (for me) is the single "&"
> at the end, which I have no idea why is there, but I'll dutifully copy
> it.
>
> 3) As a fallout from this, I'll continue to argue that if Mathematica
> really wants to expand and serve the widest possible customer base --
> e.g., high school math and physics students, college students (and grad
> students) in nontechnical fields, working engineers in industry, etc. --
> for those audiences (aka customers) it should:
>
> 1) Substantially sharpen its focus on making and keeping Mathematica
> simpler and easier to use and much easier to learn for those audiences,
> including a focus on better documentation and fewer complexities and
> "gotchas" (which is not imply taking away any of the pattern matching
> and functional programming underpinnings that are so crucial to other,
> more sophisticated users of Mathematica); and
>
> 1) Drastically reduce its prices.
>
> --AES, Oct 2008
>
--
Murray Eisenberg murray at math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
- References:
- Re: Comparison between Mathematica and other
- From: AES <siegman@stanford.edu>
- Re: Comparison between Mathematica and other