http://www.wolfram.com/mathematica/new-in-10/key-value-assoc...
Version 10 introduces fundamental new constructs called associations. They associate keys with values, allowing highly efficient lookup and updating, even with millions of elements. Associations provide generalizations of symbolically indexed lists, associative arrays, dictionaries, hashmaps, structs, and a variety of other powerful data structures.
Hash-tables in previous versions of Mathematica:
>mymap["abc"]=1
>mymap[2]=2
>mpmap[hello]=3
>mymap["abc"]
1
>mymap[2]
2
>mymap[hello]
3
>myDerivative[a_ x_^n_] = n a x^(n - 1)
>myDerivative[1.1y^3]
3.3 y^2 In[1]:= mymap["abc"]=1;
mymap[2]=2;
mpmap[hello]=3;
DownValues[mymap]
Out[4]= {HoldPattern[mymap[2]]:>2,HoldPattern[mymap[abc]]:>1}
That said, Association[] looks nice. Presumably it gets a speed improvement by bypassing the pattern matching. And I remember being annoyed by using JSON data in Mathematica structures, this looks nicer. The literal syntax is appreciated too. Actually I'm kind of surprised they didn't choose another weird unicode symbol like 〚, for the literal syntax.
As a note: IIRC, SWI-Prolog got hash tables in their 7th release, so some fundamental data structure can be added to a language when it's seen as not needed by the language developers.
I'm just a little hesitant to do any meaningful work in such a closed ecosystem.
(That said, I also avoid using Mathematica for most things because I'm squeamish about ending up with any significant project too closely tied to a proprietary platform.)
It's interesting. I do sometimes wonder if it's being held back because it's proprietary. Other companies have proved it's possible to monetise an open source product, and Wolfram Research is a private company so they can really do what they want in that regard. I want to see it succeed because I think it's a great product, and a very clever one at that, but I can't justify doing research that uses it when there are open source implementations I can use instead.
In the end I moved everything I had to the Python scientific stack and I'm very happy I did it.
In fact Mathematica shows its advantages most when used interactively (compared to languages, like Python, which were not really designed for this).
So far ZIPCodeData[], NeighborhoodData[] and MountainData[],BroadcastStationData[], MovieData[], BuildingData[], PersonData[] are all mangled.
Worse yet, URLFetch is broken also. Something bad happened, at least with the Mac release.
In[1]:= URLFetch["http://www.google.com/"]
General::unavail: ExportString is not available in this version of the Wolfram Language.
ImportString::string: First argument ExportString[{60, 33, 100, 111, 99, 116, 121, 112, 101, 32, 104, 116, 109, 108, 62, 60, 104, 116, 109, 108, 32, 105, 116, <<19757>>, 111, 100, 121, 62, 60, 47, 104, 116, 109, 108, 62}, <<2>>] is not a string.
Out[1]= ImportString[ExportString[{60, 33, 100, 111, 99, 116, 121, 112, 101,
Mac OSX 10.9.4
uname -a <~/Library/Mathematica/Licensing nyx[33] Darwin nyx.local 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Session log below.
Mathematica 10.0 for Mac OS X x86 (64-bit) Copyright 1988-2014 Wolfram Research, Inc.
In[1]:= $Version
Out[1]= 10.0 for Mac OS X x86 (64-bit) (June 29, 2014)
In[2]:= $VersionNumber
Out[2]= 10.
In[3]:= SystemInformation["Small"]
Out[3]= {Kernel ->
> {SystemID -> MacOSX-x86-64, ReleaseID -> 10.0.0.0 (5098698, 5098537),
> CreationDate -> DateObject[{2014, 6, 29}, TimeObject[{20, 38, 32}]]},
> FrontEnd ->
> {OperatingSystem -> $Failed, ReleaseID -> Missing[NotActive],
> CreationDate -> DateObject[$Failed]}}
In[4]:= URLFetch["http://www.google.com/"]
General::unavail: ExportString is not available in this version of the Wolfram Language.
ImportString::string: First argument ExportString[{60, 33, 100, 111, 99, 116, 121, 112, 101, 32, 104, 116, 109, 108, 62, 60, 104, 116, 109, 108, 32, 105, 116, <<19641>>, 111, 100, 121, 62, 60, 47, 104, 116, 109, 108, 62}, <<2>>] is not a string.
Out[4]= ImportString[ExportString[{60, 33, 100, 111, 99, 116, 121, 112, 101,
> 32, 104, 116, 109, 108, 62, 60, 104, 116, 109, 108, 32, 105, 116, 101,
-- Snip --
In[5]:= ExportString[]
ExportString::argrx: ExportString called with 0 arguments; 2 arguments are expected.
Out[5]= ExportString[]
GeoGraphics is amazing example of the power of integration between domains. Built-in data about the world, with semantic integration into graphics as well as data analysis. This is way beyond what any existing mapping solution has delivered.
The geometry stuff is also amazing and very useful for generative design and "making"
There is no doubt that what Wolfram Research has done with Mathematica is amazing and tempting. It is a very complete and uniform engine, and can be very useful for very different kinds of mathematics.
However, Wolfram Research deliberately keeps their methods and source code closed. Note that this is more serious than just the "Stallman-esque" open-source-everything philosophy. Wolfram insists that users do not need to know implementation details of their methods. This is plainly in their documentation. You can see the uncompelling argument from Wolfram here [6]. The gist of the argument is that interfaces matter, not implementations.
I strongly argue that users, especially mathematicians and engineers, should care about the internals of mathematical software, especially when it's being used, even in a utilitarian fashion, for research and engineering.
Not only this, but Wolfram has litigated against his own employees for publishing mathematical proofs about cellular automata. Information about this lawsuit is sparse, but evidence of it can be seen in [0]. More information can be found here [1].
Unfortunately most responses to the above from users of Mathematica is "well I just use Mathematica as a calculator, nothing serious" or "I wouldn't look at the source code anyway, so what gives?" It's an unfortunate response, and I don't have a technical rebuttal, but a moral one, which many don't want to hear.
It pains me to see the technical reliance on Mathematica (and other software such as MATLAB) in professional mathematicians, scientists, and engineers. It reminds me of an addictive drug; one of the best hackers I know does their work completely in Mathematica, and can no longer work without it.
As is the case with a lot of closed source, proprietary software, there aren't a ton of good alternatives. There is a plethora of logistical issues with existing computer algebra systems, but I nonetheless recommend them. Sage [2] is a continuously growing system based on Python which has backing from a lot of mathematicians. They are continually improving it. There's also Maxima [3]. None of these has quite an extensive array of functionality and graphical capabilities as Mathematica.
I (and others) have written more about this issue more extensively here [4] for those interested. This is an extension on the article written by Jordi G. Hermoso [5].
If you took the time to read this, thanks.
[0] https://groups.yahoo.com/neo/groups/theory-edge/conversation...
[1] http://vserver1.cscs.lsa.umich.edu/~crshalizi/reviews/wolfra...
[3] http://andrejv.github.io/wxmaxima/
[4] http://symbo1ics.com/blog/?p=69
[5] http://www.symbo1ics.com/files/jordi.pdf
[6] http://reference.wolfram.com/language/tutorial/WhyYouDoNotUs...
Open source systems like Sage always look desirable, simply by virtue of being open source. But every time I look at it I'm left with a very bad taste in the mouth because of the constant badmouthing of non-open-source systems that is going on in that community. Companies do that sort of thing, and it doesn't inspire trust. But we know that it can happen just because a few people in the management made bad decisions. But when a community (!) around an open source (!) system takes on that attitude, it looks much worse. Don't you realize you're driving people away?
Why not put all that energy into improving your own system instead of trying to actively hinder others? Examples of that are forking GMP and making in GPL (not LGPL); actively pointing out to people (as Mr. Hermoso did to me) that no you can't link Octave to Mathematica because Octave is GPL (which is just a hindrance for my research, as well as to others); building on the fallacy that results obtained with Sage are inherently better because Sage is open sourced software is _theoretically_ verifiable. All software is buggy, and the only thing that makes a research result more trustworthy is if it is indeed verified, not if it's theoretically verifiable, but no one ever does it. Practical verification is almost never about reading the source code. It's about making sure the result is consistent and computing it with alternative tools.
I don't consider what I said "bad mouthing". Maybe it was. I tried to be as respectful as possible, and provide links where I could.
I am certainly trying to improve existing systems. I've written a library for doing computational group theory, for which a paper was just published, and I plan to include it in Maxima.
Regarding verifiability, Sage has a lot more going for it than "theoretical verification". Professional mathematicians, especially those in algebraic combinatorics, regularly hold conferences and write software along with papers to show correctness of the system, and write new mathematically grounded functionality.
I apologize to both the authors of open source systems and to potential consumers of such systems if I am driving them away. My goal is to at least spark the idea for one to step back and evaluate what it means/implies/etc. to make use of proprietary mathematical systems, especially in professional or academic settings.
"This reduces the problem to computing blah, which we did using the following Sage code. The function foo used here uses the algorithm of X and Y as described in their paper [XY2006]"
You can't say:
"This reduces the problem to calculating blah which the following Mathematica code computes using an unspecified algorithm for which there is no accompanying paper proving correctness."
Of course a paper proving that an algorithm is correct can contain errors, and also even if the proof of correctness is fine the actual implementation can contain bugs. But if you have no way of knowing how something is computed and whether anybody at any point in time even tried to prove mathematically that the method used is correct, you have no moral authority to rely on the result. That's just the standard adopted in mathematics: you can depend on results you have good reason to believe are true and are documented in the literature; you can't rely on stuff that's not written about. I don't know how citing results works in other areas, but that's how it is in mathematics (at least in the fields of mathematics I'm familiar with).
What exactly did you want to do?
GPLv3 (which is the license Octave uses) does not always prohibit linking GPLv3 code with proprietary code. In particular, if you want to hack up a private copy of Octave for your own use, and do not distribute that to others, that's fine.
The key grant of rights is this, from section 2: "You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force".
A covered work is "either the unmodified Program or a work based on the Program".
"Convey" means "any kind of propagation that enables other parties to make or receive copies".
If you are just doing stuff for your own private use, you are not conveying, and so that grant of rights to "make, run, and propagate covered works...without conditions" applies to you.
The proposed frame is "mathematica is somewhat better in polish and functionality, but we should stick to OSS on principle."
The problem is, by this argument, no will actually ever know what Mathematica is, what it does, and what cool ideas it had that could potentially inspire further work.
All the examples of alternative software have lots to learn from Mathematica; but thinking of Mathematica as a collection of algorithms for math is both wrong and misses the point. Mathematica is increasingly about knowledge computing; its moved on from where other systems are now just thinking about getting to.
Instead of competing with and replacing mathematica, everyone would be better off first learning from it, and then trying to apply and extend the fundamental principles in their own work.
Maybe I'm naive but I think that we really can just "all get along" -- notebook-based programming is just one example of how ideas can incubate in closed-source projects, and end up benefiting open-source projects. I'm hoping knowledge-based computation ends up being another.
And the reverse happens too -- Light Table is tremendously exciting, and I hope WRI can learn from that as it develops.
Other systems should "learn" from it, sure. It is hard to change Maxima, unfortunately, since it's entrenched in its roots from the 1960s. That's no excuse for making it difficult to use.
I think Sage's Python interface is doing better and better, learning what it needs to learn from Mathematica, including its documentation and interface.
I definitely don't agree with you that everyone should use or learn Mathematica though to learn it. As a student of computer algebra, I'd have to contend that Mathematica actually does computer algebra remotely correctly. A much more beautiful system for doing computer algebra was Axiom [0].
As an aside, I've been using IPython Notebooks a lot over Mathematica over the past year and have generally been really happy with the change – not least because I know I won't be locked out of my notebooks if I can't afford a Mathematica license in future! That all said, I recently revisited a Mathematica notebook I'd made in the past, and it reminded me why I started using it in the first place. It really is a great piece of software: great libraries, great performance, generally a pleasure to use.
Just, it will be slow...