Tag Info

New answers tagged

2

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 ...


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.} // Developer`ToPackedArray; add1NonVoid[a] (* 0 *) a (* {2., 3.} *) then it will ...


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 ...


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", %]


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. ...


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 ...


13

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] := ...


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}}


0

It seems that for some reason all Integer values are converted to Real in the environment in which the autoload process takes place, therefore the value of $SystemWordLength is changed to a Real which breaks the path. I have been unable to figure out the source of the Integer to Real conversion and therefore I do not know what else it may affect, but I can ...


3

Confirmed by WRI (@ilian) as bug introduced in 10.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 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, ...


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], ...


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 NDSolve`SPRKDump`CheckSeparability 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 ...


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 ...


0

This bug has been fixed as of version 10.0.2. See also these other questions: (58799), (60408), (72750) and (90054).


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", ...


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 -> ...


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]] & *)


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.


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 ...


7

To me this looks like a bug. A possible workaround is to use ProbabilityDistribution together with the PDF of the VonMisesDistribution: SeedRandom[1] RandomVariate@ProbabilityDistribution[PDF[VonMisesDistribution[0, 0], x], {x, -∞, ∞}] $\ $ 1.99422 This bug is caused by the evaluation of Statistics`NormalDistributionsDump`compiledvonmisesrandom[0, 0, ...


3

As indicated by Michael E2's edit, this crash has been fixed as of version 10.1.0. f[xs_?(VectorQ[Flatten[#], NumericQ] &)] := {{Sin[xs[[1, 1]]]}}; Last @ Table[FindRoot[f[{{x}}] == {{x}}, {x, 0.3}], {1000}] // InputForm (* {x -> 1.9942762963668195*^-8} *)


6

tl;dr I think it's a memory leak (bug) and you should report it to Wolfram Support (please do!) According to my reading, you were saying that after importing JSON files many times, the kernel memory usage reported by the operating system (or some task manager program) was growing to unreasonable levels. However, the memory usage reported by the kernel ...


0

Interested to know how this DE arises. Note that you can also use ParametricNDSolve psol = ParametricNDSolve[{Derivative[3][y][x] + (x^3 + a^3) y[x] == 0, y[0] == b, y'[0] == c, y''[0] == d}, y, {x, -3, 3}, {a, b, c, d}] and visualize: Manipulate[Plot[(y[a, b, c, d] /. psol)[x], {x, -3, 3}, PlotRange -> 5], {a, -1, 1}, {{b, 1}, -1, 1}, {{c, 0}, ...


7

So if you have: file = Import[path] then after the file is not needed: Clear[file] e.g.: In[77]:= MemoryInUse[] file = Import[StringJoin[NotebookDirectory[], "IMG_3025.jpg"]]; MemoryInUse[] Clear[file]; MemoryInUse[] Out[77]= 79593488 Out[79]= 115619864 Out[81]= 79591456


10

I think the symbols sym and $m7res are created by Information. They are not present when the kernel is started. Fresh kernel 1: Quit[] Names["Global`*"] (* {} *) Fresh kernel 2: Quit[] foo = Trace[ Information["Global`*"], TraceInternal -> True]; foo[[8, 3, 5, 7, 2, 9, 18, 65, 2, 1, 3, 6, 7, 5, 6, 4, 3, 3, 6, 2, 8, 12, 10, 5, 6, 2, ...



Top 50 recent answers are included