# Tag Info

22

Yes, there was a recently pushed incorrect paclet update that will cause this startup hang. All platforms can be affected, not just Windows. For a workaround, start a standalone kernel (WolframKernel.exe on Windows, WolframKernel in a terminal on Linux or Mac) and evaluate PacletUpdate["CloudObject"] which should allow a normal startup afterwards. It is ...

15

The memory leak in NIntegrate is a bug and has been fixed as of version 10.2.0. Earlier versions would lose around 720 bytes per evaluation for this example, which could not be recovered without restarting the kernel. ClearSystemCache[] should be used to make sure the memory is released. Using version 10.2: NI[z_?NumericQ, b0_?NumericQ] := ...

11

I have distilled a minimal dataset reproducing the problem: data = {{{45.904, 227.46}, {46.012, 222.72}, {46.076, 215.51}, {46.107, 206.26}, {46.119, 196.15}, {46.119, 186.97}, {46.118, 178.5}, {46.104, 168.16}, {46.079, 156.43}}, {{45.912, 212.72}, {45.976, 205.51}, {46.007, 196.26}, {46.019, 186.15}, {46.019, ...

8

I think you've found a bug in pattern matcher. This problem can be reduced to matching sequence of length one with named BlankSequence patterns in Orderless functions, it stopped working in v10.1. In previous versions your replacement rule works (as noted by belisarius). Minimal example of this behavior is: ClearAll[f, a] SetAttributes[f, {Orderless}] ...

8

I think there's a bug in the internal function NDSolveSPRKDumpCheckSeparability that leads NDSolve to conclude that the system is not separable. I think you should report it and see if WRI can verify it (they would probably appreciate a link to this Q&A). It's a fair amount of work to track it down, and there is a lot of nearly unreadable stuff to ...

7

Since there is really something wrong with the BezierCurve, I made this work-around: Clear[bezierCurve]; bezierCurve[pts_] := First@ParametricPlot[ BezierFunction[pts, SplineDegree -> Length[pts] - 1][t], {t, 0, 1}] Manipulate[ Graphics[{bezierCurve[pts], Dashed, Green, Line[pts]}, PlotRange -> {{-.5, 1.5}, {-.5, 1.5}}, Frame -> ...

6

The problem arises due to PiecewiseExpand operating inside TransformedDistribution, similarly to the following pw = PiecewiseExpand[f[Max[x, y], z]] (* Piecewise[{{f[x, z], x - y >= 0}}, f[y, z]] *) however this kind of transformation is not appropriate when f is TransformedDistribution pw /. {f -> TransformedDistribution, z -> {x ...

6

Restrict the domain to Reals $Version "10.2.0 for Mac OS X x86 (64-bit) (July 7, 2015)" eqn = 1/Sqrt[x] == x + 1/(Sqrt[2] + Sqrt[3]); sol = Reduce[eqn, x, Reals] // ToRules {x -> Root[1 - 10*#1^2 - 4*#1^3 + #1^4 + 20*#1^5 + 6*#1^6 - 10*#1^8 - 4*#1^9 + #1^12 & , 4]^2} eqn /. sol // FullSimplify ... 5 Erfc[-30. + 10^-1 I] used to return the result shown in the documentation through version 7.0.1. The implementation changed for version 8.0 and it started giving a machine precision answer (which is correct, more consistent and still demonstrates the same possible issue by being very close to 2). The (documentation) bug is that this example did not get ... 4 As noted in the comment by WRI staff, this is indeed a bug in the interplay between RandomVariate and the distribution at hand. The obvious workaround for now is to use UniformDistribution[{μ - Pi, μ + Pi}] for zero-concentration cases. 4 To upgrade my comment to an answer, and perhaps give some more background information: This bug has been fixed as of version 10.0.2. The crash happened in the libcurl library, which is being used in a separate thread via the HTTPClient package by the paclet manager at kernel startup to check for updates. It had to do with thread safety in certain ... 4 data = {{{45.904, 227.46}, {46.012, 222.72}, {46.076, 215.51}, {46.107, 206.26}, {46.119, 196.15}, {46.119, 186.97}, {46.118, 178.5}, {46.104, 168.16}, {46.079, 156.43}}, {{45.912, 212.72}, {45.976, 205.51}, {46.007, 196.26}, {46.019, 186.15}, {46.019, 176.97}, {46.018, 168.5}, {46.004, 158.16}, ... 3 This bug was speedily confirmed... Bug reported internally. Thank you! – ilian Aug 7 at 15:22 and fixed...internally at least Fixed in the development version. – ilian Aug 11 at 15:16 3 It doesn't work because your function returns Void and for some reason Compile can't handle that. If you cheat Mathematica and tell it that your function returns an Integer: add1NonVoid = LibraryFunctionLoad[add1lib, "add1", {{Real, 1, "Shared"}}, Integer]; a = {1., 2.} // DeveloperToPackedArray; add1NonVoid[a] (* 0 *) a (* {2., 3.} *) then it will ... 3 Confirmed by WRI (@ilian) as bug introduced in 10.1. 3 This bug has been fixed as of version 10.0.0. ToString[Infix[f[x, a]]] (* "x ~f~ a" *) OutputForm[Infix[f[x, a]]] (* x ~f~ a *) 3 It appears that HDF.exe crashes. This should not happen and I think this is a bug. On OS X I can reproduce the crash with M9.0, but not with M10.0 or later. On Linux I can reproduce the crash with M10.2 too. A possible workaround is to convert the file from HDF4 to HDF5 format. You could use the h4toh5 tool for this, which I installed using MacPorts. ... 2 The reason for this error is that NIntegrate uses fixed precision when computing the integration ranges, while EllipticK needs to raise the precision internally to obtain a good result. N[EllipticK[7/10], 20] (* 2.0753631352924691439 *) Block[{$MinPrecision = \$MaxPrecision = 20}, N[EllipticK[7/10], 20]] (* Divide::infy: Infinite expression ...

2

To fix this problem on Mma 10.1 on OS X 10.10.4 I took off one of the blanks on term, i.e. ReplaceAll[a.b.c.d + a.ss.e.g.r + Transpose[a.b.c.d], {Plus[front___, term__, middle___, Transpose[term__], end___] :> Plus[front, middle, end, 2*term]}] a.b.c.d + a.ss.e.g.r + Transpose[a.b.c.d] ReplaceAll[a.b.c.d + a.ss.e.g.r + Transpose[a.b.c.d], ...

2

This is surely a bug. The misbehavior certainly persists through V10.2. In fact, the two images below are of the same computation. The only difference is where they appear on the screen (as I scrolled the notebook, the transformed red disk jumped around). μ = 0.16255558520216132 + 0.1849493244071408 I; pic[τ_] := Block[{d, ds, arc}, d = Disk[{0, ...

2

On v10.0.0, In[1]:= FindInstance[(c3 != 0 || c2 != 0) && c1 == 0 && -c2 == 0, {c1, c2, c3}] Out[1]= {{c1 -> 0, c2 -> 0, c3 -> 1}}

2

Just as a complementary and extended comment and as was recently observed in a related post, you get exactly the same problem if, not surprisingly, you use geometric transformation functions instead: Given the initial object to transform: circles = {Circle[{0, 0}, 1], Circle[{0, 0.5}, 0.5]}; the OP transformation: t1 = Rotate[Scale[circles, 12], -45 ...

1

I've stumbled a workaround by specifying a "direction vector" through the Text function instead of through Rotate: Show[Plot[x, {x, 0, 1}], Graphics[{Text["test", {0.5, 0.5}, Automatic, {1, 0.5}]}]] Export["~/tmp.pdf", %]

1

I also think this is a bug, but at least there is a way out: realQ[x_] := Im@x == 0 && (Re@x >= 0 || Re@x < 0) (*or just Im@x == 0 if you aren't suspicious *) {Reduce[Exists[x, x^3 == 1, Not[realQ@x]]], Reduce[ForAll[x, x^3 == 1, realQ@x]], Reduce[ForAll[x, x == 1, realQ@x]]} (* {True, ...

1

As indicated in the comments, this bug has been fixed as of version 10.0.2. See also these other questions: (58799), (86891), (72750) and (90054).

1

Just another way to calculate volume of hypersphere and then relevant probability using recursion: vs[n_] := Most@Nest[{#[[2]]/(#[[3]] + 1), 2 Pi #[[1]], #[[3]] + 1} &, {1, 2, 0}, n] v[n_] := vs[n][[1]] The probabilities: Grid[Prepend[{#1, #2, N@#2} & @@@ ({#, v[#]/2^#} & /@ Range[10]), Style[#, Bold] & /@ {"n", ...

1

As indicated in the comments, this has been fixed as of version 9.0.0. lst = {{a1, a2}, {b1, b2}, {c1, c2}}; Derivative[1][lst[[1]] + #*(lst[[2]] - lst[[3]]) &] (* lst[[2]] - lst[[3]] & *)

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