Hot answers tagged

14

The default SumCompileLength is 250. You can increase this number for example to 500 using SetSystemOptions["CompileOptions" -> {"SumCompileLength" -> 500}] or to infinity using SetSystemOptions["CompileOptions" -> {"SumCompileLength" -> ∞}] What is "SumCompileLength" for? For sums with a finite number of at least "SumCompileLength" ...


13

There are a couple of issues at play. One is that the implementation of Total has changed, and it is now using several threads in parallel. Furthermore, there are platform-specific differences in how Timing works. On Windows, it will only measure the CPU time used by the main kernel thread, excluding any subthreads. On Linux, and I believe OS X, it will ...


11

This is a common limitation experienced in versions prior to 9. As Oleksandr explains: Are you by chance using Mathematica 8? Integers were based on 32-bit machine values in previous versions, and this was changed to 64-bit only in version 9. As a result, Range[2^31, 2^31 + 1] returns a packed array only in the most recent version. Fold automatically ...


10

I think this may be a duplicate of: How to avoid unpacking from Language`ExtendedFullDefinition In Mathematica parallelism is only useful when processing takes longer than data transfer, otherwise the overhead of that transfer will make the parallel operation slower than the plain one. It should be somewhat faster than your original use of ParallelMap, but ...


9

I believe the difference you are observing is attributable to packed arrays. What is a Mathematica packed array? The difference between slow and fast is due to the behavior of RandomChoice. Observe: << Developer` RandomChoice[{pr1, 1 - pr1} -> {1, 0}, 1350] // PackedArrayQ RandomInteger[1, 1350] // PackedArrayQ ...


9

ord = 9; Timing[d1 = Table[D[y[x, v], {v, i}], {i, 0, ord - 1}];][[1]] (* 2.06537 *) Rather than using Table, mapping onto a Range is often more efficient Timing[ d12 = D[y[x, v], {v, #}] & /@ Range[0, ord - 1];][[1]] (* 2.03747 *) For a fair timing comparison, the initialization of the array should be included in the timing Timing[ ...


8

What about timer[s_] := Dynamic[s - Clock[{0, s, 1}, s, 1]]


7

The progress cell that you see when you load data from the Wolfram server is a "PrintTemporary" cell. The following example is based on what is used by Mathematica to print these cells. You can modify and adapt this to suit your use. monitorCell[i_] := CellPrint@Cell[ BoxData[ FrameBox[StyleBox[ToBoxes@StringForm["Progress: `1`", i], ...


7

This is just a comment with code. Here is a very simple multithreaded compiled function (not a sum calculation) to prove that the issue has nothing to do with Total specifically, but is a more general (and unfortunate) issue with Timing: fc = Compile[{{x, _Real, 0}, {n, _Integer, 0}}, Block[{y = x}, Do[y = Tan[y], {n}]; y], Parallelization -> True, ...


6

To demonstrate the time saving using a linked list instead of AppendTo :- time1[myN_] := First@Timing[ finalList = {}; For[i = 1, i <= myN - 3, i++, For[j = i + 1, j <= myN - 2, j++, For[k = j + 1, k <= myN - 1, k++, l = RandomInteger[{k + 1, myN}]; AppendTo[finalList, {i, j, k, l}]]]]]; time2[myN_] := First@Timing[ ...


6

This isn't the most exciting example but I hope it helps. Use AbsoluteTiming to time the function and use Table to iterate over a set of values. We're simply going to time the Pause function which just waits x seconds, in this case x^2. The values will be stored as list. First gives us the first element of the output of AbsoluteTiming which is the time ...


6

I am not sure PrintTemporary doesn't do your job Module[{pTmp, etc}, pTmp = PrintTemporary["bla"]; Pause[3];(* do your stuff *) NotebookDelete[pTmp]; PrintTemporary["blo"]; Pause[2] (*do more stuff*) ] Your function would be something like SetAttributes[DynamicDisplayFunction, HoldFirst]; DynamicDisplayFunction[code_, message_] := Module[{tmp = ...


6

Your question are impossible to answer in detail. Let my try anyway: a) No one can tell you the exact reason of the different timings on your machine. You should keep in mind that it is very possible, that one run of your computation has side-effects you are not aware of. One obvious example for such a behavior can be demonstrated when you try this on a ...


6

Fred's answer explains why Timing is a poor indicator of how much internal computation is taking place. This is an extended comment to point out that the real timing differences you see are just due to the different arithmetic problem in each case. Note that the inverse of your integer matrix is a matrix of rationals with large numerators and denominators. ...


5

You need your evaluations to take enough time for this to display. For example this works fine for me: DynamicModule[{tmp}, Monitor[ tmp = First @ Import["http://www.census.gov/foreign-trade/balance/country.zip", "*"], Grid[{{"imported data being downloaded..."}}, Frame -> All, FrameStyle -> Darker[Blend[{Blue, Green}], .1], ...


5

If you don't want to change the system options just to make Sum auto-compile, then you could instead replace Sum by Total: Clear[vec, time]; vec = Table[i, {i, 100}, {j, 100}, {k, 300}]; time = Timing[ Table[Total[vec[[i, j, 1 ;; 250]]], {i, 1}, {j, 1}]][[1]]; time The resulting timing doesn't show any significant difference between 249 and 250, and is ...


5

Update The original approach for one ellipse (below) may be adapted for several: eq = With[{p = {x, y} - {x0, y0}}, (RotationMatrix[-t0].p).{{1/a^2, 0}, {0, 1/b^2}}.(RotationMatrix[-t0].p)] - 1; sub[pt_] := Thread[{x, y} -> pt]; dir[t0_] := {Cos[t0], Sin[t0]}; ClearAll[next, cuts]; Block[{a, b, t0, x0, y0, x1, y1, α, x, y, t, ellipses}, next = ...


5

As suggested by LLlAMnYP in a comment to this question, this is a humble contribution. The OP has already been answered. This is not answer per se but shows that CompileLength should not always be increased, and should even sometimes be reduced for significant speed gain. Consider the following (stupid) function: x1 = Function[{n, T, t}, (Table[Cos[(Mod[t, ...


4

Change to delta := Module[{y}, NDSolve[{y''[n] + y'[n] - y[n] == 0, y[-3] == 1, y'[-3] == 1}, y, {n, -3, 0}]] This is a possible bug.


4

According to Leonid Shifrin recommendation: Put your Mathematica session in debug mode by going to Evaluation->Debugger F[x_] := Total[DigitCount[Mod[(2^10000) + 1, Prime[x]]]] Table[F[x], {100000}]; // RuntimeTools`Profile


4

When calculating indefinite integrals Mathematica does not care about the convergence in a domain {x_min,x_max}. In case of definite integrals, at times it is necessary to provide information on the constants in order to obtain the proper result. Check the tutorial on definite integrals. The example with 1/(1 + a Sin[x]) is very similar to your problem.


4

I found a certain improvement using WolframAlpha. To get the rates for the last 20 days I wrote: GetRates[c1_, c2_] := With[{rt = WolframAlpha["Exchange rate " <> c1 <> " " <> c2, {{"History", 1}, "FormattedData"}]}, Round[#, 0.01]& @ Take[Cases[rt, {DateObject[__], a_Real} :> a/100, Infinity], -20]] GetRates["USDollars", ...


4

list = SparseArray[# -> 1 & /@ {4, 5, 10, 11}, 20]; pos = {{1, 5}, {10, 11}, {15, 20}}; tstFunc[pos_, lst_] := Pick[pos, Sign@Total@lst[[Span@##]] & @@@ pos, 1] tstFunc[pos, list] {{1, 5}, {10, 11}}


4

It seems to me that your results have to do more with strange behaviour of Timing than with Module. See the answers on my question here for more information. In absolute timings, the results are as expected. I included also Nasser's modification. Here are the definitions: mat1=RandomInteger[{-100,+100},{200,200}]; mat2=RandomInteger[{-100,+100},{200,200}]; ...


3

Plot on its own does not take much CPU, added some dummy computation and count of how many refreshes has happened to make it more interesting. Is this what you meant? You do not wrap Timing around the whole of Manipulate. To measure the CPU taken for each Manipulate refresh of its expression, which happens each time a control dynamic changes, just make a ...


3

Timing under 20 seconds on my computer now. Ok, your original program took about 60 seconds on my computer meaning that my computer is faster. The dramatical gain of time is due to halfing the MaxRecursion option value. The plot still shows no visible difference. I replaced Pi-Symbol by Pi for increasing readability in forum. I tested some scenarios, and ...


3

I think that ParallelMap has bad implementation of the data distribution between kernels. However if computation of f takes a long time there is some speedup (tested on Core2Duo) LaunchKernels[]; f[x_] := Nest[Sin, x, 1000]; test = N@Range[100000]; Map[f, test]; // AbsoluteTiming ParallelMap[f, test]; // AbsoluteTiming {5.813099, Null} ...


3

I'm going to step out on the limb and answer re: what is almost certainly the "problem" - you are repeatedly evaluating to the same result, an aspect of recursive functions, so you're creating excess work. By example of Fibonacci numbers: fib[1] = 1; fib[2] = 1; fib[n_] := fib[n - 1] + fib[n - 2]; fib[5] // Timing fib[30] // Timing (* {0., 5} ...


3

This has been fixed in 10.0.2. The longer time now remain in the status windows. On windows 7, 64 bit SetOptions[$FrontEnd, EvaluationCompletionAction -> "ShowTiming"] Plot[{BesselJ[1, x], BesselJ[2, x]}, {x, 0, 10}, PlotPoints -> 1*^5, Filling -> {1 -> {2}}]



Only top voted, non community-wiki answers of a minimum length are eligible