Mathematica Student Edition
Mathematica Home Edition
Computable Document Format (CDF)
Aerospace Engineering & Defense
Biotechnology & Medicine
Finance, Statistics & Business Analysis
Financial Engineering & Mathematics
Financial Risk Management
Software Engineering & Content Delivery
Authoring & Publishing
Social & Behavioral Sciences
Design, Arts & Entertainment
Game Design, Special Effects & Generative Art
STEM Education Initiative
Community & Technical College Education
Primary & Secondary Education
Computable Document Format (CDF)
High-Performance & Parallel Computing (HPC)
See Also: Technology Guide
Other Ways to Buy
Volume & Site Licensing
Does My Site Have a License?
Wolfram User Portal
About Wolfram Research
Stephen Wolfram's Home Page
Wolfram Functions Site
More Info >>
Mark as an Answer
Uses for the new Association feature
The Raspberry Pi version has a completely new data structure:
This is very similar to the dictionary data structure found in many other languages, but it does seem to keep its ordering. A dictionary doesn't seem to bring anything entirely new in possibilities (??), but it does finally give us this data structure without having to use any hacks (like Dispatch or DownValues), which is a big improvement.
Have any of you already found any practical uses for this data structure in your day-to-day work? I'd be curious how people are using it, especially in instances when it makes code significantly nice (shorter or easier to follow). I will need some until I get used to it and it'll become a key part of my active vocabulary, so I'm asking for some ideas/thoughts ...
This data structure seems to be a very natural fit for the output of many functions. It would be very natural for example for Tally and for GatherBy. It seems that instead of keeping the same functionality ties to the same functions, completely new names are made up. For example the twin of Tally is called
and GatherBy has
(they're not 100% equivalent but there's a large intersection). Generally, it should be a good output format for many of the "TransformBy" type function I talked about
and indeed the naming of new functions follows this.
I'm not entirely satisfied with the performance at this moment though. As of today, both GatherBy and Tally seems to perform significantly faster than the Associations versions. Take for example
implementation and compare the performance to the seemingly entirely equiavalent
. When there are a large number of duplicates, GatherBy is orders of magnitude faster; for no duplicates it's still faster but the difference is much smaller. The same goes for Tally vs CountBy. I'm hoping the performance will be improved eventually.
Several of the doc pages mention map-reduce which points at applicatons for distributed computing.
Re performance, I believe some of the implementation code will be revisited. That said, I'm not sure offhand if this will hit the specific functions you mention.
I apologize I can't go into more detail about this functionality, but I would like to make a couple notes about the Linux-ARM port. First off, for reasons of technical feasibility this release represents a snapshot, so any function that you find and *especially* functions that did not exist before could have their performance and behavior change drastically within the next year. So, for that reason alone some of what you find might not be fully representative of language features we release in the future. That said, the character of performance on the Raspberry Pi is significantly different also because it simply doesn't have the same level of machine optimizations we have in our x86 builds. Those optimizations are coming over time, but I would caution you against judging the character of performance on functionality on this platform in general for this reason.
As a hypothetical example, a developer writing new functionality might rely heavily on functions that have high performance CPU-specific optimizations applied in the case of our current development build. While this would be a good practice for building future-facing functionality for the product, the Raspberry Pi port might not have such optimizations available and instead rely on an implementation of a given function that performs orders of magnitude slower than on our optimized build, even with the difference in performance between a modern x86 and ARM11 processor taken into account. So, in this hypothetical example, functions that predate those optimizations might outperform the newer code because they may not have been written with that optimization in mind. I can't speak in detail about this given functionality, but for reasons like this I think it would be very easy to mischaracterize the performance of langauge features judging by the Raspberry Pi build alone. I strongly recommend waiting for the next official release of the product to scrutinize the behaviors and *especially* performance of new functionality.
I'm sorry if my post was misunderstood as criticism, it wasn't meant to be. I understand that this is not finalized functionality, but that's exactly why it's so exciting for many users, including me :-)
I don't have a Pi to play with, but offhandedly, Associations allow the most straightforward OO-like behavior in terms of syntax. It's possible the people at WR had this in mind, given the sugar for string keys:
obj = <|"x" -> 1, "y" -> 1|>
If there was a way to give Associations default values (like the third argument to
, but automatic), you could even have a basic form of inheritence (so-called prototypal inheritence, sans 'this'/'self'). Hopefully no one listens to me though, because the thought of OO-y Mathematica, even of an immutable flavor, brings great disgust to my loins. Although, because Associations are immutable, you can actually accomodate for inheritence just by adding onto the parent. Whoaaah.  This might end up being a lot more useful than it seems at first glance.
But even just in terms of basic functionality, I do have a couple programs where Associations would straightforwardize things. It's definitely a "quality of life" improvement, since otherwise you have to choose between intentfulness of declaration (Rules) vs ease of use (Functions).