MathGroup Archive 2010

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

Search the Archive

Re: something nice I found today, return multiple

  • To: mathgroup at smc.vnet.net
  • Subject: [mg113144] Re: something nice I found today, return multiple
  • From: Ingolf Dahl <Ingolf.Dahl at physics.gu.se>
  • Date: Fri, 15 Oct 2010 13:51:03 -0400 (EDT)

Nasser,
There are two different organizing principles: "positional ordering" and "naming of things". In cases of perfect order, the first principle is more effective, but if there is some disordering around (e.g. forgetting where things are put), the second principle often is better. Functional programming works according to the first principle, avoiding putting unnecessary names on things, and often then get high efficiency. It is faster to tell "he is there!" instead of "his name is Peter, and you might find his position in the name list". So if you have any ambition to satisfy the needs of your functional programmer friends you should return lists from your functions, as =
you did before:

computeSomething[r_] := Module[{var1 = -99, var2 = 20, result},
result = {var1*r, var2*r}];

And then you might also get naming of things by

{x,y} = computeSomething[30];

or by redefining computeSomething:

computeSomething[r_] := Module[{var1 = -99, var2 = 20, result},
result = {x=var1*r, y=var2*r}]; computeSomething[30];

If you do not care about the functional programming aspects, you might reserve two variable names, say x and y (or something more complicated), for the result, and directly write

computeSomething[r_] := (x= -99*r; y*r);  computeSomething[30];

Then I guess that the functional programmer guy will say that you pick out the results as side effects of the function.

With your solution, I see it as if you will save the result in two places, both as (x, y) and as (result["x"], result["y"]). To me it seems better to just use one place, and use the default name space for variables to store results rather than to define a new name space of the type result[string]. Duplication of data is an unnecessary complication, which might lead to errors if the data need updating.

I see one instance when an approach similar to yours is attractive. If I am
 doing many similar experiments, I might want to store the experimental data in files. Then it is convenient to write text files containing self-defining data as executable Mathematica code:

lambda[measurement_number]=544;
mu[measurement_number]=0.7;

Then I can read these data files directly into Mathematica as m files, without any special interpreter, and I can also easily modify and complement th=
e measurement files with additional information. The measurement data are then also easily interpreted by a human reader, if necessary.

Best regards

Ingolf Dahl
ingolf.dahl at telia.com

> -----Original Message-----
> From: Nasser M. Abbasi [mailto:nma at 12000.org]
> Sent: den 14 oktober 2010 05:29
> To: mathgroup at smc.vnet.net
> Subject: [mg113134] Re: something nice I found today, return multiple values from a
> function
>
> On 10/12/2010 11:42 PM, Albert Retey wrote:
>
> >>
> >
> > 1) I think it has been mentioned in another post today: Module with an
> > empty list is just an elaborate noop: You better just say:
> >
> >   getPointCoordinates[x_, y_] := {x ->  10, y ->  7}
> >
>
> Ok, but I was just using an example to illustrate the main point of how
> to package multiple return values neatly.
>
>
> > 2) you also might like this:
> >
> >
> > makepoint[p_Symbol,xx_,yy_]:=(p[x]=xx;p[y]=yy; p);
> >
> > makepoint[p,10,7]
> >
> > p@x
> > p@y
> >
> > hth,
> >
> > albert
> >
>
> Well, after more playing around, I know settled on this 'pattern'.
>
> But before I show it, let me be clear what I am trying to do: Sometimes
> I call a Module[] with some input parameters, and it does some
> computation, and return back number of results. I used to return the
> result in a LIST to the caller.  Had to make sure I access the return
> values from the list on return in the same order they are put in.
>
> A struct would have solved this. But now I can do this, please let me
> know what you think of this new way:
>
> In[11]:= computeSomething[r_] := Module[{var1 = -99, var2 = 20, result},
> result["x"] = var1*r; result["y"] = var2*r;
>       result];
> In[12]:= result = computeSomething[30];
> x = result["x"]
> y = result["y"]
> Out[13]= -2970
> Out[14]= 600
>
>
> ---- define some module to do some work and return many results
>
> computeSomething[r_] := Module[{var1 = -99, var2 = 20, result},
>        result["x"] = var1*r;
>        result["y"] = var2*r;
>        result]
>
>
> ---- now call it with some data to compute something
> result = computeSomething[30];
>
> --- now result is in a struct-like, I can access the
> --- result by NAME, which is important
>
> x = result["x"]
> y = result["y"]
> Out[9]= -2970
> Out[10]= 600
>
> ---------------------------
>
> Now I think I have what seems like a good struct emulation in
> Mathematica. unless I found a problem with this 'pattern', I think I
> will start using it.
>
> The above is better than what I used to do which is:
>
> ------------------------------
> computeSomething[r_] := Module[{var1 = -99, var2 = 20, result},
>      result = {var1*r, var2*r}
> ];
>
> result = computeSomething[30];
>
> x = result[[1]]
> y = result[[2]]
> Out[7]= -2970
> Out[8]= 600
> -------------------------------------
>
> The difference is that now I do not have to worry about which position
> each individual result is at.  Instead of result[[1]], I write result["x"=
]
>
> Thanks all for the input.
>
> --Nasser


  • Prev by Date: Re: Using Mathematica remotely (installed on Mac, to
  • Next by Date: Re: What is the ESC sequence for the "Matching Double Brakets"? From
  • Previous by thread: Re: Using Mathematica remotely (installed on Mac, to
  • Next by thread: Re: Re: something nice I found today, return multiple