Related
In general, mathematica always assumes the most general case, that is, if I set a function
a[s_]:={a1[s],a2[s],a3[s]}
and want to compute its norm Norm[a[s]], for example, it will return:
Sqrt[Abs[a1[s]]^2 + Abs[a2[s]]^2 + Abs[a3[s]]^2]
However, if I know that all ai[s] are real, I can invoke:
Assuming[{a1[s], a2[s], a3[s]} \[Element] Reals, Simplify[Norm[a[s]]]]
which will return:
Sqrt[a1[s]^2 + a2[s]^2 + a3[s]^2]
Which is what I expect.
Problem happens when trying to, for example, derive a[s] and then (note the D):
Assuming[{a1[s], a2[s], a3[s]} \[Element] Reals, Simplify[Norm[D[a[s],s]]]]
Returns again a result involving absolute values - coming from the assumption that the numbers may be imaginary.
What is the way to overcome this problem? I want to define a real-valued function, and work with it as such. That is, for instance, I want its derivatives to be real.
I would use a custom function instead, e.g.
vecNorm[vec_?VectorQ] := Sqrt[ vec.vec ]
Then
In[20]:= vecNorm[D[{a1[s], a2[s], a3[s]}, s]]
Out[20]= Sqrt[
Derivative[1][a1][s]^2 + Derivative[1][a2][s]^2 +
Derivative[1][a3][s]^2]
Warning: I don't have much practical experience with this, so the examples below are not thoroughly tested (i.e. I don't know if too general assumptions can break anything I haven't thought of).
You can use $Assumptions to define permanent assumptions:
We could say that all of a1[s], a2[s], a3[s] are reals:
$Assumptions = {(a1[s] | a2[s] | a3[s]) \[Element] Reals}
But if you have e.g. a1[x] (not a1[s]), then it won't work. So we can improve it a bit using patterns:
$Assumptions = {(a1[_] | a2[_] | a3[_]) \[Element] Reals}
Or just say that all values of a[_] are real:
$Assumptions = {a[_] \[Element] Reals}
Or even be bold and say that everything is real:
$Assumptions = {_ \[Element] Reals}
(I wonder what this breaks)
AppendTo is useful for adding to $Assumptions and keeping previous assumptions.
Just like Assuming, this will only work for functions like Simplify or Integrate that have an Assumtpions option. D is not such a function.
Some functions like Reduce, FindInstance, etc. have an option to work only on the domain of Reals, Integers, etc., which assumes that all expressions and subexpressions they work with are real.
ComplexExpand[] and sometimes FunctionExpand[] may also be useful in similar situations (but not really here). Examples: ComplexExpand[Abs[z]^2, TargetFunctions -> {Sign}] and FunctionExpand[Abs'[x], Assumptions -> {x \[Element] Reals}].
Generally, as far as I know, there is no mathematical way to tell Mathematica that a variable is real. It is only possible to do this in a formal way, using patterns, and only for certain functions that have the Assumptions option. By "formal" I mean that if you tell it that a[x] is real, it will not know automatically that a'[x] is also real.
You could use ComplexExpand in this case albeit with a workaround. For example
ComplexExpand[Norm[a'[s], t]] /. t -> 2
returns
Sqrt[Derivative[1][a1][s]^2 + Derivative[1][a2][s]^2 + Derivative[1][a3][s]^2]
Note that doing something like ComplexExpand[Norm[a'[s], 2]] (or indeed ComplexExpand[Norm[a'[s], p]] where p is a rational number) doesn't work for some reason.
For older Mathematica versions there used to be an add-on package RealOnly that put Mathematica in a reals-only mode. There is a version available in later versions and online with minimal compatibility upgrades. It reduces many situations to a real-only solution, but doesn't work for your Norm case:
I have an issue concerning constraints which should be generated dynamically from a list of variables.
Suppose I have an expression which is contained in variable R which itself has a varying number of variables in it, like x[1]*5+x[3]*x[2]. If I knew the number upfront I would just use NMaximize[{R, 1 > x[1] > -1 && 1 > x[2] > -1 && 1 > x[3] > -1}, f] where f is a list of the variables x constructed by f = Array[x,n], n being the number of variables I use.
As others do not seem to have similar problems I assume that this is not the way in which such issues are normally addressed in mathematica... However if there is a way to tackle this problem easily I would be glad to hear about it (otherwise I would also be glad to hear about a way to bypass that whole thing).
Thanks in advance!
Suppose this is your expression:
In[1]:= r = x[1]*5+x[3]*x[2];
It is relatively easy to extract a list of variables if you know their base symbol:
In[5]:= vars = Union#Cases[r,x[_],Infinity]
Out[5]= {x[1],x[2],x[3]}
Now you can call NMaximize with dynamically generated constraints:
In[7]:= NMaximize[{r,And##Map[Greater[1,#,-1]&,vars]},vars]
Out[7]= {6.,{x[1]->1.,x[2]->-1.,x[3]->-1.}}
The code And##Map[Greater[1,#,-1]&,vars] specifically answers your question, generating the constraints. You can execute it stand-alone to see them.
Examples:
In
CT = Table[Prepend[10^4*x[range2] /.
NDSolve[{...series of equations here...}, {t, range1, range2},
MaxSteps -> 10000,
PrecisionGoal -> 11], delay],
{delay, delaymin, delaymax, 0.1}]; // Timing
what does it mean this // Timing after the semicolon?
In
Dρ = -I*((H0 + V).ρ - ρ.(H0 + V)) - Γ*ρ // Simplify;
And this // Simplify here?
I can't find this explanation anywhere!
Thanks in advance,
Thiago
This is Mathematica's postfix notation.
Basically x//f is the same as f[x]
Yes, argument // function is postfix function application.
Useful about it is that it has a different, lower binding power relative to prefix application (f # x).
In fact it is lower than most other things (exceptions include CompoundExpression ; and Set =), and therefore it can often be considered as "apply to everything before this."
You say: "I can't find this explanation anywhere!". I assume this means you are not aware of the documentation center that's right under your fingertips whenever you're using Mathematica.
All you have to do is to place your cursor on the // and press F1 and you'll get some sort of explanation, or a list with relevant (hopefully) matches. In this case the PostFix page, which is not extremely helpful. However, it has some links at the bottom (assuming you have versions 6, 7 or 8) that provide more insight, among which a link to the syntax overview page (click the Mathematica syntax link, or enter "guide/Syntax" in the search box).
expr // f is essentially equivalent to f[expr]. Sometimes, it's called postfix notation. I read expr // f as "pass the expression expr to the function f".
a // f
is, I believe, the same thing as
f[a]
(which incidentally, any sane mathematician I know would write as
f(a)
just as it is done in most computer languages.)
As others have mentioned, // is the postfix notation and expr//f means f[expr] in mathematica and f(expr) in math.
Although there might be more subtleties involved, my usage of // has often been in cases where I've started writing out an expression and then realized I wanted to operate a function on it. So instead of moving the cursor all the way back to type f#expr or f[expr], I can simply finish typing what I had in mind, and use expr//f.
Example:
Plot[Sin[x],{x,0,Pi}]
%//Export["test.pdf",#]&
The graphics is passed to the export function and is saved as test.pdf.
As your question has already got very good answers, I want to add just a clarification on usage.
The three expressions
Sin[x]
Sin#x
x // Sin
Are equivalent.
Although, to my knowledge, the last two can't be used with functions with more than one argument. So
Plot[Sin[x], {x, 0, Pi}]
Can't be invoked in prefix or postfix notation without tricks like
Sin[x] // Plot[#, {x, 0, Pi}] &
or
Plot[#, {x, 0, Pi}] &#Sin[x]
The prefix notation is usually seen when using simple functions like Sin#x or Sort#list, while most uses of the postfix involve a reasoning like "and now do whatever with this thing I got", for example
(Sin#x+ ...) // Timing
where you decided what to calculate, and then you also want it timed.
One more note:
Really there is much more under the scenes, as the priority of each of these functional constructs is different, but I think that is a much deeper subject and you have to experiment a little before going for subtleties.
I recently rediscovered a small package by Roman Maeder that tells Mathematica to automatically thread arithmetic and similar functions over expressions such as x == y. Link to Maeder's package.
First, to demonstrate, here's an example given by Maeder:
In[1]:= Needs["EqualThread`"]
Now proceed to use the threading behavior to solve the following equation for x 'by hand':
In[7]:= a == b Log[2 x]
In[8]:= %/b
Out[8]:= a/b == Log[2 x]
Now exponentiate:
In[9]:= Exp[%]
Out[9]= E^(a/b) == 2 x
And divide through by 2:
In[10]:= %/2
Out[10]= (E^(a/b))/2 == x
Q: From a design perspective, can someone explain why Mathematica is set to behave this way by default? Automatically threading seems like the type of behavior a Mathematica beginner would expect---to me, at least---perhaps someone can offer an example or two that would cause problems with the system as a whole. (And feel free to point out any mathematica ignorance...)
Seems natural when thinking of arithmetic operations. But that is not always the case.
When I write
Boole[a==b]
I don't want
Boole[a] == Boole[b]
And that is what Maeder's package does.
Edit
Answering your comment below:
I noticed that Boole[] was added in v.5.2, whereas Maeder's package was authored for v.3. I guess the core of my question still revolves around the 'design' issue. I mean, how would one get around the issue you pointed out? To me, the clearest path would be declaring something about variables you're working with, no? -- What puzzles me is the way you can generally only do this with Assumptions (globally or as an option to Simplify, etc). Anyone else think it would be more natural to have a full set of numerical Attributes? (in this regard, the Constant Attribute is a tease)
My answer is by no means a critic to Maeder's package, which is nice, but a statement that it should not be the mainstream way to treat Equal[ ] in Mma.
Equal[ ] is a function, and not particularly easy to grasp at first:
returns True if lhs and rhs are identical
returns False if lhs and rhs are determined to be unequal by comparisons between numbers or other raw data, such as strings.
remains unevaluated when lhs or rhs contains objects such as Indeterminate and Overflow.
is used to represent a symbolic equation, to be manipulated using functions like Solve.
The intent of Maeder's package, which I understand is well aligned with yours, is to give to the expression lhs == rhs the same meaning and manipulation rules humans use when doing math.
In math, equality is an equivalence relation, imposing a partial order in a set, and an equation is an assertion that the expressions are related by this particular relation.
Compare these differences with other Mma "functions". Sin[x] is in Mma, and in usual math the same thing (well, almost), and the same can be said of most Mma beasts. There are a few Mma constructs, however, that do not hold that exact isomorphism to math concepts: Equal, SameQ, Equivalent, etc. They are the bridge from the math world to the programming world. They are not strict math concepts, but modified programming concepts to hold them.
Sorry if I got a little on the philosophical side.
HTH!
I guess it is partly because the behavior can not be extended over to inequalities. And also because the behavior should make sense both when equalities become evaluated:
Would be nice:
In[85]:= Thread[Power[a == b, 2], Equal]
Out[85]= a^2 == b^2
In[86]:= Thread[Power[a == b, c == d], Equal]
Out[86]= a^c == b^d
but:
In[87]:= Thread[Power[a == b, c == d] /. {c -> 2, d -> 2}, Equal]
Out[87]= a^True == b^True
Suppose I want to construct something like
Array[#1^#2 == 3 &, {3, 3}]
And now I want to replace the "3" with a variable. I can do, for example:
f[x_] := Array[#1^#2 == x &, {x, x}]
The question is: Is there a way using only slots and & as the functional notation?
Not really the answer to the original question, but I noticed that many people got interested in #0 stuff, so here I put a couple of non-trivial examples, hope they will be useful.
Regarding the statement that for nested functions one should use functions with named arguments: while this is generally true, one should always keep in mind that lexical scoping for pure functions (and generally) is emulated in Mathematica, and can be broken. Example:
In[71]:=
Clear[f,g];
f[fun_,val_]:=val/.x_:>fun[x];
g[fn_,val_]:=f[Function[{x},fn[#1^#2==x&,{x,x}]],val];
g[Array,3]
During evaluation of In[71]:= Function::flpar: Parameter specification {3} in
Function[{3},Array[#1^#2==3&,{3,3}]] should be a symbol or a list of symbols. >>
During evaluation of In[71]:= Function::flpar: Parameter specification {3} in
Function[{3},Array[#1^#2==3&,{3,3}]] should be a symbol or a list of symbols. >>
Out[74]= Function[{3},Array[#1^#2==3&,{3,3}]][3]
This behavior has to do with the intrusive nature of rule substitutions - that is, with the fact that Rule and RuleDelayed don't care about possible name collisions between names in scoping constructs which may be present in expressions subject to rule applications, and names of pattern variables in rules. What makes things worse is that g and f work completely fine when taken separately. It is when they are mixed together, that this entanglement happens, and only because we were unlucky to use the same pattern variable x in the body of f, as in a pure function. This makes such bugs very hard to catch, while such situations do happen sometimes in practice, so I'd recommend against passing pure functions with named arguments as parameters into higher-order functions defined through patterns.
Edit:
Expanding a bit on emulation of the lexical scoping. What I mean is that, for example, when I create a pure function (which is a lexical scoping construct that binds the variable names in its body to the values of passed parameters), I expect that I should not be able to alter this binding after I have created a function. This means that, no matter where I use Function[x,body-that-depends-on-x], I should be able to treat it as a black box with input parameters and resulting outputs. But, in Mathematica, Function[x,x^2] (for instance) is also an expression, and as such, can be modified like any other expression. For example:
In[75]:=
x = 5;
Function[Evaluate[x],x^2]
During evaluation of In[75]:= Function::flpar: Parameter specification 5 in Function[5,x^2] should
be a symbol or a list of symbols. >>
Out[76]= Function[5,x^2]
or, even simpler (the essence of my previous warning):
In[79]:= 1/.x_:>Function[x,x^2]
During evaluation of In[79]:= Function::flpar: Parameter specification 1 in Function[1,1^2] should
be a symbol or a list of symbols. >>
Out[79]= Function[1,1^2]
I was bitten by this last behavior a few times pretty painfully. This behavior was also noted by #WReach at the bottom of his post on this page - obviously he had similar experiences. There are other ways of breaking the scope, based on exact knowledge of how Mathematica renames variables during the conflicts, but those are comparatively less harmful in practice. Generally, I don't think these sorts of things can be avoided if one insists on the level of transparency represented by Mathematica expressions. It just seems to be "over-transparent" for pure functions (and lexical scoping constructs generally), but on the other hand this has its uses as well, for example we can forge a pure function at run-time like this:
In[82]:= Block[{x},Function##{x,Integrate[HermiteH[10,y],{y,0,x}]}]
Out[82]= Function[x,-30240 x+100800 x^3-80640 x^5+23040 x^7-2560 x^9+(1024 x^11)/11]
Where the integral is computed only once, at definition-time (could use Evaluate as well). So, this looks like a tradeoff. In this way, the functional abstraction is better integrated into Mathematica, but is leaky, as #WReach noted. Alternatively, it could have been "waterproof", but perhaps for the price of being less exposed. This was clearly a design decision.
How about
Map[Last, #] & /# Array[#1^#2 == #3 &, {#, #, #}] &[3]
Horrendously ugly element extraction, and very interestingly Map[Last, #]& gives me a different result than Last /#. Is this due to the fact that Map has different attributes than &?
I guess you know what the documentation says about nested pure functions.
Use explicit names to set up nested
pure functions (for example):
Function[u, Function[v, f[u, v]]][x]
Anyway, here's the best I could come up with without following the above advice:
f[x_] := Array[#1^#2 == x &, {x, x}]
g = Array[With[{x = #}, #1^#2 == x &], {#, #}] &
g is functionally identical to your original f, but is not really better than the recommended
h = Function[x, Array[#1^#2 == x &, {x, x}]]
How about With[{x = #1}, Array[#1^#2 == x &, {x, x}]] &?
Perhaps
Array[#1^#2 &, {#, #}] /. i_Integer :> i == # &[3]
Or
Thread /# Thread[# == Array[#1^#2 &, {#, #}]] &[3]