Extending Van Gogh’s Starry Night with Inpainting
blog.wolfram.com
blog.wolfram.com
The high level functions, while nice for demos, never quite do what you need. Want to display data vs. time with errorbars around the data? Sorry, no function for this completely exotic use case, please hack a DateListPlot on top of an ErrorListPlot [1].
The WolframAlpha integration "transparently" interprets code for you in the background. This interpretation can change any day [2] and leaves you guessing why your notebook doesn't run anymore.
The bugs I encountered were severe: One of the output function swallows the "-" sign if the result is between -1 and 0 [3]. Currently I am battling file corruption of notebooks that are saved on network drives and open while the drive is disattached/reattached.
Had it not been for the awesome support by the mathematica. stackexchange.com community, I would have quit Mathematica completely. Now I vowed to use it only for small hacks. And, if I want to impress someone, for demos.
[0] https://www.youtube.com/watch?v=EjCWdsrVcBM
[1] http://mathematica.stackexchange.com/questions/18962
[2] The input
Quantity[1, "Kelvins"]
Quantity[1, "Kelvin"]
Two recent problems I had with LaTeX:
* If you put a \dfrac inside a table, the table thinks that the fraction is smaller and the line of the borders of the table collide with the numbers.
* If you need a different header height in your first page, you need some black magic macrology to get a not so good solution.
Here's a very simple way to do it for DateListPlot:
Get["https://raw.githubusercontent.com/szhorvat/Spelunking/master/Spelunking.m"]
DateListPlot;
Spelunk[DateListPlot]
So the OC could actually rewrite DateListPlot to add error bar support, if he wanted to. He could even overwrite the original MX file in his installation once he had done this, if he so desired.
Even thought it's true, probably he couldn't legally distribute his own modified copy of DateListPlot. Right know you can hack together error bars for a plot even if you only know the output format of DateListPlot (FullForm and patter matching helps a lot).
Thanks for "Spelunk", it's awesome.
I have access to the source of tons of stuff, and yet I can't fix it.
Not without spending months on understanding their codebase and going out of my actual projects and work.
(And even then, my fix might not be accepted upstream, so it could be invalidated with any major or even minor version update).
That other's have access too, so someone might fix it, also doesn't work that much. Tons of projects, even extremely popular ones like GTK have but a few commiters, and tons of open bugs.
'Never' seems like quite a generalization. What about e.g. Classify and Predict, or FormFunction, or Interpreter, or Nearest? Do those all not do quite what you need? Conversely, does other software do better, on average, in 'doing what one wants'? Which software?
There are gaps, definitely, one small example you've pointed out. My pet peeve, for example, is that it is unnecessarily difficult to map colors and sizes onto graph vertices based on vertex properties, which I needed to do for [1].
Still, the scope of visualization functionality is so vast [4] that it's not surprising there are gaps (which we continue to plug, the whole language is a never ending project). And having users report to us what they want lets us prioritize those things. Anyway, clearly DateListPlot should learn about error bars, and I'm sure in a year or two it will. Although it is frustrating you can't just go in there and tweak the source code yourself, I agree.
> Don't get me started on the KelvinsDifference vs. Kelvins thing, which are both represented by the same symbol to maximize your confusion when your unit conversions are failing...
I think Quantities should probably gain a little box, like DateObjects have [2], that lets you mouse-over for more information, which should make this problem easier to diagnose. But the distinction is apparently important [3], although I don't want to "get you started" :-). Either way, Alpha shouldn't change its interpretation from under you, that's definitely a bug.
> http://mathematica.stackexchange.com/questions/65600
Unfortunate, but fixed within a day of being reported! 10.0.2 has passed many weeks of SQA and will ship shortly. So at least this bug will only have been around for 0.0.2 versions :-)
[1] http://blog.stephenwolfram.com/2013/04/data-science-of-the-f...
[2] http://reference.wolfram.com/language/ref/DateObject.html, http://reference.wolfram.com/language/ref/Entity.html
[3] http://reference.wolfram.com/language/tutorial/TemperatureUn...
[4] http://reference.wolfram.com/language/guide/DataVisualizatio..., http://reference.wolfram.com/language/guide/FunctionVisualiz..., http://reference.wolfram.com/language/guide/ChartingAndInfor..., http://reference.wolfram.com/language/guide/MapsAndCartograp..., http://reference.wolfram.com/language/guide/DynamicVisualiza..., http://reference.wolfram.com/language/guide/GraphicsOptionsA..., http://reference.wolfram.com/language/guide/GraphicsInteract..., http://reference.wolfram.com/language/guide/SymbolicGraphics..., http://reference.wolfram.com/language/guide/ImportingAndExpo...
Certainly, there are many functions that do what I need - but in my experience, the "higher" the level of the function is, the smaller the chances that it fullfills my needs.
> Conversely, does other software do better, on average, in 'doing what one wants'? Which software?
Over the years I have come to appreciate Matlab. Like Mathematica, it also has some maddening idiosyncrasies [0] and is mostly closed source, but it let's me inspect its high level functions. For instance, if I am not happy about the errorbar plots, I can execute the command "edit errorbar" to get an idea what I have to change. If the change is complex, Matlab is a decent enough IDE to implement it anyways. In comparison, Mathematica seems like a front-end to the kernel to me. It is not a proper IDE. I heard there is a Mathematica IDE called Wolfram Workbench [1], but it costs extra.
For me, my biggest problem is not about the sofware "doing what one wants", but that it is doing things I don't want. File corruption and sign error bugs are absolutely not ok for software that I base my publications on, and I have not encountered them in the alternatives [2].
Mathematica is a powerful piece of software and has many use cases. Of course it can't be a "eierlegende Wollmilchsau" that is good at everything [3]. But personally (disgruntled customer rambling here) I wonder why Wolfram Research is devoting so much energy into developing all these new, shiny features while the foundation is crumbling.
[0] Try running a Matlab script that has - gasp - a space in its name. It will fail and produce an "undefined function" error message. (Not very helpful to new users.) The newer versions at least warn you if you try to save a script with an illegal name - but they still allow you to run it and produce the non-descript error message.
[1] http://www.wolfram.com/products/workbench/
[2] The alternatives I actually use are Igor Pro, Matlab, and Excel. Excel can easily lead to sign errors because of the unexpected behaviour of the unary minus. It takes precedence over the power operator, so if you evaluate "-1^2", the result is +1. While you can get used to that behaviour, you can easily forget it when you work with references. Say A1 contains 1, then "-A1^2" evaluates to +1. If, like me, you prefer working with named cells and name A1 as x, then "-x^2" also evaluates to +1. I once botched an analysis due to this behaviour. Ironically, this was one of the reasons why I wanted to base my current analysis on Mathematica.
[3] http://commons.wikimedia.org/wiki/File:Wollmilchsau.png?usel...
Ok. It's hard to argue with a generalization absent more examples. I don't see DateListPlot as one that supports your point: it's relatively specific to plotting lists of dates. Whereas e.g. Classify and Predict are much more level: they're single-function wrappers around the most common use cases of machine learning.
But in a sense what you say must be true: the higher level you get, the more likely there will be some low-level detail you will not be able to change. That's kind of inevitable -- if you don't write it yourself, it is unlikely to do exactly what you want to do.
But that doesn't make the high level functions ridiculous, at all, or the entire project of building them ridiculous. When the high-level functions provide, they're beautiful. Plus, the low-level functions (in this case, Graphics) are still there.
Look, I don't want to discount your experience -- you're a customer, after all :). But it's a vast system that I know in some amount of detail, and despite my obvious bias, I think you are vastly overstating the case that it's a "demo language". People generally like to form opinions and then rant on the basis of little data, so I guess I'm challenging you there.
> Over the years I have come to appreciate Matlab. Like Mathematica, it also has some maddening idiosyncrasies [0] and is mostly closed source, but it let's me inspect its high level functions.
While not as friendly as seeing a source file, you can inspect almost all the high-level Mathematica code via tools like Spelunking: https://github.com/szhorvat/Spelunking (see my comment below)
> In comparison, Mathematica seems like a front-end to the kernel to me. It is not a proper IDE.
Agreed there, our 'package editor' isn't appropriate for serious programming. Workbench is fairly decent, but as you say, not free. Still, in my view Sublime* surpasses almost all other text editors, anyway, so it's much of a muchness. [* replace with Emacs or Vim to taste]
> File corruption and sign error bugs are absolutely not ok for software that I base my publications on, and I have not encountered them in the alternatives
I have often found network file systems (and their integration in modern OSes) to be unreliable with many kinds of software. Perhaps the FE could be more defensive about the OS lying to it ("I wrote those bytes, I promise"). Or perhaps there is a genuine bug where we don't check that some buffer got flushed successfully. Either way, I don't think this can be adduced in support of your crumbling foundations claim.
> I wonder why Wolfram Research is devoting so much energy into developing all these new, shiny features while the foundation is crumbling.
A function like TextString, which is new in 10.0.0, is not I think an indication of a crumbling foundation :). But sure, there are sections of entropying code. But we spring clean them with some regularity, at least.
One thing I think we can agree on: the whole grandiloquent project of Wolfram Language does make those flaws, when they come up, somehow infuriating. I wouldn't be infuriated if I found them in an open source project (partly because I could just contribute a fix, but also partly because my expectations wouldn't have been built up).
It makes working on the language a rollercoaster. When you add something really tight and clean, or when you rationalize some domain that was previously irrational, or when you see things fit together really beautifully, it can be incredibly satisfying. But when you see problems, or it lets you down, or you see when someone in the past took a shortcut, it can be very frustrating. Irrationally so.
[0], [2], ... wow... It reminds me of how the Glasgow Haskell Compiler used to delete your source code if it didn't type check. Apparently people didn't complain: "fair enough, I deserved it..." :)
[3] That's a glorious image I will carry with me for the rest of my life. Thank you.
Also I have this in my init.m: Unprotect[WolframAlpha]; ClearAll[WolframAlpha]; WolframAlpha[x__] := Null; Protect[WolframAlpha];
It'd be great to hear how they did an efficient implementation of texture synthesis. But if you want to read at least about the basics, the dissertation they linked [1] gets into the details on page 18, anyway, in section 2.2 (and beyond).
[1] http://www.logarithmic.net/pfh-files/thesis/dissertation.pdf
http://reference.wolfram.com/language/tutorial/WhyYouDoNotUs...
Trust us, we're professionals!
That is from my favorite texture synthesis paper of all (Efros & Leung '99), for these reasons:
- I know Efros, and he's a genius, and also an absolutely adorable human being.
- This paper was inspired by Markov text generators, its the two-dimensional equivalent, e.g., http://en.wikipedia.org/wiki/Mark_V_Shaney. Its very simple, produces great results, - AND - this texture synthesis algorithm will synthesize written text from a picture of written text. Almost none of the faster texture synthesis algorithms do this, and it seems meta; I like to think there is some deep fundamental truth hiding in there somewhere.
(edited for typos and formatting)
Some of these look so seamless it's staggering.
[1] http://www.logarithmic.net/pfh-files/thesis/dissertation.pdf
There's an oldish plugin for the GIMP called Resynthesizer, but there are better algorithms out now. G'MIC has one called "inpainting". http://gmic.eu/repository.shtml
Some more tests of the algorithm with less impressive results (though still good looking)
I've personally found Photoshop's Content-Aware Fill to be so useful on films and comics that it now gets its own credit, as:
"Matte extension: Content-Aware Phil".
SIGGRAPH-style research shouldn't validate itself merely because it teaches the computer to adopt a cliched mode of image-making.
Some of these are pretty impressive and do more than just pattern repetition.
They're all interesting as technology demonstrations, but none of them improve on the original compositions, and some of them are almost completely unsuccessful as visual art.