| Author |
Topic: Lap time mystery |
29 replies
|
|
|
|
#1 posted Oct 9th 2019, 19:12:17
|
Quote
|
I can't explain it!
The setting (rubber) is the same, but the net lap time is different (practice). [Pilot will not change.]
|
|
|
|
|
|
#2 posted Oct 9th 2019, 19:18:39
|
Quote
|
I assume you're talking about the net time.
Have you tested between practice laps?
|
|
|
|
Quote ( Ahmet Sonverdi @ October 9th 2019,19:18:39 )
I assume you're talking about the net time. Yes.
Quote ( Ahmet Sonverdi @ October 9th 2019,19:18:39 ) Have you tested between practice laps? No.
|
|
|
|
|
|
#4 posted Oct 9th 2019, 19:25:49
|
Quote
|
Also, the difference is more than 0.001s? That would indeed be surprising if nothing were changed
|
|
|
|
Quote ( Harsh Sheth @ October 9th 2019,19:25:49 )
Also, the difference is more than 0.001s?
That's it: 0.001".
Quote ( Harsh Sheth @ October 9th 2019,19:25:49 ) That would indeed be surprising if nothing were changed I was surprised too.
|
|
|
|
I play because it's a "good" game. I also support this game financially (while being struck by the VAT) because I am interested in the mechanism of the game.
if they cheat with 0.001, I'm sad.
As an example: GPRO - counting to many decimal places - shows us an integer rounded.
Dear Vlad: please! Check the rounding rules.
|
|
|
|
By the way: I would also be interested in a wear-corrected PHA fit. Maybe I would also like to hear about DE weight loss.
Vlad[b/]: These are open questions - I think.
|
|
|
|
|
|
#8 posted Oct 9th 2019, 21:20:13
|
Quote
|
It's a known rounding bug that is fairly rare.
Ultimately practice times don't count for anything anyways, so while it isn't ideal I don't see how it is particularly unfair.
|
|
|
|
|
|
#9 posted Oct 9th 2019, 21:27:33
|
Quote
|
|
I believe that on each lap the driver will make mistakes or minor differences in riding and this is considered in the game's algorithm that brings him closer to reality.
|
|
|
|
Quote ( George Slater @ October 9th 2019,21:20:13 ) It's a known rounding bug that is fairly rare. Ridiculous. Rounding error?
They are important. We would count that.
Quote ( George Slater @ October 9th 2019,21:20:13 )
It's a known rounding bug that is fairly rare.
|
|
|
|
Quote ( Antonio Guzzo @ October 9th 2019,21:27:33 ) I believe that on each lap the driver will make mistakes or minor differences in riding and this is considered in the game's algorithm that brings him closer to reality.
There is no pilot error in net time.
|
|
|
|
Quote ( Tibor Szuromi @ October 9th 2019,20:16:18 ) That's it: 0.001".
isn't that a bit nit-picking
Quote ( Tibor Szuromi @ October 9th 2019,21:31:26 ) They are important. We would count that.
Come on :)
just for context, one eye-blink lasts about 0,1 sec, so what's 0,001 sec in scope of 1,5 minutes
Just thinking... the world must be quite ready if 0,001 sec is a problem :)
|
|
|
|
|
|
|
I had a similar (but different) rounding issue last night - on the new race screen, my FL was 1:13.836, but my race analysis tells me that lap was 1:13.837.
Since it doesn't matter (just like Tibor's doesn't matter) - it's no big deal....
|
|
|
|
Awh I clicked in here thinking this was a new silly game..
|
|
|
|
|
Quote ( Robin Goodey @ October 9th 2019,21:47:45 ) I had a similar (but different) rounding issue last night - on the new race screen, my FL was 1:13.836, but my race analysis tells me that lap was 1:13.837.
Since it doesn't matter (just like Tibor's doesn't matter) - it's no big deal....
I believe its the analysis time that counts (and old screen aswell). Jukka Sireni has confirmed it somewhere on the forums
|
|
|
|
The rounding rules, like everything else in this game, have a random factor in it :rofl: (/s just in case)
|
|
|
|
|
|
#18 posted Oct 10th 2019, 00:22:48
|
Quote
|
|
|
|
Quote ( Ivan Silva @ October 9th 2019,22:31:11 ) I believe its the analysis time that counts (and old screen aswell).
Good if the data were the same, accurate.
From this we can build and analyze.
|
|
|
|
The error is negligible but I'm curious to understand how a rounding can give different result starting from the same set of data and using the same formula... Weird, isn't it? I think it would be extremely hard to try to reproduce this bug in excel, for instance.
|
|
|
|
|
|
|
I'm no pro regarding writing code, but I've read something like this could happen when using floats. It's described here I think: https://www.theregister.com/2006/08/12/floating_point_approximation/
Some quotes from that article:
To understand why we need to understand a little about how floating points are represented internally in the IEEE-754 specification. The key thing is to recognize that floating types do not represent numbers exactly. Internally the value is not a continuous range of numbers; instead it is represented as an exponent multiplied by an arithmetical series (such as, for example, ½1 + ½2 + ½3 + … + ½23). This means that in the range of floating point numbers there are gaps; between any two floating point numbers there is a difference related to smallest element in the arithmetical series (½23 in the example)
So what happens if we have a number that falls into such a gap? Well the system will choose a floating point number that has a close value. For example, the real number ‘.37’ cannot be represented exactly by the arithmetic series described above so, if you assign this number to a floating point, the value stored could actually be ‘0.370000004’
We call the difference between the real value of a number and the actual value of the floating point an approximation error. This error is a fundamental property of floats and with regard to rounding there are two important points; firstly, the approximation can be either under or over the exact number so, for example, imagine that .37 is represented as .369999998 rather than .370000004. Secondly, for a given value the approximation error isn't always the same;
Fundamentally, if you're using floats you’re using an approximate representation and you’ve lost a small amount of information on the exact value of the number. As rounding is a process that requires exact values there simply isn’t a silver bullet solution
|
|
|
|
|
|
Quote ( Josh Clark @ October 9th 2019,21:41:26 ) Quote ( Mikko Heikkinen @ October 9th 2019,21:39:44 )
just for context, one eye-blink lasts about 0,1 sec, so what's 0,001 sec in scope of 1,5 minutes
In this race the difference was $1million :)
/gb/RaceSummary.asp?group=Pro+-+3&Season=72&Race=9
Just curious, who made the fast lap first, you or the other guy?
|
|
|
|
Quote ( Auke Haarsma @ July 3rd 2020,12:53:23 ) Fundamentally, if you're using floats you’re using an approximate representation and you’ve lost a small amount of information on the exact value of the number. As rounding is a process that requires exact values there simply isn’t a silver bullet solution
There is a very simple artifice that is a solution, but I am afraid it's too late for gpro as it would require a lot of changes which are not feasible. But other than that you are most likely correct :P
To avoid this, one needs to just use integers (scaled appropriately), and before displaying divide to get the required decimals (be it 2, 3 or whatever). There is also a nice bonus to it since integer arithmetic should be faster in mostly everything.
|
|
|
|
Does anyone know of a 9 month old thread we could dig up out of the blue and start asking people questions about?
|
|
|
|
Isn't usual suggestion to search the forum? :P
|
|
|
|
Quote ( Daniel Douglas @ July 3rd 2020,16:27:21 ) Does anyone know of a 9 month old thread we could dig up out of the blue and start asking people questions about?
Oh well, didn't look the date of the original post
|
|
|
|
|
|
|
I do wonder though why a rounding error would occur there though, does GPRO use several different kinds of rounding in the same place?
|
|
|
|
|
Deutsch
Español
Română
Italiano
Português
Português
Français
Polski
Русский
Български
Македонски
Српски
Nederlands
Vlaams
Suomi
Lietuvių
Čeština
Magyar
Eesti keel
Slovenčina
Türkçe
Shqip
Ελληνικά
Hrvatski
Bahasa Melayu
Dansk
Pirate
