MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

slow built in functions

  • To: mathgroup at
  • Subject: [mg114586] slow built in functions
  • From: truxton spangler <truxtonspangler29 at>
  • Date: Thu, 9 Dec 2010 06:01:27 -0500 (EST)
  • References: <idnqqs$q69$>

On Dec 8, 10:40 pm, Daniel Lichtblau <d... at> 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

  • Prev by Date: Re: Table for FindInstance solutions
  • Next by Date: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • Previous by thread: On the foundation of Mathematica, was Re: Foo /: Plus[b_Foo] := b
  • Next by thread: Importing Google Result Page into Mathematica