In the course of my physics analysis for my PhD, I have come across something very interesting. In particular, I have proved - proved, I say! - the existence of free will.
In particular, when I run my perfectly deterministic program three times, same computer architecture, same inputs, I will get two different answers. Free-willed computers!
Unfortunately this tends to cause some difficulty for getting my PhD in physics, because who knows which answer is the right one? But clearly it would be a great advance for philosophy.
Posted by ricree101 (Member # 7749) on :
Posted by rivka (Member # 4859) on :
Perhaps it actually proves something about the quantum fluctuations in the computer. Which is either chemistry or physics, depending who you ask.
Posted by King of Men (Member # 6684) on :
Physics, but no; it's very reliable. Run three jobs, one will disagree with the other two.
Posted by fugu13 (Member # 2859) on :
I can come up with at least one or two fairly plausible reasons. Do you want me to take a look at your code, assuming you haven't found the bug yet?
Posted by King of Men (Member # 6684) on :
Actually I'm fairly convinced it's due to a race condition where simultaneously-running jobs were writing to, and then reading from, the same file. Old code that assumed I would only be running one job at a time. I'm testing this now. But I'd be glad to hear other possible causes, because I've been beating my head on this for a while, and if this dang race condition isn't the problem I'll cry.
The code is around 5000 lines of bad C++ just counting my own, and then there are two big third-party libraries, one of which is known to be - in my advisor's phrase - a piece of shit. I suggest that this is not something to casually look over between bites of your lunch. And you'd need the data to do any actual testing, of course. If you still feel like volunteering, on your own head be it!
Posted by Blayne Bradley (Member # 8565) on :
If I recall my basic laymans quantum physics correctly the right answer is whichever one you choose to be the right answer.
Posted by Orincoro (Member # 8854) on :
quote:Originally posted by King of Men: Actually I'm fairly convinced it's due to a race condition where simultaneously-running jobs were writing to, and then reading from, the same file. Old code that assumed I would only be running one job at a time. I'm testing this now. But I'd be glad to hear other possible causes, because I've been beating my head on this for a while, and if this dang race condition isn't the problem I'll cry.
I'm only experienced in music programming and sequencing, but may I ask why it isn't possible to just run the jobs in sequence rather than at the same time? While we're talking about cludgy composer-type work arounds, why not create two copies of the file and have the jobs write and read from separate files?
That said, this is the kind of thinking that leads to my rat's nest patches, but they still work better than those made by people with no imagination, and a squeamishness about clutter.
Posted by fugu13 (Member # 2859) on :
I'd be happy to volunteer. I've dissected more troublesome codebases before. It is a sad requirement of having to work with academic programmers
Race conditions are one of my candidates; another is simply reading uninitialized memory, which would help explain the periodicity (which out of the three runs is the different one, generally?) Then there are more obscure possibilities such as the sort implementation triggering based on amount of free memory, and one sort being stable and the other not, and that being something that affects the algorithm.
Posted by mr_porteiro_head (Member # 4644) on :
quote:it's very reliable. Run three jobs, one will disagree with the other two.
quote:I'm only experienced in music programming and sequencing, but may I ask why it isn't possible to just run the jobs in sequence rather than at the same time?
Because I have several dozen jobs and they take ~10 hours each. Also, it is not yet certain that this is the problem.
quote:Another is simply reading uninitialized memory
I am ~95% convinced that this is not the problem, on the grounds that the starting values look reasonable to me.
quote:which out of the three runs is the different one, generally?
It varies, actually.
quote:Then there are more obscure possibilities such as the sort implementation triggering based on amount of free memory, and one sort being stable and the other not, and that being something that affects the algorithm.
There is no sorting taking place, so this seems unlikely to be the problem. ETA: And anyway I think it's safe to say that nobody in this codebase is doing anything fancy like checking the available memory! We don't even use the standard library, we've got self-rolled container classes.
quote:I'd be happy to volunteer. I've dissected more troublesome codebases before.
Ok, if the file-writing isn't the problem I'll dump it all on your head. Tremble!
[ August 04, 2009, 01:11 PM: Message edited by: King of Men ]
Posted by Darth_Mauve (Member # 4709) on :
Well, see, two of the computers, the ones running the programs dirt-side, they are fine. The third one, running on the space ship, it has top secret orders that the other two backup computers don't have. These orders involve secretly investigating the black obelisk circling Jupiter's moon Io and is identical to the one that was found buried in a crater on the moon.
Posted by King of Men (Member # 6684) on :
Looks like it was the race condition, yes. I just ran six jobs and they all agreed.
![[Big Grin]](biggrin.gif)
![[Wink]](wink.gif)