Update: This event is scheduled for 9/6/2019 at 3:30pm US Central timezone.
We are planning to have our live-streamed “Bugs Review” event soon, where Stephen Wolfram will discuss issues (bugs: incorrect behaviors, crashes, hangs, performance issues, etc.) that you care the most about. If you plan to attend and to help prepare for this event, please reply to this post with issues in the Wolfram Language (including the Notebook Interface) you think are the most important to discuss.
Thanks!
@Arnoud Buzing Here is a nice one:
Graphics3D /@ NestList[BeveledPolyhedron[#, 0.1] &, Dodecahedron[], 3]
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).
Thanks, noted!
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.
@Arnoud Buzing And another one related to region. See attachment.
RegionDifference.nb (166 KB)
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)
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
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"] *)
Another fun one:
(*(*(*invalid=Union[invalid]*)*)
try to un-comment that by selecting it and pressing CMD + /
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.
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
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
Don’t forget the Graph bugs that Szabolcs Horvat has
been posting about. They are important to lots of MM users. Has Wolfram abandoned the Graphs and Networks functionality?
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.
Some explicit examples would be useful here because there are 10s of formats
[CASE:4286463] Error with Histogram
Error with Histogram.nb (831 KB)
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
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
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.