12

# Calculating wrong time for 42.195 in race predictor (Read 174 times)

Enric Hilversum

Just noticed:

When you set to distances in the race time predictor and set the predictor to 41,195 (or 42, for that matter) the time returned is extremely low and seems to be a prediction for a half marathon.

You can use these values (almost random, close to some of my recent runs):

• 21 KM  time: 1:46:11
• 23 KM  time: 1:44:16

Result:

Predicted time: 1:31:52
Predicted pace: 2:12 / km

For the half marathon distance the results do however make sense (1:46:12 for the same input values)

Regards,

Enric

A Saucy Wench

The solution is clear.  Run 42 miles instead of 42 km.  Then it drops you down to 2:01/mile

The problem is trying to do a prediction off of two times where your longer race is a shorter overall time than your shorter race.  So by that logic, you will run an even faster marathon.  But a really freaking slow 5K.

Use one of them, not both.   The purpose of 2 races is if you have say a 5K and a HM, both done recently, both representative of your current fitness, then it can override the generic pace degredation/distance value and replace it with a more personalized one.

I have become Death, the destroyer of electronic gadgets

"When I got too tired to run anymore I just pretended I wasnt tired and kept running anyway" - dd, age 7

The calculator works just fine for 42km or 41.195km as long as you input valid data.

You shouldn't use those two race times that you listed to try and predict your marathon time.

The predictor generates a coefficient from the two race times. It assumes your pace slows as your race distance goes up, but that the rate of decline is different among individuals. Rather than use an average coefficient, as the McMillan and other calculators do, it tries to calculate your own personal coefficient.

For it to work, you need to chose two race distances that are not so close together and that both realistically represent your true fitness. The two times you chose obviously can't both be representative of your true fitness, since your an faster for the longer distance. Based on that the predictor should naturally assume that the longer the run, the shorter the time it takes you.

mta: or what Ennay said.

Runners run.

It would be a pretty amazing calculator that could predict race times based on random runs. I am surprised that anyone would think such a calculator could be invented.

HobbyJogger & HobbyRacer

Maybe try a calculator that takes just one time, and uses some standard (guess) coefficient.

It's a 5k. It hurt like hell...then I tried to pick it up. The end.

Enric Hilversum

Sorry mates,

It doesn't matter if the data is totally random or Real Offically Meassured Race Time(TM), nor does it matter in which order they are. If the algorithm does not work correctly with distances / times close to each other it means that it is wrongly implemented. I am not talking about sports here but about programming and math. I am sorry for not being able to provide the code itself but the calculation is done via ASP.NET on the server and I have no idea about .NET.
BTW: I tried checking it with HTTPFoX and the Web Developer toolkit assuming it was implemented in Javascript.

The formula is:

T2 = T1 x (D2 / D1)C

NOTE: C is a constant, in this case set to 1.08, this value is irrelevant in this case

And D2 should be averaged from Race 1 and Race 2. I suppose that with only 2 values the calculation would simply be

(Race1+Race2)/2

Here another example I got with the calculator using two datasets:

Race1: 21km  T: 1:40:00

Race2: 23km  T: 1:45:00

Prediction for 42km: 2:25:02

I will now use a desktop calculator to get the results manually to demonstrate my point. Again, the data is random and used solely for making it more convenient to calculate with (yet it makes sense):

1. I convert the time to minutes and seconds R1=6000 / R2=6300 (that's hours*3600 and mins*60)
2. I use (R1+R2)/2 to get the average: 6150 sec
3. Converting back to H:mm:ss = 1:42:30 for a distance of (21+23)/2 = 22km
4. Now I use this value in the formula as D1 and T1 (in seconds)

5. T2=6150sec*(42km/22km)*1,08
6. = 6150sec*1.91*1.08 =12680,18sec
7.  rouding down = 12680sec
8. converting to H:mm:ss = 3:31:20

I have used the very same formula and got a very different and sound result.

I guess that at some point one of the conversions from HH:mm:ss is missing as I get a very close result when I skip converting the minutes to seconds:

Taking the same data I will now skip the conversion of the minutes and just add them:

1.         1:40:00 = (1h*3600)+40min = 3640  AND 1:45:00 = 3645
2.          (R1+R2)/2 = 3642
3.           T1=3642*1.91*1.08=7513sec = 2:05:13

Conclusion: A step in the conversion from hours:minutes:seconds to seconds fails for a cause unknown.

Sorry mate, but your math is different from the algorithm, hence the different results. The algorithm (as people before me have tried pointing out) tries to estimate how much you slow down when the distance increases. Your math, taking the average between two sets of data, does not do that. The large discrepancy is down to the fact that your two data sets are "wrong" in the sense that if you can run 21 km in 1h40min (race effort), then it is pretty unusual to be able to run another 2 km in 5 min (which equates to a 5k in 12:30).

Also, why would you think that the results:

• 21 KM  time: 1:46:11
• 23 KM  time: 1:44:16

Could be used to calculate a race time? If your longer race (or run) was faster than your shorter run you need to recongize that this will break any calculator. This bad starting data will tell you that you will run 1000KM at a faster pace than you could run 1KM.

If you select realistic data to input you will get a more realistic result. (They don't need to both be races, but the two runs that you enter need to be at equivalent effort without change of fitness between the two runs).

You are missing the forest for the trees.

You are also missing some important information that's written in black and white at the bottom of the page: If you enter a second distance, the predictor will automatically make use of this second value to create a personalized coefficient, which will improve the accuracy of the predicted time. You can also type in your own performance factor to adjust the calculation. Typical values are 1.06 to 1.10.

In both of your examples, your time for the longer distance was a faster per kilometer pace than for the shorter distance. This is an impossible scenario if both times are representative of your real fitness. It will result in a coefficient less than 1.

If you are using two race times that are that close in distance, just pick the better one and leave the other one out. This will cause the calculator to use the average coefficient of 1.08 and it will work just like ever other race time predictor.

By the way when I change the time for race 2 to something that actually makes sense like 1:54:00, it predicts a 3:58:03 marathon. Seems about right.

Race1: 21km  T: 1:42:00

Race2: 23km  T: 1:54:00

Prediction for 42km: 3:58:03

Runners run.

A few years back I put in two races into the calculator, one on a hilly route and one on a flat route. Both were well run and represented my fitness on each course, but the flat route was longer and I ran a faster pace. This is when I figured out everything that is being discussed above.

I have to imagine that for everyone willing to post about about their confusion there are a few not posting, suffering quietly with their result, contemplating theropy or another few beers. Therefore, I wonder if the calculator can be adjusted to throw out the shorter race if slower automagical and just give a result based on the one result?

A Saucy Wench

Sorry mates,

It doesn't matter if the data is totally random or Real Offically Meassured Race Time(TM), nor does it matter in which order they are. If the algorithm does not work correctly with distances / times close to each other it means that it is wrongly implemented. I am not talking about sports here but about programming and math. I am sorry for not being able to provide the code itself but the calculation is done via ASP.NET on the server and I have no idea about .NET.
BTW: I tried checking it with HTTPFoX and the Web Developer toolkit assuming it was implemented in Javascript.

Seriously,  Mikey and I weren't guessing at what the issue was, we were TELLING you that this is how THIS calculator works.  Period.  We are not wrong, we've been here awhile mate.

Your error is assuming that D2 is an average of the input which is false. When inputing the OPTIONAL second input the 2 data points ARE d1 and d2 and used to calculate C which then replaces the default 1.08 used in the sequential calculation of the desired predicted distance.   If you use one race C=1.08.  If you use 2 races C= calculated from the first 2   and then 42km becomes D3

I have become Death, the destroyer of electronic gadgets

"When I got too tired to run anymore I just pretended I wasnt tired and kept running anyway" - dd, age 7

Seems that it would avoid confusion if it just gave an error result or something if the longer distance entered was at a faster pace than the shorter distance entered.

Age: 45 Weight: 200 Height: 6'2" (Goal weight 200)

2013 Goal #1 - Sub 4 hour First Marathon - 3:48:09 at the Flying Pig 5/5/13!

2013 Goal #2 - Run my age in 10K.  44:51 on 9/14/13!

mileage hound

If you run a longer distance at a faster pace, your running is wrongly implemented and no calculator is going to be able to help you.  Garbage in, garbage out.  Why are you trying to base the performance of the calculator off of nonsense data?  Just put in your real race times.

Sorry mates,

It doesn't matter if the data is totally random or Real Offically Meassured Race Time(TM), nor does it matter in which order they are. If the algorithm does not work correctly with distances / times close to each other it means that it is wrongly implemented. I am not talking about sports here but about programming and math. I am sorry for not being able to provide the code itself but the calculation is done via ASP.NET on the server and I have no idea about .NET.
BTW: I tried checking it with HTTPFoX and the Web Developer toolkit assuming it was implemented in Javascript.

The formula is:

T2 = T1 x (D2 / D1)C

NOTE: C is a constant, in this case set to 1.08, this value is irrelevant in this case

And D2 should be averaged from Race 1 and Race 2. I suppose that with only 2 values the calculation would simply be

(Race1+Race2)/2

Here another example I got with the calculator using two datasets:

Race1: 21km  T: 1:40:00

Race2: 23km  T: 1:45:00

Prediction for 42km: 2:25:02

I will now use a desktop calculator to get the results manually to demonstrate my point. Again, the data is random and used solely for making it more convenient to calculate with (yet it makes sense):

1. I convert the time to minutes and seconds R1=6000 / R2=6300 (that's hours*3600 and mins*60)
2. I use (R1+R2)/2 to get the average: 6150 sec
3. Converting back to H:mm:ss = 1:42:30 for a distance of (21+23)/2 = 22km
4. Now I use this value in the formula as D1 and T1 (in seconds)

5. T2=6150sec*(42km/22km)*1,08
6. = 6150sec*1.91*1.08 =12680,18sec
7.  rouding down = 12680sec
8. converting to H:mm:ss = 3:31:20

I have used the very same formula and got a very different and sound result.

I guess that at some point one of the conversions from HH:mm:ss is missing as I get a very close result when I skip converting the minutes to seconds:

Taking the same data I will now skip the conversion of the minutes and just add them:

1.         1:40:00 = (1h*3600)+40min = 3640  AND 1:45:00 = 3645
2.          (R1+R2)/2 = 3642
3.           T1=3642*1.91*1.08=7513sec = 2:05:13

Conclusion: A step in the conversion from hours:minutes:seconds to seconds fails for a cause unknown.

Your math and assumptions are wrong.  Others have clearly explained this.  C is not "irrelevant", in fact it is the basis of the prediction.  The given algorithm is in fact fairly advanced in that, rather than assuming 1.08 for everyone, it gives you the option of using multiple race times to get a better individual approximation.

2013 goals:  Somehow get healthy again.

"If you want to be a bad a\$s, then do what a bad a\$s does.  There's your pep talk for today.  Go Run." -- Slo_Hand

"Determined is what I am. Maybe a little sick in the head? Ok who am I kidding ALOT sick in the head" -- rockenmamaof5

If you run a longer distance at a faster pace, your running is wrongly implemented and no calculator is going to be able to help you.  Garbage in, garbage out.  Why are you trying to base the performance of the calculator off of nonsense data?  Just put in your real race times.

Not really.  Just as xhristopher explained, you could have a tough course or less than ideal conditions that could result in exactly what is being described as happening.

I have a 14K and a 15K race that are run within a month of each other.  The 15K course is harder and generally has worse weather, but if the 14K race was the one that had the tough course then it could very well be that my avg pace on the 14K could be worse than my avg pace on the 15K even if I ran both races as well as I could.

Age: 45 Weight: 200 Height: 6'2" (Goal weight 200)

2013 Goal #1 - Sub 4 hour First Marathon - 3:48:09 at the Flying Pig 5/5/13!

2013 Goal #2 - Run my age in 10K.  44:51 on 9/14/13!

Actually, just looking back at my PR's I've got the exact scenario.

10K on June of this year.  Nice weather, very easy flat course.  Avg pace 7:34.

5 miler in August of this year.  Not terrible weather, but not as nice as June.  Tougher course.  Avg pace 7:39.

I don't feel that I wrongly implemented my race in August.  I didn't do as well as I had hoped, but it just didn't happen that day.

I enter those races into the calculator and it is going to blow up.

Age: 45 Weight: 200 Height: 6'2" (Goal weight 200)

2013 Goal #1 - Sub 4 hour First Marathon - 3:48:09 at the Flying Pig 5/5/13!

2013 Goal #2 - Run my age in 10K.  44:51 on 9/14/13!

12