Tag Info

Hot answers tagged

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.


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


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


5

The main issue here is already fixed in 10.0.1 (probably as a side-effect of fixes for some of the other typesystem bugs that have already been reported by you and others!). The span issue is separate, I've reported that (thanks!)


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


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

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

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


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}]; ...


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


2

Until this bug is fixed, a work-around is to avoid the operator form of GroupBy, e.g.: titanic[GroupBy[#, Key@"sex"]& /* "female"] This same bug affects many operator forms, but this work-around frequently dodges it.


2

This has been confirmed by Wolfram Technology Group as a bug.


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

Confirmed bug by WRI tech support


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

The bug is reproduced in v. 10.0.0 under Win7 x64. A workaround: Graphics[{Inset[Graphics3D[Sphere[], Axes -> True], Center, Center, Scaled[1]], Inset[Column[{"a"}], {.05, .05}]}]


2

While searching for a possible workaround I observed another strange behaviour: Only functions in V9 (ticks disappear in V10): Graphics3D[Sphere[], Axes -> True, Epilog -> Inset[Style["First row\nSecond Row", 12, Bold], {.05, .05}], ImagePadding -> 40] But this functions in both versions: Graphics3D[Sphere[], Axes -> True, Epilog ...


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


1

A memory consumption demonstration Manipulate[{Plot3D[Sin[x a] - Cos[y], {x, -10, 10}, {y, -10, 10}, ColorFunction -> "TemperatureMap", PlotRange -> 11], MemoryInUse[]} // Column, {a, -2, 2, 0.1, Appearance -> "Open"}, TrackedSymbols :> a] After testing this code you should restart MMA, to guarantee full memory available.


1

Since IgnoringInactive is presently bugged we may wish to have a workaround for this operation. Here is my first attempt at implementing this. Please test it and give me feedback. patternHead = Pattern | Blank | Repeated | HoldPattern | Verbatim | Inactive | _Alternatives; ignInac[pat_] := Replace[pat, (h : Except[patternHead])[x___] :> (h | ...



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