Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: General--Difficulties in Understanding Mathematica Syntax

  • To: mathgroup at smc.vnet.net
  • Subject: [mg69031] Re: [mg69006] Re: General--Difficulties in Understanding Mathematica Syntax
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sun, 27 Aug 2006 01:24:02 -0400 (EDT)
  • References: <echdk4$oir$1@smc.vnet.net> <ecmgpr$9b3$1@smc.vnet.net> <200608260604.CAA02766@smc.vnet.net> <54B808EB-0990-4D9B-A310-33F14AAF73BE@mimuw.edu.pl>
  • Sender: owner-wri-mathgroup at wolfram.com

On 26 Aug 2006, at 11:23, Andrzej Kozlowski wrote:

>
> On 26 Aug 2006, at 08:04, AES wrote:
>
>> In article <ecmgpr$9b3$1 at smc.vnet.net>,
>>  Jean-Marc Gulliet <jeanmarc.gulliet at gmail.com> wrote:
>>
>>>
>>> Now, it is utterly better to use high-level constructs such as Map,
>>> Thread, Apply, ... when you code in Mathematica.
>>>
>>
>> I don't exactly quarrel with this -- but I sure don't fully accept it
>> either.
>>
>> Concepts like Map[ ], Thread[ ], Apply[ ] are thoroughly  
>> understood by
>> adepts, and marginally understood by some of the rest of us.  They're
>> not concepts, or terms, commonly used in everyday speech.  And  
>> they may
>> have some hidden subtleties in their operation, even some  
>> "gotchas", in
>> how they apply to what's inside the [ ]s.
>>
>> Constructs like Do[] , If[ ], While[ ] are fairly likely to be
>> understood not just by adepts, but by anyone who's ever done even  
>> very
>> elementary programming in (horrors!) BASIC.  Their programming use
>> matches up pretty well with the same terms in everyday speech.  They
>> make the flow of the program logic more obviously visible (at  
>> least to
>> us non-adepts).  And I suspect they have fewer hidden gotchas.
>>
>> Writing complex Mathematica expressions as dense, deeply nested,
>> sometimes lengthy expressions full of arcane shorthands ("\\@",  
>> etc) is
>> akin to writing dense, arcane, possible lengthy prose sentences  
>> full of
>> arcane terminology.  Writing them as short, crisp, clear  
>> constructs, one
>> task at a time, is like writing short, crisp, clear prose sentences.
>> The people who construct "readability indexes" for prose have some
>> opinions about this.
>>
>> [We all, of course, fondly remember APL:  "Code once, read or modify
>> never".]
>>
>> What is it that's actually **better** (for the "ordinaryt user")  
>> about
>> these more sophisticated constructs?
>>
>> *  Readability? -- except for adepts, I don't think so.
>>
>> *  Faster, more efficient execution? -- perhaps so, but in the vast
>> majority of cases, who cares?!?
>>
>> *  More accurate execution?  -- I sure hope not.
>>
>> *  Shorter code (fewer characters)? -- again, who cares?!?
>>
>> *  Bragging rights (I can accomplish the task with fewer  
>> characters than
>> anyone around)? -- Well, that was a very salable skill, in  
>> magnetic core
>> and assembly language days.
>>
>> Again, to each his own.  Part of the genius of Mathematica is that it
>> serves the novice user and the sophisticated adept.  But "better"?
>
>
> I don't really disagree with you but I also find your comments  
> somewhat.

Those horrid gremlins got me again :-(  It should have been "I also  
find your comments somewhat incomplete".

Andrzej Kozlowski


> I think the answer to the question: is it much better to use  
> functional rather than procedural programing depends above all on  
> what you are doing. I am doubtful that your view correctly reflects  
> the "vast majority" of Mathematica users.
> For some purposes, for example, when you want to implement quickly  
> in Mathematica an algorithm written in some sort of pseudo code in  
> some book on algorithms, and many other similar purposes,  
> procedural code will generally be much more convenient. It indeed  
> corresponds better to the way normal processors work and therefore  
> it is use din almost all books on algorithms etc.
>
> For purely numerical purposes, provided your program can be  
> compiled, you can often achieve pretty satisfactory results with  
> procedural code (but note that it is very hard to make use of  
> Mathematica's ultra-efficient numerical methods like packed arrays  
> or SparseArrays unless you have use functional programming. This  
> may not be important to you but judging by the posts to this list  
> people who do not care about the speed of execution of their  
> numerical code are not "the vast majority of cases".)
>
> Finally, the area that interests me most and where I have the most  
> experience: symbolic algebra. Here I have no doubt that "algebraic"  
> languages (which for the sake of argument we can identify with  
> "functional") like Lisp, ML or Mathematica, etc., are vastly  
> superior to procedural ones. Just remember that you can map a  
> function not only onto a list but onto any algebraic expression.  
> Here is a silly example I just made up on the spot and which is not  
> supposed to have any significance besides showing the kind of thing  
> that would be pretty hard do accomplish in a non-functional language:
>
>
> (If[#1 >= 3 && PrimeQ[#1], #1^2, #1] & ) //@
>   (7*x^2 + 3*y^4 + 2.5)
>
> 9*y^4 + 49*x^2 + 2.5
>
> This may be of little interest to those users not interested in  
> symbolic algebra, but if they are not interested in it than I am  
> not exactly sure why they use a Computer Algebra System rather than  
> an ordinary programming language, like, for example, Basic.
>
> Andrzej Kozlowski
>
>
>
>
>


  • Prev by Date: Re: Re: General--Difficulties in Understanding Mathematica Syntax
  • Next by Date: hatching of the area between two curves?
  • Previous by thread: Re: Re: General--Difficulties in Understanding Mathematica Syntax
  • Next by thread: Re: Re: General--Difficulties in Understanding Mathematica Syntax