36MINS Personal TT

klisse · Post by **klisse** » 21 Mar 2005, 12:32

TorInge's total is NOT under 37.

I know I'm a real mongo now but I just wanted to highlight the well known "round off" problem in Elma.
As you may already know, a xx.12 rec, may aswel be a xx.129 drive as a xx.120 drive.

When counting TT's it is a big different in "real" TT and Elma TT.

If we extends a recs decimals from 2 to 3 digits we could do this simple calculation:

On average an elma rec shows (00,009 + 00,000)/2 = 00,0045 sec less then real time: (closer to 00,005 for more decimals).
For all 54 internals 00.0045*54 = 0,243 sec.
That would make TorInge's real TT: 36:59,95 + 0,243 = 37:00,193 -> 37:00,19
Or in other words: He has a real TT somewhere between 36:59,95 and 37:00,44.
If you calculate the possibility that TorInge's total is less then 37 you will find that it is very unlikely ( one to many millions I quess).

So lets see who reach the "real" under 37 TT first.

Lukazz · Post by **Lukazz** » 21 Mar 2005, 12:34

klisse wrote:TorInge's total is NOT under 37.

I know I'm a real mongo now but I just wanted to highlight the well known "round off" problem in Elma.
As you may already know, a xx.12 rec, may aswel be a xx.129 drive as a xx.120 drive.

When counting TT's it is a big different in "real" TT and Elma TT.

If we extends a recs decimals from 2 to 3 digits we could do this simple calculation:

On average an elma rec shows (00,009 + 00,000)/2 = 00,0045 sec less then real time: (closer to 00,005 for more decimals).
For all 54 internals 00.0045*54 = 0,243 sec.
That would make TorInge's real TT: 36:59,95 + 0,243 = 37:00,193 -> 37:00,19
Or in other words: He has a real TT somewhere between 36:59,95 and 37,044.
If you calculate the possibility that TorInge's total is less then 37 you will find that it is very unlikely ( one to many millions I quess).

So lets see who reach the "real" under 37 TT first.

yes you are a real mongo now *confuzing*

sierra · Post by **sierra** » 21 Mar 2005, 13:21

klisse wrote:TorInge's total is NOT under 37.

I know I'm a real mongo now but I just wanted to highlight the well known "round off" problem in Elma.
As you may already know, a xx.12 rec, may aswel be a xx.129 drive as a xx.120 drive.

When counting TT's it is a big different in "real" TT and Elma TT.

If we extends a recs decimals from 2 to 3 digits we could do this simple calculation:

On average an elma rec shows (00,009 + 00,000)/2 = 00,0045 sec less then real time: (closer to 00,005 for more decimals).
For all 54 internals 00.0045*54 = 0,243 sec.
That would make TorInge's real TT: 36:59,95 + 0,243 = 37:00,193 -> 37:00,19
Or in other words: He has a real TT somewhere between 36:59,95 and 37,044.
If you calculate the possibility that TorInge's total is less then 37 you will find that it is very unlikely ( one to many millions I quess).

So lets see who reach the "real" under 37 TT first.

recs are one thing, but he sent his actual state.dat

sorry, you're wrong

klisse · Post by **klisse** » 21 Mar 2005, 13:49

recs are one thing, but he sent his actual state.dat

sorry, you're wrong

So stat show correct time?
e.g a 14.015 rec becomes 14.02 in stat?

If so, my post was really mongo.

ELMA PRO · Post by **ELMA PRO** » 21 Mar 2005, 14:30

it doesnt even matter - in elma, times are measured to 2 decimal places. Doesn't matter what replays are/can be measured to...his stats.txt says his total time is 36:xx therefore it is 36:xx

klisse · Post by **klisse** » 21 Mar 2005, 15:07

ELMA PRO wrote:it doesnt even matter - in elma, times are measured to 2 decimal places. Doesn't matter what replays are/can be measured to...his stats.txt says his total time is 36:xx therefore it is 36:xx

All programs has buggs you know (e.g. a bug bounce is not accepted)...
So the question is if there should be a corrected stat.txt, where the mathematics are more accurate.

petsen · Post by **petsen** » 21 Mar 2005, 15:17

klisse does have a good point so dont, go saying "YOUR WRONG" just yet..

I never actually thought about that it affects the tt when you put it like klisse does... I even think this is a correct worthy problem that needs to be solved either in a new patch or in Elma 2.... yes i said.. me.. who has always been against elma 2... I think it would be better if the math is done right.

Flyrre · Post by **Flyrre** » 22 Mar 2005, 00:08

klisse wrote:TorInge's total is NOT under 37.

I know I'm a real mongo now but I just wanted to highlight the well known "round off" problem in Elma.
As you may already know, a xx.12 rec, may aswel be a xx.129 drive as a xx.120 drive.

When counting TT's it is a big different in "real" TT and Elma TT.

If we extends a recs decimals from 2 to 3 digits we could do this simple calculation:

On average an elma rec shows (00,009 + 00,000)/2 = 00,0045 sec less then real time: (closer to 00,005 for more decimals).
For all 54 internals 00.0045*54 = 0,243 sec.
That would make TorInge's real TT: 36:59,95 + 0,243 = 37:00,193 -> 37:00,19
Or in other words: He has a real TT somewhere between 36:59,95 and 37:00,44.
If you calculate the possibility that TorInge's total is less then 37 you will find that it is very unlikely ( one to many millions I quess).

So lets see who reach the "real" under 37 TT first.

But if everybody for as long as everybody can remember has counted TT the same way as we always do, why change now? Then it would not be certain that DZ broke 40 min limit etc.

His TT is for sure under 37 min since we count TT in the way we always do.

Juski · Post by **Juski** » 22 Mar 2005, 02:28

sierra wrote:sorry, you're wrong

I must say that you have no right to discard that so easily, yes i agree he is under 37. But when you measure the times of the recs, you are measuring the actual time.

klisse wrote:So stat show correct time?
e.g a 14.015 rec becomes 14.02 in stat?

If so, my post was really mongo.

State show the correct time and 14,015 is 14,01 in state. because if you finish a level at e.g 14.049 the timer hasn't passed 14.05 yet so it would be mongo if the timer already showed 14.05 then?

teajay · Post by **teajay** » 22 Mar 2005, 06:45

Yet, the system is like that, and that doesn't make a difference for that toringe is under 37 minutes. It is not wrong, it is just the way it is. We could throw in some bunch of new WR's because they're a third decimal faster?

It's something like a false reason to make up some dipshit, just like now happens in america, the "Terri" affair.

psteve · Post by **psteve** » 22 Mar 2005, 10:13

while it is possible and in fact highly likely that the exact times of all 54 rides totalled would be over 37mins, his tt in elma is definetely under 37 because tt is measured by adding up the state times. i think klisse is correct in showing how all his drives could be greater than 37, but he is wrong to say toringe's tt in not under 37.

zworqy · Post by **zworqy** » 22 Mar 2005, 13:49

What does it matter anyway? I'm sure TorInge can improve 0,1-0,2 secs more if he has to.

Post by **Abula** » 22 Mar 2005, 19:21

We all knew and know the rules. The player has 36mins tt when stats.txt says so. No sense to think any other ways to calculate it.

Also I'm pretty sure that the possibility is not that bad (one to million). Some mathematic guru could solve this.

John · Post by **John** » 22 Mar 2005, 21:03

Abula wrote:Some mathematic guru could solve this.

I immediately thought of Phillip

ribot · Post by **ribot** » 22 Mar 2005, 21:07

klisse wrote:TorInge's total is NOT under 37.
On average an elma rec shows (00,009 + 00,000)/2 = 00,0045 sec less then real time: (closer to 00,005 for more decimals).
For all 54 internals 00.0045*54 = 0,243 sec.
That would make TorInge's real TT: 36:59,95 + 0,243 = 37:00,193 -> 37:00,19
Or in other words: He has a real TT somewhere between 36:59,95 and 37:00,44.

first of all yiour calculation is wrong. i don't know where you get your numbers from, but:
- your averege time is statistical, not real
- the error of a time depends on its rendering
- the error of a time is likely to be bigger on longer levels, and bigger than 0.01
so your calculation does not show a real time.

in elma, for example, every time ground is touched, there is an error calculation, that depends on the rendering rate, which depends on vsync and other factors. this means you don't know exactly what the error time is, because it depends on every level, how many times your wheel touches ground, and the rendering of every individual play.

apart from that, elma uses physics that are not calculated exactly, something similar to the euler method, and that too depends on the rendering rate. for example, the wheel is not exactly round when elma drives on corners.

it's not only the rendering rate, but also where the calculations happen to render. if you dont drive on any corners, for example, it's theoretically possible to drive exact. that's highly unlikely though.

also, i don't know how elma fixes the errors. but maybe there is a reason why you can make your bike jump in the start, if the wheel is stuck between tiny polygons. this is a bug, or a work-around to make easier physics. it seems like errors in the time for me.

another problem, is in animal farm, when the bikes goes strange, when it's stuck between two lines (as if one wheel falls into a part of a polygon looking like a V). this too is a bug which most probably gives error calculations.

then, if and when you take apples and touch flowers - they will be in slightly difference positions in the level.

yet another problem, is that computers don't calculate numbers with many decimals right. since i don't have elma source code, i don't know how erroneous this is, but it is likely that this is another inaccuracy with elma. different gfx engines can have different calculation precision, unless, which is unlikely, there is a program included to calculate more exact numbers.

conclusion: elma is not exact at all, it is not a game made for accurate time measurement. so the "real" time cannot be calculated without the recs. second of all, elma is not made for accuracy. with the recs and levels however, it might be possible to make a program that calculates the real time. it will not be the elma time, but could be a time calculated with exact mathematics in the physics formulas.

The_BoneLESS · Post by **The_BoneLESS** » 22 Mar 2005, 21:21

Mathematic is shit

State.dat is always correct

Ky.Jelly · Post by **Ky.Jelly** » 22 Mar 2005, 21:44

jeez ribot, yuo doing some owning with the math ;p
its is kinda interesting though, klisse did raise some good debate or point i should say that is at least interesting to explore even if not correct

jaytea · Post by **jaytea** » 23 Mar 2005, 12:25

you dont need a math guru for this

on each level, a person's time could be up to 0.01 slower than the one displayed in the state. if t0r has 14.07 in wu for example, his time could be anywhere between 14.070 and 14.07999999999 (a value slightly less than 14.08) so 14.07 <= his time < 14.08 since any time in that range would be rounded down to 14.07 by elma. that's 0.01 uncertaintly for 1 level, 54 levels means his tt could be up to 0.54 sec higher

probability he is currently under is (37.00.00 - 36.59.95) / 0.54 * 100 = 9.3%

but either way, tor is officialy under. and even if some ppl stil doubt that based on the above explanation, im sure his tt will soon be under 36.59.46

sierra · Post by **sierra** » 23 Mar 2005, 14:46

owned

ribot · Post by **ribot** » 23 Mar 2005, 23:42

you think it can be wrong because it says +- 0.01 in rec mode? i have had a rec that is 2 hundreds wrong in that case. common sense says in longer levels the errors can be bigger.

milagros · Post by **milagros** » 24 Mar 2005, 00:14

rec always goes 30 frames/sec that means the time difference is always same

Zweq · Post by **Zweq** » 24 Mar 2005, 00:31

according to teh records it seems he realy tried, gota apperciate that oki, though i don like bein teh 2nd. KIK:D!

zworqy · Post by **zworqy** » 24 Mar 2005, 01:23

milagros wrote:rec always goes 30 frames/sec that means the time difference is always same

WTF did you just say?

milagros · Post by **milagros** » 24 Mar 2005, 02:30

i meant that +-0.02 is always same, doesnt depend on the length of the rec

Kopaka · Post by **Kopaka** » 24 Mar 2005, 10:52

But the 0,01-0,02 whatever difference in rec doesn't matter, state doesn't take it times from the replays ok.

sierra · Post by **sierra** » 24 Mar 2005, 11:16

omg did you guys even understand what jaytea says, he wasn't talking about rec timer

he said since 14,000 counts as 14.00 as does 14,0099999999999999 (recurring) , that gives an allowance of 0,010 on every level

jaytea · Post by **jaytea** » 24 Mar 2005, 11:19

DONT BE DUMB

IN STATE.DAT IT SHOW THE TIME ROUNDED DOWN TO THE NEAREST 0.01. OBVIOUSLY THIS MEANS THAT ALL OF T0R'S RIDES MIGHT BE 0.01 MORE THAN THE STATE SAYS. AT MOST HIS TT COULD BE OFF BY 54 * 0.01 = 0.54 SECONDS OKI??

EasyGijs · Post by **EasyGijs** » 24 Mar 2005, 12:27

jaytea wrote:you dont need a math guru for this

probability he is currently under is (37.00.00 - 36.59.95) / 0.54 * 100 = 9.3%

this isn't true

I'm too lazy to do the maths now, but there will be a normality shape like ditribution. So the chance for 37.00.22 is much higher as the chance for 36.59.95

CaeZar · Post by **CaeZar** » 24 Mar 2005, 12:34

14:079 is just more specific, still 14:07 ffs, just understand...

ribot · Post by **ribot** » 24 Mar 2005, 14:24

milagros wrote:rec always goes 30 frames/sec that means the time difference is always same

i dunno what kind of calculation this is. but at least every calculation is rounded, so you get more error each calculation.

but if rec always is 30 per sec you can count the frames of a rec and the time will always be exact?

Juski · Post by **Juski** » 24 Mar 2005, 15:20

CaeZar wrote:14:079 is just more specific, still 14:07 ffs, just understand...

Yes but 14.07 is under 14.075 while 14.079 is NOT under 14.075

sierra · Post by **sierra** » 24 Mar 2005, 17:01

ribot wrote:but if rec always is 30 per sec you can count the frames of a rec and the time will always be exact?

time would not necessarily be exact. 30 frames a second means each complete frame lasts for 0.03333333 (recurring) seconds. However, what's to say a ride will always last for an integer number of frames? Seems more likely that the final frame will only exist for less than 0.03 seconds

Phillip · Post by **Phillip** » 24 Mar 2005, 19:35

ribot wrote:but if rec always is 30 per sec you can count the frames of a rec and the time will always be exact?

You don't get it, do you?

Yes, the rec stores the position of the bike 30 times per second. But, elma's own calculation is more precise than that. If you want to calculate the exact time of a rec, you have to see how far the bike was from the flower on the last of those recorded frames, what speed the bike had, and then calculate how much time the bike would use the rest of the way to the flower with the current speed/acceleration.

This is how the elma rec timing prog works. Even though elma only stores the position 30 times per second, elma (of course) does this same precise calculation (based on the data available in the game). Your suggestion ("count the frames of a rec and tell the time") is not precise, that's what is done when you press Ctrl+alt+Enter in elma, and get a time that is only approximately right.

To stay on topic:
klisse's calculations are correct, but I agree with what has already been pointed out: That would be a new way of counting total times. And still, his calculations were based on probability, TorInge could have been "lucky" and driven only times like 14.070, (with a zero following the hundred).
So without having the recs and actually having done the measurement, you can't say (even with this "new" way of calculating total times) with 100% certainty that his total is not under 37

ribot · Post by **ribot** » 26 Mar 2005, 11:53

I was talking about the time of a rec. Why does it matter exactly when the flower is touched when counting the time and not exactly when ground is touched, or an apple?

sierra · Post by **sierra** » 26 Mar 2005, 13:22

ribot wrote:I was talking about the time of a rec. Why does it matter exactly when the flower is touched when counting the time and not exactly when ground is touched, or an apple?

Time of a rec = time taken to touch flower. Whatever happens in between is irrelevant

jaytea · Post by **jaytea** » 25 Aug 2020, 09:20

jaytea wrote: ↑23 Mar 2005, 12:25 you dont need a math guru for this

on each level, a person's time could be up to 0.01 slower than the one displayed in the state. if t0r has 14.07 in wu for example, his time could be anywhere between 14.070 and 14.07999999999 (a value slightly less than 14.08) so 14.07 <= his time < 14.08 since any time in that range would be rounded down to 14.07 by elma. that's 0.01 uncertaintly for 1 level, 54 levels means his tt could be up to 0.54 sec higher

probability he is currently under is (37.00.00 - 36.59.95) / 0.54 * 100 = 9.3%

but either way, tor is officialy under. and even if some ppl stil doubt that based on the above explanation, im sure his tt will soon be under 36.59.46

Christ, you're a fucking noob.

Your maximum uncertainty of 0.01 is merely theoretical. Let us consider instead a measurement to which we have access in practice: replay time, precise to 3 decimal places. We proceed:

- Elma truncates the 3rd digit
- So for each of the 54 levels, our error margin is between 0.000 and 0.009; that is, 10 values in increments of 0.001.
- Total error margin is between 0 and 0.009 x 54 = 0.486
- t0r's TT at the time of writing was 36:59.95X where X could take on any value between 0 and 9 with equal probability. Its expected value is therefore 36:59.9545
- With adjustments, we expect t0r's TT to lie somewhere between 36:59:9545 and 37:00.4405
- 36:59.9995 is the highest TT that would qualify t0r for 36min club
- 59.9995 - 59.9545 = 0.045

The problem becomes: what is the probability that the sum of 54 random integers between 0 and 9 is <= 45?

The answer is obviously 0.000000000000000000000000033423305263785776227024572546 (ie. "really fucking small")

pawq · Post by **pawq** » 25 Aug 2020, 11:14

jaytea wrote: ↑25 Aug 2020, 09:20X could take on any value between 0 and 9 with equal probability

No xd

Grace · Post by **Grace** » 26 Aug 2020, 00:22

Zweq wrote: ↑24 Mar 2005, 00:31 according to teh records it seems he realy tried, gota apperciate that oki, though i don like bein teh 2nd. KIK:D!

Good post

36MINS Personal TT

Re:

Re: Re:

Re: