The Mathematica Journal
Volume 9, Issue 2

Search

In This Issue
Articles
Tricks of the Trade
In and Out
Trott's Corner
New Products
New Publications
Calendar
News Bulletins
New Resources
Classifieds

Download This Issue 

About the Journal
Editorial Policy
Staff
Submissions
Subscriptions
Advertising
Back Issues
Contact Information

In and Out
Edited by Paul Abbott

Autocompilation

Q: I would like to understand the timing difference between the following two code samples. Slow version:

Fast version:

Is this due to autocompilation?

A: Robert Knapp (rknapp@wolfram.com) answers: The issue has to do with autocompilation, but is quite subtle. is basically equivalent to . With the second form, it is a bit easier to see why it cannot be autocompiled. Each time the inner Table is computed, needs to be evaluated to determine what the limit should be. Therefore the issue boils down to why it needs to be evaluated each time through the outer loop. Before evaluation, is just a symbol, so it could have any evaluation attached to it, for example, . In this example, the result of evaluating with only one would obviously be wrong. You might think it would be possible to evaluate with unset, but there are cases where that would be incorrect, for example, . This is, of course, pathological, but it is not too difficult to construct real cases that give incorrect or misleading values. It is very important that Mathematica be consistent, so we cannot do this. Thus, since cannot be known, except for specific values of , there is no way to autocompile the loop as a whole in a really efficient way. On the other hand, when you evaluate or put in literal numbers, everything is known, so compilation analysis can be done quite completely.



     
About Mathematica | Download Mathematica Player
Copyright © Wolfram Media, Inc. All rights reserved.