[BUG] Inconsistent telemetry dtypes

[leonardobocci]

Describe the issue:

The dtypes for telemetry are inconsistent across the documentation. I may well be missing something, but here the speed and throttle pct are documented as float: https://docs.fastf1.dev/core.html#fastf1.core.Telemetry
while in the response data, and in the private endpoint: https://docs.fastf1.dev/api.html#fastf1.api.car_data they are integers.
If the source API provides access to floats, they should be also reflected in the telemetry endpoint through session.car_data, while if float data is not available, the documentation should be corrected.

Reproduce the code example:

import fastf1
session = fastf1.get_session(year=2024, gp=1, identifier=4)
session.load(laps=False, telemetry=True, weather=False, messages=False)            
car_data = session.car_data
session.car_data['16'].dtypes

Error message:

Date            datetime64[ns]
RPM                      int64
Speed                    int64 <- Expected float here
nGear                    int64
Throttle                 int64 <- Expected float here
Brake                     bool
DRS                      int64
Source                  object
Time           timedelta64[ns]
SessionTime    timedelta64[ns]
dtype: object

[theOehrly]

The dtypes documented in fastf1.api.car_data don't necessarily need to match those in fastf1.core.Telemetry. The first one is s just what the API returns and that is integer values. The second one is what FastF1 uses internally and that could differ.
You are correct that the documentation is incorrect for Telemetry at the moment.
But it might actually be that I intended for these channels to be floats. Mainly because the Telemetry class supports resampling and then it does interpolation. Sticking with integer values then basically enforces quantization of the resampled data. This probably isn't too bad for RPM, because of the high resolution, but much more noticeable with throttle and speed.

I actually currently tend towards leaving the documentation as is and changing the implementation to explicitly convert to float. But I'll have to think about this a bit more.

Thanks for noticing this!

[leonardobocci]

Understood, thanks, I didn't think of the point on interpolated values and your explanation on internal vs api dtypes makes sense.
I would also lean towards converting to float, even if the source data is coming in integers, to be consistent with docs and support interpolated values.