Comments on: Debugging fun

By: Mikaelhc

Mikaelhc — Tue, 13 May 2008 13:51:41 +0000

Well, it is only a guess.

There must be something different between yours and Garrett’s machine.

If both your machines are using Intel CPU’s, it might be the case that the 64-bit machine defaults to using the fast SSE registers, which are 64-bit wide. This could be checked on a 32-bit machine/OS by compiling with “-mfpmath=sse” (for GCC) to see if the behavior changes. He might also have more aggressive optimization applied which turns off rounding (not very likely though).

All guesses though, but let us know if you find out what causes the difference!

By: Thomas Mailund

Thomas Mailund — Tue, 13 May 2008 11:12:25 +0000

Michael, I never compare floats without a threshold, but then, I rarely compare them…

Thanks for the info on Intel, though. Does it explain why it worked for Garrett and not me, though?

By: Mikaelhc

Mikaelhc — Tue, 13 May 2008 11:02:18 +0000

It is probably related to the internal rounding when doing floating point math.

Since 0.5 may be exact represented, and both 0.1 and 0.4 have simple repeating bit patterns (e.g. 0.4 decimal = 0.0110011001100…. and 0.1 is the same shifted two positions) it should not matter at all how many bits you use to represent them. But the rounding will be important (it is stated in ‘float.h’).

Actually since Intel FPU’s all use an internal 80-bit float representation, the compiler may choose to keep some numbers in registers at a higher resolution until the result is written back to memory – further complicating matters.

But anyway, consider adding a threshold when comparing floats :-)

By: Thomas Mailund

Thomas Mailund — Tue, 13 May 2008 06:21:29 +0000

Michael: Actually, I was just guessing about the size of doubles. If they are not of different size than on my box, I don’t know why it worked for Garrett and not me

By: Reed A. Cartwright

Reed A. Cartwright — Mon, 12 May 2008 23:07:57 +0000

I think generate was making a temporary copy of my global random number object and when the temp copy of the object was destroyed (in connection with the push_back) command, the GSL rng that both wrapped was freed. If I’d written a proper copy constructor/operator it probably wouldn’t have happened.

I solved the issue by passing a functional wrapper object to generate instead of the actual rng.

By: Mikaelhc

Mikaelhc — Sun, 11 May 2008 20:28:17 +0000

Hi,

Just out of curiosity: On which platform (and using which C++ type) did you find 128-bit floats? Isn’t this quite exotic? (I believe most (all?) 64-bit platforms still use 8 bytes for doubles)

By: Thomas Mailund

Thomas Mailund — Sun, 11 May 2008 06:59:37 +0000

What was it, Reed, do you think? Some trashing of uninitialized memory or such? I have struggled with such problems countless of times… valgrind usually is a life saver, but you don’t want to run a long MCMC in valgrind, ’cause that will never finish.

As for GSL, I had a problem with that yesterday, but that was (of course) my own fault. I had a global variable for the random number generator. I usually keep that global, but probably should use a Singleton pattern instead. Anyway, the global variable is one of the last thing I initialise before I run my main code. I was re-factoring HapCluster yesterday to move a lot of the logic into two classes (a Chain and a State class for the MCMC) to make it easier to customise the chain to the different updates needed for different kinds of input data. Now the problem was that I need to initialise these two classes early in the setup code and State objects need random numbers in the initialisation. Of course, before I had initialised the random number generator. It took me a little while to figure out I was using uninitialised memory to generate random numbers…

By: Reed A. Cartwright

Reed A. Cartwright — Sun, 11 May 2008 03:29:22 +0000

I had a very strange bug in one of my programs recently. After a couple of simple code changes GSL started to fail when I tried to generate a multinomial. After a while, I eventually determined that my rand number object was being cleared earlier in the code. I traced it to an unrelated vector::push_back command, which had been fine before. I then went back to commenting out several recent changes and found that a “generate” command was doing “something” so that when I pushed the generated object onto the vector, it erased what I thought was an unrelated random number object.

As soon as I changed the generate line a bit, everything was fine. It’s the weirdest bug I’ve ever had.