..:: PCSX2 Forums ::..

Full Version: r4925 - why not use exact float for NTSC?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Quote:GSDX:
- Use float instead of int for the video framerate.
- Use 59.94 instead of 60 for the ntsc framerate.
This replaces a previous hackfix with a better one, but it's still not ideal.
The ideal solution for the video encoding side would be to use an actual fraction (60000/1001) and pass this fraction to the encoder.
The ideal solution for the gsdx side would be to deduce the real framerate from the timing parameters.

Any reason why not to just set the float to the exact value of the fraction, aka:
59.94005994005994005994005994006

If you copy paste that number into a calculator (so you know its just a number and no hidden metadata is transfered) and multiply it by 1001 you get exactly 60000. It is an exact value of the fraction of 60000/1001 as a decimal.
Rather then 59.94 which is an approximation. (a better approximation than 60.00, but an approximation nonetheless)
Just in case you haven't figured it out already by yourself, r4927 uses division to get better accuracy (still not the ideal solution, but on par with your suggestion).
(10-12-2011, 09:17 PM)avih Wrote: [ -> ]Just in case you haven't figured it out already by yourself, r4927 uses division to get better accuracy (still not the ideal solution, but on par with your suggestion).

I did get it. But it uses a rough approximation instead of the exact result. It then goes on to complain about the lack of accuracy compared to giving a fraction. I propose that using the exact figure would solve that.
It is not an irrational number, it is not infinitely long, and the figure I posted is exact. There are no more digits.
Essentially it is the same as passing a fraction (which will have to be converted to this number anyways)
How exactly is (30/1.001f)*2 a "rough approximation"??
(10-12-2011, 09:29 PM)avih Wrote: [ -> ]How exactly is (30/1.001f)*2 a "rough approximation"??

What are you talking about. (30/1.001f)*2 is the DESIRED method that COULD NOT be implemented. It isn't the current method.

The notes CLEARLY state that they are currently passing 59.94

From notes:
Old method: Pass int 60

New method: Pass float 59.94

Desired method (which could not be implemented yet): Pass a fraction of 60000/1001 (which equals to (30/1.001f)*2)

Now, why hasn't the desired method (which you described) been implemented? Because it is either too much work or no known way of doing that.

My proposal was instead of passing float 59.94 you pass float 59.94005994005994005994005994006

It should give identical results to the desired method (aka, correct results) and it bypasses whatever difficulty there was in implementing the passing of a fraction. It would be SUPER easy to implement too, just replace 59.94 with 59.94005994005994005994005994006 in current code. Thats it.

BTW. question, what is the point of passing a fraction? Doesn't the target software then must convert it to a float anyways to actually do math with it?
You're talking about r4925, and I noted about r4927.
(10-12-2011, 09:37 PM)avih Wrote: [ -> ]You're talking about r4925, and I noted about r4927.

you mean
Quote:GSDX: Whoops sorry I mixed two conflicting ideas into one.
?

I was wondering what that was. So you are saying that the code has already been changed again from 59.94 and now passes it on as an exact fraction?
(10-12-2011, 09:35 PM)taltamir Wrote: [ -> ]...
BTW. question, what is the point of passing a fraction? Doesn't the target software then must convert it to a float anyways to actually do math with it?

Not necessarily. The are integer-based calculations that can keep it accurate forever if the number is rational with known nominator/denominator (even if the floating point representation is infinite -> any finite approximation of it is inaccurate).

(10-12-2011, 09:43 PM)taltamir Wrote: [ -> ]...
I was wondering what that was. So you are saying that the code has already been changed again from 59.94 and now passes it on as an exact fraction?

It has been improved, yes, but not exact since float isn't accurate enough to hold so many digits. Exact (ideal) would have been, as you quoted, to pass the nominator and denominator values themselves.
(10-12-2011, 09:48 PM)avih Wrote: [ -> ]Not necessarily. The are integer-based calculations that can keep it accurate forever if the number is rational with known nominator/denominator (even if the floating point representation is infinite -> any finite approximation of it is inaccurate).

Certainly sounds like a good idea. I was actually considering fractional mathematics before in that you always keep your data rational and accurate. No rounding errors at all.

But what I meant was, in this specific case what would be the benefit, since it is not an infinite floating point. It is somewhat long, but none of it is truncated.

(10-12-2011, 09:48 PM)avih Wrote: [ -> ]It has been improved, yes, but not exact since float isn't accurate enough to hold so many digits. Exact (ideal) would have been, as you quoted, to pass the nominator and denominator values themselves.
So you are saying it ISN'T passing on a fraction yet? That it is still passing on 59.94?

Because 59.94005994005994005994005994006 is not an approximation, it is an exact number. There has been no rounding here. It would need to be 2 digits longer before windows calculator has round off the last digit.
(10-12-2011, 09:55 PM)taltamir Wrote: [ -> ]...
It is somewhat long, but none of it is truncated.
But it is truncated. The float type has 24 bits precision, or about 7 decimal digits. Anything longer is truncated. It's better than 59.94, but ultimately not fully accurate.
Pages: 1 2