I have a list of points:
points = {{0.144, 1.20}, {0.110, 1.60}, {0.083, 2.00}, {0.070, 2.40},
{0.060, 2.80}, {0.053, 3.20}, {0.050, 3.60}, {0.043, 4.00}}
I want to pass each point to this function, returning a new point:
coordinate[length_,frequence_] = {(1/(2*length)) , (frequence*1000)}
Which should result in a list like so:
{ {3.47, 12 000}, {4.54, 16 000}, ... }
I've been trying to do so with map:
data = Map[coordinate, points]
It yields something like:
{coordinate[{0.144, 1.2}], coordinate[{0.11, 1.6}]}
At first that seems correct, except it passes a list rather than just arguments. However, even if I change my coordinate function to accept a list (by changing the expected parameter to list_ and changing length to list[[1]] and frequence to list[[2]]), I won't be able to use the list returned by that map for e.g. linear regression by LinearModelFit[data, x, x]["BestFit"].
The simplest way that uses your definition, is Apply at level 1 which has the shorthand ###. (See the more info part of the Apply documentation.) So, you want
points = {{0.144, 1.20}, {0.110, 1.60}, {0.083, 2.00}, {0.070,
2.40}, {0.060, 2.80}, {0.053, 3.20}, {0.050, 3.60}, {0.043, 4.00}}
coordinate[length_, frequence_] := {(1/(2*length)), (frequence*1000)}
coordinate ### points
Note that I've changed your definition into a SetDelayed instead of just Set (pay attention to the syntax highlighting showing you the localized variables on the right hand side). See the Immediate and Delayed Definitions guide page.
This said, it's probably best to make coordinate take a list instead of a sequence, as done in belisarius' and ninjagecko's answers, i.e.,
coordinate[{length_, frequence_}] := {(1/(2*length)), (frequence*1000)}
coordinate[{length_, frequence_}] := {(1/(2*length)), (frequence*1000)}
data = coordinate /# points
(*
->{{3.47222, 1200.}, {4.54545, 1600.}, {...
*)
And
lm = LinearModelFit[data, x, x]
(*
-> -40.3573 + 348.678 x
*)
Show[ListPlot[data], Plot[lm[x], {x, 0, 15}], Frame -> True]
Change your definition to
coordinate[point_] := {(1/(2*point[[1]])) , (point[[2]]*1000)}
coordinate[{length_, frequence_}] := {1/(2*length), frequence*1000}
coordinate /# points
sidenote: I would personally stay away from the ### that has been proposed in other answers, since it feels awkward to me as a programmer. But those answers are also certainly valid.
Alternatively, you could use Apply instead of Map:
coordinate ### points
output:
{{3.47222, 1200.}, {4.54545, 1600.}, {6.0241, 2000.}, {7.14286, 2400.},
{8.33333, 2800.}, {9.43396, 3200.}, {10., 3600.}, {11.6279, 4000.}}
I feel that ### is the cleanest way to handle this. However, if you can to redefine coordinate but you do not want remove its existing syntax, you may consider this construct.
Clear[coordinate]
coordinate[length_, frequence_] := {(2 length)^-1, 1000 frequence}
coordinate[l_List] := Apply[coordinate, l, {-2}]
The new line adds a definition to handle lists. This assumes that your arguments are not themselves objects with depth. It allows for quite a bit of flexibility in the way you use the function:
coordinate[0.144, 1.20]
(*Out= {3.47222, 1200.} *)
coordinate[{0.144, 1.20}]
(*Out= {3.47222, 1200.} *)
coordinate[points]
(*Out= {{3.47222, 1200.}, {4.54545, 1600.}, {6.0241,
2000.}, {7.14286, 2400.}, {8.33333, 2800.}, {9.43396, 3200.}, {10.,
3600.}, {11.6279, 4000.}} *)
coordinate /# points
(*Out= {{3.47222, 1200.}, {4.54545, 1600.}, {6.0241,
2000.}, {7.14286, 2400.}, {8.33333, 2800.}, {9.43396, 3200.}, {10.,
3600.}, {11.6279, 4000.}} *)
coordinate ### points
(*Out= {{3.47222, 1200.}, {4.54545, 1600.}, {6.0241,
2000.}, {7.14286, 2400.}, {8.33333, 2800.}, {9.43396, 3200.}, {10.,
3600.}, {11.6279, 4000.}} *)
Related
What is the best way to define a numerical constant in Mathematica?
For example, say I want g to be the approximate acceleration due to gravity on the surface of the Earth. I give it a numerical value (in m/s^2), tell Mathematica it's numeric, positive and a constant using
Unprotect[g];
ClearAll[g]
N[g] = 9.81;
NumericQ[g] ^= True;
Positive[g] ^= True;
SetAttributes[g, Constant];
Protect[g];
Then I can use it as a symbol in symbolic calculations that will automatically evaluate to 9.81 when numerical results are called for. For example 1.0 g evaluates to 9.81.
This does not seem as well tied into Mathematica as built in numerical constants. For example Pi > 0 will evaluate to True, but g > 0 will not. (I could add g > 0 to the global $Assumptions but even then I need a call to Simplify for it to take effect.)
Also, Positive[g] returns True, but Positive[g^2] does not evaluate - compare this with the equivalent statements using Pi.
So my question is, what else should I do to define a numerical constant? What other attributes/properties can be set? Is there an easier way to go about this? Etc...
I'd recommend using a zero-argument "function". That way it can be given both the NumericFunction attribute and a numeric evaluation rule. that latter is important for predicates such as Positive.
SetAttributes[gravUnit, NumericFunction]
N[gravUnit[], prec_: $MachinePrecision] := N[981/100, prec]
In[121]:= NumericQ[gravitUnit[]]
Out[121]= True
In[122]:= Positive[gravUnit[]^2 - 30]
Out[122]= True
Daniel Lichtblau
May be I am naive, but to my mind your definitions are a good start. Things like g > 0->True can be added via UpValues. For Positive[g^2] to return True, you probably have to overload Positive, because of the depth-1 limitation for UpValues. Generally, I think the exact set of auto-evaluated expressions involving a constant is a moving target, even for built-in constants. In other words, those extra built-in rules seem to be determined from convenience and frequent uses, on a case-by-case basis, rather than from the first principles. I would just add new rules as you go, whenever you feel that you need them. You probably can not expect your constants to be as well integrated in the system as built-ins, but I think you can get pretty close. You will probably have to overload a number of built-in functions on these symbols, but again, which ones those will be, will depend on what you need from your symbol.
EDIT
I was hesitating to include this, since the code below is a hack, but it may be useful in some circumstances. Here is the code:
Clear[evalFunction];
evalFunction[fun_Symbol, HoldComplete[sym_Symbol]] := False;
Clear[defineAutoNValue];
defineAutoNValue[s_Symbol] :=
Module[{inSUpValue},
s /: expr : f_[left___, s, right___] :=
Block[{inSUpValue = True},
With[{stack = Stack[_]},
If[
expr === Unevaluated[expr] &&
(evalFunction[f, HoldComplete[s]] ||
MemberQ[
stack,
HoldForm[(op_Symbol /; evalFunction[op, HoldComplete[s]])
[___, x_ /; ! FreeQ[Unevaluated[x], HoldPattern#expr], ___]],
Infinity
]
),
f[left, N[s], right],
(* else *)
expr
]]] /; ! TrueQ[inSUpValue]];
ClearAll[substituteNumeric];
SetAttributes[substituteNumeric, HoldFirst];
substituteNumeric[code_, rules : {(_Symbol :> {__Symbol}) ..}] :=
Internal`InheritedBlock[{evalFunction},
MapThread[
Map[Function[f, evalFunction[f, HoldComplete[#]] = True], #2] &,
Transpose[List ### rules]
];
code]
With this, you may enable a symbol to auto-substitute its numerical value in places where we indicate some some functions surrounding those function calls may benefit from it. Here is an example:
ClearAll[g, f];
SetAttributes[g, Constant];
N[g] = 9.81;
NumericQ[g] ^= True;
defineAutoNValue[g];
f[g] := "Do something with g";
Here we will try to compute some expressions involving g, first normally:
In[391]:= {f[g],g^2,g^2>0, 2 g, Positive[2 g+1],Positive[2g-a],g^2+a^2,g^2+a^2>0,g<0,g^2+a^2<0}
Out[391]= {Do something with g,g^2,g^2>0,2 g,Positive[1+2 g],
Positive[-a+2 g],a^2+g^2,a^2+g^2>0,g<0,a^2+g^2<0}
And now inside our wrapper (the second argument gives a list of rules, to indicate for which symbols which functions, when wrapped around the code containing those symbols, should lead to those symbols being replaced with their numerical values):
In[392]:=
substituteNumeric[{f[g],g^2,g^2>0, 2 g, Positive[2 g+1],Positive[2g-a],g^2+a^2,g^2+a^2>0,
g<0,g^2+a^2<0},
{g:>{Positive,Negative,Greater}}]
Out[392]= {Do something with g,g^2,True,2 g,True,Positive[19.62\[VeryThinSpace]-a],
a^2+g^2,96.2361\[VeryThinSpace]+a^2>0,g<0,a^2+g^2<0}
Since the above is a hack, I can not guarantee anything about it. It may be useful in some cases, but that must be decided on a case-by-case basis.
You may want to consider working with units rather than just constants. There are a few options available in Mathematica
Units
Automatic Units
Designer units
There are quite a few technical issues and subtleties about working with units. I found the backgrounder at Designer Units very useful. There are also some interesting discussions on MathGroup. (e.g. here).
Is it possible to define a function that holds arguments at given positions ?
Or to do something like HoldLast as a counterpart to HoldFirst ?
As far as I know, you can not do this directly in the sense that there isn't a HoldN attribute.
However, below there is a work-around that should be doing what you requested.
Proposed solution
One simple way is to define an auxiliary function that will do the main work, and your "main" function (the one that will actually be called) as HoldAll, like so:
In[437]:=
SetAttributes[f, HoldAll];
f[a_, b_, c_] :=
faux[a, Unevaluated[b], c];
faux[a_, b_, c_] := Hold[a, b, c]
In[440]:= f[1^2, 2^2, 3^2]
Out[440]= Hold[1, 2^2, 9]
You don't have to expose the faux to the top level, can wrap everyting in Module[{faux}, your definitions] instead.
Automation through meta-programming
This procedure can be automated. Here is a simplistic parser for the function signatures, to extract pattern names (note - it is indeed simplistic):
splitHeldSequence[Hold[seq___], f_: Hold] := List ## Map[f, Hold[seq]];
getFunArguments[Verbatim[HoldPattern][Verbatim[Condition][f_[args___], test_]]] :=
getFunArguments[HoldPattern[f[args]]];
getFunArguments[Verbatim[HoldPattern][f_[args___]]] :=
FunArguments[FName[f], FArgs ## splitHeldSequence[Hold[args]]];
(*This is a simplistic "parser".It may miss some less trivial cases*)
getArgumentNames[args__FArgs] :=
args //. {
Verbatim[Pattern][tag_, ___] :> tag,
Verbatim[Condition][z_, _] :> z,
Verbatim[PatternTest][z_, _] :> z
};
Using this, we can write the following custom definition operator:
ClearAll[defHoldN];
SetAttributes[defHoldN, HoldFirst];
defHoldN[SetDelayed[f_[args___], rhs_], n_Integer] :=
Module[{faux},
SetAttributes[f, HoldAll];
With[{heldArgs =
MapAt[
Unevaluated,
Join ## getArgumentNames[getFunArguments[HoldPattern[f[args]]][[2]]],
n]
},
SetDelayed ## Hold[f[args], faux ## heldArgs];
faux[args] := rhs]]
This will analyze your original definition, extract pattern names, wrap the argument of interest in Unevaluated, introduce local faux, and make a 2-step definition - basically the steps we did manually. We need SetDelayed ## .. to fool the variable renaming mechanism of With, so that it won't rename our pattern variables on the l.h.s. Example:
In[462]:=
ClearAll[ff];
defHoldN[ff[x_,y_,z_]:=Hold[x,y,z],2]
In[464]:= ?ff
Global`ff
Attributes[ff]={HoldAll}
ff[x_,y_,z_]:=faux$19106##Hold[x,Unevaluated[y],z]
In[465]:= ff[1^2,2^2,3^2]
Out[465]= Hold[1,2^2,9]
Notes
Note that this is trivial to generalize to a list of positions in which you need to hold the arguments. In general, you'd need a better pattern parser, but the simple one above may be a good start. Note also that there will be a bit of run-time overhead induced with this construction, and also that the Module-generated auxiliary functions faux won't be garbage-collected when you Clear or Remove the main ones - you may need to introduce a special destructor for your functions generated with defHoldN. For an alternative take on this problem, see my post in this thread (the one where I introduced the makeHoldN function).
Another way to do would be for example:
SetAttributes[f,HoldFirst];
f[{heldArg1_,heldArg2_},arg3_,arg4_,arg5_]:= Hold[arg3 heldArg1];
And this would allow to be able to have any mix of held and non held arguments.
HoldRest could be used similarly.
I would like to define a symbol pt to hold a point (and eventually cache some data related to that point):
pt::"usage" = "pt[{x,y}] represents a point at {x,y}";
I would like to be able to use such pt objects as points in as many ways as possible, an particularly, I would like to be able to write
{a0,a1}+pt[{b0,b1}]
and have it return pt[{a0+b0,a1+b1}] rather than {a0+pt[{b0,b1}],a1+pt[{b0,b1}]}.
My original idea was to use:
pt /: Plus[pt[p0_], p1 : {_, _}] = pt[p0 + p1];
But this doesn't work (because Plus is Listable?). Is there a way to do this without unprotecting Plus?
Update:
As Leonid points out, this is not possible without globally or locally hacking Plus, since the Listable attribute is considered before any *values. This is actually described very precisely in the evaluation tutorial.
Mathematica's evaluator seems not flexible enough to do this easily. UpValues for pt indeed are applied before DownValues for Plus, but threading over lists due to Listability happens even before that. In this particular case, the following might work for you:
eval = Function[code,Block[{Plus = Plus, attr = DeleteCases[Attributes[Plus], Listable]},
SetAttributes[Plus, attr]; code], HoldAll]
To use it, wrap it around a piece of code where you want your rule for pt to apply, e.g.:
eval[{a0, a1} + pt[{b0, b1}]]
You can use $Pre as $Pre = eval to avoid typing eval every time, although generally I would not recommend this. Blocking Plus is a softer way of disabling some or all of its Attributes temporarily. The advantage w.r.t. clearing and setting attributes without Block is that you can not end up in a global state with Listable attribute permanently disabled, even if exception is thrown or the computation is Abort-ed.
Since Listable attribute directly affects evaluation rather than pattern-matching (the latter may of course be affected indirectly if some pattern has to match the result of Plus threaded over a list), this should be ok in most cases. In theory, it may still lead to some unwanted effects in some cases, particularly where pattern-matching is involved. But in practice, it might be good enough. A cleaner but more complex solution would be to create a custom evaluator tailored to your needs.
The following is a bit wasteful, but it works: The idea is to simply watch for cases where the Listable attribute of Plus has put the same pt into all elements of a list (i.e. a raw point) -- and then pull it back out. First, define a function for adding pt objects:
SetAttributes[ptPlus, {Orderless}]
ptPlus[pt[pa : {_, _}], pt[pb : {_, _}], r___] :=
ptPlus[pt[pa + pb], r];
ptPlus[p_pt] := p;
Then we make sure that any Plus which involves a pt is mapped to ptPlus (an associate the rule with pt).
Plus[h___, a_pt, t___] ^:= ptPlus[h, a, t];
The above rules means that: {x0,y0}+pt[{x1,y1}] will be expanded from {x0+pt[{x1,y1}],y0+pt[{x1,y1}]} to {ptPlus[x0,pt[{x1,y1}]],ptPlus[y0,pt[{x1,y1}]]}. Now we just make a rule to transform this to pt[{x0,y0}]+pt[{x1,y1}] (note the deferred condition which checks that the pts are equal):
{ptPlus[x__], ptPlus[y__]} ^:= Module[{
ptCases = Cases[{{x}, {y}}, _pt, {2}]},
ptCases[[1]] + pt[Plus ### DeleteCases[{{x}, {y}}, _pt, {2}]]
/; Equal ## ptCases]
A more opaque, but slightly more careful version which is easier to generalize to higher dimensions:
ptPlus /: p : {_ptPlus, _ptPlus} := Module[{ptCases, rest,
lp = ReleaseHold#Apply[List, Hold[p], {2}]},
ptCases = Cases[lp, _pt, {2}];
rest = Plus ### DeleteCases[lp, _pt, {2}];
ptCases[[1]] + pt[rest] /; And[Equal ## ptCases, VectorQ#rest]]
This whole approach will of course lead to horribly subtle bugs when {a+pt[{0,0}],a+pt[{0,b}]} /. {a -> pt[{0,0}]} evaluates to pt[{0,0}] when c==0 and {pt[{0,0}],pt[{0,c}]} otherwise...
HTH -- said the guy to himself...
A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"
One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?
Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None]
edit 11/14
A general cause of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root. Built-ins evaluated along the way notice the badness and produce warnings. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.
One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.
Having the debugger set to "break on Messages" prevents an avalanche of errors, although it seems like an overkill to have it turned on all the time
As others have pointed out, there are three ways to deal with errors in a consistent manner:
correctly typing parameters and setting up conditions under which your functions will run,
dealing correctly and consistently with errors generated, and
simplifying your methodology to apply these steps.
As Samsdram pointed out, correctly typing your functions will help a great deal. Don't forget about the : form of Pattern as it is sometimes easier to express some patterns in this form, e.g. x:{{_, _} ..}. Obviously, when that isn't sufficient PatternTests (?) and Conditions (/;) are the way to go. Samdram covers that pretty well, but I'd like to add that you can create your own pattern test via pure functions, e.g. f[x_?(Head[#]===List&)] is equivalent to f[x_List]. Note, the parentheses are necessary when using the ampersand form of pure functions.
The simplest way to deal with errors generated is obviously Off, or more locally Quiet. For the most part, we can all agree that it is a bad idea to completely shut off the messages we don't want, but Quiet can be extremely useful when you know you are doing something that will generate complaints, but is otherwise correct.
Throw and Catch have their place, but I feel they should only be used internally, and your code should communicate errors via the Message facilities. Messages can be created in the same manner as setting up a usage message. I believe the key to a coherent error strategy can be built using the functions Check, CheckAbort, AbortProtect.
Example
An example from my code is OpenAndRead which protects against leaving open streams when aborting a read operation, as follows:
OpenAndRead[file_String, fcn_]:=
Module[{strm, res},
strm = OpenRead[file];
res = CheckAbort[ fcn[strm], $Aborted ];
Close[strm];
If[res === $Aborted, Abort[], res] (* Edited to allow Abort to propagate *)
]
which, Until recently, has the usage
fcn[ file_String, <otherparams> ] := OpenAndRead[file, fcn[#, <otherparams>]&]
fcn[ file_InputStream, <otherparams> ] := <fcn body>
However, this is annoying to do every time.
This is where belisarius solution comes into play, by creating a method that you can use consistently. Unfortunately, his solution has a fatal flaw: you lose support of the syntax highlighting facilities. So, here's an alternative that I came up with for hooking into OpenAndRead from above
MakeCheckedReader /:
SetDelayed[MakeCheckedReader[fcn_Symbol, symbols___], a_] :=
Quiet[(fcn[file_String, symbols] := OpenAndRead[file, fcn[#, symbols] &];
fcn[file_Symbol, symbols] := a), {RuleDelayed::"rhs"}]
which has usage
MakeCheckedReader[ myReader, a_, b_ ] := {file$, a, b} (*as an example*)
Now, checking the definition of myReader gives two definitions, like we want. In the function body, though, file must be referred to as file$. (I have not yet figured out how to name the file var as I'd wish.)
Edit: MakeCheckedReader works by not actually doing anything itself. Instead, the TagSet (/:) specification tells Mathematica that when MakeCheckedReader is found on the LHS of a SetDelayed then replace it with the desired function definitions. Also, note the use of Quiet; otherwise, it would complain about the patterns a_ and b_ appearing on the right side of the equation.
Edit 2: Leonid pointed out how to be able to use file not file$ when defining a checked reader. The updated solution is as follows:
MakeCheckedReader /:
SetDelayed[MakeCheckedReader[fcn_Symbol, symbols___], a_] :=
Quiet[(fcn[file_String, symbols] := OpenAndRead[file, fcn[#, symbols] &];
SetDelayed ## Hold[fcn[file_Symbol, symbols], a]),
{RuleDelayed::"rhs"}]
The reasoning for the change is explained in this answer of his. Defining myReader, as above, and checking its definition, we get
myReader[file$_String,a_,b_]:=OpenAndRead[file$,myReader[#1,a_,b_]&]
myReader[file_Symbol,a_,b_]:={file,a,b}
I'm coming late to the party, with an accepted answer and all, but I want to point out that definitions of the form:
f[...] := Module[... /; ...]
are very useful in this context. Definitions of this kind can perform complex calculations before finally bailing out and deciding that the definition was not applicable after all.
I will illustrate how this can be used to implement various error-handling strategies in the context of a specific case from another SO question. The problem is to search a fixed list of pairs:
data = {{0, 1}, {1, 2}, {2, 4}, {3, 8}, {4, 15}, {5, 29}, {6, 50}, {7,
88}, {8, 130}, {9, 157}, {10, 180}, {11, 191}, {12, 196}, {13,
199}, {14, 200}};
to find the first pair whose second component is greater than or equal to a specified value. Once that pair is found, its first component is to be returned. There are lots of ways to write this in Mathematica, but here is one:
f0[x_] := First # Cases[data, {t_, p_} /; p >= x :> t, {1}, 1]
f0[100] (* returns 8 *)
The question, now, is what happens if the function is called with a value that cannot be found?
f0[1000]
error: First::first: {} has a length of zero and no first element.
The error message is cryptic, at best, offering no clues as to what the problem is. If this function was called deep in a call chain, then a cascade of similarly opaque errors is likely to occur.
There are various strategies to deal with such exceptional cases. One is to change the return value so that a success case can be distinguished from a failure case:
f1[x_] := Cases[data, {t_, p_} /; p >= x :> t, {1}, 1]
f1[100] (* returns {8} *)
f1[1000] (* returns {} *)
However, there is a strong Mathematica tradition to leave the original expression unmodified whenever a function is evaluated with arguments outside of its domain. This is where the Module[... /; ...] pattern can help out:
f2[x_] :=
Module[{m},
m = Cases[data, {t_, p_} /; p >= x :> t, {1}, 1];
First[m] /; m =!= {}
]
f2[100] (* returns 8 *)
f2[1000] (* returns f2[1000] *)
Note that the f2 bails out completely if the final result is the empty list and the original expression is returned unevaluated -- achieved by the simple expedient of adding a /; condition to the final expression.
One might decide to issue a meaningful warning if the "not found" case occurs:
f2[x_] := Null /; Message[f2::err, x]
f2::err = "Could not find a value for ``.";
With this change the same values will be returned, but a warning message will be issued in the "not found" case. The Null return value in the new definition can be anything -- it is not used.
One might further decide that the "not found" case just cannot occur at all except in the case of buggy client code. In that case, one should cause the computation to abort:
f2[x_] := (Message[f2::err, x]; Abort[])
In conclusion, these patterns are easy enough to apply so that one can deal with function arguments that are outside the defined domain. When defining functions, it pays to take a few moments to decide how to handle domain errors. It pays in reduced debugging time. After all, virtually all functions are partial functions in Mathematica. Consider: a function might be called with a string, an image, a song or roving swarms of nanobots (in Mathematica 9, maybe).
A final cautionary note... I should point out that when defining and redefining functions using multiple definitions, it is very easy to get unexpected results due to "left over" definitions. As a general principle, I highly recommend preceding multiply-defined functions with Clear:
Clear[f]
f[x_] := ...
f[x_] := Module[... /; ...]
f[x_] := ... /; ...
The problem here is essentially one of types. One function produces a bad output (incorrect type) which is then fed into many subsequent functions producing lots of errors. While Mathematica doesn't have user defined types like in other languages, you can do pattern matching on function arguments without too much work. If the match fails the function doesn't evaluate and thus doesn't beep with errors. The key piece of syntax is "/;" which goes at the end of some code and is followed by the test. Some example code (and output is below).
Input:
Average[x_] := Mean[x] /; VectorQ[x, NumericQ]
Average[{1, 2, 3}]
Average[$Failed]
Output:
2
Average[$Failed]
If the test is simpler, there is another symbol that does similar pattern testing "?" and goes right after an argument in a pattern/function declaration. Another example is below.
Input:
square[x_?NumericQ] := x*x
square[{1, 2, 3}]
square[3]
Output:
square[{1, 2, 3}]
9
It can help to define a catchall definition to pick up error conditions and report it in a meaningful way:
f[x_?NumericQ] := x^2;
f[args___] := Throw[{"Bad Arguments: ", Hold[f[args]]}]
So your top level calls can use Catch[], or you can just let it bubble up:
In[5]:= f[$Failed]
During evaluation of In[5]:= Throw::nocatch: Uncaught Throw[{Bad Args: ,Hold[f[$Failed]]}] returned to top level. >>
Out[5]= Hold[Throw[{"Bad Args: ", Hold[f[$Failed]]}]]
What I'd love to get is a way to define a general procedure to catch error propagation without the need to change radically the way I write functions right now, preferentially without adding substantial typing.
Here is a try:
funcDef = t_[args___] :c-: a_ :> ReleaseHold[Hold[t[args] :=
Check[a, Print#Hold[a]; Abort[]]]];
Clear#v;
v[x_, y_] :c-: Sin[x/y] /. funcDef;
?v
v[2, 3]
v[2, 0]
The :c-: is of course Esc c- Esc, an unused symbol (\[CircleMinus]), but anyone would do.
Output:
Global`v
v[x_,y_]:=Check[Sin[x/y],Print[Hold[Sin[x/y]]];Abort[]]
Out[683]= Sin[2/3]
During evaluation of In[679]:= Power::infy: Infinite expression 1/0 encountered. >>
During evaluation of In[679]:= Hold[Sin[2/0]]
Out[684]= $Aborted
What we changed is
v[x_, y_] := Sin[x/y]
by
v[x_, y_] :c-: Sin[x/y] /. funcDef;
This almost satisfies my premises.
Edit
Perhaps it's also convenient to add a "nude" definition for the function, that does not undergo the error checking. We may change the funcDef rule to:
funcDef =
t_[args___] \[CircleMinus] a_ :>
{t["nude", args] := a,
ReleaseHold[Hold[t[args] := Check[a, Print#Hold[a]; Abort[]]]]
};
to get for
v[x_, y_] :c-: Sin[x/y] /. funcDef;
this output
v[nude,x_,y_]:=Sin[x/y]
v[x_,y_]:=Check[Sin[x/y],Print[Hold[Sin[x/y]]];Abort[]]
I would like to pass the parameter values in meters or kilometers (both possible) and get the result in meters/second.
I've tried to do this in the following example:
u = 3.986*10^14 Meter^3/Second^2;
v[r_, a_] := Sqrt[u (2/r - 1/a)];
Convert[r, Meter];
Convert[a, Meter];
If I try to use the defined function and conversion:
a = 24503 Kilo Meter;
s = 10198.5 Meter/Second;
r = 6620 Kilo Meter;
Solve[v[r, x] == s, x]
The function returns the following:
{x -> (3310. Kilo Meter^3)/(Meter^2 - 0.000863701 Kilo Meter^2)}
which is not the user-friendly format.
Anyway I would like to define a and r in meters or kilometers and get the result s in meters/second (Meter/Second).
I would be very thankful if anyone of you could correct the given function definition and other statements in order to get the wanted result.
Here's one way of doing it, where you use the fact that Solve returns a list of rules to substitute a value for x into v[r, x], and then use Convert, which will do the necessary simplification of the resulting algebraic expression as well:
With[{rule = First#Solve[v[r,x]==s,x]
(* Solve always returns a list of rules, because algebraic
equations may have multiple solutions. *)},
Convert[v[r,x] /. rule, Meter/Second]]
This will return (10198.5 Meter)/Second as your answer.
You just need to tell Mathematica to simplify the expression assuming that the units are "possitive", which is the reason why it doesn't do the simplifications itself. So, something like
SimplifyWithUnits[blabla_, unit_List]:= Simplify[blalba, (#>0)&/#unit];
So if you get that ugly thing, you then just type %~SimplifyWithUnits~{Meter} or whatever.