GNU Rocket on non-Windows platforms
category: code [glöplog]
Changing the rounding mode of all float->int casts seems dangerous... Wouldn't it be better for intros to implement _ftol themselves, or at the least setting the rounding mode at startup?
Here's a very simple attempt at implementing _ftol with SSE (SSE wizards might do better):
Code:
int ftol(float f)
{
return _mm_cvttps_epi32(_mm_load_ss(&f)).m128i_i32[0];
}
Exactly, that's what I do. The problem with setting the rounding mode at startup is, that every floating point operation (even float with float) is affected by the rounding mode. Changing that also changes the result of fp arithmetic ops (multiplication, division, etc...).
Like you said, implementing ftol manually is the way to go :)
Like you said, implementing ftol manually is the way to go :)
That's a good point regarding fp arithmetic ops. So, if you can convince the compiler to pick up your ftol implementation instead of MSVCRTs, you should be pretty safe. AFAIK, it should simply be a matter of aliasing the symbol and drop /QIfist, but I haven't actually tried this.
Perhaps I should write a README for usync that mentions this pitfall?
Perhaps I should write a README for usync that mentions this pitfall?
Quote:
So, if you can convince the compiler to pick up your ftol implementation instead of MSVCRTs, you should be pretty safe.
Or my implementation of <math.h>'s floor, both should do.
xTr1m: while that will also work in this particular case, it might make other code misbehave. I think having a correct ftol is the way to go, and then remove the floor (and perhaps assert that the input is not negative).
The problem isn't a negative value, it's a wrong scene number, the sync is completely off! It really needs to be floor.
The negative value-thing is only about the difference between round to zero and floor. It shouldn't matter at all in this case, as the row cannot be negative.
Ill have a look at this in the morning too
i'll put it in my cereal!
