& & & 20000 &13.3 & 233 &$7.9\cdot10^{-4}$ & 0.97 & 136 &$3.7\cdot10^{-4}$ 50000 &27.7 & 1483 &$5.2\cdot10^{-4}$ & 2.64 & 924 &$3.3\cdot10^{-4}$ 200000 &158 & 24330 &$8.4\cdot10^{-4}$ &10.77 & 14694 &$3.4\cdot10^{-4}$ 500000 &268 &138380 &$7.0\cdot10^{-4}$ &29.42 & 91134 &$3.7\cdot10^{-4}$ 1000000 &655 &563900 &$7.1\cdot10^{-4}$ &58.34 &366218 &$3.5\cdot10^{-4}$

To assess the effect of these differences, we compared our code directly with the 3D adaptive FMM code by Cheng, Greengard & Rokhlin [@FMMb]. We performed a test identical to one reported by these authors ($N$ bodies randomly distributed in a cube) on an identical computer (a Sun UltraSPARC with 167MHz) using the same error measure (eq. (57) of [@FMMb]): $$E = \left[\sum_i(\Phi_i - \tilde\Phi_i)^2 \Big/ \sum_i \Phi_i^2\right]^{1/2}$$ where $\Phi$ and $\tilde\Phi$ are the potential computed by direct summation and the approximate method, respectively (unfortunately, Cheng et al. do not give the more relevant error of the accelerations). [Table \[tab:compare\]]{} gives, in the last three columns, the CPU time ($T_{\rm approx}$) in seconds and error $E$ for our code with $\theta=1$ and $s=6$ as well as the time needed for direct summation in 64bit precision ($T_{\rm direct}$); columns 2-4 report the data from Table I of [@FMMb]. On average our code is faster 