Test errors on Windows 32bit about delaydiffeq.jl

[devmotion]

As the hypothesis above suggests, not setting the initial time step dt = 0.1 in the constrained tests leads to different initial time steps also for the constrained tests (1.0e-06 vs. 0.0001). As a consequence, also the constrained tests fail (see https://ci.appveyor.com/project/devmotion/delaydiffeq-jl-p4v3l/build/job/fhu7jik5t33r1jy6).

[ChrisRackauckas]

As the hypothesis above suggests, not setting the initial time step dt = 0.1 in the constrained tests leads to different initial time steps also for the constrained tests (1.0e-06 vs. 0.0001).

That's really weird. Doesn't it suggest there's a difference due to OrdinaryDiffEq.jl and not DelayDiffEq.jl though?

[devmotion]

I'm not sure yet. At least I could not reproduce the difference with a simple ODE example. Moreover, I discovered that the initial time step in these examples is set to 1.0e-6 on my computer and 9.999999999999999e-5 on Windows 32bit, but still the first non-zero time point of the solution is 1.0e-6 on my computer and 0.0001 on Windows 32bit.

[devmotion]

Oh my god :D Of course 9.9999e-5 != 1.0e-6

[devmotion]

Fixed by SciML/OrdinaryDiffEq.jl@b70c49e

[devmotion]

Seems there is another problem on Windows 32bit that was not fixed by that commit, since now another test fails:
https://ci.appveyor.com/project/ChrisRackauckas/delaydiffeq-jl/build/1.0.96/job/l0ty4hq534tsxhep

[ChrisRackauckas]

Only 32-bit and only unconstrained tests with a really small difference? I'll take a quick look but that sounds like a nightmare to find haha.

[devmotion]

Yes, and it's only one single test.

[ChrisRackauckas]

Discussed in #22. The errors are fixed because they needed a higher bound anyways after the OrdinaryDiffEq changes. A lot of this may be due to compiler optimizations not be applied uniformly. Practical steps forward would be to reduce numerical errors all around via things like SciML/OrdinaryDiffEq.jl#93 and summation re-ordering. I'm closing this because I think the @fastmath tests show that the level of accuracy that was looked at here is just beyond our control, but we can focus on SciML/OrdinaryDiffEq.jl#93 instead. Feel free to pursue this further if you want though, and we can re-open if you find something.