I mean, we could make an WFR function that does it better and with different metrics… Like most uniform area, or smallest standard deviation between angles of nearest neighbours, or …

–SH

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

Where do you paste it?

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

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

If you filter mathematica stackexchge for posts having the tag “bugs” you get 1529 posts with 96 from this year. Have these been reviewed by Wolfram?

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

I believe that for practical network-analysis work, the following is the single most important issue with Graph. This problem is going to be very difficult to fix. Therefore, it would be encouraging for us users to hear not just a promise that it will be fixed, but something about how it could be fixed at all without compromising existing functionality.

Property API design is flawed because it can't handle multigraphs

Properties are accessed like this in WL:

PropertyValue[{obj, item}, propname]

For edge properties of graphs, this looks like

PropertyValue[{graph, v1 <-> v2}, propname]

In other words, in order to access a property of an edge, we need to refer to that edge by its endpoints (v1 and v2).

Now what if there are multiple edges between the very same two vertices?

Graph[{1<->2, 1<->2}]

It is simply not possible to distinguish these two edges using this notation, so it's not possible to work with edge properties of multigraphs. (Also, if we try to do it anyway, we get no clear error message about what is going wrong. Things just fail silently. This sort of behaviour is unfortunately standard for Graph stuff, see redmine #101—this should be discussed too.)

The API simply provides no way to unambiguously refer to one of these two edges.

This extends to styling too since edge styles are stored as properties. It is not possible to style parallel edges differently.

I think that this is one of the most serious issues with Graph because it's not just a simple wrong behaviour bug which could in principle be just corrected. The flaw is in the design of the API. It seems to me that a proper fix would involve changing the API and breaking backwards compatibility. Because of this, I am very worried that this will never get fixed.

I asked about this countless times through various channels and never got a proper response (of course, it is a very difficult issue).

Supporting edge properties for multigraphs is absolutely critical if Mathematica wants to be a serious tool for network analysis.

This issue also ties into several others, e.g. Import mishandling graph exchange formats when they can contain multi-edges with properties.

Related issues

• Graph property system is not clearly described in the documentation, so we have to do some guesswork to be able to work effectively. See e.g. https://mathematica.stackexchange.com/q/118196/12 For example, certain build-in properties like EdgeWeight, EdgeCapacity and EdgeCost do work with multigraphs. However, this is undocumented and one must take special care to avoid using the standard property API. The fact that these do work is what keeps Mathematica usable for me for many network analysis tasks. Unfortunately, working with these requires some esoteric knowledge ... (because of the lack of proper documentation).

• Property inheritance was added to M12.0, but it's still completely undocumented (other than a single mention in the list of new features). Some of the details are not obvious and can't be guessed. This also ties into the issue with edge properties for multigraphs. E.g., functions like SimpleGraph now handle the EdgeWeight of multigraphs and add them up when merging parallel edges. This is extremely useful and completely undocumented.

Suggestion for interim solution

Above, I mentioned multiple times that this is the single biggest issue with Graph for my work, and also that this is going to be very difficult to fix.

I'd like to suggest an interim solution. EdgeWeight, etc. also sort of work with multigraphs, but this is undocumented, and therefore effectively unsupported. Please document, polish, and support this limited solution until a more general solution can be implemented.

This is one of the most talked-about issues with Graph

The following is a list of links to discussions about this issue to demonstrate that many users care about it:

• https://mathematica.stackexchange.com/q/133734/12
• https://mathematica.stackexchange.com/q/92360/12
• https://mathematica.stackexchange.com/q/129170/12
• https://mathematica.stackexchange.com/q/145417/12
• https://mathematica.stackexchange.com/q/132624/12
• https://mathematica.stackexchange.com/q/74125/12
• https://mathematica.stackexchange.com/q/92014/12
• https://mathematica.stackexchange.com/q/184216/12
• https://mathematica.stackexchange.com/questions/184160/graphunion-but-with-multiple-edges#comment480340_184163
• https://mathematica.stackexchange.com/q/124228/12
• There are several others, but I think these are sufficient to show that there is great demand for this feature

How do other libraries deal with this?

How do other network analysis libraries (in other programming languages) deal with this issue?

• igraph refers to edges by their index (their position in the edge list)
• networkx uses an extra "tag" to distinguish parallel edges. There's (v1, v2, tag1) and (v1, v2, tag2).
• Some C++ libraries like LEMON use pointers to edge objects, but this sort of solution doesn't apply to WL

It's not just about edge properties—it's about the distinguishability of edges

There's more to this problem than just edge properties. In practice, this is a big issue when doing network analysis (working with empirical data). But similar issues also come up in graph theory (pure mathematics). For example, when working with planar graph (or other topological topics), using multigraphs instead of simple graphs is a natural choice. We may ask:

• Which edges belong to a face of a planar graph? We need a notation to distinguish between parallel edges.

• When specifying a combinatorial embedding of a graph (i.e. an ordering of edges around each vertex), we also need to distinguish edges. We need a notation to distinguish them.

• When finding cycle bases, the same problem arises. Mathematica has FindFundamentalCycles but its result is ambiguous because parallel edges are indistinguishable. Mathematica also has EdgeCycleMatrix, which does not suffer from this problem because effectively it refers to edges by their index (i.e. row i of the matrix corresponds to the ith edge of the graph).

We may even want to first find the faces of a planar graph, then look at the weights (i.e. property) of edges for each face. This is not just a theoretical example. Here's a paper which does exactly this. It should be feasible to implement the analysis technique from this paper in WL.

Another example where cycles and multi-edges come up is resistor networks (electrical circuits). Think resistors in parallel (multi-edges with weights).

• In my opinion NumericArray would be very useful - if one could fully use it, see e.g. this discussion;
• The frequent occurrence of functions qualified as "EXPERIMENTAL" (in particular in v12) unsettles me a bit;

• I would like to see a consistent behavior when plotting functions with quantities (there was a former post about this I cannot find), e.g.:

  f[Quantity[x_, "Meters"]] := Quantity[x^2, "Joules"]
  
  Table[f[x], {x, Quantity[0, "Meters"], Quantity[10, "Meters"]}] (* does work *)  
  Plot[f[x], {x, Quantity[0, "Meters"], Quantity[10, "Meters"]}]  (* does not work *)
  (* possible workaround: *)
  ListLinePlot[Table[{x, f[x]}, {x, Quantity[0, "Meters"], Quantity[10, "Meters"]}], AxesLabel -> Automatic] 
  

Hi Arnoud,

That is really good to hear. Yes, I would be interested in joining the prerelease program.

Thanks, Rohit

Plot should pass on warnings from Interpolating Functions when they are given arguments outside their range.

Wolfram Workbench throws errors for single stepping unless the code contains at minimum an undocumented number of lines.

Hi Peter,

Thank you for explaining the reason for the erroneous email that I received. I think WRI would benefit from making the issue/bug management process more transparent and exposed.

The MSE community has discussed this here. Patrick Scheibe has a well thought out post on how WRI and its users could benefit from this.

I look forward to WRI seriously considering these options and implementing a better and more transparent issue/bug management and QA process.

Rohit

[CASE:4286463] Error with Histogram

Attachments:

Error with Histogram.nb

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.

And another one with the Geo functions, GeoHistogram fails with WeightedData and GeoRange:

GeoHistogram[
 WeightedData[
  CountryData["UnitedStates", 
   "LargestCities"], #["Population"] &], 
  GeoRange -> 
  Entity["AdministrativeDivision", {"California", "UnitedStates"}]]

I think the WeightedData case is used more often than the "list of GeoPositions" case (at least for me) and it would be great to see this fixed. Related: https://mathematica.stackexchange.com/questions/190697/geohistogram-with-georange-fails-with-weighteddata/190704#190704

This one is the posted solution to SW's EIWL exercise 22.13.

NearestNeighborGraph[
 Table[Rasterize[Style[FromLetterNumber[n], 20]], {n, 26}], 2, 
 VertexLabels -> All]

Reported to WRI July 31, 2018: CASE:4093797. Not fixed in 12.0. I don't think it is a serious issue but SW may think otherwise since it is in his book.

For this one I got an email from support on Aug 8, 2019

[CASE:4287750] The current Mathematica addresses an issue you reported

In February 2018 you reported an issue with Mathematica wherein GeoHistogram was failing with weighted data in certain instances. We believe that the issue has been resolved in the current 12.0 release of Mathematica.

It is actually not fixed in 12.0. I consider this to be a much more serious issue. User reported an issue with an attached notebook to reproduce it and receives an email that it has been fixed, but it has not been fixed. Clearly something is broken in WRI's issue management / QA process.

I also posted the example that fails on MSE.

The false-positives of the Dataset type system can be quite annoying, especially since it fails with a single Failure object instead of the usual messages. One frequent issue for me is the fact that variables can't be used as Part specifications:

Dataset[{1, 2, 3}][Table[#[[i]], {i, 3}] &]
(* Failure["i is not a valid Part specification"] *)

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.

I can work around most little bugs I run into in the core Kernel itself--and Kernel bugs just make me reimplement functionality, which means I have a more robust implementation that I understand in the end--but there are many things in the FE I can't work around, almost entirely related to Dynamic and its brethren as there is no way to really robustly control the FE from the WL at the low level (even using undocumented functions).

I'd really like a discussion, then, of the generally poor performance of Dynamic and the crazy work-arounds one has to do to make it clean.

Here's one such issue. First I make a Dynamic which uses a TaggingRule to listen for a specific key:

Dynamic[
 {
  RandomReal[],
  CurrentValue[
   EvaluationNotebook[], 
   {TaggingRules, "test"}
   ]
  }
 ]

Then if I update a completely unrelated key, that Dynamic gets updated, e.g. by:

CurrentValue[
  EvaluationNotebook[], 
  {TaggingRules, "not-test"}
  ] = 1

I emailed John Fultz about this and he said the best option was something like:

DynamicModule[{cachedValue},
 DynamicWrapper[
  Dynamic[
   {
    RandomReal[],
    cachedValue
    }
   ], cachedValue = CurrentValue[EvaluationNotebook[], {TaggingRules, "test"}]]
 ]

which kinda works in this case but which is definitely not scalable and I'm not even convinced is robust in the more complicated workflows I want to build.

Long term I want to be able to use the FE as an IDE with efficient tab management, toolbars, file browsing, extension-specific stylesheets, etc.

I have all the infrastructure for this and I use it day-to-day, but the FE is too slow to really encourage other people to use it--and much of the reason for this is in the poor performance of Dynamic (there are other issues like the fact that NotebookWrite is ridiculously slow, but that's probably harder to fix).