Tag Info

Hot answers tagged

13

Solution It appears this bug is the result of attempted parallelism gone wrong. I believe it is corrected in all cases by setting this System Option: SetSystemOptions[ "ParallelOptions" -> {"MachineFunctionParallelThreshold2" -> Infinity} ] This appears to be an out and out bug and I tagged the question accordingly. Original observations: ...


11

It appears to be rounding only in the visual representation, but internally it stores the exact number. So e,g. doing: ds[1, "value2"] We get 387750. Which is the number from the excel sheet.


9

Am I wrong to understand from the documentation that your proposed short query syntax should work? In the meantime, a subquery seems to work planets[All, "Moons", Query[{Median, Length}], "Mass"]


8

In my opinion it's a bug. I input your data in Excel without the comma separator, execute the steps as per your question and get the same wrong result. A possible workaround: fileTemp = Flatten[Import["C:\\...\\problem.xlsx"], 1] /. x_Real :> Round[x] assoc = AssociationThread[fileTemp[[1]] -> #] & /@ fileTemp[[2 ;;]] Dataset[assoc]


7

This is a bug, I think, and I filed it as such: The second region should not evaluate to a RegionQ BoundaryMeshRegion. A BoundaryMeshRegion is valid if it contains a closed surface. The subtle point about BoundaryMeshRegion is that this closed surface is a (sparse) representation of the entire region the surface encloses. Why the first one does not work, I ...


7

An alternative workaround is to convert the BoundaryMeshRegion into a MeshRegion from the MeshCoordinates and MeshCells. This lets you use HighlightMesh as desired: SeedRandom[0]; pts = RandomReal[4, {200, 2}]; chull = ConvexHullMesh[pts]; styles = MapThread[Style, {{0, 1, 2}, {Red, Green, Yellow}}]; fullmesh[bm_] := MeshRegion[MeshCoordinates[bm], ...


7

Here is a workaround that's easy enough since it makes use of the already created Mesh region: Graphics[GraphicsComplex[ MeshCoordinates[chull], {Green, MeshCells[chull, 1], Red, PointSize[0.02], MeshCells[chull, 0], Opacity[0.6], Yellow, MeshCells[chull, 2]}]]


6

I got an answer from Wolfram Technical Support today. They had the following to say so far: "...It does appear that Manipulate is not behaving properly, and I have forwarded an incident report to our developers with the information you provided. [...] We hope this will be resolved in our future release of Mathematica."


5

Let's try something more basic that doesn't require GeoGraphics to interpret entities: countries = CountryData[#, "FullPolygon"] & /@ {Entity["Country", "Spain"], Entity["Country", "Belgium"], Entity["Country", "Romania"]}; GeoGraphics[{ Mouseover[{Red, #}, {Blue, #}] & /@ countries }] OK, it still doesn't work so it seems like it's a bug. ...


5

Until the issue is fixed, you can observe that the provided ClassPriors are inside the ClassiferFunction (in some way): ClassifierInformation[c,"Options"] Update This confused me as well when I first stumbled across it, but I have a utility function that I find quite useful for these SubValue type problems (as in the case of ClassifierInformation we ...


5

This has been confirmed as a bug and reported by rcollyer.


5

In the meantime, here is a way to repair the gridlines fixGridLines[plot : _Graphics | _Legended] := Module[{xmin, xmax, ymin, ymax}, {{xmin, xmax}, {ymin, ymax}} = Through[{Min, Max}[#]] & /@ Transpose@Cases[plot, {_Real, _Real}, Infinity]; With[{p = plot}, MakeBoxes[p, StandardForm]] /. pat : (GridLines -> ...


5

Edit: Wolfram Technical Support has confirmed this as a bug The only workaround I know is to turn the MeshRegion into a BoundaryMeshRegion and triangulate the resulting mesh object: dr = DiscretizeRegion[reg, MaxCellMeasure -> {"Area" -> 0.05}]; Then: TriangulateMesh[BoundaryMeshRegion[MeshCoordinates[dr], MeshCells[dr, 2]], ...


4

Update: same thing happens in versions 8.0.4 and 9.0.1. I'm on OS X 10.9.4, Mathematica 10.0.0. I did not wait for 10 minutes, but I do notice that the memory usage of the front end process (Mathematica) is increasing without bound. After a relatively short time it has reached 1.5 GB, so in 4 minutes it is certain to exceed 16 GB. This might be the ...


4

Partial sums of this sequence are given by: Sum[(-1)^(n + 1) Cos[3^n x]^3/3^n, {n, 1, m}] (* output: 1/4 Cos[3 x] - 1/4 (-(1/3))^m Cos[3^(1 + m) x] *) For real $x$, we know this converges because $\cos(3^{1+m}x)$ is bounded. Mathematica does not assume $x$ is real and, as Bob Hanlon notes, will produce the correct result by evaluating a partial sum, ...


4

I believe that this is a bug. The rest of this response speculates as to the possible cause. We start by observing that the test can be made to work by suppressing MissingBehaviour: mTest[ ProbitModelFit[#, var, var] & , {#age, #gender, #photo6, #rawM} & , MissingBehavior -> None ] It also works if FailureAction -> None is specified ...


4

I was able to isolate the problem with BarLegend in v.10.0.0. Yes, it is clearly a bug. Let us see the how the thin grey lines are implemented: Cases[ ToBoxes[BarLegend[{"DeepSeaColors", {0, 1}}, LegendLayout -> "ReversedColumn"]], _LineBox, Infinity] {LineBox[ NCache[{{-(15/2), 225/2}, {15/2, 225/2}, {15/ 2, -(225/2)}, {-(15/2), ...


3

This should solve the problem: ImagePad[ImagePerspectiveTransformation[i2, Round[f[[2]][[1]]], DataRange -> Full], -BorderDimensions[ ImagePerspectiveTransformation[i2, Round[f[[2]][[1]]], DataRange -> Full]]]


3

Here's my current workaround. Works only if the distinct time coordinates are sufficiently separated. corr[z_] := Module[{z1, z2}, z1 = SplitBy[SortBy[z, First], #[[1]] &]; z2 = Table[ Transpose[{z1[[k, All, 1]] + Range[0, Length[z1[[k]]] - 1], z1[[k, All, 2]]}], {k, Length[z1]}]; Partition[Flatten[z2], 2]] and ...


3

The same problem also appears in the related function ClebschGordan. This is indeed a bug which appears when Mathematica is given symbolic parameters instead of specific integers or half-integers. We can check that the first result in the question is incorrect by using the explicit sum definition of ThreeJSymbol given in the documentation under Properties: ...


3

Just to expand on what @eldo has written. I found that this odd behavior happens for all odd $n$ values where $n$ is the argument of this function:- f[n_] := Module[{r1, r2, r3}, r1 = ThreeJSymbol[{a, 0}, {b, 0}, {c, 0}] /. {a -> n, b -> n, c -> 0}; r2 = ThreeJSymbol[{a, 0} /. a -> n, {b, 0} /. b -> n, {c, 0} /. c -> 0]; r3 = ...


3

To get a plot very similar to the version 9 plot: SeedRandom[0] DensityHistogram[ Transpose[{RandomReal[NormalDistribution[], 1000], RandomReal[NormalDistribution[], 1000]}], PlotRangePadding -> {{-3.4, -1.4}, {-3.4, 0}}, PlotTheme -> "Classic"] Looks like a bug. Specifying bin delimiters is an other option: SeedRandom[0] ...


3

Not sure why PlotRange doesn't work (might need to report wolfram technical support), for workaround you could wrap it with Show: SeedRandom[0] Show[DensityHistogram[ Transpose[{RandomReal[NormalDistribution[], 1000], RandomReal[NormalDistribution[], 1000]}]], PlotRange -> {{0, 3}, {0, 3}}]


3

It appears to be a bug in the reporting mechanism. The individual components x and y are being tested for normality but the reported value is that of a joint test for multivariate normality. The conclusion is correct, the message is wrong. SeedRandom[2154]; x = RandomReal[{-5, 5}, 100]; y = 2 x + 1 + RandomReal[{-0.1, 0.1}, 100]; X = Transpose[{x, y}]; ...


2

Permissions->"Public" is exactly the right thing to do, you should only need a permission of All -> "Execute" for users to access and use a form. What you saw was a bug that has been fixed. For APIs, forms, and web computations, the "Execute" permission is the one needed to use it (that is to run, or execute), whereas the "Read" permission allows ...


2

GeoGraphics seems to have some fragility. I post this as a way (unfortunately not Mouseover) to achieve some interactivity: {spain, belgium, romania} = countries; h["Spain"] = spain; h["Belgium"] = belgium; h["Romania"] = romania; g[x_] := {Blue, h[x]}; cnt = {"Spain", "Belgium", "Romania"}; f = DynamicModule[{col = Black}, ...


2

Since the bug doesn't seem to occur when the Inset contains a Row instead of a Column or Grid, one could define the following function: Attributes[fixInsets] = {HoldFirst}; fixInsets[plot_] := ReleaseHold[ Hold[plot] /. HoldPattern[Rule[Epilog, Inset[x_, y___]]] :> Rule[Epilog, Inset[Row[{x}], y]] ] Then use it on the faulty plots like ...


2

Confirmed bug by WRI tech support


2

Line1: ThreeJSymbol is evaluated before replacement. Line2: ThreeJSymbol is evaluated after replacement. To give another example: D[x^2, x] /. x -> 2 4 D[x^2 /. x -> 2, x] 0



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