Because I find it consistently disturbing: I would like that SpherePoints would work in a reliable way, e.g.:

Grid[{#, Show[Graphics3D[{Opacity[.2], Sphere[]}], 
     ConvexHullMesh@SpherePoints[#]]} & /@ {10, 13, 50}, Frame -> All]

Dear Sander,

thank you for your quick response and for sharing your interesting function (but this very procedure should not be necessary)! Already some years(!) ago we had a conversation about this. My point here is that it irritates me that for such a long time it is not possible to correct this obvious misbehavior of an "official" function. I do not regard the solution to this problem as very complicated. Maybe this post might serve as a slight "nudge".

And - as a side note - even if it works I find the distribution of points quite boring (i.e. the pattern is too simple) if compared to alternative methods, e.g.:

ptsMH = Chop@*First /@ MeshPrimitives[DiscretizeGraphics[Sphere[], MaxCellMeasure -> .05], 0];
ptsSP = SpherePoints[Length[ptsMH]];
Graphics3D[Tube[#[[Last@FindShortestTour[#]]], .1], ImageSize -> Medium] & /@ {ptsSP, ptsMH}

Best regards -- Henrik

@Arnoud Buzing hi there!

Testing "12.1.0 for Microsoft Windows (64-bit) (October 6, 2019)"

The quality of the copied graphics is very poor.

Copying directly with the screen capture looks like this.

Using the [copy graphic] option by right click, looks like this.

Microsoft OneNote for Office 365 MSO (16.0.11328.20420) 64-bit

GeoRegionValuePlot doesn't normalize the color function as expected. I would like to make multiple maps (for different dates) and have the scale be consistent from map to map. For example, the scales on these three maps show up differently with changes to one state's value.

Row[{ countydata = <| Entity["AdministrativeDivision", {"Georgia", "UnitedStates"}] -> 1/100, Entity[ "AdministrativeDivision", {"Florida", "UnitedStates"}] -> 30/100, Entity[ "AdministrativeDivision", {"SouthCarolina", "UnitedStates"}] -> 50/100, Entity[ "AdministrativeDivision", {"NorthCarolina", "UnitedStates"}] -> 90|>; GeoRegionValuePlot[countydata, PlotRange -> {0, 1., {{-88, -70}, {23, 42}}}, ColorRules -> {0. -> Transparent, 100. -> Black}, ColorFunction -> "NeonColors", ColorFunctionScaling -> False, GeoRangePadding -> Quantity[300, "Kilometers"], PlotLegends -> Placed[BarLegend[Automatic, LegendFunction -> "Frame", LegendLabel -> "Values"], {0.85, 0.40}], GeoLabels -> (Tooltip[#1, #2] & ), ImageSize -> 300],

countydata = <| Entity["AdministrativeDivision", {"Georgia", "UnitedStates"}] -> 20/100, Entity[ "AdministrativeDivision", {"Florida", "UnitedStates"}] -> 30/100, Entity["AdministrativeDivision", {"SouthCarolina", "UnitedStates"}] -> 50/100, Entity["AdministrativeDivision", {"NorthCarolina", "UnitedStates"}] -> 50/100|>; GeoRegionValuePlot[countydata, PlotRange -> {0, 1., {{-88, -70}, {23, 42}}}, ColorRules -> {0. -> Transparent, 100. -> Black}, ColorFunction -> "NeonColors", ColorFunctionScaling -> False, GeoRangePadding -> Quantity[300, "Kilometers"], PlotLegends -> Placed[BarLegend[Automatic, LegendFunction -> "Frame", LegendLabel -> "Values"], {0.85, 0.40}], GeoLabels -> (Tooltip[#1, #2] & ), ImageSize -> 300],

countydata = <| Entity["AdministrativeDivision", {"Georgia", "UnitedStates"}] -> 30/100, Entity[ "AdministrativeDivision", {"Florida", "UnitedStates"}] -> 30/100, Entity[ "AdministrativeDivision", {"SouthCarolina", "UnitedStates"}] -> 50/100, Entity[ "AdministrativeDivision", {"NorthCarolina", "UnitedStates"}] -> 50/100|>; GeoRegionValuePlot[countydata, PlotRange -> {0, 1., {{-88, -70}, {23, 42}}}, ColorRules -> {0. -> Transparent, 100. -> Black}, ColorFunction -> "NeonColors", ColorFunctionScaling -> False, GeoRangePadding -> Quantity[300, "Kilometers"], PlotLegends -> Placed[BarLegend[Automatic, LegendFunction -> "Frame", LegendLabel -> "Values"], {0.85, 0.40}], GeoLabels -> (Tooltip[#1, #2] & ), ImageSize -> 300]}]

I've tried changing GeoFunctionScaling to no effect. SAWilkus@gmail.com

Attachments:

debug.nb

I would like to see how to suppress the pink-box-of-gloom since Mathematica will behave properly but, someplace in the inner workings, warnings get spawned ... apparently by the front end ... without any ability to suppress them even though things seem to be fully functional.

Attachments:

PinkBoxOfGloom.png

Fontsize->Large does not work when a PlotLabel is applied

The error that is generated is: "The specified setting for the option FontSize cannot be used."

Long-unfixed graph bugs

What's common in the below bugs is that they have stayed unfixed even after repeated reports.

Wrong result bugs

Here's a list of some wrong-result graph bugs. I won't repeat the details as all of these have been reported in the past.

This is the most serious class of bugs because wrong results are returned silently. A crash is not as bad because we can immediately see that something went wrong. When the result is just incorrect, we might continue working, maybe even publish a paper, without realizing what happened.

• FindVertexCut[g, s, t] typically returns wrong results
• FindMaximumFlow with vertex capacities returns not only wrong, but also random results
• FindKPlex[g, k] returns wrong results for directed graphs for k > 1
• Edge properties are not set on a graph if the edge is specified with a different orientation in the property list. Graph[{1<->2}, EdgeWeight -> {2<->1 -> 1.23}]
• RandomGraph[DegreeGraphDistribution[...]] does not sample uniformly.

Other long-standing bugs

• KaryTree, StarGraph and some other functions return a graph with a broken internal representation, whose properties can't be changed further using Graph or Graph3D. Graph3D[KaryTree[5], GraphStyle -> "BasicBlack"] (However, a simple Uncompress@Compress[graph] fixes this by reconstructing the internal representation.
• Vertex and edge labels are cut off in any graph style/theme except the default. Example: GridGraph[{5, 5}, GraphStyle -> "BasicBlack", VertexLabels -> Automatic].
• There is no documented way to remove EdgeWeights from a graph once added. EdgeWeights affect the output of many graph functions. Sometimes we might want to compute an unweighted distance on a weighted Graph expression. Repeated requests to fix this go back to 2012!!
• Export creates GraphML files that do not follow the standard and cannot be loaded by other software.
• VertexLabels -> "Name" or VertexLabels -> "Index" is mishandled when exporting graphs to most formats (e.g. Graphlet, GraphML, GXL, etc.)
• Weighted graphs with (EdgeWeight) fail to export to the Graphlet format.
• Regarding the above: currently, Mathematica's export is unusably buggy for all graph exchange formats which support properties. All of them have at least one deal-breaking bug (see above).

Other serious bugs (I'm not aware of these having been reported a long time ago)

• Adding self-loops to multigraphs results in errors or a crash

Fit also fails with quantities. See this for an example.

Case 3780236: Periodogram does not respect SetOptions.

Submitted as Case 1661658 and submitted as an incident response by Lin Geo at Tech Support :

OutputResponse applied to a TransferFunctionModel provides an incorrect response, apparently due to a failure to converge to the correct solution. A correct output can be produced by employing the undocumented option Method -> {"NDSolve", MaxStepSize -> stepSize} for an appropriately small step size.

The entire suite of control system tools at least needs better documentation.

There is also an ever-growing list of issues with various import/export formats (e.g. all the issues with PDF exporting,...). Would be nice to see this addressed at some point, especially since the documentation claims support for hundreds of formats. Many of the importers/exporters are also working with ancient versions of the formats, often not supporting the latest features.

Don't forget the Graph bugs that Szabolcs Horvat has been posting about. They are important to lots of MM users. https://community.wolfram.com/groups/-/m/t/1321057

In support of Neil comment about issues with large sets of data, I have many notebooks that include plots and are affected by this [CASE:4225009]. These open fine in v11.3 but crash on v12 (Windows) upon opening. I was able to construct a command to demonstrate the issue:

(* Save your docs before running this on v12 *)
ListLinePlot[{
  Table[{t, RandomReal[]}, {t, 0, 1, 0.00005}], 
  Table[{t, RandomReal[]}, {t, 0, 1, 0.00005}]},
PlotStyle -> {Dashing[{Small, Small}]}]

The other big issue on my radar is the reliability of asynchronous network functions. In particular URLSubmit [CASE:4026293]. For this reason in my application I am still using URLFetchAsynchronous which it is not supposed to be used for new developments as I understand is deprecated and also less convenient than URLSubmit. More details at:

https://mathematica.stackexchange.com/questions/167357/can-i-trust-urlsubmit

Hello Rohit,

Thank you very much for bringing the incorrect notification on a supposedly fixed GeoHistogram issue to our attention.

Reviewing all available information, it turns out that GeoHistogram had two very similar problems in Wolfram Language 11.3, in both cases returning the same error message. The first one was of type

GeoHistogram[WeightedData[...]]

for certain WeightedData arguments, while the issue you pointed out was of type

GeoHistogram[WeightedData[...], GeoRange ->...]

The first problem was addressed in version 12.0, while the second one persists, unfortunately.

Tracing back internal communication and records, it appears that we erroneously conflated the two issues while trying to determine an essential example for the latter.

Furthermore, just before informing you about the supposed fix, we apparently only double-checked examples of the first kind instead of your original example, leading to the incorrect note we sent.

I sincerely apologize for this mixup and for sending you wrong information. We are now working on strengthening our related processes, so you will find whatever we send to be correct and trustworthy. Furthermore we will ask the according development team to prioritize addressing the issue, if possible.

Thank you very much again for bringing this mistake to our attention.

Sincerely,

Peter Fleck

Manager, Wolfram Technology Group

Rohit, we're actually working toward an open issue tracker for Wolfram Language issues. Would you be interested in joining our prerelease program, so you have early access to this issue tracker?

Another fun one:

(*(*(*invalid=Union[invalid]*)*)

try to un-comment that by selecting it and pressing CMD + / …

Not directly a bug, but the GeoTIFF support in Mathematica could be much improved. You can't even get the bounding box information from GeoTIFFs when imported at the moment and this is pretty sub-par. I think much of the functionality was written before the Geography functions came to be and it could really use an update. It seems as though the GeoTIFF support is written with DEMs in mind and no other use case, which is certaintly not the way things are anymore. I use GeoTIFFs on a daily basis and end up using Python and GDAL to process them because it's easier - one of the few places in my life I don't like to use Wolfram Language! (Same goes for GeoJSON, although this is significantly better than the GeoTIFF format)

I'd enjoy seeing dynamic pan and zoom with 2d plots, similar to what you can already do with the 3d plots. It would be invaluable when exploring large datasets, without having to hand-roll something with Manipulate and PlotRange.