slow built in functions
- To: mathgroup at smc.vnet.net
- Subject: [mg114586] slow built in functions
- From: truxton spangler <truxtonspangler29 at gmail.com>
- Date: Thu, 9 Dec 2010 06:01:27 -0500 (EST)
- References: <idnqqs$q69$1@smc.vnet.net>
On Dec 8, 10:40 pm, Daniel Lichtblau <d... at wolfram.com> wrote: > truxton spangler wrote: > > [...] > > > Why is it that a function called Count is not the fastest way to > > count, a function called BinCount is not the fastest way to count > > bins, a function called Sort is rarely the fastest way to sort, a > > function called Select is rarely the fastest way to select ...and so > > on. When "named" built in functions are rarely the best programming > > option this seems like a flaw in the design philosophy of the software > > and certainly is an added barrier to Mathematica becoming an intuitive program > > to learn. > > > While I am on this topic the date and time handling functions in Mathematica, > > even in version 8, are so slow as to be useless for real work. This is > > another example of named functions not being the best programming > > option. Ditto the time value of money functions. It is very easy to > > get 2 orders of magnitude speed enhancement writing your own code > > which brings into question the point of developing these sort of built > > in functions in the form that they currently exist. > > I have to punt on the second paragraph issues. Others know much more > about that stuff. > > For the first, let me point out that most of the functions you claim to > be slow are meant to work in very general ways. Some work with pattern > matching and/or function predicates. These involve invocations of the > full Mathematica evaluation sequence. Every so often we recognize > special cases that need to be faster, and optimize for those cases. > > Functions like Clip and Unitize work on vecotrs of reals, and I think > were designed with packed arrays in mind. They are thus more > specialized, and faster. But you cannot get them to do the things you > might do with e.g. Select or Count. > > Sort tends to be fast, by the way, if using default ordering. If you > have an example that shows otherwise, we (at WRI) would want to see it. > > Daniel Lichtblau > Wolfram Research e.g. Carl Woll has contributed many examples of ways to program things that work orders of magnitude faster than the built in functions. Why wouldn't these algorithms be used internally within the built in function? Why don't these bits of code appear with the documentation under the relevant function so people can easily figure out the fastest way to do something? I got to tell you that one of the reasons that you see 100 competitors for every Mathematica user is because it is perceived as slow and only for prototyping not for production. Long term users know Mathematica can be fast -- often by ignoring built in functionality -- but some of these IMO design oversights do not help make the case ...especially when other things about the product seem so random (example: it was more important to develop a Renki chart in version 8 than a two axis plot!?).