Tag Info

New answers tagged

4

This gives a slight speed up (~40%) for me: stepcp = Compile[{{m, _Complex, 2}, {u, _Complex, 2}, {n, _Integer}, {l, _Real}}, Block[{ m2 = ConjugateTranspose@m, x = u, ut = Flatten@Transpose@u}, Join[{1.0}, Table[x = m.x.m2; Flatten[x].ut, {i, n - 1}]/(2 l)]]] I replaced the NestList with a more procedural approach, calculating the trace of the ...


2

Sorry, I don't know. Have you tried compiling to C? One point: you should define stepcp with Set (=) rather than SetDelayed (:=) or you recompile it every time you use it. SparseArray is a specialized format of the high-level Mathematica language. It is not supported by compilation. Many operations are optimized to work on sparse arrays, saving ...


6

Without a more complete example of your function all I can offer are bare guidelines to (hopefully) point you in the right direction. The first level is merely syntactical; you would use OptionsPattern, OptionValue etc., in a high level function simply for convenience, but pass all arguments as machine types to an inner compiled function. A second level is ...


2

As @RunnyKine comments, String arguments cannot be compiled. From the documentation: The types handled by Compile are: _Integer machine‐size integer _Real machine‐precision approximate real number (default) _Complex machine‐precision approximate complex number True | False logical variable


4

This is inspired by my recent answer to Save a C compiled function without losing the blessing of C compiler. The key point here is to retain the {Listable} attribute of the compiled function. This is difficult as this attribute is stored in the Mathematica definition of the function, rather than the compiled C code, so neither Export/DumpSave or ...


13

It appears that LibraryFunction occurs if the function being called inside the other compiled function is a function that has been compiled to C, provided this function has been called with the right type of arguments. It seems that in other cases there is a CompiledFunctionCall. As pointed out by Simon Woods in the comments below, there is a type mismatch ...


13

Yes, there is! Mathematica creates a LibraryFunction when compiling to C, but puts it in a temporary directory. If you can recover the library, you can load it as often as you like! First let's define the function as in the question: generatef[opt_] := Compile[{}, Module[{j = 0}, Do[j++, {i, 10^8}]; j], CompilationTarget -> opt]; f2 = generatef["C"]; ...


2

No fair, you let NIntegrate see the symbolic form of the native expression. If you do the same trick: f3[x_?NumericQ, y_?NumericQ, z_?NumericQ] := g[x, y, z]; NIntegrate[g[x, y, z], {x, 0, 100}, {y, 0, 10}, {z, 0, 9}] // Timing NIntegrate[f2[x, y, z], {x, 0, 100}, {y, 0, 10}, {z, 0, 9}] // Timing NIntegrate[f3[x, y, z], {x, 0, 100}, {y, 0, 10}, ...


1

With RuntimeOptions -> "EvaluateSymbolically" -> False and Evaluate you don't need an intermediate function and get 3x speedup: f = Compile[{{x, _Real}, {y, _Real}, {z, _Real}}, g[x, y, z]]; f2[x_Real, y_Real, z_Real] := f[x, y, z]; f3 = Compile[{{x, _Real}, {y, _Real}, {z, _Real}}, Evaluate@g[x, y, z], RuntimeOptions -> ...


3

Here are some reasons or surmises: I believe some functions are special-cased in NIntegrate; I'm pretty sure this is true for low-degree polynomials. To get the advantage of compiling, use f = Compile[{{x, _Real}, {y, _Real}, {z, _Real}}, Evaluate@g[x, y, z]], but it will still be slower than just using g. Without the Evaluate, the compiled function makes ...


2

According to a comment by @ilian, this has been fixed as of version 10.0.0. It certainly works in version 10.1, as we can see below: $Version (* 10.1.0 for Linux x86 (64-bit) (March 24, 2015) *) fC[randomdata] == (fC /@ randomdata) (* True *) totalC /@ randomdata totalC[randomdata]


6

It happens because Compile cannot infer the types returned by the subsidiary functions enn and fF. In the second approach, you partially solved this by specifying it manually for enn. In principle you could have done that in the first approach as well if you had specified it for fF too, but in practice getting the type inference to work out correctly is not ...


6

While I'm not sure why the error you see is generated, you can fix your sumT function by taking the fF call out of the Map form: sumT = Compile[ {{tab, _Real, 2}}, Total[fF /@ Map[enn[#[[1]], #[[2]]] &, tab]], CompilationTarget -> "C"]; This worked fine for me in version 10.1 of Mathematica: sumT[tab] // AbsoluteTiming (* ==> {0.000667, ...


2

It happens quite often that compilation of a correctly running Mathematica function for some or other reason fails. The reason for that is not always easy to trace. After some testing I feel that the problem you ran into is close to a bug. First let us further simplify your problem, showing the same warnings: fc=Compile[{}, Block[{mat}, mat=Array[1&, ...


0

This generates all primitive pythagorean triples: pythT[triple_] := triple.# & /@ {{{1, 2, 2}, {-2, -1, -2}, {2, 2, 3}}, {{1, 2, 2}, {2, 1, 2}, {2, 2, 3}}, {{-1, -2, -2}, {2, 1, 2}, {2, 2, 3}}} pythT2[triples_] := Join[Flatten[pythT@# & /@ triples, 1], triples] pythN[n_] := Join[{{3, 4, 5}}, DeleteDuplicates[Sort@Nest[pythT2, pythT@ {3, 4, 5}, ...


1

The thing to do is to compare lots of different options and see what comes out. Ultimately what you're doing is taking the FullForm of this object: $Version (* 10.1.0 for Linux x86 (64-bit) (March 24, 2015) *) FullForm[Compile[{{x, #}}, x]] & /@ {_Real, _Integer, _Complex} This returns List[10, 10.1, 5468] for all 3 cases, so I would guess at 10 ...



Top 50 recent answers are included