## 2 Materials and Methods
The balls from long pimples with reduced rotation have a different flight path with less lift and fall down earlier such that the player misses the ball, and he complains that the ball was swirling. Figure 1: Air drag coefficient \(C_{D}\) (upper green curve) and airlift coefficient \(C_{L}\) (lower red curve) as a function of the ratio of spinning velocity \(u\) to the translational velocity \(v\). The computer code solves the equation of motion of table-tennis balls for given initial positions, velocities, and spins (see one example in Figure 2). A Euler solver was used, because its algorithmic simplicity allowed an easy transfer onto the GPU with CUDA. The implicit assumption of the Verlet algorithm (with or without velocity calculation) is that the driving force is conservative, i.e., on a closed path, no work is done. For our system studied here, this was not the case, since the drag and the Magnus force both influence the trajectory depending on the actual velocity. If a particle on a closed path comes back to its origin, the drag will slow it down. Energy is not conserved. In the standard Verlet scheme, the second force evaluation depends only on the position, whereas the force on the table-tennis ball is velocity-dependent. Thus, valid options are the Euler and Runge-Kutta (RK) methods. The RK fourth-order method requires four force calculations compared to one for the Euler method. Each force evaluation calls a function to calculate the drag coefficient and another one for the lift coefficient, because these depend on the actual translational velocity. These are rational functions where the numerator and denominator are polynomials of the third order. This makes every force evaluation costly. For a very long flight of 2 s, a test trajectory with the standard time step of the code (\(10^{-4}\) s) led to an end position even beyond the table. The difference of the final positions was 0.115 mm for the Euler and RK4 methods. This was well below the precision of 1 mm we were looking for. However, the RK4 method was 4.37 times slower. Increasing the time step by a factor of five to compensate for the reduced calculation speed compared with the Euler method increased the error for the RK4 method beyond 1 mm, which we defined as our resolution limit. A more extensive comparison of the Euler and RK4 algorithms was done for \(10^{5}\) random test trajectories with identical start conditions for both integrators. The differences are listed in Table 1.  
The results confirm the single test trajectory results. The number of successful trajectories and their distribution is nearly indistinguishable for the two cases and the 4.4-times-faster Euler integrator can be used. One important factor for the limits of the time step for the integrator is the additional dependence of the drag and lift coefficients on the velocity (see Figure 1). These are non-linear terms in velocity, and changes in velocity in one time step need to be small enough to linearize this term during the time integration. Adaptive time-stepping could solve the problem, but this counteracts the optimized usage of GPUs, because this is only effective if the calculation effort for the different trajectories calculated in parallel is balanced. A strong variation of calculation time would reduce the effectivity of this parallelization strongly, because the slowest trajectory is then defining the limit. Therefore, the Euler method was chosen as a fast method for the calculation of half a billion trajectories for each case within the precision limit of 1 mm for the time step of \(10^{-4}\) s.  
For a statistical analysis of the effects of ball sizes and net heights on trajectories of table-tennis balls a Monte Carlo procedure was used. Many different initial conditions were solved: \(x\) was varied between 0.3 m and \(-\)3 m, representing hitting locations from 30 cm above the table to 3 m behind the table; \(y\) was kept constant at 0.381 m, which is \(\frac{1}{4}\) of the width of the table-tennis table. This was chosen as a representative position, the exact