Re: Random timing results with 'fsolve'

[Olaf Till]

On Wed, Oct 12, 2011 at 06:21:28PM +0200, Søren Hauberg wrote:
> ons, 12 10 2011 kl. 16:53 +0200, skrev Olaf Till:
> > On Wed, Oct 12, 2011 at 04:21:57PM +0200, Søren Hauberg wrote:
> > > ons, 12 10 2011 kl. 14:02 +0000, skrev bpabbott:
> > > > It does look strange.
> > > > 
> > > > 
> > > > Have you looked at the 2nd (function values) and 3rd (termination
> > > > status) outputs of fsolved?
> > > 
> > > Hmm, okay... it seems like the algorithm converges to different solution
> > > each time. The problem I'm solving is under-determined so it does not
> > > surprise me that the solver can converge to different solutions, but I
> > > am surprised that this happens when the solver is given the same
> > > starting conditions. Does 'fsolve' perform any random steps?
> > > 
> > > Søren
> > 
> > Wild guess: hardware floating point randomness (maybe due to
> > differences between processor cores?) which has only "negligible"
> > effect on accuracy, but could change the course of optimization in
> > under-determined problems...
> 
> Could be. Do you have any idea on how to determine if this is indeed the
> case?
> 
> Søren

No, I know too little of this to suggest tests. I have only a vague idea that
some indeterministic behavior is probably possible due to hardware issues.
A quick search shows that similar things are sometimes discussed, see e.g.

http://stackoverflow.com/questions/968435/what-could-cause-a-deterministic-process-to-generate-floating-point-errors

where some suggestion of a reason is given at the end.

Without understanding that all, maybe if you manage to test with all but one
CPU core turned off (how?), things could be reproducible ...

Olaf