Mathematica - General--Difficulties in Understanding Mathematica Syntax

Author

General--Difficulties in Understanding Mathematica Syntax

madhukarrapaka@yahoo.com

2006-08-23, 8:04 am

Hi Mathematica Experts,

Sorry for a lengthy query.

I am new to Mathematica. The syntax of mathematica is quite different from other programming languages.
I am

how to use loops like "If",FOR;DO;...

Here i am giving details of a problem i want to solve. I made an attempt to solve this. Please go thru it and give me necessary corrections.

Here i am giving the details:
P = 10.3;l = 0.45mm;T = 0.9;r0 = 0.025mm;d = 0.1643mm;
r[xk_, yk_] := (Sqrt[(x - xk)^2 + (y - yk)^2]);
Intensity[xk_, yk_] := (P/(2*Pi*r[xk, yk]*l))*T^(r[xk, yk] - r0);
Imoy=[Integrate[Intensity[xk, yk]],{xk, 0.1, -0.1}, {yk, 0.1, -0.1}] ;
Print[Imoy]

Then i am getting some value, which is not the correct one.
How to check the output for each step in Mathematica(for example: if i want to find out the values of "r", In C language i can use Printf statement to print the values of "r" for each xk,yk)

And if i want to evaluate the "Intensity[xk_, yk_] " depending on a condition (say: r[xk,yk]<d) [I think it can be done by using IF statement, but i have no clue how to use the IF statement in MATHEMATICA].

Please help me by providing some advices.

It would be better if one can provide me some examples., or documentation which contains some solved examples in Mathematica.

Thanks in advance.

Link to the forum page for this post:
http://www.mathematica-users.org/we...id=12943#p12943
Posted through http://www.mathematica-users.org [[postId=12943]]

Jean-Marc Gulliet

2006-08-25, 4:05 am

madhukarrapaka@yahoo.com wrote:
> I am new to Mathematica. The syntax of mathematica is quite different from other programming languages.
> I am

how to use loops like "If",FOR;DO;...

Procedural constructs in Mathematica work roughly like in any procedural
or object-oriented languages (BASIC, FORTRAN, C, C++, JAVA, PASCAL
DELPHI, C#, to name a few). The concepts are the same; the syntax may
differ, however.

Now, it is utterly better to use high-level constructs such as Map,
Thread, Apply, ... when you code in Mathematica.

> Here i am giving details of a problem i want to solve. I made an attempt to solve this. Please go thru it and give me necessary corrections.
>
> Here i am giving the details:
> P = 10.3;l = 0.45mm;T = 0.9;r0 = 0.025mm;d = 0.1643mm;
> r[xk_, yk_] := (Sqrt[(x - xk)^2 + (y - yk)^2]);
> Intensity[xk_, yk_] := (P/(2*Pi*r[xk, yk]*l))*T^(r[xk, yk] - r0);
> Imoy=[Integrate[Intensity[xk, yk]],{xk, 0.1, -0.1}, {yk, 0.1, -0.1}] ;
> Print[Imoy]
>
> Then i am getting some value [...]

No you don't, since the code displayed above is erroneous and returns
error messages if you attempt to execute it.

First, correct the syntax.

Second, remove the units.

Third (a), use NIntegrate since you want numerical answers.

Third (b), if you do want a symbolic solution, use exact numbers (0.1 is
not the same than 1/10 in terms of precision).

Fourth, test individually each function and ask yourself what are and/or
where are coming from the values of the variables x and y.

For instance,

P=10.3; l=0.45; T=0.9; r0=0.025; d=0.1643;
r[ xk_?NumericQ, yk_?NumericQ]:= ( Sqrt[ ( x-xk)^2+ ( y-yk)^2]);
Intensity[ xk_?NumericQ, yk_?NumericQ]:= ( P/ ( 2*Pi* r[ xk,yk]*l))*
T^ ( r[ xk,yk]-r0);
Imoy= NIntegrate[ Intensity[ xk,yk]/. { x->1, y->1}, { xk, -0.1,0.1},
{ yk, -0.1,0.1}]

--> 0.08909421835919498

HTH,
Jean-Marc

Chris Chiasson

2006-08-25, 4:05 am

Your equations seem to be dimensionally inconsistent. If you need more
help, please provide the dimensions of all your variables.

On 8/23/06, madhukarrapaka@yahoo.com <madhukarrapaka@yahoo.com> wrote:
> Hi Mathematica Experts,
>
> Sorry for a lengthy query.
>
> I am new to Mathematica. The syntax of mathematica is quite different from other programming languages.
> I am

how to use loops like "If",FOR;DO;...
>
> Here i am giving details of a problem i want to solve. I made an attempt to solve this. Please go thru it and give me necessary corrections.
>
> Here i am giving the details:
> P = 10.3;l = 0.45mm;T = 0.9;r0 = 0.025mm;d = 0.1643mm;
> r[xk_, yk_] := (Sqrt[(x - xk)^2 + (y - yk)^2]);
> Intensity[xk_, yk_] := (P/(2*Pi*r[xk, yk]*l))*T^(r[xk, yk] - r0);
> Imoy=[Integrate[Intensity[xk, yk]],{xk, 0.1, -0.1}, {yk, 0.1, -0.1}] ;
> Print[Imoy]
>
> Then i am getting some value, which is not the correct one.
> How to check the output for each step in Mathematica(for example: if i want to find out the values of "r", In C language i can use Printf statement to print the values of "r" for each xk,yk)
>
> And if i want to evaluate the "Intensity[xk_, yk_] " depending on a condition (say: r[xk,yk]<d) [I think it can be done by using IF statement, but i have no clue how to use the IF statement in MATHEMATICA].
>
> Please help me by providing some advices.
>
> It would be better if one can provide me some examples., or documentation which contains some solved examples in Mathematica.
>
> Thanks in advance.
>
> Link to the forum page for this post:
> http://www.mathematica-users.org/we...id=12943#p12943
> Posted through http://www.mathematica-users.org [[postId=12943]]
>
>
>

--
http://chris.chiasson.name/

David Park

2006-08-25, 4:05 am

You will probably get a number of different answers on this with various
approaches and some of them may be better than mine. But here is my
approach.

First I would recommend working through as much of Part I in The Mathematica
Book as seems relevant to you in order understand the basic syntax and usage
of Mathematica, and become familiar with the more common commands.

Secondly, don't think of Mathematica as either a 'super calculator' or as a
'programming language', althought it is in part these things. Think of it as
a piece of paper on which you are going to write down and do your
mathematics. Keep the mathematics in the foreground and let Mathematica be
in the background. You want to write down your specifications and
definitions and then perform mathematical operations on them. You have
actually gotten a fairly good start on doing that.

I would define your data values as a set of rules as follows:

data = {p -> 10.3, l -> 0.45, t -> 0.9, r0 -> 0.025, d -> 0.1643};

I started all the symbol names with small case letters. This is not
absolutely necessary but Mathematica always starts the reserved names with a
capital letter so this avoids any possible conflict. By using rules and
substituting when we want to we are still free to use these symbols as
strictly symbolic quantities. We might want to do this in equations and to
manipulate the equations before we actually substitute values. In your
problem we don't actually do this but it is still good practice not to Set
values to commonly used symbols. It is a common source of error. Also, you
had units 'mm' I think on some of the quantities. If we are going to do
numerical operations we want to get rid of the units. (Keeping the implied
units straight is another topic.)

Next, I rewrite the definitions you gave.

r[xk_, yk_] [x_, y_] := Sqrt[(x - xk)^2 + (y - yk)^2]

Intensity[xk_, yk_][x_, y_] := (p/(2*Pi*r[xk, yk][x, y]*l))*
t^(r[xk, yk][x, y] - r0);

The main thing I did here was put xk,yk in as subvalues and x,y as regular
arguments. I imagine that these are all used as variables in your final
output explorations. We might also consider adding p,l,t,r0 as parameters
but I would imagine that they are relatively fixed.

We could then calculate your integrated intensity at a specific location.
For example. I substitute the data values and use NIntegrate instead of
Integrate. (When I tried to integrate symbolically it took too long.)

NIntegrate[Intensity[xk, yk][0, 0] /. data, {xk, 0.1, -0.1}, {yk,
0.1, -0.1}]
2.56003

Suppose we want to see what this integrated intensity looks like along the
x-axis. We can write the following definition.

integral[s_] :=
NIntegrate[
Intensity[xk, yk][s, 0] /. data, {xk, 0.1, -0.1}, {yk, 0.1, -0.1}]

Then we could generate a set of values along the x axis.

xvals = Table[{s, integral[s]}, {s, 0, 2, 0.1}]
{{0, 2.56003}, {0.1, 1.74232}, {0.2, 0.743068}, {0.3, 0.480509}, {0.4,
0.353898}, {0.5, 0.279127}, {0.6, 0.229701}, {0.7, 0.194581}, {0.8,
0.168337}, {0.9, 0.147981}, {1., 0.131733}, {1.1, 0.118467}, {1.2,
0.107431}, {1.3, 0.0981102}, {1.4, 0.0901345}, {1.5, 0.0832341}, {1.6,
0.0772066}, {1.7, 0.0718977}, {1.8, 0.0671871}, {1.9, 0.0629802}, {2.,
0.0592012}}

There was also a warning message but I don't know if we have to worry much
about it.

We could then define this as a function by interpolating on the values
calculated above.

f[x_] = Interpolation[xvals][x]
InterpolatingFunction[{{0., 2.}}, <>][x]

And then we could plot the resulting function.

Plot[f[x], {x, 0, 2},
Frame -> True,
FrameLabel -> {x, f},
PlotRange -> All,
PlotLabel -> "Integral of Intensity Along x Axis",
ImageSize -> 500];

There may be better approaches to this particular problem but I hope that I
have conveyed the idea that we are just doing the mathematics and writing it
down in the notebook and it is really not at all like formal 'computer
science programming'.

David Park
djmp@earthlink.net
http://home.earthlink.net/~djmp/

From: madhukarrapaka@yahoo.com [mailto:madhukarrapaka@yahoo.com]

Hi Mathematica Experts,

Sorry for a lengthy query.

I am new to Mathematica. The syntax of mathematica is quite different from
other programming languages.
I am

how to use loops like "If",FOR;DO;...

Here i am giving details of a problem i want to solve. I made an attempt to
solve this. Please go thru it and give me necessary corrections.

Here i am giving the details:
P = 10.3;l = 0.45mm;T = 0.9;r0 = 0.025mm;d = 0.1643mm;
r[xk_, yk_] := (Sqrt[(x - xk)^2 + (y - yk)^2]);
Intensity[xk_, yk_] := (P/(2*Pi*r[xk, yk]*l))*T^(r[xk, yk] - r0);
Imoy=[Integrate[Intensity[xk, yk]],{xk, 0.1, -0.1}, {yk, 0.1, -0.1}] ;
Print[Imoy]

Then i am getting some value, which is not the correct one.
How to check the output for each step in Mathematica(for example: if i want
to find out the values of "r", In C language i can use Printf statement to
print the values of "r" for each xk,yk)

And if i want to evaluate the "Intensity[xk_, yk_] " depending on a
condition (say: r[xk,yk]<d) [I think it can be done by using IF statement,
but i have no clue how to use the IF statement in MATHEMATICA].

Please help me by providing some advices.

It would be better if one can provide me some examples., or documentation
which contains some solved examples in Mathematica.

Thanks in advance.

Link to the forum page for this post:
http://www.mathematica-users.org/we...?pageName=Speci
al:Forum_ViewTopic&pid=12943#p12943
Posted through http://www.mathematica-users.org [[postId=12943]]

Peter Pein

2006-08-25, 4:05 am

madhukarrapaka@yahoo.com schrieb:
> Hi Mathematica Experts,
>
> Sorry for a lengthy query.
>
> I am new to Mathematica. The syntax of mathematica is quite different from other programming languages.
> I am

DarkWing

2006-08-25, 4:05 am

madhukarrapaka@yahoo.com wrote:
>
> And if i want to evaluate the "Intensity[xk_, yk_] " depending on a condition (say: r[xk,yk]<d) [I think it can be done by using IF statement, but i have no clue how to use the IF statement in MATHEMATICA].

The real gem in Mathematica is its online help functionality which can
be reached by pressing the 'F1' key at any time. Here you have access
to the documentation for *all* functions and packages in Mathematica.

A nice little trick is to highlight the function you are interessted in
and then press 'F1'.
For example if you want the details about the Mathematica function
If[], then write If[] in your notebook, highlight it with the mouse and
hit 'F1'

> It would be better if one can provide me some examples., or documentation which contains some solved examples in Mathematica.

All the documentation has examples, you justr have to press the little
triangle in the bottom left of the help page.

> Thanks in advance.
No problem, happy exploration :-)

- oh yeah i almost forgot; the written manual called "The Mathematica
Book" is also found electronically in the help browser. Enjoy!

AES

2006-08-26, 4:03 am

In article <ecmgpr$9b3$1@smc.vnet.net>,
Jean-Marc Gulliet <jeanmarc.gulliet@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"?

Andrzej Kozlowski

2006-08-27, 4:06 am

On 26 Aug 2006, at 08:04, AES wrote:

> In article <ecmgpr$9b3$1@smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet@gmail.com> wrote:
>
>
> 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. 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

Andrzej Kozlowski

2006-08-27, 4:06 am

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

>
> On 26 Aug 2006, at 08:04, AES wrote:
>
>
>
> 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
>
>
>
>
>

David Bailey

2006-08-27, 4:06 am

AES wrote:
> In article <ecmgpr$9b3$1@smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet@gmail.com> wrote:
>
>
> 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 agree with AES on this 100%. One problem with functional programming
is that it reduces easy problems to one line but leaves a novice with
little idea how to tackle a slightly more substantial problem - say one
with boundary conditions which mean the edges of an array need to be
treated differently. Of course there are ways to solve these problems
functionally as well, but they take a lot more experience and are not as
elegant. I teach both functional and non-functional approaches and point
out the advantages of each.

Yes, explicit loops are less efficient in Mathematica, but you can do
very sophisticated work with Mathematica without ever being troubled by
speed of execution.

David Bailey
http://www.dbaileyconsultancy.co.uk

Chris Chiasson

2006-08-27, 4:06 am

It's gotten to the point where I don't even attempt to read or
understand Mathematica code if it's written with Do, For, or While.

On 8/26/06, AES <siegman@stanford.edu> wrote:
> In article <ecmgpr$9b3$1@smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet@gmail.com> wrote:
>
>
> 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"?
>
>

--
http://chris.chiasson.name/

Bill Rowe

2006-08-27, 4:06 am

On 8/26/06 at 2:04 AM, siegman@stanford.edu (AES) wrote:

>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.

<snip>

>What is it that's actually **better** (for the "ordinaryt user")
>about these more sophisticated constructs?

>* Faster, more efficient execution? -- perhaps so, but in the vast
>majority of cases, who cares?!?

The difference in execution speed can easily be 2 orders of magnitude or more. This is enough performance difference to be the difference between a problem that can be done and one that cannot be done.

>* More accurate execution? -- I sure hope not.

Yes and no. No, in the sense that correct code written with procedural programming will produce the same results as those obtained with Map and the like. But the code with Map is simpler since I do not need to worry about indexing. For example, a typical
error when coding with For loops to index an array is to be one off, i.e., using say greater as the stopping criteria when it should have been greater than or equal. Since indexing is never explicitly coded with Map, this error cannot happen.

Once you become accustom to using Map, Apply etc. you will find additional benefits besides improved execution speed. Your overall productivity will improve since you will no longer need to worry about indexing of arrays, how long an array is etc. This al
low you to focus more on the problem being solve rather than worrying about low level implementation details. And this in turn, will give you greater confidence in the completed code.

Yes, it requires a bit of effort and time to become proficient in using Map etc since they are quite different than procedural programming constructs. But I believe it is time and effort well spent, particularly if you use Mathematica as frequently as I d
o.
--
To reply via email subtract one hundred and four

AES

2006-08-28, 4:08 am

In article <ecrbsu$pc5$1@smc.vnet.net>,
Bill Rowe <readnewsciv@earthlink.net> wrote:

> lBut the code with Map is simpler since I do not need to worry about
> indexing. For example, a typical error when coding with For loops to index an
> array is to be one off, i.e., using say greater as the stopping criteria when
> it should have been greater than or equal. Since indexing is never explicitly
> coded with Map, this error cannot happen.

I do agree with the underlying point in this comment. The gimmick I've
learned to always use with indexing is more or less the following. If
I'm doing a problem that involves say stepping over values of an
independent variable x ranging from 0 to xmax -- or more generally from
xmin to xmax -- I start by defining an x array using

xArray = Table[x, {xmin, xmax, (xmax-xmin)/nSteps]} ]

and then never touch a specific index or use [[ ]] notation again.
Plotting of results is done using

ListPlot[Transpose[{ xArray, resultArray} ]

János

2006-08-29, 4:34 am

On Aug 26, 2006, at 2:04 AM, AES wrote:

> In article <ecmgpr$9b3$1@smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet@gmail.com> wrote:
>
>
> 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"?

Newbie comment :)

- It took me to get used to Map about as much time that it took me to
get used to LET in Algol 60 :)

- For me better usually means how efficient the programming structure
is when I try to scale. For data elements of a few hundred almost
every construct works, but when I scale up to a few hundred thousand
or million data elements, then functional constructs proved to be
much BETTER.

János

----------------------------------------------
Trying to argue with a politician is like lifting up the head of a
corpse.
(S. Lem: His Master Voice)

robert.prince-wright@shell.com

2006-08-29, 4:34 am

This thread is an important one for the folks at Wolfram who are after all going to work to make a living by selling licenses. I was talking with another engineer last w

about the kinds of work we did. I have stuck with Mathematica and resisted the pat
h to other maths packages despite the fact that the vast majority of engineers have taken the 'easy' route. This has left me stranded in some ways since there is now a huge inventory of competent Math utilities - e.g. Roark and Young. Others have also inc
reased the sophistication of their maths packages so that they can be used as a web integrated solution engine, much like webMathematica.

One of the key benefits of the alternatives (I am told) is that they are easier to understand and there is more commonality with the normal Windows environment. I have to say after using Mathematica for research and having used it to teach the Applicable
Mathematics course at The University of Glasgow (1990) I can easily say I hated using the well know alternative when I returned to Industry - unfortunately I was the only one in the office.

I would guess that Wolfram would argue that Mathematica is aimed at a different market and there is some truth in that, however, having spent some time this morning looking at the competition I wonder if Wolfram are on a risky path since it's starting to
look like Apple vs. Microsoft in the 90s.

I think most would accept that David is correct in that the functional programming approach in Mathematica can result in code that is very difficult to read first time over. I end up having to unwrap the experts code when ever I'm looking to tap into Math
source. Every now and then I am amused at how crafty some of you are when compacting code. The problem is not their code, nor the syntax, it's the fact that Mathematica makes it difficult to understand what's actually happening as, for example, we MapAll,
MapThread, etc. a function onto a list, or list of lists. The current front end is still rather clunky and seems very underinvested. One simple way of helping people up the learning curve (or reminding occasional users like me) would be to have an option
al window which dynamically shows a Short version of the effect of what were typing in. This would save people like me from having to repeatedly evaluate the complete expression in order to understand exactly what the outcome will be. Something akin to th
e Java applet that animates Map, Apply etc.

We all know that Mathematica 6.0 is coming and one can only imagine that the next quantum step in Mathematica is being delayed to align with Windows Vista - I'm just hoping that the 'next step' (bad pun for oldies!) is going to provide better support for
the next generation of Mathematica users. Let's hope the fact my current job is being implemented near a place called Dinosaur is not my fate.

Robert

-----Original Message-----
From: David Bailey [mailto:dave@Remove_Thisdbailey.co.uk]
Subject: Re: General--Difficulties in Understanding
Mathematica Syntax

AES wrote:
> In article <ecmgpr$9b3$1@smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet@gmail.com> wrote:
>
>
> 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 agree with AES on this 100%. One problem with functional programming
is that it reduces easy problems to one line but leaves a novice with
little idea how to tackle a slightly more substantial problem - say one
with boundary conditions which mean the edges of an array need to be
treated differently. Of course there are ways to solve these problems
functionally as well, but they take a lot more experience and are not as
elegant. I teach both functional and non-functional approaches and point
out the advantages of each.

Yes, explicit loops are less efficient in Mathematica, but you can do
very sophisticated work with Mathematica without ever being troubled by
speed of execution.

David Bailey
http://www.dbaileyconsultancy.co.uk

Murray Eisenberg

2006-08-30, 8:04 am

I would disagree that "the functional programming approach in
Mathematica can result in code that is very difficult to read first time
over." At least not necessarily more difficult than the explicit loop
alternative.

An example -- Newton's method to find, say, the root of Tan[x] - x near
x = 4.5.

f[x_] := Tan[x] - x

A functional approach:

newtonStep[x_] := x - f[x]/f'[x]
NestList[newtonStep, 4.5, 10]

An iterative approach:

approx = {}; current = 4.5;
Do[current = newtonStep[current]; approx = Append[approx, current],
{10}]
approx

Of course one could modify either method to insert a stopping test (in
the functional approach, this would probably mean to use NestWhileList
instead of NestList).

Mathematica is "harder to read than BASIC" if all you know is BASIC.
And Russian is harder to read than English if all you know is English.

robert.prince-wright@shell.com wrote:
> This thread is an important one for the folks at Wolfram who are after all going to work to make a living by selling licenses. I was talking with another engineer last w

Chris Chiasson

2006-08-30, 8:04 am

Another system and its add-ons have intrigued me for a long time because
their notebooks really do look close to sets of equations an engineer
would write on a sheet of paper. However, I do not think that it
is actually a serious long term threat to Mathematica because it is
not oriented toward programming - which you always end up doing no
matter how good the interface and basic functions.

The more serious threats come from open general purpose programming
languages. One of the baddest is Microsoft's C# & the whole rest of
the .NET platform. Even though C#'s basic libraries are closed, the
language itself is open to be implemented by Free Software folks.
That's why its uptake has been so quick relative to Java and Java is
starting to be open sourced to compete with .NET. Also, XSLT is
another contender; it is weaker than Mathematica syntactically (but
even stronger than C# in openness and standardization). XSLT even has
a functional programming library. If XML & XSLT were simplified to
remove attributes, they would be a lot like Mathematica.

what C# code looks like - http://www.codeproject.com/cs/algorithms/

some screenshots from the mono C# project -
http://www.mono-project.com/Screenshots

Of course, I'll stick with Mathematica and its present licensing
scheme as long as I need it. Other language syntaxes still look
retarded to me compared to Mathematica syntax, but I know I'm biased.

On 8/29/06, robert.prince-wright@shell.com
<robert.prince-wright@shell.com> wrote:
> This thread is an important one for the folks at Wolfram who are after al=
l going to work to make a living by selling licenses. I was talking with an=
other engineer last w

about the kinds of work we did. I have stuck with =
Mathematica and resisted the path to other maths packages despite the fact =
that the vast majority of engineers have taken the 'easy' route. This has l=
eft me stranded in some ways since there is now a huge inventory of compete=
nt Math utilities - e.g. Roark and Young. Others have also increased the so=
phistication of their maths packages so that they can be used as a web inte=
grated solution engine, much like webMathematica.
>
> One of the key benefits of the alternatives (I am told) is that they are =
easier to understand and there is more commonality with the normal Windows =
environment. I have to say after using Mathematica for research and having =
used it to teach the Applicable Mathematics course at The University of Gla=
sgow (1990) I can easily say I hated using the well know alternative when I=
returned to Industry - unfortunately I was the only one in the office.
>
> I would guess that Wolfram would argue that Mathematica is aimed at a dif=
ferent market and there is some truth in that, however, having spent some t=
ime this morning looking at the competition I wonder if Wolfram are on a ri=
sky path since it's starting to look like Apple vs. Microsoft in the 90s.
>
> I think most would accept that David is correct in that the functional pr=
ogramming approach in Mathematica can result in code that is very difficult=
to read first time over. I end up having to unwrap the experts code when e=
ver I'm looking to tap into Mathsource. Every now and then I am amused at h=
ow crafty some of you are when compacting code. The problem is not their co=
de, nor the syntax, it's the fact that Mathematica makes it difficult to un=
derstand what's actually happening as, for example, we MapAll, MapThread, e=
tc. a function onto a list, or list of lists. The current front end is stil=
l rather clunky and seems very underinvested. One simple way of helping peo=
ple up the learning curve (or reminding occasional users like me) would be =
to have an optional window which dynamically shows a Short version of the e=
ffect of what were typing in. This would save people like me from having to=
repeatedly evaluate the complete expression in order to understand exactly=
what the outcome !
> will be. Something akin to the Java applet that animates Map, Apply etc.
>
> We all know that Mathematica 6.0 is coming and one can only imagine that =
the next quantum step in Mathematica is being delayed to align with Windows=
Vista - I'm just hoping that the 'next step' (bad pun for oldies!) is goin=
g to provide better support for the next generation of Mathematica users. L=
et's hope the fact my current job is being implemented near a place called =
Dinosaur is not my fate.
>
> Robert
>
>
>
> -----Original Message-----
> From: David Bailey [mailto:dave@Remove_Thisdbailey.co.uk]
> To: mathgroup@smc.vnet.net
> Subject: Re: General--Difficulties in Understanding
> Mathematica Syntax
>
>
> AES wrote:
e[color=darkred]
n[color=darkred]
e[color=darkred]
> I agree with AES on this 100%. One problem with functional programming
> is that it reduces easy problems to one line but leaves a novice with
> little idea how to tackle a slightly more substantial problem - say one
> with boundary conditions which mean the edges of an array need to be
> treated differently. Of course there are ways to solve these problems
> functionally as well, but they take a lot more experience and are not as
> elegant. I teach both functional and non-functional approaches and point
> out the advantages of each.
>
> Yes, explicit loops are less efficient in Mathematica, but you can do
> very sophisticated work with Mathematica without ever being troubled by
> speed of execution.
>
> David Bailey
> http://www.dbaileyconsultancy.co.uk
>
>
>
>

--=20
http://chris.chiasson.name/

Chris Chiasson

2006-08-30, 8:04 am

I really don't think anyone has a prayer of competing with
Mathematica's Integrate, Solve, Reduce, Piecewise, etc, until they use
a tree based structure for mathematics (similar to MathML or just
regular Mathematica syntax) and provide functions to manipulate it -
then add on years of expert mathematics knowledge. Basically, WRI is
very far ahead.

As far as integrating Mathematica with the web, I place the blame
squarely on the Export command (which is eally just a catch-all for
other exporting sub-commands). See basically every post I've made in
this group about XML, SVG, MathML, and Export for specific complaints.

On 8/29/06, robert.prince-wright@shell.com
<robert.prince-wright@shell.com> wrote:
> Hi Chris,
>
> do you think that the C# world will include solvers like Integrate, DSolve etc and are there plans to include the symbolic capabilities of Mathematica? These are examples of the key strenghts which keep us all paying for Mathematica upgrades.
>
> What you describe below leads me to wonder whether Wolfram are on the road to making the Front End better integrated with the web. It seems daft that the process of converting Notebooks to WebPages is so time consuming, and why cant we use GUIKit to cre
ate web ready interfaces?
>
>
>
>
>
> -----Original Message-----
> From: chris.chiasson@gmail.com [mailto:chris.chiasson@gmail.com]On
> Behalf Of Chris Chiasson
> Subject: Re: Re: General--Difficulties in
> Understanding Mathematica Syntax
>
>
> Another system and its add-ons have intrigued me for a long time because
> their notebooks really do look close to sets of equations an engineer
> would write on a sheet of paper. However, I do not think that it
> is actually a serious long term threat to Mathematica because it is
> not oriented toward programming - which you always end up doing no
> matter how good the interface and basic functions.
>
> The more serious threats come from open general purpose programming
> languages. One of the baddest is Microsoft's C# & the whole rest of
> the .NET platform. Even though C#'s basic libraries are closed, the
> language itself is open to be implemented by Free Software folks.
> That's why its uptake has been so quick relative to Java and Java is
> starting to be open sourced to compete with .NET. Also, XSLT is
> another contender; it is weaker than Mathematica syntactically (but
> even stronger than C# in openness and standardization). XSLT even has
> a functional programming library. If XML & XSLT were simplified to
> remove attributes, they would be a lot like Mathematica.
>
> what C# code looks like - http://www.codeproject.com/cs/algorithms/
>
> some screenshots from the mono C# project -
> http://www.mono-project.com/Screenshots
>
> Of course, I'll stick with Mathematica and its present licensing
> scheme as long as I need it. Other language syntaxes still look
> retarded to me compared to Mathematica syntax, but I know I'm biased.
>
> On 8/29/06, robert.prince-wright@shell.com
> <robert.prince-wright@shell.com> wrote:
path to other maths packages despite the fact that the vast majority of engineers have taken the 'easy' route. This has left me stranded in some ways since there is now a huge inventory of competent Math utilities - e.g. Roark and Young. Others have also
increased the sophistication of their maths packages so that they can be used as a web integrated solution engine, much like webMathematica.[color=darkred]
ble Mathematics course at The University of Glasgow (1990) I can easily say I hated using the well know alternative when I returned to Industry - unfortunately I was the only one in the office.[color=darkred]
to look like Apple vs. Microsoft in the 90s.[color=darkred]
Mathsource. Every now and then I am amused at how crafty some of you are when compacting code. The problem is not their code, nor the syntax, it's the fact that Mathematica makes it difficult to understand what's actually happening as, for example, we Map
All, MapThread, etc. a function onto a list, or list of lists. The current front end is still rather clunky and seems very underinvested. One simple way of helping people up the learning curve (or reminding occasional users like me) would be to have an op
tional window which dynamically shows a Short version of the effect of what were typing in. This would save people like me from having to repeatedly evaluate the complete expression in order to understand exactly what the outco[color=darkred]
> me !
for the next generation of Mathematica users. Let's hope the fact my current job is being implemented near a place called Dinosaur is not my fate.[color=darkred]
>
>
> --
> http://chris.chiasson.name/
>
>
>

--
http://chris.chiasson.name/

robert.prince-wright@shell.com

2006-08-30, 8:04 am

Hi Chris,

do you think that the C# world will include solvers like Integrate, DSolve etc and are there plans to include the symbolic capabilities of Mathematica? These are examples of the key strenghts which keep us all paying for Mathematica upgrades.

What you describe below leads me to wonder whether Wolfram are on the road to making the Front End better integrated with the web. It seems daft that the process of converting Notebooks to WebPages is so time consuming, and why cant we use GUIKit to creat
e web ready interfaces?

-----Original Message-----
From: chris.chiasson@gmail.com [mailto:chris.chiasson@gmail.com]On
Behalf Of Chris Chiasson
Subject: Re: Re: General--Difficulties in
Understanding Mathematica Syntax

Another system and its add-ons have intrigued me for a long time because
their notebooks really do look close to sets of equations an engineer
would write on a sheet of paper. However, I do not think that it
is actually a serious long term threat to Mathematica because it is
not oriented toward programming - which you always end up doing no
matter how good the interface and basic functions.

The more serious threats come from open general purpose programming
languages. One of the baddest is Microsoft's C# & the whole rest of
the .NET platform. Even though C#'s basic libraries are closed, the
language itself is open to be implemented by Free Software folks.
That's why its uptake has been so quick relative to Java and Java is
starting to be open sourced to compete with .NET. Also, XSLT is
another contender; it is weaker than Mathematica syntactically (but
even stronger than C# in openness and standardization). XSLT even has
a functional programming library. If XML & XSLT were simplified to
remove attributes, they would be a lot like Mathematica.

what C# code looks like - http://www.codeproject.com/cs/algorithms/

some screenshots from the mono C# project -
http://www.mono-project.com/Screenshots

Of course, I'll stick with Mathematica and its present licensing
scheme as long as I need it. Other language syntaxes still look
retarded to me compared to Mathematica syntax, but I know I'm biased.

On 8/29/06, robert.prince-wright@shell.com
<robert.prince-wright@shell.com> wrote:
> This thread is an important one for the folks at Wolfram who are after all going to work to make a living by selling licenses. I was talking with another engineer last w

Jean-Marc Gulliet

2006-08-31, 4:06 am

madhukarrapaka@yahoo.com wrote:
> Hi Mathematica Experts,
>
> Sorry for a lengthy query.
>
> I am new to Mathematica. The syntax of mathematica is quite different from other programming languages.
> I am

how to use loops like "If",FOR;DO;...
[...snipped...]

The following web site may be a great help in understanding how most of
the Mathematica programming functions work:

http://www.mathematica.co.kr/mathco...nviz/index.html

HTH,
Jean-Marc

Sponsored Links