Message Boards Message Boards

9
|
30799 Views
|
44 Replies
|
63 Total Likes
View groups...
Share
Share this post:

[LiVE] Request for suggestions for a livestreamed "Bugs Review" event

Posted 5 years ago
POSTED BY: Arnoud Buzing
44 Replies
POSTED BY: Sander Huisman

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}

enter image description here

Best regards -- Henrik

POSTED BY: Henrik Schachner
Posted 4 years ago

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

POSTED BY: Diego Zviovich

10 and 15 are presets. Non-presets (including 13) follow the following formula:

 iSpherePoints[n_Integer] := Block[{offset, r, z, NKSSpecialFunctions`SpherePoints`Dump`\[Phi]},
    offset = 2. / (n + 2);
    z = ((Range[n] * offset) + offset / 2.) - 1;
    r = Sqrt[1 + -(z ^ 2)];
    NKSSpecialFunctions`SpherePoints`Dump`\[Phi] = Range[n] * N[GoldenAngle];
    Transpose[{r * Cos[NKSSpecialFunctions`SpherePoints`Dump`\[Phi]], r * Sin[NKSSpecialFunctions`SpherePoints`Dump`\[Phi]], z}]
 ];

which works very nice for large n.

POSTED BY: Sander Huisman

Where do you paste it?

POSTED BY: Sander Huisman

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]

enter image description here

POSTED BY: Henrik Schachner
Posted 4 years ago

@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. enter image description here

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

enter image description here

POSTED BY: Diego Zviovich
Posted 4 years ago
POSTED BY: Diego Zviovich
Attachments:
POSTED BY: Stephen Wilkus
Posted 5 years ago

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?

POSTED BY: David Keith

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.

Attachment

Attachments:
POSTED BY: Mark Kotanchek

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

enter image description here

POSTED BY: Martijn Froeling
POSTED BY: Martijn Froeling

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)

POSTED BY: Szabolcs Horvát

DegreeGraphDistribution misbehaves

DegreeGraphDistribution is effectively undocumented. There is no clear statement in the docs about what it is supposed to mean. I can't even decide if certain behaviours are bugs or not.

(Of course, using our common sense we can see that these behaviours are clearly bugs. However, when reporting issues with Graph it is often a requirement to stick to the letter of the documentation.)

However, after a lot of guesswork, I suspect that:

  • It should sample uniformly from the set of graphs with a given degree sequence. Confirming of correcting this was outright refused by the developer when contacted through support. A simple test shows that it does not in fact sample uniformly. I can't even decide if this is a bug because of no documentation and no support (perhaps the sampler is meant to be approximately uniform only?)

  • For non-graphical sequences, it samples non-uniformly (not even approximately) from non-simple graphs. Again, answers to any questions about this were plainly denied. A typical answer is "no information is available".

  • Without a proper definition, I am completely lost when trying to figure out how this should work with functions like GraphPropertyDistribution

  • The syntax for directed graphs is again undocumented

The situation has been like this for many years, and nothing has changed after many reports. This is symptomatic of how problems with Graph are handled in general.

Related: https://community.wolfram.com/groups/-/m/t/1756560?p_p_auth=QIf48N5F (Note: still no response.)

POSTED BY: Szabolcs Horvát

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:


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

POSTED BY: Szabolcs Horvát
Posted 5 years ago

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

POSTED BY: Rohit Namjoshi
  • 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] 
    
POSTED BY: Henrik Schachner

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

POSTED BY: Gustavo Delfino
Posted 5 years ago

Hi Arnoud,

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

Thanks, Rohit

POSTED BY: Rohit Namjoshi

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?

POSTED BY: Arnoud Buzing
Posted 5 years ago

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

POSTED BY: David Keith
Posted 5 years ago

Case 3780236: Periodogram does not respect SetOptions.

POSTED BY: David Keith
Posted 5 years ago

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

POSTED BY: David Keith
Posted 5 years ago

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.

POSTED BY: David Keith
Posted 5 years ago

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

POSTED BY: Rohit Namjoshi
Posted 5 years ago

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

POSTED BY: Peter Fleck
Posted 5 years ago

[CASE:4286463] Error with Histogram

POSTED BY: Diego Zviovich

Some explicit examples would be useful here because there are 10s of formats…

POSTED BY: Sander Huisman
Posted 5 years ago

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.

POSTED BY: Lukas Lang

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

POSTED BY: l van Veen
Posted 5 years ago

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

POSTED BY: Carl Lange

Related to Kirk's post above, MMA has a huge shortcoming with 2D plotting. In addition to zooming and panning, The plot functions fail on large datasets. For example, I plotted a 30 million point data set in MATLAB and it was fine. I could zoom in and out, etc. I plotted a 30 million point dataset in Wolfram SystemModeler and similarly had no issues. I tried a 30 million data point set in MMA and brought the system to its knees. I had to write a decimation program (based on a stackexchange post) that automatically "Enveloped" the data, reducing the number of points in the plot. MMA should do something like this automatically (or take an option like "AutoDecimate") while allowing zooming in (with each zoom you can then increase the resolution to combine detailed viewing with fast interface response).

Regards,

Neil

POSTED BY: Neil Singer
Posted 5 years ago

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.

POSTED BY: Rohit Namjoshi

Another fun one:

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

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

POSTED BY: Sander Huisman
Posted 5 years ago

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"] *)
POSTED BY: Lukas Lang
Posted 5 years ago

Again not so much a bug as a quality-of-life improvement: GeoWithinQ could use a bit of a speedup - at the moment it uses the network, which makes it pretty much useless when you have ten thousand points around Europe and you only want to see the ones in France. Related: https://mathematica.stackexchange.com/questions/195482/how-to-speed-up-geowithinq/195483#195483

POSTED BY: Carl Lange
Posted 5 years ago

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)

POSTED BY: Carl Lange

@Arnoud Buzing And another one related to region. See attachment.

Attachments:
POSTED BY: Sander Huisman
Posted 5 years ago

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.

POSTED BY: Kirk Klobe

Thanks, noted!

POSTED BY: Arnoud Buzing
Posted 5 years ago

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

POSTED BY: b3m2a1 ​ 

@Arnoud Buzing Here is a nice one:

Graphics3D /@ NestList[BeveledPolyhedron[#, 0.1] &, Dodecahedron[], 3]
POSTED BY: Sander Huisman
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract