Re: Counting number of numbers in a large list between two valus
- To: mathgroup at smc.vnet.net
- Subject: [mg114568] Re: Counting number of numbers in a large list between two valus
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Wed, 8 Dec 2010 06:40:15 -0500 (EST)
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