FAQ  •  Login

Sig. fig. anomaly in acceleration times

<<

Packbat

User avatar

Posts: 953

Joined: Fri Mar 13, 2015 4:07 pm

Location: Eastern Time Zone, USA

Cars: I, being poor, have only my dreams

Post Thu Jun 18, 2015 8:50 am

Sig. fig. anomaly in acceleration times

I noticed something very strange when I was looking at the statistics of cars in the BRC 1955 competition: unlike most stats (which seem to be calculated very precisely) there only seems to be a couple decimal places that vary for the acceleration times. The ["HundredTime"] value in the trim .lua file for all the cars in the competition were either x.xx49999999999 or x.xx49999999998, and looking at other trim .luas I have on my hard drive, the only exceptions to this are cars that have x.xx5 or x.xx99999999999 as the values.

Is this intended behavior? Is this a bug? Is this a side effect of rounding the actual calculation off for display on screen? I'm confused.
<<

Kubboz

User avatar

5-Star Beta Tester
5-Star Beta Tester

Posts: 1297

Joined: Fri Jul 30, 2010 3:24 am

Cars: Skoda Felicia Combi 1.3 MPi LXi

Post Thu Jun 18, 2015 9:36 am

Re: Sig. fig. anomaly in acceleration times

It's a side effect to how the acceleration is calculated. See, there is no simple way to precisely calculate acceleration time (you would first need to do some differential equation stuff. Ouch). So, Automation calculates the acceleration time with an approximation that is close enough. It divides the time into small, 0.005 second steps, and uses the forces acting on the car at the beginning of the step for the rest of that 0.005 s period. Then it looks at the changed forces, sees if its time to shift or not, and adjusts the acceleration again. Since one step is very short, the final acceleration time figure is not off by a significant amount (not if you display it with just one decimal place).

The .lua value is not always a clean x.xx0 or x.xx5 because of how floating-point numbers are represented in the computer.
<<

Packbat

User avatar

Posts: 953

Joined: Fri Mar 13, 2015 4:07 pm

Location: Eastern Time Zone, USA

Cars: I, being poor, have only my dreams

Post Thu Jun 18, 2015 10:48 am

Re: Sig. fig. anomaly in acceleration times

Oh, I see. I had been wondering why I didn't get green/red numbers when I changed my gear ratios unless the displayed 0-100 time changed - that would explain it.

...could you interpolate between steps to get a rough approximation? So if (to make up numbers) the car goes from 99.6 kph at 9.250 seconds to 100.1 kph at 9.255 seconds, you record the 0-100 time as
  Code:
9.250 + 0.005 * (100-99.6)/(100.1-99.6) = 9.254

I know it wouldn't make a difference to the 0-100 times displayed, but it would give us green/red numbers.
<<

Killrob

User avatar

Developer - Lead Beta Tester/Producer/German Efficiency Expert
Developer - Lead Beta Tester/Producer/German Efficiency Expert

Posts: 3711

Joined: Fri Mar 11, 2011 1:00 am

Location: Lower Hutt, New Zealand

Cars: I owned a Twingo... totally bad-ass!

Post Thu Jun 18, 2015 6:26 pm

Re: Sig. fig. anomaly in acceleration times

In principle an interpolation like this would be possible because taken small enough steps, a linear function is always a good approximation to a smooth, continuous function. :)
<<

Packbat

User avatar

Posts: 953

Joined: Fri Mar 13, 2015 4:07 pm

Location: Eastern Time Zone, USA

Cars: I, being poor, have only my dreams

Post Fri Jun 19, 2015 1:40 am

Re: Sig. fig. anomaly in acceleration times

That was my thinking. There might be cleverer ways to do it, but apart from when you're changing gears there shouldn't be any moments when your acceleration changes abruptly. You'd need to make sure that you don't record your 0-100 time twice if you happen to change gears right after crossing that speed threshold, but that's the only complexity I can think of.

Return to Developer Questions

Who is online

Users browsing this forum: No registered users and 0 guests