Message Boards Message Boards

0
|
10899 Views
|
11 Replies
|
16 Total Likes
View groups...
Share
Share this post:

Understanding Wolfram Language programs

Posted 10 years ago

I am very new to Mathematica, and the Wolfram Language. I have been going through various demonstration files, and I am finding it surprisingly difficult to 'grok' the code. I have experienced this problem with other Lisp-like languages, and it seems to be driven by having to read the programs 'inside out'.

What I would like to understand is whether this is something that just goes away with time & experience, i.e. for highly experienced Mathematica programmers, do you find you just read the code naturally. Or, do you break apart people's code, perhaps using intermediate variables, in order to understand the various elements?

If you do break it apart, are there any tools that help? For instance, is there a way to unbundle function calls, and format them as chained functions - which is what I find myself doing.

POSTED BY: Andrew Burnett
11 Replies

That is such a good question. I have been using the program for a long time and I still have problems. For an example that I have had since 2005 i[t_?NumericQ] := 0.3*10^-9 UnitStep[10 [Tau] - t] UnitStep[t] What was he or she doing with this code line? I still cannot figure it out.

The demonstrations are wonderful, but to try to figure them out is a task. When I was a professor I never had trouble when my students tuned in FORTRAN programs even if they were not perfect. But if I was teaching today and they turned in a Mathematica demo. I would be climbing the walls. Maybe I am just too old now!

POSTED BY: Jake Trexel

I just want to second the above.

In general, displays of data, especially as in data-driven programming, make Mathematica code much easier to read and understand.

-- Mark

POSTED BY: Mark Tuttle

Hi Andy,

the relevant things are already said above. I just want to make a minor remark: One can easily write simple "help functions" to make complicated pieces of code more understandable, e.g.:

Attributes[makeObviousFrame] = 
  Attributes[makeObviousTree] = {HoldAllComplete};
makeObviousFrame[expr_] := Map[Framed, Inactivate[expr], {0, -2}];
makeObviousTree[expr_] := TreeForm[Inactive[expr]]

Putting these function in front of some "complicated" expression, e.g.:

makeObviousFrame @
 Flatten[mkArray1D /@ 
   Partition[
    Select[mccRaw, (NumberQ[#[[1]]] || 
        StringMatchQ[#[[1]], "INPLANE" ~~ ___]) &], 28], 1]
makeObviousTree @
 Flatten[mkArray1D /@ 
   Partition[
    Select[mccRaw, (NumberQ[#[[1]]] || 
        StringMatchQ[#[[1]], "INPLANE" ~~ ___]) &], 28], 1]

gives: enter image description here

Maybe this is helpful.

Henrik

POSTED BY: Henrik Schachner
Posted 10 years ago

Thanks Henrik, That is really helpful. I particularly like the tree layout, I think the way it demonstrates the branching structure is very useful indeed.

For anyone else who comes across this question in the future. I have a few observations: 1. The virtual book is very helpful indeed. I think it would pay Wolfram to make it more visible to new users. The one thing that is rather strange about it is that the navigation is not linear. In other words, you can't always step through the book page by page. Sometimes you have to backtrack to a section description to get to the next section. No doubt it made sense to the designers, but I am finding it breaks up the reading flow.

  1. It takes a while to learn the terminology used within the system. I think this is a bigger barrier for me than for some others. I do most of my programming in Smalltalk. When I first came across Entities I - unconsciously - interpreted them as 'objects', and that meant I brought a whole collection of assumptions with me. It has taken a while to escape from that construct. I am still not quite sure how to thing about Entities, but I now see them more as a bundle of arrays, with some accessing methods.

  2. There seems to be an idiomatic style to writing Wolfram Language programs. I think it is really important to let go of other style experience and try to embody this style, otherwise I feel I am going to be fighting the system to try to make it conform to my view of how it should work.

  3. Debugging is a pain! I would love for someone to show me the best way of debugging, and I do understand that by building up the code from very small functions, debugging is much less of an issue. However, the fact that I can't easily inspect, values really throws me off. Hopefully, someone will enlighten me to the true way :-)

I am really enjoying learning the system, and I can see that it has huge potential.

POSTED BY: Andrew Burnett

Hi Andy,

yes, it definitely has a huge potential! But one has to pay a price in terms of effort. When I started learning Mathematica only three years ago, we had version 8 and there the Virtual Book was very explicit to find. And the best and fastest way to get familiar with WL is to work through the capter "Core Language" entirely. I do not understand why something that useful as this Virtual Book is now in V10 so completely hidden - you will not find it unless you know that there is one.

Debugging is in my opinion not that a big problem, because it is an interpreter language after all. And there the notebook environment is helpful, e.g. the possibility of double/triple/multiple clicks to make whole expressions visible - very simple, but effective!

But anyway - you made a top decision! I use MMA every day and I am sort of addicted!

Henrik

POSTED BY: Henrik Schachner
Posted 10 years ago

I can't claim to know the best way of debugging, but here is how I approach developing code.

Mathematica (WL) uses a functional paradigm. Generally, I try to keep things readable and testable by keeping functions simple, and calling functions from functions to build up complexity.

However, there are times when that doesn't work - particularly when I need a complex function to map onto a list. A good example is a function to process data in a file, when I want to process many files, or a new file at intervals. In this case, I start out developing the function as a section of a notebook that performs the import and analysis on a single file using a sequence of separate cells. I will take a sample file name and assign it to a variable called "file." Then in the next cell I'll Import "file" assigning the import to "raw." Then in successive cells I'll format the data as needed, do any required analyses, export data as needed, make plots and export them as needed, or just format the data into an expression I want as the output of the function. I can see the results and correct any errors as I go along. When I'm happy, I'll usually save the notebook as a development book. But then I will delete all output from the sequence of cells and terminate each with a semicolon. I place a cell with the opening for Module at the top, including the list of internal variables as used in the cells below. I use "file_" as the argument since I used "file" as the file name. If necessary, I add a cell at the end with the output I want from the function, and merge the cells into what is now a single cell which defines the function using the Module. In writing the initial cells, I use (* *) comments for documentation rather than formatted cells, anticipating that they need to be within a single cell when finished.

I find this generally produces functions which work. If I later get an error, perhaps due to unanticipated input, I try first to troubleshoot with embedded print statements or an altered final expression. (Like we did oh so many years ago.) If that fails, I load the development notebook with the inline cells version of the function and feed that the input that is causing the problem.

Best regards,

David

POSTED BY: David Keith
Posted 10 years ago

Thanks David, That is very helpful indeed. I like the idea of building up the function in a notebook, and then collapsing it into code.

It is interesting that you use mapping the function on a file as the example. Because, I was trying to do exactly that yesterday. In my case, I had a collection of pdf files that had been encoded in Base64 as part of a mime message. I needed to turn them base into binary pdfs. The good news is that I got it to work, and the WL expressions were incredibly simple, and powerful.

The bad part was that there was something wrong with the input file format, and it seemed to be quite difficult to get Mathematica to show me the contents of what it was trying to import. I am sure there is a way to dump the value of the Import expression, but this was an example of where I needed to understand debugging in more detail.

In the end, tackled the problem in Smalltalk, and spotted the problem easily, because Smalltalk has such excellent inspection capabilities. I need to find the equivalent capabilities in WL. But, in the meantime, I will definitely adopt your approach.

Cheers

POSTED BY: Andrew Burnett

The Virtual Book was easier to find in versions 8 and 9.

The on-line version is at http://reference.wolfram.com/language/tutorial/VirtualBookOverview.html .
In Mathematica, you can go to Help menu - Wolfram Documentation, and search for "virtual book". It is found at tutorial/VirtualBookOverview.

POSTED BY: Bruce Miller
Posted 10 years ago

That is just what I needed!

Thanks so much. I was struggling to understand the whole system, but this book gives me exactly the on-ramp I need.

Right, off to write my first WL programs!

Cheers Andy

POSTED BY: Andrew Burnett
Posted 10 years ago

Thanks Sean, that's very helpful indeed.

You mention a virtual book, but I not quite sure what you mean. I have found this page

http://reference.wolfram.com/language/?source=nav

is that what you meant? Or, is there an actual 'learn the wolfram language' book?

Cheers Andy

POSTED BY: Andrew Burnett

The demonstrations code isn't good code to start with. I would have found it overwhelming and confusing when I started. I always recommend going through the virtual book and reading documentation examples.

You're right that it's very easy to make dense unreadable code in practically any lisp like language. Some of the coding styles I've seen used in the demonstrations are very difficult to piece together.

I find well written Wolfram Language code easy to read. More so than even, say, Python. But badly written code is always hard to read.

I don't know of any tools like you describe existing in any language. I'm not sure how it would know how to unbundle and un-nest the functions in a way that made it readable. Ideally, well written code is like that anyway.

POSTED BY: Sean Clarke
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract