Has anyone quantified the runtime cost of doing interface upgrades? I have a vague memory that the vtable for a specific type/interface pair is constructed at runtime and then cached -- is this true?
2,464 karma · joined July 25, 2010
https://tali.link
https://twitter.com/taliesinb
I replicated this particular experiment in WL, of course, because it's a 5-minute thing to do [3], and I could actually do the community detection the author alluded to.
But I noticed that the correlation matrix itself is much more suggestive than the graph ends up being, with or without community detection. Take a look at the correlation matrix (note that MatrixPlot does some clever combination of rank and absolute value to get high dynamic range):
The tri-diagonal structure is because the original dataset is derived from the pixel counts from successive 4x4 tiles on NIST written-digit images [4].
Those 8x8 matrix of tiles is flattened onto the 64 random variables, so the large correlation with tiles on the left and right explain the 1-off-diagonal orange lines, the other two diagonals are offset by 8 and correspond the high correlation with the tiles above and below. That's the 'connectivity kernel' of a 2D manifold, so to speak.
The curious squiggles in all the other blocks of this matrix are unusual. I don't know what's going on there. Maybe something interesting.
[2] http://en.wikipedia.org/wiki/Topological_data_analysis
[3] https://www.wolframcloud.com/objects/c7927909-448d-4502-9c1a...
[4] https://archive.ics.uci.edu/ml/machine-learning-databases/op...
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.
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.
'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...
Then we execute that symbolic representation using a variety of strategies. There are funnily enough quite a few cases where we can understand the question but don't have the curated algorithms to actually answer it.
What do you mean by a template database?
Luckily if you say "Wolfram XXX" instead of just "XXX" Siri will route your question straight to Alpha no-questions-asked.
If you stick to subreddits thing are much better. For example, I lurk on r/rust a lot, and like other high-quality subreddits they have a stickied code of conduct to establish the ground rules. And the community there is extremely friendly and encouraging.
The general phenomenon of misogynist trolling, and in particular the wave of misogyny masquerading as #gamergate has been astonishing to read about. There's something deeply, deeply disturbing and raw going on here and it is hard to see the contours of it.
It's a pity that a 12-hour old HN submission [1] of Anita Sarkeesian's moving talk at XOXO [2] didn't get much traction (indeed a sock-puppet immediately emerged to denounce the submission as 'trash').
[0] Emerald Therapeutics: http://emeraldcloudlab.com/
By running this code:
CloudDeploy[
FormFunction[
"text" -> "String",
Classify["FacebookTopic", #text, "TopProbabilities"] &,
"JSON"
],
Permissions -> "Public"
]
https://www.wolframcloud.com/objects/0cda973b-8e12-43d7-a9d3...
Try something like "I just had the most amazing meal at Four Burgers today".
https://www.wolframcloud.com/objects/051a4cda-5c0e-423b-8872...
I don't think there's another language you could use to do that in ~5 minutes.
I suppose people at all levels of discovery are excited by what they're learning, especially because we all possess a brain and it is intriguing to begin pulling back the curtain of how it might work.
But as I said before, CPython is a close analogy for where we are at. What we don't have yet is the equivalent of PyPy. Still, if you were to make this kind of dismissive critique against the maintainers of CPython, I think most people would find it kind of silly.
Also, one should note that this documentation was written during an era when perhaps most of Mathematica's user base were people doing math, for which the primary use for compilation was things like plotting, numeric solving, and so on. The language of the tutorial reflects that heritage. At this point we should probably rewrite it.
It's light on math and heavy on hand-drawn transparencies being lined up on an overhead projector. He has these inscrutable registration marks that he matches by hand -- reminds one of the alien code in the movie Contact.
One of my favorite parts concerns some mysterious scribblings by Kepler that seem to presage his work!
That's a really good example: you'd have to find the tutorial [0] to know what to do. And we could make that job easier by detecting your probably incorrect use of = instead of := and giving you a "I see you're trying to define a function" kind of deal. Of course people hated Clippy, so we have to tread carefully with that kind of thing :)
> This is important, I think, but I also think the problem's less in your documentation than in how I "learned" Mathematica.
Yes, I think you hit the nail on the head with this paragraph. It is possible to 'accrete' tricks in a way that potentially blocks you from having a holistic knowledge of the language. The workflows for symbolic manipulation, which involve lots of global state and symbols representing variables, is probably a prime culprit.
> My problem was in setting up the matrix to be diagonalized. The state space had something like seven degrees of freedom (four two-dimensional and three with arbitrary dimensions), so I was calculating matrix elements for up to something like N = 10^5 basis states.
That makes more sense. There might have been higher level ways to do this using functions like Array and Table, but perhaps not. And Julia is a really interesting language, I think we can learn a lot from them.
> I can't shake the feeling, though, that I'd want to run away very quickly from a large Mathematica/WL project like Wolfram|Alpha.
Huge codebases in any language get hairy. I'd say we're on a par with C++ in that respect (meaning: not very good, but workable).
Modern languages have had some innovations with clean package systems and API boundaries (though the ML family showed the way), so it's perhaps good we're still waiting to modernize our package system. Plus, I think we have a chance in the next year or two to really leapfrog other languages with some amazing static analysis tools.
Still in the lab, though :)
[0] http://reference.wolfram.com/language/tutorial/ImmediateAndD...
[1] http://reference.wolfram.com/language/ref/Array.html, http://reference.wolfram.com/language/ref/Table.html
That inference is not correct. That doc is one of many hundreds of 'guide pages' that collect together various functions by domain/concern. It's not meant to be the exhaustive proof of "WL is a modern functional programming language with all the features you expect".
> I fear these are all dirty hacks and performing very poorly.
Why do you fear that? From my experience we're about on a par with CPython.
> Why isn't it better specified?
There is a gargantuan library of documentation, available both offline and online, that covers every area of the language, including core language areas like scoping.
> Why isn't it better specified? Because Wolfram wants to prevent competition?
We don't need to obscure how the language works to prevent competition, we can rely on the fact that it would take hundreds of engineers (with a full spectrum of domain knowledge) a decade to replicate the kind of functionality we have.
The exact thing you seem to want, which is "what does a LISP programmer need to know about WL?" doesn't exist, but perhaps it should! It might make sense to add Block, Module, and With to the functional programming page, though the Scoping Constructs guide [1] is the place to start understanding our scoping.
> > Compiled code does not handle numerical precision and local variables in the same way as ordinary Wolfram Language code. > This is a huge warning sign.
Again, you seem to have little patience for documentation. The notes in the function page are a summary of salient points, rather than an essay about every detail. The tutorial goes into more depth [2].
And specifically: precision tracking is something almost no-one else does. BLAS can't do it -- so yes, the semantics have to change if you want speed. Lisp and the FP community would have the same problem if they represented quantities with the generality we do.
[1] http://reference.wolfram.com/language/guide/ScopingConstruct...
[2] http://reference.wolfram.com/language/tutorial/CompilingWolf...
Can you give an example of bonkers-ness?
The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0].
In fact the suite of functions you have available for basic list and hashmap manipulation is probably one of the richest among languages in this space.
Btw, its called a "term rewriting system", not a "rule rewriting engine".
> Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow.
It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops. But you can use Compile[1] if you want to write fast procedural-style code. We also do some amount of JIT compilation.
> Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience.
Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years?
> Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.)
> The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3].
Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing. The video helps a bit, and there is the fast introduction for programmers [4].
[0] http://reference.wolfram.com/language/guide/FunctionalProgra...
[1] http://reference.wolfram.com/language/ref/Compile.html
[2] http://reference.wolfram.com/language/ref/Eigensystem
[3] http://www.wolframalpha.com/facebook/
[4] http://www.wolfram.com/language/fast-introduction-for-progra...
Really glad to see it's still going!