Open leonardobocci opened 2 weeks ago
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!
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.
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:
Error message: