Cogitatio

MathematicaCookbook.com

2012-01-09T22:54:00.003-05:00

My new blog related to work on Mathematica is finally up at mathematicacookbook.com

The Creators

2011-08-24T21:34:00.003-05:00

Consider the following syllogism:

Everything that exists has a creator.
God exists.
Therefore God has a creator.

Now, this is clearly valid from a purely deductive point of view. But deduction is nothing more than the mechanical rearrangement of symbols, hence it prove nothing about the true state of affairs in our universe until one considers the premises.

First consider "Everything that exists has a creator". If you accept this as a universal truth than we can move on. If you don't then you can entertain the thought that somethings exist and have no creator. Let's revisit the idea a bit later.

No consider the premise "God exists". If you are a believer than you hold this premis as true, by definition. But, if you also hold the first premise true, then you are logically bound to admit God was created by some prior God and so on ad infinitum. But clearly, this is not in line with the teachings of any mainstream religion. So as, say a Christian, you are forced to deny that everything that exists has a creator. Indeed, Christians would argue that everything that exists has a creator EXCEPT God.

So the rather than presupposing that "the universe always existed" or "some universe always existed", Christians belive in an all powerful, all knowing entity that exists and has no creator. I find that incredulous and any reasonable person should as well.

Personally, it seems obvious that both premises above are false. There are many things that exist and have no creator (but God is not one of them).

All this aside, if you are mathematically literate, enjoy physics and worry about matters of what can exist without having a creator I highly recommend The Fallacy of Fine-Tuning: Why the Universe Is Not Designed for Us by Victor J. Stenger.

Dashed Lines in HTML5 Canvas

2011-08-06T12:19:00.007-05:00

There is a lot of functionality missing from the Canvas API. One obvious facility is support for dashed lines. Here is the start of some dashed line code I am working on as part of a larger project. It is not fully tested yet so caveat emptor. I started with code I found here and attempted to make it more efficient by taking most of the math out of the main loop.


var initDashing = function(ctx) {
 if (!ctx.dashLine) {
  ctx.dashStyle=[3,2] ;
  ctx.dashedLine = function(x1,y1,x2,y2) {
   var dashStyle = ctx.dashStyle,
    dashCount = dashStyle.length,
    sign = x2>=x1 ? 1 : -1,
       dx = x2-x1,
       dy = y2-y1,
       m = dy/dx,
       xsteps = dashStyle.map(function(len){return sign*Math.sqrt((len*len)/(1 + (m*m)));}),
       dRem =  Math.sqrt( dx*dx + dy*dy ),
       dIndex=0,
       draw=true;
   this.moveTo(x1,y1) ;
   while (dRem>=0.1){
         var dLen = dashStyle[dIndex],
             xStep = xsteps[dIndex];
         if (dLen > dRem) {
          xStep =  Math.sqrt(dRem*dRem/(1+m*m));
         }
         x1 += xStep ;
         y1 += m*xStep;
         this[draw ? 'lineTo' : 'moveTo'](x1,y1);
         dRem -= dLen;
         draw = !draw;
         dIndex = (dIndex+1) % dashCount ;
   }
  };
 };
};

Here are some examples of usage (here I am using the Jasmine unit testing framework)



describe("Dashing", function() {
 it("draws a 3-2 dashed line by default", function(){
  var ctx = document.getElementById('test1').getContext("2d");
  ctx.strokeStyle = "black" ;
  initDashing(ctx) ;
  ctx.beginPath() ;
  ctx.dashedLine(0,0,100,100) ;
  ctx.closePath();
  ctx.stroke();
 });
 
 it("draws a 10-5 dashed line", function(){
  var ctx = document.getElementById('test2').getContext("2d");
  ctx.strokeStyle = "black" ;
  initDashing(ctx) ;
  ctx.dashStyle = [10,5] ;
  ctx.beginPath() ;
  ctx.dashedLine(0,0,100,100) ;
  ctx.closePath();
  ctx.stroke();
 });
 
 it("draws a 10-5-2-5 dashed line", function(){
  var ctx = document.getElementById('test3').getContext("2d");
  ctx.strokeStyle = "black" ;
  initDashing(ctx) ;
  ctx.dashStyle = [10,5,2,5] ;
  ctx.beginPath() ;
  ctx.dashedLine(0,0,100,100) ;
  ctx.closePath();
  ctx.stroke();
 });
 
 it("draws a 10-5-3-4 dashed line", function(){
  var ctx = document.getElementById('test4').getContext("2d");
  ctx.strokeStyle = "black" ;
  initDashing(ctx) ;
  ctx.dashStyle = [10,5,3,4] ;
  ctx.beginPath() ;
  ctx.dashedLine(100,13,0,80) ;
  ctx.closePath();
  ctx.stroke();
 });
});

I still have to implement a dashed version of arc, encapsulate better and test this code much more thoroughly. I'll upload to git hub when it is ready.

On the Goodness of Programming Languages

2011-06-05T21:52:00.002-05:00

Since my last post on C I have been thinking a lot about what makes a programming language good. This is also motivated by my recent emersion into JavaScript that has me wondering how good of a language is JavaScript. I've had similar thoughts about C++, Java, Lisp and others in the past.

I think that the only sensible conclusion is there is no way to measure the goodness of a language in any objective way. I am certain that I can can come up with a metric that would declare C as the best language ever developed, and another that would make the winner Lisp, or Mathematica or JavaScript. For example if, to simplify things a bit, I decide that the metric for a language's goodness is that:

It be functional (first class functions, closures, etc.)
It be ubiquitous (available on almost every computing device)

Then it is clear that JavaScript is the best language ever. I can also easily derive a metric that would declare Mathematica as the best language ever (and on some days I am convinced of the absolute truth of this!).

But the truth is that there can never be the best language ever. This is not because programming language technology is constantly (or at least in fits and starts) evolving. The reason there can never be a best programming language begins with the idea of Turing Completeness but it does not end there. Any language worth learning is TC and by that metric is no better than any other. Yet, it is often argued that some languages are more expressive than others (e.g. Lisp is more expressive than Fortran) and therefore one can solve a wider class of problems faster in Lisp than Fortran. But that does not mean there are not valid metrics by which Fortran can be declared the world champion of programming languages.

Humans spend a way too much time debating what the best is. What is the best car, best restaurant, best sport, best OS and best programming language? We do this because we want to be associated with the best. I drive an X, X is the best, therefore I have superior taste. For programming languages such arguments are silly not because we each have our own tastes. They are silly because if you are a programmer and don't sometimes see the superiority of Language A over Language B (and visa versa) then my guess is you are a rank amateur (or really boring person to sit next to at the office). So next time you find yourself in one of those "my language is better than yours" debates (and I've been there too) stop yourself, pick up the best editor :-) and write some code instead!

The Joy of C

2011-05-21T14:49:00.005-05:00

My latest assignment at work is to write a very fast message journal. Basically this is a way for writers to stream FIX messages (but could be anything) into a file while at the same time having one or more readers receive the messages. There are numerous little details I am leaving out but they are not important to the point I wish to make.

The programmers who wanted this journal asked me to write it in C rather than C++. Although I usually prefer C++ there was no compelling reason that C++ was needed. To my surprise, I rather enjoyed writing it in straight C and in fact, I am pretty sure the end result is a lot less complex than it would have been in C++.

Don't get me wrong. I am still a fan of OO but the attitude that anything OO is apriori better than pure procedural is a crock of poo. Programming in C forces you to be economical. There is no fancy data structures, templates or virtual functions. There is no Boost or meta-programming. You basically get arrays, macros and some straightforward libraries for threading, I/O and string manipulation. And for many more problems than you might expect, this is all you need.

In C (well written C anyway), you can almost always look at a piece of code and see by inspection exactly what will happen. In OO languages, with virtual functions, this is rarely the case. When you see p->f() in C++ you need to consider p's type and all classes derived from it to imagine everything that might happen. This often incurs a high cognitive load on maintainers of the code. Of course, with function pointers you can create equally obscure C, but you need to work harder in C so you only do that when there is a good reason. C forces you to keep your eye on the ball.

Now, in defense of C++, I have to say that programming in C++ has actually prepared me to be a better C programmer. For example, I treated all my structs as if they were private and wrote interfaces so users of my API never needed to know the internal workings of theses structs. In fact, most of my structs were hidden in private headers or in the .c files themselves. Most of my implementation functions were statics and hence private. This gave me the flexibility to change the internals without breaking user code. OO taught me to think this way. OO also taught me to think about writing code that can be unit tested and to write the tests right after the interfaces were specified but before the implementation. I brought this discipline to C as well.

The one thing truly lacking in C is exceptions. I have to say that exception handling and RAII are two of C++'s strengths. However, with discipline, you can do without these as well.

So if you ever find yourself forced back into a ancient language like C, don't fret. Take the concepts you learned in more modern languages and think about how you can uses the spirit of those concepts to write better code. You just might enjoy going retro!

End to End JavaScript with Node and HTML5

2011-05-07T21:50:00.002-05:00

This is my latest book project. In this book I will build a online multi-player poker game application entirely in JavaScript using Node.js on the server and JQuery+HTML5 Canvas on the client. The book will also feature MongoDB and Jasmine.

The main emphasis of the book is to illustrate test driven development of a non-trivial client-server JavaScript application. Although the book subject matter is a game, there will be lots of valuable take-aways for JavaScript, Node and Canvas developers.

Mathematica Cookbook Attacked by a Troll: Jon Harrop

2010-07-10T20:02:00.006-05:00

Recently I have had a very unpleasant experience with a known internet troll who has been attacking Mathematica Cookbook on the amazon.co.uk site. I posted the following review on amazon.co.uk by way of defending myself and my work. They may or may not allow it but I wanted to share it with you....

I would like to direct UK customers who may be interested in my book to a few facts.

1) Both of the previous reviewers (Edward and Jon Harrop) are actually the same person. I have very strong evidence this is the case. You may email me at mathematicacookbook@gmail.com if you want the details.

2) Jon Harrop is author of "F# for scientists" and about 2 years ago I blogged unfavorably about Mr. Harrop's book. You can see my comments here: .

3) Apparently I hurt Jon's feelings so badly that he could not wait to order my book just to give it a poor review. In fact, he has given it two!

4) Since then he has been using my own book as inspiration for several of his own blog posts so apparently he does not find it totally useless.

5) If you would like to see a more balanced treatment of my book please see these reviews: http://amzn.to/cKxJVh, http://oreil.ly/9ypIlX, http://bit.ly/b6HqFS and http://amzn.to/bQSr6Y.

6) I won't comment further on Mr. Harrops character because I think his actions speak for themselves. The interested reader can google "Jon Harrop Troll" and draw their own conclusions.

7) Finally, my book is not perfect. But I absolutely did not plagiarize anyone and link extensively to others work where they inspired my codes. I have been correcting issues as they are found and the O’Reilly site is where errata can be found. I think may readers in the UK who are fans of Mathematica can find a lot of value in my book and I don't want the bitter feelings of one individual to scare you away.

The Elegance of Rule-Based Programming in Mathematica

2010-07-06T19:11:00.012-05:00

Not too long ago I had to take a programming test as part of the application process for a development position at a hedge fund. The test had two problems - one easy and one not so easy. The solutions to both problems had to be implemented in your choice of Java, C or C++. You had two hours to finish.

I have never been good at presure cooker coding tests like this. I personally don't think these kind of tests bring out the best in most developers but there are some good devlopers who work well under these conditions. I just am not one of them.

In any case I recently thought of the hard problem on this test and how trivial it would be to solve in Mathematica. Indeed I whipped up and tested this solution on my train ride home which is only about 45 mins!

The solution is very short and I am guessing is much shorter than the average solution you can find in Java or C in the equivalent amount of time. The brevity come form exploiting mathematica's powerful rule-based approach. Most of the code is comments!

Problem

A collection of particles is contained in a linear chamber. They all have the same speed, but some are headed toward the right and others are headed toward the left. These particles can pass through each other without disturbing the motion of the particles, so all the particles will leave the chamber relatively quickly.

You will be given the initial conditions by a string containing at each position an 'L' for a leftward moving particle, an 'R' for a rightward moving particle, or a '.' for an empty location. Initially, no location in the chamber contains two particles passing through each other.

Create an animation of the process. At each unit of time, you want a string showing occupied locations with an 'X' and unoccupied locations with a '.'. Create code that for a function animate that is given an integer speed and a string giving the initial conditions. The speed is the number of positions each particle moves in one time unit.

The function will return a list of strings in which each successive element shows the occupied locations at the next time unit. The first element of the return should show the occupied locations at the initial instant (at time = 0) in the 'X', '.' format. The last element in the return should show the empty chamber at the first time that it becomes empty.

Solution


ClearAll[simulation, step, L, R, r, l, rule1, rule2, rule3, animation];

(* 
This function does most of the work. It simulates a single step in the animation.
It uses 3 rules which are initialized in the calling function and are visble
here via the dynamic scoping of Block.

There are 3 transformations performed within a Do. The Do's role is to run the
transformations velocity times as a means for making the particles move
that many steps.

The first transform takes the input and adds an empty cell to the start and end of the chamber.
This is done to avoid having special rules to deal with the 
boundary conditions at the end of the chamber. 

The second transformation uses rules that are applied repeatedly using ReplaceAll (//.). 
I discuss the rules below. 

Delete is used to remove the dummy empty cells added in the first step and 
a third transformation maps lower case r and l back to upper case before the Do
repeats.

*)
step[chamber_List, velocity_Integer] := Module[{work = chamber},
  Do[
   work = 
    Delete[work  /. {P__} :> {{}, P, {}} //. {rule1, rule2, 
        rule3}, {{-1}, {1}}] /. {r -> R, l -> L}, {velocity}];
  work
  ]

(*
The simulation sets up 3 rules. It is not necessary to define the rules here in a
Block. The code is written this way largely because I incrementally developed the
rules in the global scope and grafted them into a program later on.

rule1 is responsible for moving a R partcle to the Right. NOTE: When a particle moves
I change its case from upper to lower to make it invisble to subsequent rules.

rule2 is responsible for handling an intermediate condition where a right moving
particle lands in a cell of another right moving particle that has not moved yet.

rule3 deals with left moving particles being careful to also handle the case where a
previously moved partcle Z may be in the same cell as the L. 

The hardest aspect of this solution was distilling the transformations down to these
three rules. It took some trial and error. It is possible I missed some corner case 
so let me know if you see a bug!!

The idea here is that FixedPointList drives the simulation until it reaches a steady
state and Most removes the repetitive last entry. 

A final transformation maps particles to "X" as dicated by the specifications.
*)

simulation[chamber_List, velocity_Integer] := 
 Block[
  {rule1 = {X___, {R}, {P___}, Y___} :> {X, {}, {P, r}, Y} ,
   rule2 = {X___,  {R | r, r}, {P___}, Y___} :> {X, {r}, {P, r}, Y},
   rule3 = {X___, {P___}, {L, Z___}, Y___} :> {X, {l, P}, {Z}, Y} },
  Most[FixedPointList[
     step[#, velocity] &, chamber]] //. {{(L | R) ..} -> "X", {} -> 
     "."}
  ]

(* 
The main function does little but convert from the string encoding specified by the problem to a more convenent symbolic form where each position in the chamber is one of {L}, {R} or {} for empty and the chamber itself is a list rather than a string.
*)

animation[chamber_String, velocity_Integer] := 
 simulation[
  (Characters[chamber] //. {"." -> {}, a_String :> {Symbol[a]}}), 
  velocity]

The Test Cases

1) The single particle starts at the 3rd position, moves to the 5th, then 7th, and then out of the chamber.

In[360]:= animation["..R....",2]//Grid
Out[360]=
..X....
....X..
......X
.......

2) At time 1, there are actually 4 particles in the chamber, but two are passing through each other at the 4th position.


In[361]:= animation["RR..LRL",3]//Grid
Out[361]= 
XX..XXX
.X.XX..
X.....X
.......

3) At time 0 there are 8 particles. At time 1, there are still 6 particles, but only 4 positions are occupied since particles are passing through each other.


In[362]:= animation["LRLR.LRLR",2]//Grid
Out[362]=
XXXX.XXXX
X..X.X..X
.X.X.X.X.
.X.....X.
.........

4) These particles are moving so fast that they all exit the chamber by time 1.

In[363]:= animation["RLRLRLRLRL",10]//Grid
Out[363]= 
XXXXXXXXXX
..........

5) The empty chamber test


In[364]:= animation["...",1]//Grid
Out[364]=
...

6) A complicated test


In[365]:= animation["LRRL.LR.LRR.R.LRRL.",1]//Grid
Out[365]= 
XXXX.XX.XXX.X.XXXX.
..XXX..X..XX.X..XX.
.X.XX.X.X..XX.XX.XX
X.X.XX...X.XXXXX..X
.X..XXX...X..XX.X..
X..X..XX.X.XX.XX.X.
..X....XX..XX..XX.X
.X.....XXXX..X..XX.
X.....X..XX...X..XX
.....X..X.XX...X..X
....X..X...XX...X..
...X..X.....XX...X.
..X..X.......XX...X
.X..X.........XX...
X..X...........XX..
..X.............XX.
.X...............XX
X.................X
...................

I'll post the Mathematica Notebook on MathematicaCookbook.com

Hold Everything!

2010-06-28T21:41:00.024-05:00

In Mathematica Cookbook recipe 2.2 I discuss a "technique" for holding arbitrary arguments. Well truth be told, this recipe is pretty lame and was not supposed to make it into the final book. This post is intended to make of for that lameness and hopefully clarify some of the bewildering multitude of ways Mathematica offers for Holding.

The Hold Family of Attributes

Mathematica's default behavior is to evaluate every expression it sees. Here is an example.


In[1]:= a=1;b=2;c=3; d= c; e:= d; f :=e;
{a,b,c, d,e, f}
Out[2]= {1,2,3,3,3,3}

Here we associate symbols a, b, c with integers 1, 2,3. We then associate d with the value of symbol c and we associate e with symbol d telling Mathematica not to evaluate d just yet by using SetDelayed (:=). We also associate f with symbol d likewise delaying evaluation. Later, when we evaluate the list containing these symbols Mathematica keeps evaluating until there is nothing left to do and we get the result as integers. By using Trace we can see the steps Mathematica goes through.


In[3]:= Trace[{a,b,c, d,e, f}]
Out[3]= {{a,1},{b,2},{c,3},{d,3},{e,d,3},{f,e,d,3},{1,2,3,3,3,3}}

Okay, simple enough. However, occasionally you want to write functions that act on expressions before they are evaluated. In fact, even if you never had a reason for doing so, Mathematica itself needs this capability. For example, Mathematica could not implement the function SetDelayed if it did not have a way of saying "don't evaluate". Rather then creating certain functions with special no-evaluating behavior, Mathematica takes a general approach via the concept of attributes. You can inspect the attributes of a symbol using the command Attributes.


In[4]:= Attributes[SetDelayed]
Out[4]= {HoldAll,Protected,SequenceHold}

Here we see SetDelayed has two attributes in the hold-family: HoldAll and SequenceHold. Let's explore these using our own symbols and SetAttributes. Here I use symbols f1, f2 and so on without associating them with values because that is not necessary to illustrate the behavior of the attributes.


In[5]:= (* Make sure these symbols have no values or attributes*)
ClearAll[f1,f2,f3,f4,f5,f6,f7] ;

In[6]:= (* Here you can see that our list of symbols evalauates as before when we wrap f1 around it*)f1[{a,b,c,d,e,f}]
Out[6]= f1[{1,2,3,3,3,3}]

In[7]:= (*Here we use the HoldAll and associate it with f2. This says that no arguement of f2 should be evaluated*)
SetAttributes[f2, HoldAll]
In[8]:= f2[{a,b,c,d,e,f}]
Out[8]= f2[{a,b,c,d,e,f}]

In[9]:= (* It does not matter how many seperate arguments are passed, they are all held*)f2[a,b,c]
Out[9]= f2[a,b,c]

Notice the difference between evaluating f1 which has no attributes and f2 which has attribute HoldAll. In essence, f2 acts the same as the built-in Mathematica command Hold.


In[10]:= Attributes[Hold]
Out[10]= {HoldAll,Protected}

Sometimes you want only the first argument to a function to be held unevaluated. For that you use attribute HoldFirst.


In[11]:= SetAttributes[f3, HoldFirst]
f3[a,b,c]
Out[12]= f3[a,2,3]

Alternatively you may want all arguments but the first to be held. Here you use HoldRest.


In[13]:= SetAttributes[f4, HoldRest]
f4[a,b,c]
Out[14]= f4[1,b,c]

So far I think the mechanics of HoldAll, HoldFirst and HoldRest should be pretty clear. Don't worry yet if you don't get why you would want to use these in your own code, I'll get to that later. Just make sure you are comfortable with the idea of using attributes to suppress Mathematica's desire to evaluate before reading on.

Okay, now I want to point out some important exceptions. Well, not really exceptions but rather clarifications. HoldAll, HoldFirst and HoldRest do not suppress every action that Mathematica takes when it sees an expression. To illustrate this, please recall that Mathematica has a long hand way of specifying a sequence of things.


In[15]:= Sequence[1,2,3]
Out[15]= Sequence[1,2,3]

A sequence is different form a list in that Mathematica will magically flatten out sequences and splice the result into any function call.


In[16]:= f1[Sequence[1,2,3]]
Out[16]= f1[1,2,3]
In[17]:= f1[Sequence[1,2,Sequence[3,4,5]],7,8,9]
Out[17]= f1[1,2,3,4,5,7,8,9]

Now, recall that f2 has attributes HoldAll. What do you think Mathematica does if we give f2 a sequence?


In[18]:= f2[Sequence[1,2,Sequence[3,4,5]],7,8,9]
Out[18]= f2[1,2,3,4,5,7,8,9]

Ah! The automatic flatting is not suppressed by HoldAll nor is it suppressed by HoldFirst or HoldRest. The flattening out of sequences is something you usually don't want to suppress. This is why it is an exception to the rule for the standard hold family of attributes. However, you may recall that SetDelayed had another hold-like attribute called SequenceHold and you can probably guess what it does!


In[19]:= SetAttributes[f5, SequenceHold]
f5[Sequence[1,2,Sequence[3,4,5]],7,8,9]
Out[20]= f5[Sequence[1,2,3,4,5],7,8,9]

Notice how the outer sequence remains. Why did the inner sequence get flattened? Simply because it is evaluated within Sequence which naturally does not have the SequenceHold attribute.

Okay, lets review. HoldAll, HoldFirst and HoldRest are attributes that suppress evaluation of specific arguments but don't suppress sequence flattening. For that you use SequenceHold. You can use one of the hold attributes together with SequenceHold to get both behaviors.


In[21]:= SetAttributes[f6, {HoldAll,SequenceHold}]
f5[Sequence[a,b,c]]
f6[Sequence[a,b,c]]
Out[22]= f5[Sequence[1,2,3]]
Out[23]= f6[Sequence[a,b,c]]

But we are not done yet! There is even a stronger form of holding that suppresses normal evaluation, sequence flattening and more! First, recall that sometimes you want to tell Mathematica that you want something to evaluate despite the presence of HoldAll and friends. To see how there can be a stronger form of holding we must first consider Evaluate.


In[24]:= f2[Evaluate[a,b,c]]
Out[24]= f2[1,2,3]

Evaluate is a way of saying to Mathematica that you know what you are doing and you want evaluation to take place despite the presence of HoldAll, etc.. This typically arises when you want to plot a function that you obtain by integration (or other function generating operations).


In[25]:= Attributes[Plot]
Out[25]= {HoldAll,Protected}

In[26]:= Plot[Evaluate[Integrate[Sin[x],x]], {x, 0, 2Pi}]
Out[26]:=

The attribute HoldAllComplete has super-powers because it can even shield evaluation by Evaluate!


In[27]:= SetAttributes[f7,HoldAllComplete]
In[28]:= f6[Evaluate[{a,b,c}]]
f7[Evaluate[{a,b,c}]]
Out[28]= f6[{1,2,3}]
Out[29]= f7[Evaluate[{a,b,c}]]

The built in command HoldComplete is the counterpart to the Hold command.


In[30]:= Attributes[Hold]
Attributes[HoldComplete]
Out[30]= {HoldAll,Protected}
Out[31]= {HoldAllComplete,Protected}
In[32]:= HoldComplete[Evaluate[{a,b,c}]]
Out[32]= HoldComplete[Evaluate[{a,b,c}]]

Functions with attribute HoldAllComplete also suppress upvalue evaluation. I am not going to discuss up upvalues here but you can refer to the Mathematica documentation or my cookbook.

HoldForm, Unevaluated, Defer oh my!

At this point you might think we have exhausted all the ways you can suppress evaluation but no. Mathematica has some more subtle ways you can keep its evaluation engine in check. Perhaps the easiest to understand is HoldForm. This command suppresses evaluation just like Hold except the command gets hidden when display in output form. The following should make the difference clear.


In[33]:= Hold[1+2]
Out[33]= Hold[1+2]

In[34]:= ReleaseHold[%]
Out[34]= 3

In[35]:= HoldForm[1+2]
Out[35]= 1+2

In[36]:= ReleaseHold[%]
Out[36]= 3

Unevaluated can be thought of as a temporary or one-shot Hold. It suppresses evaluation the first time the Mathematica evaluator sees it but not subsequent times. The following examples are a good illustration of the difference.


In[37]:= (*first I create a simple list *)
list = {1,2,3}
Out[37]= {1,2,3}

In[38]:= (*Now lets see what happens if we try to make list  list self-referential*)
list[[3]] = list; list
Out[38]= {1,2,{1,2,3}}

In[39]:= (* What happens if we doo this again using Hold? *)
list = {1,2,3};
list[[3]] = Hold[list];
list

Out[41]= {1,2,Hold[list]}

In[42]:= ReleaseHold[%]
Out[42]= {1,2,{1,2,Hold[list]}}

In[43]:= ReleaseHold[%]
Out[43]= {1,2,{1,2,{1,2,Hold[list]}}}

Okay, that is somewhat interesting. Each time we invoke ReleaseHold the list expands unveiling another nested version of itself. What do you think happens if we do this experiment with Unevaluated instead?


In[44]:= list = {1, 2, 3};
list[[3]] = Unevaluated[list];
list
During evaluation of In[44]:= $RecursionLimit::reclim: Recursion depth of 256 exceeded. >>
During evaluation of In[44]:= $RecursionLimit::reclim: Recursion depth of 256 exceeded. >>
Out[46]= {1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,{1,2,Hold[{1,2,list}]}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

Oops! We created an never ending evaluation that eventually blows up. The only way for Mathematica to finally display the "result" is for it to force a Hold into the output to put the breaks on this runaway evaluation train! The reason for this behavior is that Unevaluated allowed us to suppress evaluation of list up until the point where it made the symbol list the new third element of the List associated with the symbol list but after that step, evaluation is no longer suppressed. So we have a symbol which contains a reference to itself and the evaluator can never stop until recursion limit is reached.

Defer is another function that acts like Hold but will allow evaluation each time it is presented to the front-end for evaluation via the user action of hitting Shift-Enter or selection the expression and using Evaluation In Place. We can use the self-referential example to see this. Here each step in the expansion was created by hitting Shift-Enter on the prior output.


In[47]:= list = {1, 2, 3}; 
list[[3]] = Defer[list]; 
list
Out[49]= {1,2,list}

In[50]:= {1,2,list}
Out[50]= {1,2,{1,2,list}}

In[51]:= {1,2,{1,2,list}}
Out[51]= {1,2,{1,2,{1,2,list}}}

In[52]:= {1,2,{1,2,{1,2,list}}}
Out[52]= {1,2,{1,2,{1,2,{1,2,list}}}}

So you can see Mathematica has quite a rich repertoire of functions and attributes whose sole purpose is to keep it for doing what it was designed to do - evaluate! The novice Mathematica user may be mystified by this but these features are essential to the functionality of Mathematica. In other words, the rich sets of features Mathematica provides would not be there if Mathematica did not contain mechanisms for controlling itself. Programming after all is the act where an individual exerts control over a (abstract) machine. But perhaps this explanation is a bit too metaphysical for your tastes. So lets get to some concrete examples. Consider the rich family of Plot functions which take other functions as input. Notice that these all have HoldAll as attributes. Think for a second why this is the case before reading on.


In[53]:= Attributes[{Plot, ParametricPlot, Plot3D}]
Out[53]= {{HoldAll,Protected},{HoldAll,Protected},{HoldAll,Protected}}

Functions that rely on delayed evaluation are typically those that are in essence little evaluation engines themselves. Think about plotting. It must take a function and evaluate it at various points so that it can map the values at those points to the graphics coordinates of points (ultimately pixels on the display device). These evaluations can not be interfered with by the normal evaluation process because in many cases that will change the input before the evaluator can do its thing. If this reasoning is correct than any function in Mathematica which repeatedly evaluates another function should utilize the Hold family of attributes. One of the simplest of these is Table so let's see.


In[54]:= Attributes[Table]
Out[54]= {HoldAll,Protected}

Yep. Various forms of control flow (If, Do, Switch) also must use held arguments for similar reasons. Another class of functions that hold arguments unevaluated are those that must act on symbolic values themselves. Examples are Clear and AddTo (+=). The following little program lists all such symbols in the System` context that have an attribute in the Hold family.


In[55]:= Select[Names["System`*"],Length[Intersection[Attributes[#],{HoldAll,HoldFirst,HoldRest,HoldAllComplete}]]>0&]
Out[55]= {AbortProtect,AbsoluteTiming,AddTo,And,Animate,AppendTo,Arrow3DBox,ArrowBox,Assuming,Attributes,BezierCurve3DBox,BezierCurveBox,Block,BlockRandom,BSplineCurve3DBox,BSplineCurveBox,BSplineSurface3DBox,Button,CancelButton,Catch,Check,CheckAbort,CheckAll,ChoiceButtons,CircleBox,Clear,ClearAll,ClearAttributes,Compile,CompiledFunction,CompoundExpression,Condition,ConeBox,ConsoleMessage,Context,ContinuedFractionK,ContourPlot,ContourPlot3D,Control,ControlActive,ControllerManipulate,CuboidBox,CylinderBox,Debug,DebugTag,Decrement,DefaultButton,DefaultValues,Defer,Definition,DensityPlot,Dialog,DialogInput,DialogReturn,DiskBox,DivideBy,Do,DownValues,DumpSave,Dynamic,DynamicBox,DynamicModule,DynamicModuleBox,DynamicWrapper,DynamicWrapperBox,Exists,FileName,FindArgMax,FindArgMin,FindMaximum,FindMaxValue,FindMinimum,FindMinValue,FindRoot,For,ForAll,FormatValues,FullDefinition,Function,GeometricTransformation3DBox,GeometricTransformationBox,Graphics3DBox,GraphicsBox,GraphicsComplex3DBox,GraphicsComplexBox,GraphicsGroup3DBox,GraphicsGroupBox,Hold,HoldComplete,HoldForm,HoldPattern,If,Increment,Information,InsetBox,Interpretation,InterpretationBox,Line3DBox,LineBox,LineIntegralConvolutionPlot,Literal,MakeBoxes,Manipulate,MatchLocalNameQ,MemoryConstrained,MenuItem,Message,MessageName,MessagePacket,Messages,Module,Monitor,Nand,NCache,NIntegrate,Nor,NProduct,NSum,NValues,Off,On,Or,OwnValues,ParametricPlot,ParametricPlot3D,Parenthesize,Pattern,PatternTest,Piecewise,Play,Plot,Plot3D,Point3DBox,PointBox,Polygon3DBox,PolygonBox,PreDecrement,PreemptProtect,PreIncrement,PrependTo,Product,Protect,Quiet,RasterBox,Reap,RectangleBox,Refresh,RegionPlot,RegionPlot3D,Remove,RuleCondition,RuleDelayed,SampledSoundFunction,Save,Set,SetAttributes,SetDelayed,SphereBox,Stack,StackBegin,StackComplete,StackInhibit,StreamDensityPlot,StreamPlot,SubtractFrom,SubValues,Sum,Switch,SystemException,Table,TagSet,TagSetDelayed,TagUnset,Text3DBox,TextBox,TimeConstrained,TimesBy,Timing,Trace,TraceDialog,TracePrint,TraceScan,TubeBezierCurveBox,TubeBox,TubeBSplineCurveBox,Unevaluated,Unprotect,Unset,UpSet,UpSetDelayed,UpValues,ValueQ,VectorDensityPlot,VectorPlot,VectorPlot3D,WaitUntil,Which,While,With,$ConditionHold,$Failed}

Here you can see that the ultimate form of holding, HoldAllComplete, is more rarely used and when it is it is for rather low-level functions.


In[56]:= Select[Names["System`*"],Length[Intersection[Attributes[#],{HoldAllComplete}]]>0&]
Out[56]= {DebugTag,HoldComplete,InterpretationBox,MakeBoxes,Parenthesize,PreemptProtect,SystemException,Unevaluated}

Recipe 2.2 Reconsidered

In recipe 2.2 of Mathematica Cookbook I consider if it was possible to create functions that Hold other combinations of arguments than provided by HoldAll, HoldFirst and HoldRest. The solution proposed using Hold as a pattern within the function itself. This awkward construct thus required you to use Hold when you invoked the function. To further un-motivate this I presented a rather lame example in the solution.


In[57]:= array1 = Table[0, {10}]; array2 = Table[1, {10}];

arrayAssign[Hold[a_Symbol],aIndex_,Hold[b_Symbol],bIndex_]:= 
Module[{},
a[[aIndex]] = b[[bIndex]];
a[[aIndex]]]

(*Assign elements 2 through 3 in array 2 to array1 *)
arrayAssign[Hold[array1],2;;3,Hold[array2],1];
array1

Out[60]= {0,1,1,0,0,0,0,0,0,0}

There are several reasons this solution is lame. First off, the example is not at all practical. There is little reason to create a function to do this when you can do the same in a one line expression. But that could be forgiven by virtue of being a purely pedagogical example. The real flaw is that this technique requires you to use Hold at the call site which is nothing at all like the behavior of functions with attributes HoldFirst, HoldRest or HoldAll. A more sensibly way to achieve the same effect is to simply use HoldAll and force evaluation where required. So to use this somewhat useless example again...


In[61]:= array1 = Table[0, {10}]; array2 = Table[1, {10}];

SetAttributes[arrayAssign2,HoldAll];arrayAssign2[a_Symbol,aIndex_,b_Symbol,bIndex_]:= 
Module[{aIndex2,bIndex2},
{aIndex2,bIndex2} = Evaluate[{aIndex,bIndex}];
a[[aIndex2]] = b[[bIndex2]];
a[[aIndex2]]]

(*Assign elements 2 through 3 in array 2 to array1 *)
arrayAssign2[array1,2;;3,array2,1];
array1

Out[64]= {0,1,1,0,0,0,0,0,0,0}

No Sleep `Till Book Done

2009-08-01T22:11:00.005-05:00

A rap about my experience writing Mathematica Cookbook...

(Sing to the tune of "No Sleep `Till Brooklyn by The Beastie Boys)

(chorus) No sleep 'til - Book Done

Editing unsettled - but I got mettle
Laptop running hotter than a boiling kettle

My job's ain't a job - it's a damn hard time
Ideas to code - runnin' overtime

Some frustration - but it’s my vocation
Sal and the boy's skippin' vacation

Itchy index finger but a stable work table
I do what I do best because I'm willing and able

Ain't no faking - not money I'm making
Going page to page - so there's no mistaking

I'm still at the job working nine to five
So it takes more time for this to go live

(bridge) No sleep 'til –

Another chapter - another train
Mathematica code flyin out my brain

Another edit - gotta make it right
This proof-reading may go all night

My editor's cool - he continues to trust
That it'll get done, it must, it must!

Writing and typing - I code around the clock
Can't publish this book til I gen clean Doc

I'm thrashing 8 cores and making a giant file
Getting parallel code to work can take a while

Map, Apply, ListConvolve and Position
If a pattern don't match, I first Partition

I got a recursive func that blew the stack
So I used Fold – it’s less a hack

(repeat bridge)

(repeat chorus)

Making Sparse Arrays, so I'm using Band
To see all the powers, I use Expand

Schooled and work in Brooklyn - U.S.A.
Alpha did not know, so I showed it the way

Write Function with Slot - match expression with pattern
If I use AstronomicalData, I can find Saturn

Got Greeks, Graphics, Reaps and Sows
Blanks, and Slots, Plots and Shows

I got Mathematica so get out of my way
Filtering some data, I use Fourier

Learning a lot but I get no sleep
Cause I'm writing this Cookbook eight days a week

(repeat chorus)

Mapping game play into work

2009-07-31T15:01:00.003-05:00

About 15-16 years ago I had a conversation with a colleague where I thought it would be possible to create a video game where the game play mapped into useful work. So, in other words, players would think they are just being entertained but in reality they were solving some difficult problem that someone could profit from.

Well, this has come to pass:

http://bit.ly/eWhGV

and

http://bit.ly/9F98q

Should of patented that idea!

Mathematica Cookbook Status

2009-04-07T15:36:00.003-05:00

I have really neglected this blog due to the overwhelming amount of attention I had to devote to my forthcoming Mathematica Cookbook. I can see the light at the end of the tunnel and hope to blog more regularly soon.

While working on the cookbook, I came across some really great books that I highly recommend to fans of Mathematics:

Generatingfunctionology by Herbert S. Wilf. This book begins with an awesome quote, "A generating function is a clothesline on which we hang up a sequence of numbers for display."

Fundamental Finite Element Analysis and Applications with Mathematica and Matlab Computations by M. Asghar Bhatti. This book really helped me wrap my mind around the ideas of FEM. Expensive book, but worth it.

A Student's Guide to Maxwell's Equations by Dan Fleisch is really helpful in taking the mystery out of these equations. It decomposes them symbol by symbol in a way I never seen done before in a mathematics or physics text.

There are a few others but I'll save them for a future post.

Geeks just wanna have fun

2008-10-30T16:48:00.004-05:00

A computer is truly the greatest geek toy ever invented. It is like an erector set to the googleplex power. Being "forced" to earn a living making virtual toys for others to use rather than spending ones days exploring this toy's possibilities for my own edification can be truly depressing sometimes. Maybe not as depressing as having to sell used cars or life insurance to feed one's family but close. I probably should be grateful I have a job that involves these toys especially in this economy.

I guess I just feel like being a whiner today in lieu of a useful blog post. Go ahead and slam me in the comments.

More Programmers = More Code

2008-10-07T10:08:00.003-05:00

What do you get when you throw lots of programmers at a problem? You get lots of code! That's what programmers do, duh. It does not matter how simple or complex the problem is. For any given size problem, more programmers will mean more code. That is more code to debug, more code to test, more to maintain. More, more, more. Eventually this will require even more programmers and the cycle continues until the project collapses.

And it is even worse if you only hire the best and brightest programmers (don't we all!!). They write code faster! And it will be more complex than a dullard programmer because good programmers like to write general solutions.

Rich companies like Microsoft can keep this going for some time. However, you see the result in Vista and Office. Bloat, bloat, bloat.

What do you do if you have a problem that would take 12 months for 2 programmers but you want it done in 6. Hire 2 more programmers? Hire 4 more programmers? Big mistake! First off, it ain't gonna happen in 6 months no matter what you do if it is really a 12 month problem. If you must cover your ass as a manager and claim you used all your resources to make it happen in 6 months, I suggest the following.

Put 2 of the best programmers you have on the project. Make sure they like each other and think alike about software design. They are the leads. Only the leads will write code that will go into production.

Use all your remaining dollars to hire programmers who will support the leads but NOT write production code unless it is a piece of boiler plate delegated to them by one of the leads. What these junior developers do is write and execute unit tests for the leads. They write test tools when appropriate. They participate in code reviews. They are not slaves but future leads in training. Or maybe they are not future leads in training. Maybe they are salves. That's okay, mediocre programmer's need to eat to.

Some bigger projects may need 4 leads or even 6. If you have more than that your project is DOA and you better convince someone to spilt it up. If they won't, I'd find another place to work. That's better than being canned or losing all you hair/sleep/health over a doomed project. And trust me, it is doomed.

Let's Make a Deal - Let Monty Rest!

2008-10-01T19:48:00.002-05:00

Some "solved" problems just never go away. Perpetual Motion machines is one example. Another example is the Monty Hall Problem. There is presently a mini-debate in the discussion area of Scientific American's How Randomness Rules Our World and Why We Cannot See It with a significant number of adamant doubters of the standard result that states it is better to switch if Monty shows you a goat.

This problem is amazingly obvious to understand once you analyze it correctly and remove certain ambiguities from the problem statement. Here's my analysis and some Mathematica simulations to add some weight (as if any is needed).

Okay, we all can agree that the probability of NOT picking the DREAM VACATION is 2/3, right? There are two GOATS and one DREAM VACATION.

Now, when Monty shows you the remaining door with a GOAT he just beamed you some very significant information. He's told you that if you picked a GOAT then the probability of getting a DREAM VACATION is 1 if you switch! We already know the probability you picked a GOAT is 2/3 so after he gives you this new info your probability of winning is now 2/3. So switch for GOAT's sake!! If you don't switch, your probability is just 1/3.

Here is a Mathematica program for the non-believers.

GOAT = 0; (* Goat worth zero *)
VACATION = 1; (* Vacation worth one*)

makePrizes[] := Module[{},Switch[RandomInteger[{1,3}],
1,{GOAT,GOAT,VACATION},
2,{GOAT,VACATION,GOAT},
3,{VACATION,GOAT,GOAT}]]

randomPick[doors_List] := Module[{},RandomInteger[{1,Length[doors]}]]

strategy1VS2[trials_Integer] :=
Module[{winnings1=0, winnings2=0, firstPick, secondPick, doors, doors2},
SeedRandom[];
Do[doors = makePrizes[];
firstPick = randomPick[doors];
(*winnings of person who keeps first pick*)
winnings1+= doors[[firstPick]];
(*delete first pick from choices*)
doors2 = Drop[doors,{firstPick}];
(*delete goat from remaining*)
doors2 = Drop[doors2,Position[doors2,GOAT][[1]]];
(*Always pick remaining prize *)
secondPick =doors2[[1]];
(*winnings of person who switches*)
winnings2+= secondPick,{trials}];
{winnings1,winnings2}]
(*Run simulation 10000 times. *)
strategy1VS2[10000]
{3356,6644}

The result {3356,6644} means keeping first choice only paid 3356 over 10000 runs but switching paid 6644!

Now, there are ASSUMPTIONS here (there always are). One assumption is that on each run the position of the prize changes. It turns out that keeping the prize always in any particular door for the entire simulation does not matter (as long as the contestant does not have the information, obviously!)

strategy1VS2A[trials_Integer,init_List] :=
Module[{winnings1=0,winnings2=0,firstPick,secondPick,doors,doors2},
SeedRandom[];
Do[doors = init;
firstPick = randomPick[doors];
(*winnings of person who keeps
first pick*)
winnings1+= doors[[firstPick]];
(*delete first pick from choices*)
doors2 = Drop[doors,{firstPick}];
(*delete goat from remaining*)
doors2 = Drop[doors2,Position[doors2,GOAT][[1]]];
(*Always pick remaining prize *)
secondPick =doors2[[1]];
(*winnings of person who switches*)
winnings2+= secondPick;,{trials}];
{winnings1,winnings2}]

strategy1VS2A[10000,{GOAT,GOAT,VACATION}]
{3316,6684}
strategy1VS2A[10000,{GOAT,VACATION,GOAT}]
{3267,6733}

strategy1VS2A[10000,{GOAT,GOAT,VACATION}]
{3382,6618}

The other assumption is that your not forced to switch before seeing the goat. This IS important!!

strategy1VS2B[trials_Integer] :=
Module[{goatPositions,pos,winnings1=0,winnings2=0,firstPick,secondPick,doors,doors2},
SeedRandom[];
Do[doors = makePrizes[];
firstPick = randomPick[doors];
(*winnings of person who keeps first pick*)
winnings1+= doors[[firstPick]];
(*delete first pick from choices*)
doors2 = Drop[doors,{firstPick}];
(*Randomly choose from remaing*)
secondPick =randomPick[doors2];
(*winnings of person who switches*)
winnings2+= doors2[[secondPick]];,{trials}];
{winnings1,winnings2}]

strategy1VS2B[10000]
{3373,3295}

So information has value, Duh!

So now that you have this information, become a believer, make the switch!

Scratched Chrome

2008-09-05T15:08:00.002-05:00

Call me impatient and unreasonable but don't you think the features of Google Toolbar would be available in Google Chrome???

Tan of the Kitchen Sink

2008-08-29T10:29:00.003-05:00

In a post on MathForum I made the mistake of doubting Mathematica could compute the Tan of the Kitchen Sink. It is always a mistake to doubt Mathematica's prowess as Daniel Lichtblau of Wolfram pointed out to me:

In[1]:= Tan[Khinchin//Sinc] // N
Out[1]= 0.165514

I stand corrected!

p.s.

It sort of spoils the joke/pun to explain but to non-Mathematca users...

Khinchin's constant is aprox. 2.68545
Sinc[x] = Sin[x]/x
N means "give numeric value"
and // means "use postix" so
this computes N[Tan[Sin[Khinchin]/Khinchin]]

How to mess with Comp Sci Students

2008-08-28T10:14:00.002-05:00

Assignment: Write a compiler that compiles all programs that can't compile themselves.
Extra Credit: Use the compiler to compile assignment.

F# For Scientists Misses the Boat On Mathematica Performance

2008-08-26T20:40:00.009-05:00

I recently purchased F# For Scientists by Dr. Jon Harrop after the author mentioned it on the Mathematica Mailing List. According to Dr. Harrop,

Mathematica's .NET-Link technology allows Mathematica and .NET programs to interoperate seamlessly. Moreover, Microsoft's new functional programming language F# provides many familiar benefits to Mathematica programmers:
The marriage of Mathematica with F# can greatly improve productivity for a wide variety of tasks.

I am a big fan of Mathematica and functional programming and have been wanting to check out F# for some time so I decided to give the book a shot. It just arrived today so I can't post a full review but I did jump directly to the small section (5 pages) on using F# with Mathematica.

What did I learn? Well this section rightly claims that Mathematica has awesome symbolic math capabilities (it does). But then it goes on to claim that F# can beat the pants off of Mathematica on raw calculation. Thus it suggested F# programmers should call out to Mathematica for symbolic integration but then evaluate the result in F# for speed (to the tune of 3.4 times Mathematica's speed). I was naturally dubious. The explanation of this speed up is give as

The single most important reason for this speed boost is the specialization of the F# code compared to Mathematica's own general purpose term rewriter. ... Moreover, the F# programming language also excels at compiler writing and the JIT-compilation capabilities of the .NET platform make it ideally suited to the construction of custom evaluators that are compiled down to native code before being executed. This approach is typically orders of magnitude faster than evaluation in a standalone generic term rewriting system like Mathematica.

Okay, hold the phone! First off, I did not know the F# language could write compilers. I'll forgive this as poetic use of language. I guess I sort of know what he meant to say. More interesting is that we have gone from 3.7 times to "orders of magnitude". Now, I don't take anything away from the brilliant folks at Microsoft, but the equally brilliant folks at Wolfram have been focusing exclusively on mathematics software for 20 years and you might think they learned a thing or two about computational speed!

Here is the example from the book...

First, he uses Mathematica to integrate a function.

Integrate[Sqrt[Tan[x]],x]

(-2*ArcTan[1 - Sqrt[2]*Sqrt[Tan[x]]] +
2*ArcTan[1 + Sqrt[2]*Sqrt[Tan[x]]] +
Log[-1 + Sqrt[2]*Sqrt[Tan[x]] - Tan[x]] -
Log[1 + Sqrt[2]*Sqrt[Tan[x]] + Tan[x]])/(2*Sqrt[2])

He then goes to show that Mathematica takes 26 secondsto evaluate this function in loop for 360,000 iterations.

He then shows a translator that converts the Mathematica to F# and the F# code does the same work in 7.595 seconds.

So far Dr. Harrop is correct but like some many others who are in a rush to show their new favorite language superior to another's, he forgets to read the manual! Particularly, the section on optimization! If he had he would have found a handy little Mathematica function called Compile. Hmm, sounds promising. And in fact....

cf = Compile[{{x, _Complex}}, Evaluate[Integrate[Sqrt[Tan[x]],x]]]
Timing[Do[cf[x + y I],{x,-3.0,3.0,0.01},{y,-3.0,3.0,0.01}]]

{5.281,Null}

That's 5.281 seconds on my relatively underpowered laptop (Thinkpad X60) !

Some might feel I'm being a bit harsh on Dr. Harrop but after all he made me layout bucks for a book that promised me "many familiar benefits" only to deliver 5 measly pages of half truth. F# programmers may benefit from Mathematica but the jury is still out as to whether the reverse is true.

Drilling Square Holes

2008-08-25T12:37:00.005-05:00

One of the fringe benefits of working on a book is all the tidbits of knowledge you come across while doing research. While working on the graphics chapters I cam across a shape known as a Reuleaux triangle.

It turns out that this shape is the key to doing what on the surface may seem impossible, Drilling a nearly square hole.

A Biological Programming Language

2008-07-26T18:08:00.002-05:00

I've often said to friends that if I could start my career over again I would go into biology instead of computer science. Now, perhaps, there is a way to have a foot in both worlds.

Little b is a programming language for modeling biological systems. Quoting from the languages site...

The little b project is an effort to provide an open source language which
allows scientists to build mathematical models of complex systems. The
initial focus is systems biology. The goal is to stimulate widespread sharing
and reuse of models. The little b language to allow biologists to build
models quickly and easily from shared parts, and to allow theorists to program
new ways of describing complex systems.

Currently, libraries have been developed for building ODE models of
molecular networks in multi-compartment systems such as cellular epithelia.
Aneil Mallavarapu is the author and inventor of little b, and runs the
project. Little b is based in Common Lisp and contains mechanisms for rule-based
reasoning, symbolic mathematics and object-oriented definitions. The syntax is
designed to be terse and human-readable to facilitate communication. The
environment is both interactive and compilable.

Makes me wonder if Mathematica would be a good enviornment for similar exploration but with more sophisticated tools already built in.

I was simply awed by this TED presentation

2008-07-22T10:48:00.002-05:00

You will never think the same about mushrooms again.

Find the next row. Win $25

2008-07-18T14:41:00.008-05:00

Each row below is produced by a definite rule. What is the next row and what is the rule? $25 Prize to the first person who posts the answer in the comments or emails me at [s m a n g a n o [at] i n t o - t e c h n o l o g y [dot] c o m].

3
4
5
5,3
6,4
7
7,4,1
7,5,1
8,3
8,6
8,6,3
9,4
9,5,3
9,6,1
9,7
9,7,5,1
10,4,1
10,5,1
10,6,4,1
10,7,4
10,7,5
10,8,4
10,8,5,3
11
11,6
11,6,4,1
11,7,1
11,7,5
11,7,5,3
11,8,4
11,9,4,1
11,9,6
11,9,7,1
11,9,7,4
12,5
12,5,3
12,7
12,7,5,1
12,8,3
12,8,6
12,9,1
12,9,4
12,9,7
12,9,7,3
12,9,7,5,1
12,10
12,10,6,4,1
12,10,8,4
12,10,8,5,3
12,10,8,6,1
13
13,5,1
13,6
13,7,5
13,8,4
13,8,6,1
13,9,3
13,9,4,1
13,9,6,3
13,9,7,1
13,9,7,4
13,10,5
13,10,7,5,1
13,10,8,3
13,10,8,4,1
13,10,8,6
13,11,6,1
13,11,7,3
13,11,8,4,1
13,11,8,5,1
13,11,8,6,3
13,11,9,4
13,11,9,6,4
13,11,9,7,4,1
14,3
14,5,1
14,6,4,1
14,7,5,3
14,8,4
14,8,6,4
14,9,6
14,9,6,3
14,9,7,5,3
14,10,1
14,10,5,3
14,10,6,4
14,10,7,4,1
14,10,8,4,1
14,10,8,6
14,10,8,6,3
14,11,1
14,11,7
14,11,8
14,11,8,4,1
14,11,8,6,4,1
14,11,9,4
14,11,9,6,1
14,12
14,12,3
14,12,7,5,3

O'Reilly Books Now On Kindle

2008-07-16T10:21:00.002-05:00

O'Reilly just started making some book available for Kindle and other readers.

This is greate news!

Semantic Vectors Revisited (for 31 bucks!)

2008-05-31T15:03:00.004-05:00

Its been a while since I posted (been busy writing my new book) and even longer since I've posted any ideas related to my ideas on using concepts from linear algebra to model intelligence. But I thought I'd share an experience that makes me wonder how anything got done before the WWW!

While doing research on tensors for my book I came across a book called MathTensor: A System for Doing Tensor Analysis by Computer. This book describes software for Tensor Math developed using Mathematica so it instantly caught my interest. This lead me to one of the author's web sites which lead me to an article Tensor Analysis of Matrix Cognition during Medical Decision-Making. Now you can't put the words matrix and cognition next to each other without getting my immediate attention so I jumped to that essay which ultimately lead me to this gem: A scaling method for priorities in hierarchical structures by
Thomas L. Sattay written in the Journal Mathematical Psychology 1977; 15:234-281 (there is no online version but you can buy a PDF copy at ScienceDirect if you are willing to part with $31.

I found this research to be fascinating and gave me much food for thought that I'll try to share when I have more time. For now I'd only like to make the following rather obvious observation. If it was not for the web, there would be close to zero chance that I would have found this article and an even smaller chance I would be reading it within 15 mins of finding it. The only sad part is that it is locked up in some obscure journal that I did not have immediate access to without parting with the cost of a nice dinner. I think publishers of journals need to catch up with the rest of the world and begin opening up their older content to free access. Clearly they can use advertising to subsidize this but perhaps advertisement driven business models have reached a point of saturation. Perhaps its time for a library based approach to become virtualized.

I am sure I could find a library within a reasonable vicinity of my home that had access to this journal but who has the time! Why not offer a version that rather than costing $31 to keep forever, costs me $1 to read for a day and $0.50 for each additional day. DRM technology is certainly good enough to make this work. And I am guessing that the publishers would make more money than by waiting for someone like me who was motivated enough to part with $31. There is a vast amount of lost knowledge hiding in these journals. History has shown that the world benefits greatly when such knowledge is serendipitously rediscovered (think Gregor Mendel and his Bean Plants). Its time to unlock the vaults of knowledge so creativity and discovery can reach new unimagined heights!