If I want to do the following:
getCH[pts_List] := Module[{t}, t = ConvexHull[pts]; Map[Part[pts, #] &, t]];
or
Map[Function[{x}, Part[#, x]], ConvexHull[#]]&
What are other ways to write this? And how do you normally do for speed and efficiency?
Edit
BTW, I am asking this in a generic way, not for this particular problem. I sometimes feel the lack of brain power to think in terms of functional programming in mma. Just want to expand my arsenal with various other ways to write function compositions and learn the analysis of their complexity/efficiency. So please add similar problems.
I don't know what a ConvexHull is but I'll assume I understood the problem
getCH[pts_]:=pts[[ConvexHull[pts]]]
getCH[pts_]:=Extract[pts, Transpose#{ConvexHull[pts]}]
If you want pts to appear only once for some reason you could always use With, Module or Block. I think most important is to say that I don't see the point in doing that. With, effectively replaces each appearance of pts with the list of points. Seems like an overkill for this but feel free to write
getCH[pts_]:=With[{p=pts},p[[ConvexHull[p]]]]
Module creates a new variable. It's usually slower than With for cases in which your variable doesn't need to be asigned a value. In other words, With is faster for defining constants. Block I think is also faster than Module (slightly) but its dynamic scoping (against Module's lexical scoping) makes it a little bit weirder. Lots of threads about these.
I don't think there's any built-in function that takes a list and a function or symbol, and extracts elements on that list indexed by the result of evaluating the function on that same list, if that's what you were looking for for your "generic" problem. Of course you can create one easily and then use it in the future. I think it's too much for such a simple issue but perhaps its the functional programming you were aiming for
ExtractIndexed[l_List, fun_]:=l[[fun[l]]]
getCH[pts_]:=ExtractIndexed[pts, ConvexHull]
You can initialize variables in a Module like this
Module[{t = ConvexHull[pts]}, Map[Part[pts, #] &, t]]
But in this case, you aren't redefining t, so it is a local constant and you are better off using With.
With[{t = ConvexHull[pts]}, Map[Part[pts, #] &, t]]
Or just
Map[Part[pts, #] &, ConvexHull[pts] ]
Or
Part[pts, #] & /# ConvexHull[pts]
This question is related: Using nested slots. It is not recommended to nest pure functions without naming variables.
You could “invert” your function like so, but I can't guarantee it works.
Function[x,Part[#,x]]& /# ConvexHull[#] & # pts
Perhaps try using Through:
Part ## Through[
List[ Identity, Graphics`Mesh`ConvexHull][{{0, 0}, {1, 0}, {.5, .5}, {1, 1}, {0, 1}}]
]
This one gives a warning (because Part evaluates), but then 'works':
Through[
Part[Identity, Graphics`Mesh`ConvexHull][{{0, 0}, {1, 0}, {.5, .5}, {1, 1}, {0,
1}}]]
I think this is a way around the Part evaluating issue above:
Through[
Unevaluated[
Part[
Identity, Graphics`Mesh`ConvexHull][
{{0, 0}, {1, 0}, {.5, .5}, {1, 1}, {0, 1}}
]]]
Related
I need to perform several operations, each of which takes several hours to complete when run one at a time. Since I have 8 cores, I should be able to run them all at once instead of one after the other. However, I cannot find a way to instruct mathematica either to run them separately automatically or to run each on core X, with me manually setting where they go so they don't overlap. These are completely separate functions that just happen to need to run at once, not any type of group of similar operations such as seen in the documentation examples for parallelism (In this case, the function are a bunch of complicated unrelated symbolic integrals, but the answer will be of more general use if it is non-specific).
It depends somewhat on what you are doing, but generally you can use a command like Parallelize, ParallelTable, ParallelEvaluate etc. In the ParallelEvaluate command, you have the option to specify the kernel.
You can compare in a very basic way these three:
Clear[a]
a[n_] := a[n] = RandomInteger[10^75]; (*Adjust exponent at your discretion*)
Timing[FactorInteger /# Table[a[n], {n, 1, 4}]]
Timing[Parallelize[FactorInteger /# Table[a[n], {n, 1, 4}]]]
%[[2]]==%%[[2]]
If you were to use ParallelEvaluate, you would be launching Kernels that function independently (which would make the above head-to-head comparison a bit trickier).
So, for your application, you might have something like this:
h[n_][x_] := Integrate[E^t*t^n, {t, 0, n x}]
Timing[Table[FullSimplify[h[n][x]], {n, 1, 10}]]
Timing[ParallelTable[FullSimplify[h[n][x]], {n, 1, 10}]]
Even in this simple example, you can see quite a speed-up.
Given some list
numbers = {2,3,5,7,11,13};
How do I translate this to
translatedNumbers = {{1,2},{2,3},{3,5},{4,7},{5,11},{6,13}}
concisely?
I am aware of how to do this using the procedural style of programming as follows:
Module[{lst = {}, numbers = {2, 3, 5, 7, 11, 13}},
Do[AppendTo[lst, {i, numbers[[i]]}], {i, 1, Length#numbers}]; lst]
But such is fairly verbose for what seems to me to be a simple operation. For example the haskell equivalent of this is
numbers = zip [1..] [2,3,5,7,11,13]
I can't help but think that there is a more concise way of "indexing" a list of numbers in Mathematica.
Potential Answer
Apparently I'm not allowed to answer my own question after having had a lightbulb go off unless I have 100 "rep". So I'll just put my answer here. Let me know if I should do anything differently then I have done.
Well I'm feeling a little silly now after having asked this. For if I treat mathematica lists as a matrix I'm able to transpose them. Thus an answer (perhaps not the best) to my question is as follows:
Transpose[{Range#6, {2, 3, 5, 7, 11, 13}}]
Edited to work for arbitrary input lists, I think something like:
With[{lst={2, 3, 5, 7, 11, 13}},Transpose[{Range#Length#lst,lst}]]
will work. Could I do any better?
One thing to consider is if the transformation will not unpack the data. This is important for large data sets.
On["Packing"]
numbers = Developer`ToPackedArray#{2, 3, 5, 7, 11, 13};
This will unpack
MapIndexed[{First[#2], #1} &, numbers]
this will not
Transpose[{Range[Length[#]], #}] &[numbers]
Off["Packing"]
I would use MapIndexed instead
MapIndexed[{First[#2], #1} &, numbers]
Well, my „solution“ is perhaps not as smart as the solution from cobbal, but when I test it with long arrays, it is faster (factor of 5!).
I am simply using:
newList = Transpose[{Range[Length[numbers]], numbers}]
AHH! ruebenko posted a similar answer during I have written my post. Sorry for this almost superfluous post. Well, perhaps it is not so superfluous. I have tested my solution with and without packing, and it works at fastest without packing.
g1=Graph[{UndirectedEdge[a,b]}];
GraphQ[g1]
(*
OUT: True
*)
(*Needs["Combinatorica`"]*)
PlanarQ[g1]
(*
OUT: PlanarQ[.-.]
*)
Combinatorica`PlanarQ[g1]
(*
OUT: Combinatorica`PlanarQ[.-.]
*)
Why doesn't PlanarQ give back "True" or "False" ?
Your graph is not a Combinatorica graph, rather it is a System graph. You'll need to specify the contexts explicitly.
Needs["GraphUtilities`"];
g1 = System`Graph[{UndirectedEdge[a, b]}];
Combinatorica`PlanarQ[
GraphUtilities`ToCombinatoricaGraph[g1]]
This returns True but, in general, this process is a pain and rather buggy. I believe that Combinatorica is on the way out and I'd recommend trying to get by without.
You probably need:
Needs["GraphUtilities`"]
Needs["Combinatorica`"]
cg1 = ToCombinatoricaGraph[g1];
PlanarQ[cg1]
I don't have v8 to check, however.
Just a note, Combinatorica is on the way out. However, three months ago a lead on the Graph project told me there were no plans to re-implement algorithm specific interfaces like BrelazColoring for System Graph. So, some things may need Combinatorica for a while, and one way to deal with this is to try to use System'Graph for everything, keep Combinatorica out of package path, and get to Combinatorica functions by explicitly converting your Graph objects to Combinatorica'Graph objects, calling Combinatorica`function and then converting back to system graph. Here is some discussion with the details
For posterity, here's the relabelGraph function I use to solve the ordering issue reported by TomD,
relabelGraph[g_Graph,labeling_]:=Module[{vcoords,gstyle,labelMap,adjMat,newOrder,newCoords,verts},
verts=VertexList#g;
vcoords=VertexCoordinates/.AbsoluteOptions[g,VertexCoordinates];
gstyle=GraphStyle/.AbsoluteOptions[g,GraphStyle];
labelMap=Thread[Range[Length[verts]]->labeling];
adjMat=Normal#AdjacencyMatrix[g];
newOrder=Ordering[VertexList[g]/.labelMap];
newCoords=Thread[(VertexList[g]/.labelMap)->vcoords];
AdjacencyGraph[adjMat[[newOrder,newOrder]],VertexCoordinates->newCoords,GraphStyle->gstyle]
];
One way of using it is below. This produces result similar to IndexGraph, but with sorted VertexList
g=relabelGraph[g,Range#Length#VertexList#g];
Some other of my "annoyance fixing" functions are described in graphUsage.nb in the package here
This is also just a note.
I want to specifically draw attention to a possible bug in ToCombinatoricaGraph and a possible workaround. It may have no relevance to the original question.
Also, I am using Mma 7, so things may be fixed in v8.
If I define a graph as follows
Needs["Combinatorica`"]
Needs["GraphUtilities`"]
gr1 = {2 -> 4, 4 -> 3, 3 -> 1}
GraphPlot of gr1
Compare the following:
EdgeList#gr1
EdgeList#ToCombinatoricaGraph#gr1
Edges#ToCombinatoricaGraph#gr1
Output
{{2, 4}, {4, 3}, {3, 1}}
{{1, 2}, {2, 3}, {3, 4}}
{{1, 2}, {2, 3}, {3, 4}}
The workaround I use is to ignore, as far as is possible, ToCombinatoricaGraph and instead convert to a Combinatorica graph using FromOrderedPairs.
For example
Edges#FromOrderedPairs#EdgeList#gr1
EdgeList#FromOrderedPairs#EdgeList#gr1
Output
{{2, 4}, {4, 3}, {3, 1}}
{{2, 4}, {3, 1}, {4, 3}}
Another example, Degrees
Compare
Degrees#MakeSimple#ToCombinatoricaGraph[gr1]
VertexList#MakeSimple#ToCombinatoricaGraph[gr1]
Output
{1, 2, 2, 1}
{1, 2, 3, 4}
with
Degrees#MakeSimple#FromOrderedPairs#EdgeList#gr1
VertexList#MakeSimple#FromOrderedPairs#EdgeList#gr1
{1, 1, 2, 2}
{1, 2, 3, 4}
I'll also include an example with Prufer codes, as here I was badly 'caught out' (I did not know about SO then)
LabeledTreeToCode#MakeSimple#ToCombinatoricaGraph#gr1
LabeledTreeToCode#MakeSimple#FromOrderedPairs#EdgeList#gr1
Output
{2, 3}
{3, 4}
(Only the second answer is correct)
I have reported this to Wolfram. Seemingly, it is connected to reordering of vertices on graph creation by ToCombinatoricaGraph. Here is part of the reply (2009)
The reason that Edges and EdgeList
don't function on ToCombinatoricaGraph
objects because the Combinatorica package was developed prior to these
functions, and the structure hasn't yet been adapted to operate
with these
functions.
Our development team is currently working to update the Combinatorica
package so that these functions will be compatible. If you happen to
run
across any other issues, or have any questions come up, please do let
me
know.
In my view, ToCombinatoricaGraph needs to be used with care (and avoided whenever possible). However, there are probably many cases (including the uses given in other answers to the original question) where it makes no difference.
Personally, I would not like to see the Combinatorica package go. It contains many useful functions (if very badly documented).
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]
The mathematica documentation on Evaluate at possible issues says:
Evaluate works only on the first
level, directly inside a held function
Why does Mathematica have this limitation? So if I have an expression with more than one level take this simplified example:
Hold[Plus[Plus[2, 2], 2]]]
Now suppose I want to see what the answer is to the the second Plus, without evaluating anything on levels below it. I've tried different things such as:
In[290]:= Hold[Plus[Evaluate[Plus[2, 2]], 2]]
Out[290]= Hold[Evaluate[2+2]+2]
In[287]:= Hold[Plus[ReleaseHold[Hold[Plus[2, 2]]], 2]]
Out[287]= Hold[ReleaseHold[Hold[2+2]]+2]
The first Hold keeps everything unevaluated at and beyond the first level in this case.
The goal is to control evaluation of an expression at each stage from the most inner nested function to the outer one using successive Hold, ReleaseHold and Evaluate functions to achieve that. I know I could use trace to see what happens beyond level one in an expression but that is different and sometimes complex to read with longer expressions.
It seems like the only way is to extract and totally dismantle the expression into lists using Extract, Part or Level; evaluate part of the expression that I want; then reconstruct and re-map the expression back together for each stage. Are there any other approaches or functions for achieving this I could consider?
Edit: This might be a better example to look at the approach of releasing the first hold. With the expression:
Hold[Plus[Plus[2, Plus[2,2]], 2]]]
If you release the first hold and place a hold on a higher level in a expression at the third Plus, to look like this:
in = Plus[Plus[2, Hold[Plus[2,2]]], 2]]]
out = Hold[2+2]+4
You find that Mathematica will evaluate lower levels in the background when you really want it to wait.
I can't give the exact reason why Evaluate "works only on the first level, directly inside a held function" but I suspect it's partly efficiency, in that it would be slow if the evaluator had to scan the complete expression tree of held arguments passed to any function with a Hold* attribute for nested Evaluate expressions and evaluate them, and then recurse and look for Evaluate subexpressions in what it just evaluated, all while keeping the rest of the expression unevaluated, especially when this might not always be what you want to happen anyway.
Doing what you want is pretty easy using a combination of Extract and ReplacePart though:
In[51]:= expr = Hold[Plus[Plus[2, 2], 2]];
In[52]:= ReleaseHoldAt[expr_, partspec_] :=
ReplacePart[expr, partspec -> Extract[expr, partspec]]
In[53]:= ReleaseHoldAt[expr, {1, 1}]
Out[53]= Hold[4 + 2]
This lets us illustrate another reason why it might not make sense for Evaluate to work at any level in an expression passed as an argument to a function with a Hold* attribute, considering the following expression involving i:
In[82]:= i = 1;
In[83]:= ReleaseHoldAt[Hold[i = 2; j = Plus[i, i]], {1, 2}]
Out[83]= Hold[i = 2; 2]
Note that the value of j would have been 4 if we had evaluated the first part of that expression before the Plus, but the results are different since we are only doing partial evaluation, and i=2 had not been evaluated when we evaluated the subexpression setting j. Sometimes, this may be what you want to happen, but often it is very likely not.
Keep in mind that even Evaluate in the first level can be defeated by a function that has the attribute HoldAllComplete or by using HoldComplete:
In[62]:= Hold[Evaluate[Plus[2,2]]]
Out[62]= Hold[4]
...versus:
In[63]:= HoldComplete[Evaluate[Plus[2,2]]]
Out[63]= HoldComplete[Evaluate[2+2]]
Finally, the output of Trace can be a little dense, but you can filter out what you want by using patterns or symbols of interest in the second argument:
In[88]:= Trace[Plus[Plus[Plus[1,2],3],4],Plus]
Out[88]= {{{1+2,3},3+3,6},6+4,10}
In[93]:= Trace[Plus[Subtract[Plus[1,2],4],8],_Plus]
Out[93]= {{{1+2}},-1+8}
HTH!
As is so often the case when you want to do something tricky in Mathematica, pattern matching and rule replacement come to the rescue. However, in this instance, you have to do something weird, and you have to use Replace instead of ReplaceAll (the /. operator) so you can take advantage of its optional third argument to give it a level specification. Using the example you offered:
In[1]:= Replace[
Hold[Plus[Plus[2, 2], 2]],
expr_Plus :> With[{eval = expr}, eval /; True],
{2}]
Out[1]= Hold[4 + 2]
The useless-looking
expr_Plus :> With[{eval = expr}, eval /; True]
rule is actually a documented way to share local variables between the test match and the body of the With structre; here you don't do anything with the local variable but force its evaluation in a roundabout way---because less roundabout ways won't work!
EDIT to add: I think you're mis-interpreting the result of Level; the two expressions at level {2} of this expression are 2 and Plus[2, 2]; you can see this by using the optional third argument to level, which does something similar to the optional third argument of Extract:
In[2]:= Level[Hold[Plus[Plus[2, 2], 2]], {2}, Hold]
Out[2]= Hold[2 + 2, 2]
With the {2} level spec, Replace will try to match-and-replace the rule against these two expressions, and it will work on the second one.
A technique which does not involve Extractis to wrap the parts inside Hold in inner Holds, and then release the outer Hold:
expr=Hold[(1+2)+3];
ReleaseHold#Map[Hold,expr,{2}]
Out[2]= Hold[3]+Hold[1+2]
You can play various games in this direction, but since I can't tell what it is you want to do, it is a bit hard to be specific. Something that might be useful is to define your own Hold that descents however you want it to:
SetAttributes[DescentHold,{HoldAll}]
DescentHold[a_Plus]:=ReleaseHold#Map[DescentHold,Hold[a],{2}]
DescentHold[a_]:=Hold[a]
Note that this one approaches the outer Holds once the insides are wrapped, so that for instance the flatness of Plus kicks in:
DescentHold[2*3+(4+5)]
Out[4]= Hold[4]+Hold[5]+Hold[2*3]
Using the idea about ReplacePart and Extract functions from the answer by Michael Pilat, one can write HoldAndEvaluate function, which allows him to evaluate a desired part of the expression without the need to calculate its position (it can be marked with "MyEvaluate").
In[1]:= expr = Hold[MyEvaluate[2 + 2] + 2];
In[2]:= HoldAndEvaluate[expr_] :=
ReplacePart[expr,
# -> Evaluate ## Extract[expr, #] & /#
Position[expr, MyEvaluate[_]] ];
In[3]:= HoldAndEvaluate[expr]
Out[3]= Hold[4 + 2]