New training metric: Daniels Points
已查看 2,025 次
跳至第一个未读帖子
Sean Rhea
2009年11月27日 18:24:402009/11/27
收件人 Golden Cheetah Mailing List
All,
This email is about a new ride metric I've been using. It is a very
long email. Apologies in advance.
As some of you already know, I skipped road season last year and tried
my hand at running. I was a runner before I was a cyclist, and most
of what I learned last year was that my hips still don't like running.
:)
On the other hand, I also discovered a really nice book, "Daniels
Running Formula". It has since become my favorite training book, and
it's influenced the way I train for cycling as much as any other book
at this point. The author is a guy named Jack Daniels (no kidding),
who in the 50s and 60s was an Olympic medalist in the modern
pentathlon (I had to look it up, too). He later became a running
coach and spent most of his career at SUNY Cortland, where his team
took 8 NCAA Div III national titles and he coached 30 individual
national champions and 130 All-Americans. Quite a record.
Anyway, like Allen, Coggan, and Skiba, he also has a point system for
tracking training stress that he describes in the book. It's a lot
like TSS/BikeScore, in that faster running counts more than slower
running, but since there aren't power meters in running he bases the
system off fractions of a runner's pace at VO2Max. Daniels doesn't
seem to intend his system to be used to help runners "peak" so much as
to avoid injury/overtraining. He has no notion of a PM chart, for
example.
The wind plays a pretty small factor in running compared to cycling.
It's true that elite marathoners draft each other, but even at a
4-minute mile, the wind accounts for only something like 10-20% of a
runner's effort. Compared to cycling at an elite 4k pursuit pace,
that's nothing at all. So it occurred to me that I could translate
Daniels' Table 2.2, which is based on fractions of VO2Max pace, into a
table based on percent of VO2Max power without too much error.
Furthermore, I could assume that VO2Max power is pretty close to 120%
of FTP/CP power (following Allen and Coggan's zones), and I'd get a
table of points per minute as a function of percentage of power at
FTP/CP.
I did just that, and a graph is attached. The x-axis is the
percentage of FTP power, and the y-axis is points per minute. The red
line (with plus marks) shows the values from Daniels' table, and the
green line shows a curve I fit to it. In the book, Daniels doesn't
give a justification for his points system, but I think this plot
makes it pretty clear what he had in mind: points per minute should be
proportional to the fourth power of power output divided by power at
FTP/CP.
If you've read the justifications behind TSS or BikeScore recently,
that fourth power bit should sound awfully familiar. Page 9 of
Coggan's "Training and racing using a power meter: an
introduction", for example, says
blood lactate (% of lactate at LT) = power (% of power at LT) ^ 3.90
for data "collected from a large number of cyclists". It wouldn't
surprise me if Daniels was himself looking at data from a bunch of
runners. There's a sweet pic of him in the book driving a golf cart
alongside a runner on the track in order to capture a bag of expelled
air (to measure VO2).
There are two big differences and one little one between Daniels'
points system and TSS/BikeScore. The little one is that Daniels
scales his points so that an hour at FTP/CP is worth 33 points,
whereas TSS/BikeScore scale so that an hour at FTP/CP is worth 100.
Keep that in mind when you're comparing the two.
The first big difference between Daniels' points and TSS/BikeScore is
that Daniels' points are what Dan Connelly likes to call "linear in
time": adding together the points values of two workouts gives the
same number as the point value of a workout that consisted of doing
the two workouts as one combined workout.
Why does this matter? Well, go read any of Dan Connelly's past posts
on the subject. Or, for a fun experiment, take any of your rides in
GC, export to CSV, add a bunch of new data points to the end that have
zero power output and non-zero speed, as though you'd coasted downhill
for a while after the ride, then re-import into GC. Your
TSS/BikeScore for the ride goes way up, even though you didn't do any
more work! On many rides in Northern California, you're either
pedaling hard uphill or riding down a twisty, fast descent, and all
that descending at near-zero power causes real problems if you're
tracking your stress with TSS/BikeScore. Daniels only gives you
points for non-zero power, and you only get a fair number by riding at
aerobic pace or higher, so his point system doesn't suffer from this
problem.
The second big difference between Daniels' points and TSS/BikeScore is
that Daniels gives you far less credit for long, slow rides. For
example, last weekend I rode for 3:45 at 72% of FTP/CP. I kept my
pace really steady, so that my NP/xPower was only 3 watts higher than
my average power. My BikeScore for that ride was 209. If you believe
that BikeScore/TSS are the "right" metric, then, you believe that ride
was just as hard as if I'd ridden *two* 1-hour, all-out time trials
that day. I've never actually done two 1-hour, all-out TTs in one
day, but I'm pretty sure the four-hour ride I did do was much, much
easier.
In contrast, Daniels gives me only 36 points for my four-hour ride,
indicating that it was just slightly harder than a single 1-hour,
all-out TT (which he assigns 33 points). Judging by how I felt after
the ride, that seems much closer to the right scale to me.
This relative weighting of endurance versus intensity seems to be an
important one, and as I've thought more about Daniels' system, I think
he is closer to the mark. Take, for another example, the week of June
2, 2008, when I was gearing up for Fitchburg Longsjo stage race in
Massachusetts. I rode 16.5 hours that week, including one 6-hour ride
and another 4.5 hour one. I also did FTP intervals and some VO2Max
intervals. My BikeScore for that week was 807.
Now, I won't lie. That was a hard week. If I did it too many times
in a row, it would get pretty old, and my experience tells me that if
I kept up the VO2Max intervals for too long I would have burnt out
after a month or two. But think about what a BikeScore of 807 is
supposed to mean based on the scaling factor: that the stress I
endured that week was roughly equivalent to riding EIGHT 1-hour,
all-out time trials. You've got to be kidding me. Had I done that, I
would have burnt out before the week was even done.
Daniels, on the other hand, assigns that week 123 points, indicating
that it was about as stressful as doing FOUR 1-hour, all-out time
trials. That's still a lot, but it's not totally unreasonable given
the rides I did. I did 38 minutes at FTP on Wed. Daniels gives me
pretty close to 38/60 points for that one. I also did 24 minutes at
120% of FTP on Fri, and Daniels calls that another TT worth. If we
say that each of the long rides was as hard as a TT as well, that's
pretty close to four. Okay, so not so outlandish. It's still pretty
high, and I'm not sure I could actually do four 1-hour, all-out TTs in
a week. But I *know* I couldn't do 8.
To be clear, I'm not saying that a stress metric should de-value long
rides. If you're going to race four hour races, you need to do some
four hour rides. If you're going to do four-day stage races, you
probably need to ride several four-plus hour rides on consecutive
days. All fitness is specific, and I get that. What I am saying is
that I'm pretty sure the stress my body undergoes during a four hour
endurance ride is *not* anything like the stress it would incur from
two back-to-back 1-hour, all-out time trials. And if I want my stress
metric to help me avoid overtraining/burnout, it has to get that part
right.
Okay, enough about Daniels points versus TSS/BikeScore.
I added Daniels' points to GC in commit 3429f2d. To compute them, I
first compute the 25-second exponentially weighted average of power
during the ride, just like we do for BikeScore. You can read Skiba's
paper for a justification of that part, but it's basically that blood
lactate takes a while to adjust to a new load. It also has another
benefit in that Daniels doesn't give point values for really high
power, since he assigns points per minute, and you just can't go that
hard for a minute. Smoothing over 25 seconds limits us to something
close to the same range of powers Daniels is working with. Given the
smoothed power values, I assign a point value to each sample by
dividing the average power at that point by FTP/CP, raising it to the
fourth power, and then scaling so that 1 hour at FTP equals 33 points.
I sum up all the points to get the value for the ride. That's it.
If you want to try using Daniels' points in the PM chart, you can also
apply the attached patch. Just be sure to delete the "stress.cache"
file from your rider home directory after rebuilding.
Enjoy, and let me know what you think.
Sean
--
“We’re borrowing money from China to buy oil from the Persian Gulf to
burn it in ways that destroy the planet. Every bit of that’s got to
change.” -- Al Gore
This email is about a new ride metric I've been using. It is a very
long email. Apologies in advance.
As some of you already know, I skipped road season last year and tried
my hand at running. I was a runner before I was a cyclist, and most
of what I learned last year was that my hips still don't like running.
:)
On the other hand, I also discovered a really nice book, "Daniels
Running Formula". It has since become my favorite training book, and
it's influenced the way I train for cycling as much as any other book
at this point. The author is a guy named Jack Daniels (no kidding),
who in the 50s and 60s was an Olympic medalist in the modern
pentathlon (I had to look it up, too). He later became a running
coach and spent most of his career at SUNY Cortland, where his team
took 8 NCAA Div III national titles and he coached 30 individual
national champions and 130 All-Americans. Quite a record.
Anyway, like Allen, Coggan, and Skiba, he also has a point system for
tracking training stress that he describes in the book. It's a lot
like TSS/BikeScore, in that faster running counts more than slower
running, but since there aren't power meters in running he bases the
system off fractions of a runner's pace at VO2Max. Daniels doesn't
seem to intend his system to be used to help runners "peak" so much as
to avoid injury/overtraining. He has no notion of a PM chart, for
example.
The wind plays a pretty small factor in running compared to cycling.
It's true that elite marathoners draft each other, but even at a
4-minute mile, the wind accounts for only something like 10-20% of a
runner's effort. Compared to cycling at an elite 4k pursuit pace,
that's nothing at all. So it occurred to me that I could translate
Daniels' Table 2.2, which is based on fractions of VO2Max pace, into a
table based on percent of VO2Max power without too much error.
Furthermore, I could assume that VO2Max power is pretty close to 120%
of FTP/CP power (following Allen and Coggan's zones), and I'd get a
table of points per minute as a function of percentage of power at
FTP/CP.
I did just that, and a graph is attached. The x-axis is the
percentage of FTP power, and the y-axis is points per minute. The red
line (with plus marks) shows the values from Daniels' table, and the
green line shows a curve I fit to it. In the book, Daniels doesn't
give a justification for his points system, but I think this plot
makes it pretty clear what he had in mind: points per minute should be
proportional to the fourth power of power output divided by power at
FTP/CP.
If you've read the justifications behind TSS or BikeScore recently,
that fourth power bit should sound awfully familiar. Page 9 of
Coggan's "Training and racing using a power meter: an
introduction", for example, says
blood lactate (% of lactate at LT) = power (% of power at LT) ^ 3.90
for data "collected from a large number of cyclists". It wouldn't
surprise me if Daniels was himself looking at data from a bunch of
runners. There's a sweet pic of him in the book driving a golf cart
alongside a runner on the track in order to capture a bag of expelled
air (to measure VO2).
There are two big differences and one little one between Daniels'
points system and TSS/BikeScore. The little one is that Daniels
scales his points so that an hour at FTP/CP is worth 33 points,
whereas TSS/BikeScore scale so that an hour at FTP/CP is worth 100.
Keep that in mind when you're comparing the two.
The first big difference between Daniels' points and TSS/BikeScore is
that Daniels' points are what Dan Connelly likes to call "linear in
time": adding together the points values of two workouts gives the
same number as the point value of a workout that consisted of doing
the two workouts as one combined workout.
Why does this matter? Well, go read any of Dan Connelly's past posts
on the subject. Or, for a fun experiment, take any of your rides in
GC, export to CSV, add a bunch of new data points to the end that have
zero power output and non-zero speed, as though you'd coasted downhill
for a while after the ride, then re-import into GC. Your
TSS/BikeScore for the ride goes way up, even though you didn't do any
more work! On many rides in Northern California, you're either
pedaling hard uphill or riding down a twisty, fast descent, and all
that descending at near-zero power causes real problems if you're
tracking your stress with TSS/BikeScore. Daniels only gives you
points for non-zero power, and you only get a fair number by riding at
aerobic pace or higher, so his point system doesn't suffer from this
problem.
The second big difference between Daniels' points and TSS/BikeScore is
that Daniels gives you far less credit for long, slow rides. For
example, last weekend I rode for 3:45 at 72% of FTP/CP. I kept my
pace really steady, so that my NP/xPower was only 3 watts higher than
my average power. My BikeScore for that ride was 209. If you believe
that BikeScore/TSS are the "right" metric, then, you believe that ride
was just as hard as if I'd ridden *two* 1-hour, all-out time trials
that day. I've never actually done two 1-hour, all-out TTs in one
day, but I'm pretty sure the four-hour ride I did do was much, much
easier.
In contrast, Daniels gives me only 36 points for my four-hour ride,
indicating that it was just slightly harder than a single 1-hour,
all-out TT (which he assigns 33 points). Judging by how I felt after
the ride, that seems much closer to the right scale to me.
This relative weighting of endurance versus intensity seems to be an
important one, and as I've thought more about Daniels' system, I think
he is closer to the mark. Take, for another example, the week of June
2, 2008, when I was gearing up for Fitchburg Longsjo stage race in
Massachusetts. I rode 16.5 hours that week, including one 6-hour ride
and another 4.5 hour one. I also did FTP intervals and some VO2Max
intervals. My BikeScore for that week was 807.
Now, I won't lie. That was a hard week. If I did it too many times
in a row, it would get pretty old, and my experience tells me that if
I kept up the VO2Max intervals for too long I would have burnt out
after a month or two. But think about what a BikeScore of 807 is
supposed to mean based on the scaling factor: that the stress I
endured that week was roughly equivalent to riding EIGHT 1-hour,
all-out time trials. You've got to be kidding me. Had I done that, I
would have burnt out before the week was even done.
Daniels, on the other hand, assigns that week 123 points, indicating
that it was about as stressful as doing FOUR 1-hour, all-out time
trials. That's still a lot, but it's not totally unreasonable given
the rides I did. I did 38 minutes at FTP on Wed. Daniels gives me
pretty close to 38/60 points for that one. I also did 24 minutes at
120% of FTP on Fri, and Daniels calls that another TT worth. If we
say that each of the long rides was as hard as a TT as well, that's
pretty close to four. Okay, so not so outlandish. It's still pretty
high, and I'm not sure I could actually do four 1-hour, all-out TTs in
a week. But I *know* I couldn't do 8.
To be clear, I'm not saying that a stress metric should de-value long
rides. If you're going to race four hour races, you need to do some
four hour rides. If you're going to do four-day stage races, you
probably need to ride several four-plus hour rides on consecutive
days. All fitness is specific, and I get that. What I am saying is
that I'm pretty sure the stress my body undergoes during a four hour
endurance ride is *not* anything like the stress it would incur from
two back-to-back 1-hour, all-out time trials. And if I want my stress
metric to help me avoid overtraining/burnout, it has to get that part
right.
Okay, enough about Daniels points versus TSS/BikeScore.
I added Daniels' points to GC in commit 3429f2d. To compute them, I
first compute the 25-second exponentially weighted average of power
during the ride, just like we do for BikeScore. You can read Skiba's
paper for a justification of that part, but it's basically that blood
lactate takes a while to adjust to a new load. It also has another
benefit in that Daniels doesn't give point values for really high
power, since he assigns points per minute, and you just can't go that
hard for a minute. Smoothing over 25 seconds limits us to something
close to the same range of powers Daniels is working with. Given the
smoothed power values, I assign a point value to each sample by
dividing the average power at that point by FTP/CP, raising it to the
fourth power, and then scaling so that 1 hour at FTP equals 33 points.
I sum up all the points to get the value for the ride. That's it.
If you want to try using Daniels' points in the PM chart, you can also
apply the attached patch. Just be sure to delete the "stress.cache"
file from your rider home directory after rebuilding.
Enjoy, and let me know what you think.
Sean
--
“We’re borrowing money from China to buy oil from the Persian Gulf to
burn it in ways that destroy the planet. Every bit of that’s got to
change.” -- Al Gore
Sean Rhea
2009年11月27日 19:19:502009/11/27
收件人 Golden Cheetah Mailing List
P.S. I meant to point out that unlike other people on this list, I do
not have a PhD in exercise physiology, or any other wet science for
that matter. I'm also bad at math. My only qualification for
evaluating stress metrics is a Cat 1 racing license. So if it seems
that I'm leaning more on experience than on science or math, it's
because I am. :)
Sean
not have a PhD in exercise physiology, or any other wet science for
that matter. I'm also bad at math. My only qualification for
evaluating stress metrics is a Cat 1 racing license. So if it seems
that I'm leaning more on experience than on science or math, it's
because I am. :)
Sean
Andy Coggan
2009年11月27日 20:20:012009/11/27
收件人 golden-cheetah-users
On Nov 27, 6:19 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> if it seems
> that I'm leaning more on experience than on science or math, it's
> because I am.
So why not just implement Foster's session RPE and be done with it?
> if it seems
> that I'm leaning more on experience than on science or math, it's
> because I am.
Andy Coggan
Jamie Kimberley
2009年11月28日 00:40:202009/11/28
收件人 Andy Coggan、golden-cheetah-users
find that having a subjective/qualitative measure of my workouts is
just as important as having an objective/quantitative measure.
Using both in concert helps me decide if it is appropriate to suck
it up and push through the fatigue, or back off and get some quality
recovery.
Perhaps I'll code up my own training metric that I use during the
winter months. I call it "the Bourbometer", but perhaps BSS
(bourbon stress score) is a catchier acronym. details here:
http://13mph.blogspot.com/2008/11/running-on-empty.html
Jamie
Jamie
"It is a mistake to think you can solve any major problems with just
potatoes."--Douglas Adams
__________________
Jamie Kimberley
Postdoctoral Fellow
Department of Mechanical Engineering
The Johns Hopkins University
Office: 410.516.5162
Mobile: 217.621.8272
Fax: 410.516.4316
E-Mail:jamie.k...@jhu.edu
Jamie Kimberley
2009年11月28日 00:45:322009/11/28
收件人 Andy Coggan、golden-cheetah-users
My apologies, The scaling of the burbometer can be found here:
http://13mph.blogspot.com/2008/11/whitey.html
I had posted the wrong link. It is probably time for bed.
Jamie
> --
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
http://13mph.blogspot.com/2008/11/whitey.html
I had posted the wrong link. It is probably time for bed.
Jamie
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
Berend De Schouwer
2009年11月28日 05:47:402009/11/28
收件人 Sean Rhea、Golden Cheetah Mailing List
Sean Rhea wrote:
> The first big difference between Daniels' points and TSS/BikeScore is
> that Daniels' points are what Dan Connelly likes to call "linear in
> time": adding together the points values of two workouts gives the
> same number as the point value of a workout that consisted of doing
> the two workouts as one combined workout.
>
> Why does this matter? Well, go read any of Dan Connelly's past posts
> on the subject.
This "linear-in-time" is becoming quite a hot topic. Before any metric
> The first big difference between Daniels' points and TSS/BikeScore is
> that Daniels' points are what Dan Connelly likes to call "linear in
> time": adding together the points values of two workouts gives the
> same number as the point value of a workout that consisted of doing
> the two workouts as one combined workout.
>
> Why does this matter? Well, go read any of Dan Connelly's past posts
> on the subject.
replaces any existing metric I'd like to know how they deal with the
non-workout time.
What happens to the 23 hours I'm sitting on a couch? What happens when
I'm doing 3 hours on the bike, and only 21 hours on the couch? What
happens if I append enough zeroes to the end of every ride, to make
every ride 24 hours?
I don't think you can solve linear-in-time -- for better or worse --
unless you acknowledge that every day has 24 hours, and you factor in
rest. Is the 5 minutes of coasting in the middle of a ride exercise,
non-exercise, or recovery? I don't think (subjectively) that full
recovery happens because you're concentrating, so how should it be
accounted for? What about 30 minutes? 30 seconds?
Is it better to split one two hour morning ride into a one hour morning,
and a one hour afternoon ride? Everything I know says: yes. If it's
yes, then linear-in-time isn't necessarily a goal. However, if it's
yes, the long-term metrics should pick it up, and not the short-term
metrics. Do the long-term metrics care about the number of hours rest
between rides?
I'm sorry if that question was answered elsewhere -- I haven't found
it. I'm off to find the wattage group I've heard so much about since
this discussion is a little off-topic.
On topic: Should GC dictate the metric, or implement 10 different
metrics from 10 different coaches, and let the user toggle? My vote is:
let the user toggle.
Apologies for any disclaimer,
Berend
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of UCS Group and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited. If you are not the intended addressee please notify the writer immediately and destroy the e-mail. UCS Group Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.
Andy Coggan
2009年11月28日 08:23:112009/11/28
收件人 golden-cheetah-users
On Nov 28, 4:47 am, Berend De Schouwer <berend.deschou...@ucs-
I realize that your questions are largely rhetorical, but if it helps
any: all pubically-described metrics to date (i.e., BikeScore, EPOC,
TRIMP, TSS, rTSS, session RPE, and TPOWER) treat training sessions as
infinitely-short impulses. In addition, all pubicallly-described
models to date assume that workouts occur only once per day.
Andy Coggan
any: all pubically-described metrics to date (i.e., BikeScore, EPOC,
TRIMP, TSS, rTSS, session RPE, and TPOWER) treat training sessions as
infinitely-short impulses. In addition, all pubicallly-described
models to date assume that workouts occur only once per day.
Andy Coggan
Andy Coggan
2009年11月28日 08:26:502009/11/28
收件人 golden-cheetah-users
On Nov 27, 11:40 pm, Jamie Kimberley <jamie.kimber...@jhu.edu> wrote:
> On Fri, 27 Nov 2009, Andy Coggan wrote:
> > On Nov 27, 6:19 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
>
> >> if it seems
> >> that I'm leaning more on experience than on science or math, it's
> >> because I am.
>
> > So why not just implement Foster's session RPE and be done with it?
>
> > Andy Coggan
>
> Despite sensing a hint of sarcasm, this is probably a good idea. I
> find that having a subjective/qualitative measure of my workouts is
> just as important as having an objective/quantitative measure.
> Using both in concert helps me decide if it is appropriate to suck
> it up and push through the fatigue, or back off and get some quality
> recovery.
No sarcasm intended. I've long advocated that people track both the
> On Fri, 27 Nov 2009, Andy Coggan wrote:
> > On Nov 27, 6:19 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
>
> >> if it seems
> >> that I'm leaning more on experience than on science or math, it's
> >> because I am.
>
> > So why not just implement Foster's session RPE and be done with it?
>
> > Andy Coggan
>
> Despite sensing a hint of sarcasm, this is probably a good idea. I
> find that having a subjective/qualitative measure of my workouts is
> just as important as having an objective/quantitative measure.
> Using both in concert helps me decide if it is appropriate to suck
> it up and push through the fatigue, or back off and get some quality
> recovery.
objective stimulus and the subjective repsonse to training for the
very reasons you mention. As well, I've often suggested that multi-
sport athletes use session RPE (since it makes no sense to add other
metrics across sports).
Andy Coggan
Berend De Schouwer
2009年11月28日 10:54:472009/11/28
收件人 Andy Coggan、golden-cheetah-users
Andy Coggan wrote:
> I realize that your questions are largely rhetorical,
It's just my funny way of asking questions. I am actually extremely
> I realize that your questions are largely rhetorical,
curious on multiple exercises. I have been for a while. However, I
don't have the knowledge or vocabulary to express some of that
curiosity. This is how I learn.
> but if it helps
> any: all pubically-described metrics to date (i.e., BikeScore, EPOC,
> TRIMP, TSS, rTSS, session RPE, and TPOWER) treat training sessions as
> infinitely-short impulses. In addition, all pubicallly-described
> models to date assume that workouts occur only once per day.
>
what those models do, and don't do, and a little of the assumptions they
make.
Now I have to learn about the assumptions I'm making.
I think it could be very interesting to find out how more than one
workout per day changes things. Do any of them follow a 24-hour day, or
do they model just the exercise, and not the x-hours of non-exercise?
Do they model rest? ie. do any of the models understand that more hours
of exercise means fewer hours of rest? From what you've said, I would
actually assume not. They all assume that there is sufficient sleep
between exercises.
It looks like they assume 2 hours is just 2 x 1 hour, and not that 2
hours is 1/12th. vs. 1/24th. I think it's important, because humans
need significant 1/24s as sleep. You can't just scale a formula from 1
hour to 24 hours, can you?
I now also have to assume that none of these would work usefully for a
25 hour exercise period.
I assume all the models assume that all the exercises start at the same
time in a 24 hour period, and they don't actually keep track if you have
some exercises at 6am and some at 5pm on a different day. I don't even
know if that would be statistically significant. I would assume it
would be more important to a dietician/nutritionist/cook.
PS. I didn't know if I should mention the spelling mistakes, but I
absolutely have to in this case. The way you spell publicly-described
is just too funny to let pass without comment.
Again, I apologise for the disclaimer.
Kevin in MD
2009年11月28日 11:39:532009/11/28
收件人 golden-cheetah-users
My opinion here is that was are worried about the top speed of the
horse but the cart only has one wheel. Or for another pithy saying, we
are counting angels on the heads of pins.
I've yet to see anything convincing me that any one workout measure is
superior to any other when it comes to how that measure transfers to
actual performance. I've implemented performance models using heart
rate based ratings, power based ratings, time, and mileage, all my
work has shown that all those inputs work OK. I have seen hints from
others that one measure beats another but nothing open to inspection
or detailed enough for me to believe it.
The issue is not the measure, it is the transfer functions. When you
start to create these measures, you are implying that they can be
turned into something meaningful, that there is a way to turn those
numbers into something meaningful. So you take your workout ratings do
some magic on them and they turn into a performance ability or perhaps
a fatigue number or perhaps a likelihood of overtraining syndrome.
For some that transfer function is the eyeball method, you kinda get a
feeling, problem here is that your eyeballs are not that well
calibrated and you can be off quite a bit.
For others that transfer function is Andy's adulterated version of the
Banister model. The issue here is that the constants for the Banister
equation he picked are almost certainly not the correct ones for any
one person and you could make sub optimal decisions based on it. Of
course, the other side of the coin is that you might find the PMC
gives answers that are "close enough."
Still others (like me) use the Banister model in its original form,
the issue here is that the model seems to be misspecified or
overspecified, the confidence intervals on the parameter estimates are
quite large, and getting the required performance tests done is a
challenge that we are working to address. Once again, it seems to give
good answers that work well for performance management and scheduling.
But the important point is that a new workout metric does nothing to
address the limitations of these transfer functions. The errors
inherent in the transfer functions completely swamp the errors in any
one workout estimate. You can drive yourself nuts trying to figure out
a better workout measure, but then how do you know when you get there?
How do you show that your new metric better predicts performance or
fatigue? You need a transfer function to do that, a mathematical way
to turn your new metric into a performance or fatigue number; an as I
said the current transfer functions all have issues.
All the pubic ones at least!
Kevin
On Nov 28, 10:54 am, Berend De Schouwer <berend.deschou...@ucs-
horse but the cart only has one wheel. Or for another pithy saying, we
are counting angels on the heads of pins.
I've yet to see anything convincing me that any one workout measure is
superior to any other when it comes to how that measure transfers to
actual performance. I've implemented performance models using heart
rate based ratings, power based ratings, time, and mileage, all my
work has shown that all those inputs work OK. I have seen hints from
others that one measure beats another but nothing open to inspection
or detailed enough for me to believe it.
The issue is not the measure, it is the transfer functions. When you
start to create these measures, you are implying that they can be
turned into something meaningful, that there is a way to turn those
numbers into something meaningful. So you take your workout ratings do
some magic on them and they turn into a performance ability or perhaps
a fatigue number or perhaps a likelihood of overtraining syndrome.
For some that transfer function is the eyeball method, you kinda get a
feeling, problem here is that your eyeballs are not that well
calibrated and you can be off quite a bit.
For others that transfer function is Andy's adulterated version of the
Banister model. The issue here is that the constants for the Banister
equation he picked are almost certainly not the correct ones for any
one person and you could make sub optimal decisions based on it. Of
course, the other side of the coin is that you might find the PMC
gives answers that are "close enough."
Still others (like me) use the Banister model in its original form,
the issue here is that the model seems to be misspecified or
overspecified, the confidence intervals on the parameter estimates are
quite large, and getting the required performance tests done is a
challenge that we are working to address. Once again, it seems to give
good answers that work well for performance management and scheduling.
But the important point is that a new workout metric does nothing to
address the limitations of these transfer functions. The errors
inherent in the transfer functions completely swamp the errors in any
one workout estimate. You can drive yourself nuts trying to figure out
a better workout measure, but then how do you know when you get there?
How do you show that your new metric better predicts performance or
fatigue? You need a transfer function to do that, a mathematical way
to turn your new metric into a performance or fatigue number; an as I
said the current transfer functions all have issues.
All the pubic ones at least!
Kevin
On Nov 28, 10:54 am, Berend De Schouwer <berend.deschou...@ucs-
Andy Froncioni
2009年11月28日 11:53:552009/11/28
收件人 Berend De Schouwer、Andy Coggan、golden-cheetah-users
Berend De Schouwer wrote:
> Andy Coggan wrote:
>
>> I realize that your questions are largely rhetorical,
>>
>
> It's just my funny way of asking questions. I am actually extremely
> curious on multiple exercises. I have been for a while. However, I
> don't have the knowledge or vocabulary to express some of that
> curiosity. This is how I learn.
>
I don't think it's being rhetorical to ask that the model behave the
> Andy Coggan wrote:
>
>> I realize that your questions are largely rhetorical,
>>
>
> It's just my funny way of asking questions. I am actually extremely
> curious on multiple exercises. I have been for a while. However, I
> don't have the knowledge or vocabulary to express some of that
> curiosity. This is how I learn.
>
same whether you split a ride or keep it whole. There are enough
mathematical tools available to make a model that works in a *similar*
way to NP/TSS/ATL/CTL but allows for 3 additional design criteria (as I
outlined in a private email to Sean and Dan).
I'm going out on a limb, here, but I guessed that the original design
criteria were something liek:
1) *Predictive:* create a metric that predicts performance. ( make
NP-busters
rare, for example )
2) *Universal:* Make the formula work for everyone, pro or couch potato.
3) *Minimal:* Only use 1 athlete parameter (FTP) in the whole equation.
And I added the following:
4) *Continuous:* (In the sense of no jumps across midnight.) Decay of
TSS = decay of ATL.
( integration of zero-power following a workout should lead to an exp( -
t/ATL_CONST ), if t is expressed in the same units -- hrs )
5) *Dimensionally correct*: If the model needs something like an
average power, then dimensionally the equation has to work out to
watts. If it's an IF, then the equation needs to be dimensionless.
example: int(d/dt) [ P * (P')^4 ] / [ int(d/dt) (P')^4 ] is in
units of watts, but is the lactate-weighted average power.
In addition, allowing for a non-regular pulse-train (rather than
one-per-day) would be a good start for 2-a-days. Also, finding another
form for NP(t) such that the step response ( 1 to 0 ) of NP^2/FTP^2 *
t decays like exp( -t/atl_const ) or exp( -t/ctl_const ) (can't think
which one is more appropriate).
Those are the things that come to mind, right now. More to follow...
Andy (no, not that one) ;-)
Sean Rhea
2009年11月28日 11:58:402009/11/28
收件人 Andy Coggan、golden-cheetah-users
On Fri, Nov 27, 2009 at 8:20 PM, Andy Coggan <aco...@earthlink.net> wrote:
> So why not just implement Foster's session RPE and be done with it?
Perhaps I wasn't clear. I didn't say I didn't like objective
> So why not just implement Foster's session RPE and be done with it?
approaches to measuring training load. I just said that my problem
with TSS/BikeScore is *not* that they don't agree with the
biochemistry or whatever. My problem with them is that in some cases
the stress score they assign to a workout is wildly out of touch with
my perception of the stress I've experienced. I can't personally do
eight 1-hour, all-out time trials in a week, but I routinely clock
weeks where my total BikeScore is 800 or more.
Sean Rhea
2009年11月28日 12:43:512009/11/28
收件人 Kevin in MD、golden-cheetah-users
Kevin,
I'm interested in the metrics primarily to avoid overtraining,
or--conversely--to help me train right up to the limit of
overtraining. I'm less interested in them for predicting performance;
I just use a pretty standard peaking procedure for that.
And I do find that if all my rides are of the form that BikeScore
works well with (i.e., no coasting), and I don't increase my weekly
BikeScore too often, and I don't increase it by too much when I do,
and I don't change my workout types too much between weeks, then I
don't get sick. Since getting sick is one of the bigger performance
limiters for me, I think there is a lot of value even in the existing
metrics.
My problems with BikeScore/TSS are just that they don't account well
for coasting or soft-pedaling, and they overstate the stress of long,
endurance pace rides. I think that Daniels' point system does a
better job at both of those things. That said, BikeScore and TSS are
still much better than just tracking weekly hours.
I also think you're right in that we can improve on the PM chart-type
long-term tracking, and Andy F has a lot of ideas that he's expressed
about that, too. I'm certainly up for trying out any concrete
proposals.
Sean
I'm interested in the metrics primarily to avoid overtraining,
or--conversely--to help me train right up to the limit of
overtraining. I'm less interested in them for predicting performance;
I just use a pretty standard peaking procedure for that.
And I do find that if all my rides are of the form that BikeScore
works well with (i.e., no coasting), and I don't increase my weekly
BikeScore too often, and I don't increase it by too much when I do,
and I don't change my workout types too much between weeks, then I
don't get sick. Since getting sick is one of the bigger performance
limiters for me, I think there is a lot of value even in the existing
metrics.
My problems with BikeScore/TSS are just that they don't account well
for coasting or soft-pedaling, and they overstate the stress of long,
endurance pace rides. I think that Daniels' point system does a
better job at both of those things. That said, BikeScore and TSS are
still much better than just tracking weekly hours.
I also think you're right in that we can improve on the PM chart-type
long-term tracking, and Andy F has a lot of ideas that he's expressed
about that, too. I'm certainly up for trying out any concrete
proposals.
Sean
> --
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
Berend De Schouwer
2009年11月28日 13:24:002009/11/28
收件人 Andy Froncioni、Andy Coggan、golden-cheetah-users
Andy Froncioni wrote:
> Berend De Schouwer wrote:
>
>> Andy Coggan wrote:
>>
>>
>>> I realize that your questions are largely rhetorical,
>>>
>>>
>> It's just my funny way of asking questions. I am actually extremely
>> curious on multiple exercises. I have been for a while. However, I
>> don't have the knowledge or vocabulary to express some of that
>> curiosity. This is how I learn.
>>
>>
> I don't think it's being rhetorical to ask that the model behave the
> same whether you split a ride or keep it whole.
I think my questions were more to find out if the body works the same
> Berend De Schouwer wrote:
>
>> Andy Coggan wrote:
>>
>>
>>> I realize that your questions are largely rhetorical,
>>>
>>>
>> It's just my funny way of asking questions. I am actually extremely
>> curious on multiple exercises. I have been for a while. However, I
>> don't have the knowledge or vocabulary to express some of that
>> curiosity. This is how I learn.
>>
>>
> I don't think it's being rhetorical to ask that the model behave the
> same whether you split a ride or keep it whole.
when you split a ride, and if the models are meant to fit that.
> There are enough
> mathematical tools available to make a model that works in a *similar*
> way to NP/TSS/ATL/CTL but allows for 3 additional design criteria (as I
> outlined in a private email to Sean and Dan).
>
> I'm going out on a limb, here, but I guessed that the original design
> criteria were something liek:
>
> 1) *Predictive:* create a metric that predicts performance. ( make
> NP-busters
> rare, for example )
> 2) *Universal:* Make the formula work for everyone, pro or couch potato.
> 3) *Minimal:* Only use 1 athlete parameter (FTP) in the whole equation.
>
> And I added the following:
> 4) *Continuous:* (In the sense of no jumps across midnight.) Decay of
> TSS = decay of ATL.
> ( integration of zero-power following a workout should lead to an exp( -
> t/ATL_CONST ), if t is expressed in the same units -- hrs )
>
about with (a) more than one exercise per day and (b) 25-hour exercises.
That's the bit of vocabulary I've been missing.
Now: is the body continuous? Or does the model assume the body is
continuous? Is that a fair assumption?
> 5) *Dimensionally correct*: If the model needs something like an
> average power, then dimensionally the equation has to work out to
> watts.
least not right now.
> If it's an IF, then the equation needs to be dimensionless.
>
> example: int(d/dt) [ P * (P')^4 ] / [ int(d/dt) (P')^4 ] is in
> units of watts, but is the lactate-weighted average power.
>
>
> In addition, allowing for a non-regular pulse-train (rather than
> one-per-day) would be a good start for 2-a-days. Also, finding another
> form for NP(t) such that the step response ( 1 to 0 ) of NP^2/FTP^2 *
> t decays like exp( -t/atl_const ) or exp( -t/ctl_const ) (can't think
> which one is more appropriate).
>
>
> Those are the things that come to mind, right now. More to follow...
>
Berend De Schouwer
2009年11月28日 13:27:242009/11/28
收件人 Sean Rhea、golden-cheetah-users
Sean Rhea wrote:
> On Fri, Nov 27, 2009 at 8:20 PM, Andy Coggan <aco...@earthlink.net> wrote:
>
>> So why not just implement Foster's session RPE and be done with it?
>>
>
> Perhaps I wasn't clear. I didn't say I didn't like objective
> approaches to measuring training load. I just said that my problem
> with TSS/BikeScore is *not* that they don't agree with the
> biochemistry or whatever. My problem with them is that in some cases
> the stress score they assign to a workout is wildly out of touch with
> my perception of the stress I've experienced. I can't personally do
> eight 1-hour, all-out time trials in a week, but I routinely clock
> weeks where my total BikeScore is 800 or more.
>
Adjust your FTP up by 25%.
> On Fri, Nov 27, 2009 at 8:20 PM, Andy Coggan <aco...@earthlink.net> wrote:
>
>> So why not just implement Foster's session RPE and be done with it?
>>
>
> Perhaps I wasn't clear. I didn't say I didn't like objective
> approaches to measuring training load. I just said that my problem
> with TSS/BikeScore is *not* that they don't agree with the
> biochemistry or whatever. My problem with them is that in some cases
> the stress score they assign to a workout is wildly out of touch with
> my perception of the stress I've experienced. I can't personally do
> eight 1-hour, all-out time trials in a week, but I routinely clock
> weeks where my total BikeScore is 800 or more.
>
/berend runs away...
Kevin in MD
2009年11月28日 16:39:572009/11/28
收件人 golden-cheetah-users
I see what your saying but then again I am back to pointing out that
the way that training transfers to illness isn't all that clear. I
have seen discussions that imply that wko users think that the rate of
increase of the fitness number is the key determinant for whether or
not one is likely to get sick.
From my own few observations, the fatigue term of the Banister model
doesn't match up with the incidence of overtraining type complaints.
So I am back to the idea that the transfer functions are the failing,
not the stress quantification.
Just my take on it.
On Nov 28, 12:43 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> Kevin,
>
> I'm interested in the metrics primarily to avoid overtraining,
> or--conversely--to help me train right up to the limit of
> overtraining. I'm less interested in them for predicting performance;
> I just use a pretty standard peaking procedure for that.
>
> And I do find that if all my rides are of the form that BikeScore
> works well with (i.e., no coasting), and I don't increase my weekly
> BikeScore too often, and I don't increase it by too much when I do,
> and I don't change my workout types too much between weeks, then I
> don't get sick. Since getting sick is one of the bigger performance
> limiters for me, I think there is a lot of value even in the existing
> metrics.
>
> My problems with BikeScore/TSS are just that they don't account well
> for coasting or soft-pedaling, and they overstate the stress of long,
> endurance pace rides. I think that Daniels' point system does a
> better job at both of those things. That said, BikeScore and TSS are
> still much better than just tracking weekly hours.
>
> I also think you're right in that we can improve on the PM chart-type
> long-term tracking, and Andy F has a lot of ideas that he's expressed
> about that, too. I'm certainly up for trying out any concrete
> proposals.
>
> Sean
>
the way that training transfers to illness isn't all that clear. I
have seen discussions that imply that wko users think that the rate of
increase of the fitness number is the key determinant for whether or
not one is likely to get sick.
From my own few observations, the fatigue term of the Banister model
doesn't match up with the incidence of overtraining type complaints.
So I am back to the idea that the transfer functions are the failing,
not the stress quantification.
Just my take on it.
On Nov 28, 12:43 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> Kevin,
>
> I'm interested in the metrics primarily to avoid overtraining,
> or--conversely--to help me train right up to the limit of
> overtraining. I'm less interested in them for predicting performance;
> I just use a pretty standard peaking procedure for that.
>
> And I do find that if all my rides are of the form that BikeScore
> works well with (i.e., no coasting), and I don't increase my weekly
> BikeScore too often, and I don't increase it by too much when I do,
> and I don't change my workout types too much between weeks, then I
> don't get sick. Since getting sick is one of the bigger performance
> limiters for me, I think there is a lot of value even in the existing
> metrics.
>
> My problems with BikeScore/TSS are just that they don't account well
> for coasting or soft-pedaling, and they overstate the stress of long,
> endurance pace rides. I think that Daniels' point system does a
> better job at both of those things. That said, BikeScore and TSS are
> still much better than just tracking weekly hours.
>
> I also think you're right in that we can improve on the PM chart-type
> long-term tracking, and Andy F has a lot of ideas that he's expressed
> about that, too. I'm certainly up for trying out any concrete
> proposals.
>
> Sean
>
Sean Rhea
2009年11月28日 16:51:332009/11/28
收件人 Berend De Schouwer、Golden Cheetah Mailing List
Berend De Schouwer <berend.d...@ucs-software.co.za> wrote:
> On topic: Should GC dictate the metric, or implement 10 different
> metrics from 10 different coaches, and let the user toggle? My vote is:
> let the user toggle.
I wholeheartedly agree. My plan was to extend the stress cache to
> On topic: Should GC dictate the metric, or implement 10 different
> metrics from 10 different coaches, and let the user toggle? My vote is:
> let the user toggle.
keep track of both BikeScore and Daniels Points, and amend the PM
chart so that you could toggle between the two.
One of the great things about GC, in my opinion, is that we don't have
to bet on just one horse in the race. We can implement anything
anyone has ever dreamed up, and let the users decide which metrics
they prefer.
Andy Coggan
2009年11月28日 17:48:432009/11/28
收件人 golden-cheetah-users
On Nov 28, 10:58 am, Sean Rhea <sean.c.r...@gmail.com> wrote:
> My problem with them is that in some cases
> the stress score they assign to a workout is wildly out of touch with
> my perception of the stress I've experienced.
Which is why I suggested that you simply use Foster's session rating
> My problem with them is that in some cases
> the stress score they assign to a workout is wildly out of touch with
> my perception of the stress I've experienced.
of *perceived* exertion method. After all, that is essentially what
you are already doing.
Andy Coggan
Andy Coggan
2009年11月28日 17:55:462009/11/28
收件人 golden-cheetah-users
On Nov 28, 9:54 am, Berend De Schouwer <berend.deschou...@ucs-
In addition to all of Kevin's points (many of which I made to the good
folks at UK Sport a number of years ago now): worrying about how split
workouts are handled, or the fact that the more you train the less you
can rest, makes little sense when you consider the time course of the
physiological adaptations to the training in question. That is, does
it really matter whether you did, e.g. 2 h or 2 x 1 h on a particular
day when it takes weeks for complete adaptation to take place?
Andy Coggan
P.S. The .ppt from the talk I gave to UK Sport is *publically*
available on Google docs.
folks at UK Sport a number of years ago now): worrying about how split
workouts are handled, or the fact that the more you train the less you
can rest, makes little sense when you consider the time course of the
physiological adaptations to the training in question. That is, does
it really matter whether you did, e.g. 2 h or 2 x 1 h on a particular
day when it takes weeks for complete adaptation to take place?
Andy Coggan
P.S. The .ppt from the talk I gave to UK Sport is *publically*
available on Google docs.
Andy Coggan
2009年11月28日 18:00:352009/11/28
收件人 golden-cheetah-users
On Nov 28, 10:39 am, Kevin in MD <kpjoub...@gmail.com> wrote:
> others (like me) use the Banister model
> others (like me) use the Banister model
> it seems to give
> good answers that work well for performance management and scheduling.
Busso doesn't think so.
> good answers that work well for performance management and scheduling.
Andy Coggan
Sean Rhea
2009年11月28日 18:45:102009/11/28
收件人 Andy Coggan、golden-cheetah-users
subjective assignment of perceived difficulty to workouts. By using
either TSS, BikeScore, or Daniels' points, I'm instead using the
(hopefully less subjective) assignment of stress to workouts that
either you, Phil Skiba, or Jack Daniels prefers.
The point I'm making is that, in my experience, Daniels' assignment of
to points to workouts makes more sense than yours.
TSS suggests that the workouts I did on the week of June 2, 2008
provided stess equivalent to eight 1-hour rides at FTP. I think
that's crazy, but of course that is my subjective judgment.
dbrower
2009年11月28日 22:16:582009/11/28
收件人 golden-cheetah-users
Not to get involved in the other debate about the merits of metric,
but I'd rather have it normalized to 100 rather than 33, no matter
what the guy has historically used. It's more consistent for mental
comparisons to have things be in the same ballpark of 100 is a full-
blast hour.
And, BTW, somebody's changes made my SEGV in the performance manager
go away.
-dB
but I'd rather have it normalized to 100 rather than 33, no matter
what the guy has historically used. It's more consistent for mental
comparisons to have things be in the same ballpark of 100 is a full-
blast hour.
And, BTW, somebody's changes made my SEGV in the performance manager
go away.
-dB
Andy Coggan
2009年11月28日 23:01:262009/11/28
收件人 golden-cheetah-users
On Nov 28, 5:45 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
should just use session RPE.
Andy Coggan
> On Sat, Nov 28, 2009 at 5:48 PM, Andy Coggan <acog...@earthlink.net> wrote:
> > On Nov 28, 10:58 am, Sean Rhea <sean.c.r...@gmail.com> wrote:
> >> My problem with them is that in some cases
> >> the stress score they assign to a workout is wildly out of touch with
> >> my perception of the stress I've experienced.
>
> > Which is why I suggested that you simply use Foster's session rating
> > of *perceived* exertion method. After all, that is essentially what
> > you are already doing.
>
> Not at all. If I were using session RPE, I'd be using my own
> subjective assignment of perceived difficulty to workouts. By using
> either TSS, BikeScore, or Daniels' points, I'm instead using the
> (hopefully less subjective) assignment of stress to workouts that
> either you, Phil Skiba, or Jack Daniels prefers.
>
> The point I'm making is that, in my experience, Daniels' assignment of
> to points to workouts makes more sense than yours.
>
> TSS suggests that the workouts I did on the week of June 2, 2008
> provided stess equivalent to eight 1-hour rides at FTP. I think
> that's crazy, but of course that is my subjective judgment.
My point is that if you trust your subjective judgement so much, you
> > On Nov 28, 10:58 am, Sean Rhea <sean.c.r...@gmail.com> wrote:
> >> My problem with them is that in some cases
> >> the stress score they assign to a workout is wildly out of touch with
> >> my perception of the stress I've experienced.
>
> > Which is why I suggested that you simply use Foster's session rating
> > of *perceived* exertion method. After all, that is essentially what
> > you are already doing.
>
> Not at all. If I were using session RPE, I'd be using my own
> subjective assignment of perceived difficulty to workouts. By using
> either TSS, BikeScore, or Daniels' points, I'm instead using the
> (hopefully less subjective) assignment of stress to workouts that
> either you, Phil Skiba, or Jack Daniels prefers.
>
> The point I'm making is that, in my experience, Daniels' assignment of
> to points to workouts makes more sense than yours.
>
> TSS suggests that the workouts I did on the week of June 2, 2008
> provided stess equivalent to eight 1-hour rides at FTP. I think
> that's crazy, but of course that is my subjective judgment.
should just use session RPE.
Andy Coggan
Sean Rhea
2009年11月29日 17:46:482009/11/29
收件人 dbrower、golden-cheetah-users
Yeah, I initially implemented it that way, but then I couldn't compare
it to my Daniels' points from my months running. Maybe I could
implement a user-selectable option of some kind, or just another
metric called "Daniels Hundreds" or something.
Sean
it to my Daniels' points from my months running. Maybe I could
implement a user-selectable option of some kind, or just another
metric called "Daniels Hundreds" or something.
Sean
> --
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
David Brower
2009年11月29日 20:08:462009/11/29
收件人 Sean Rhea、golden-cheetah-users
Options are always awful if they can be avoided How about displaying
them as a pair, like
33 D = 100 N
or
33D/100N
or
33/100, 33:100, {33, 100} etc.
D = D = Daniels, N = Normalized.
thanks,
-dB
them as a pair, like
33 D = 100 N
or
33D/100N
or
33/100, 33:100, {33, 100} etc.
D = D = Daniels, N = Normalized.
thanks,
-dB
Robb Romans
2009年11月29日 23:14:022009/11/29
收件人 dbrower、golden-cheetah-users
On Sat, Nov 28, 2009 at 9:16 PM, dbrower <dbr...@gmail.com> wrote:
> Not to get involved in the other debate about the merits of metric,
> but I'd rather have it normalized to 100 rather than 33, no matter
> what the guy has historically used. It's more consistent for mental
> comparisons to have things be in the same ballpark of 100 is a full-
> blast hour.
+1. My interest would be to compare my PMC results between the two
> Not to get involved in the other debate about the merits of metric,
> but I'd rather have it normalized to 100 rather than 33, no matter
> what the guy has historically used. It's more consistent for mental
> comparisons to have things be in the same ballpark of 100 is a full-
> blast hour.
metrics. It would be much easier for me to understand the results if
both have a base value of 100.
Just TSS (or alternatively Bikescore) has worked fine for me so far.
Robb
Sean Rhea
2009年11月30日 10:37:212009/11/30
收件人 Andy Coggan、golden-cheetah-users
On Sat, Nov 28, 2009 at 11:01 PM, Andy Coggan <aco...@earthlink.net> wrote:
> My point is that if you trust your subjective judgement so much, you
> should just use session RPE.
You're still ignoring my point about the 800 TSS week.
> My point is that if you trust your subjective judgement so much, you
> should just use session RPE.
Here's another example. You have described the impact of a workout
with TSS < 150 "on an athlete’s subsequent performance ability" as
"low (relatively easy to recover by following day)" [1]. Likewise,
you've described the impact of workouts with TSS of 150-300 as "medium
(some residual fatigue may be present the next day, but gone by 2nd
day)" [1]. Given those descriptions, I would expect the following
training week to be quite reasonable:
Mon: medium, TSS=250
Tue: off
Wed: low, TSS=100
Thu: off
Fri: medium, TSS=250
Sat: off
Sun: low, TSS=100
Weekly TSS: 700
Are you ready to argue that the above week puts a stress on an athlete
equivalent to riding for 1-hour at FTP daily for seven days in a row?
Both weeks have the same TSS.
Sean
[1] Coggan, Andrew R. "Training and racing using a power meter: an
introduction". March, 2003.
Andy Coggan
2009年11月30日 11:09:512009/11/30
收件人 golden-cheetah-users
On Nov 30, 9:37 am, Sean Rhea <sean.c.r...@gmail.com> wrote:
> On Sat, Nov 28, 2009 at 11:01 PM, Andy Coggan <acog...@earthlink.net> wrote:
> > My point is that if you trust your subjective judgement so much, you
> > should just use session RPE.
>
> You're still ignoring my point about the 800 TSS week.
>
> Here's another example. You have described the impact of a workout
> with TSS < 150 "on an athlete’s subsequent performance ability" as
> "low (relatively easy to recover by following day)" [1]. Likewise,
> you've described the impact of workouts with TSS of 150-300 as "medium
> (some residual fatigue may be present the next day, but gone by 2nd
> day)" [1]. Given those descriptions, I would expect the following
> training week to be quite reasonable:
>
> Mon: medium, TSS=250
> Tue: off
> Wed: low, TSS=100
> Thu: off
> Fri: medium, TSS=250
> Sat: off
> Sun: low, TSS=100
>
> Weekly TSS: 700
>
> Are you ready to argue that the above week puts a stress on an athlete
> equivalent to riding for 1-hour at FTP daily for seven days in a row?
> Both weeks have the same TSS.
1) Note that in the context of the single-workout guidelines you
mention, "recovered" doesn't mean that you will feel fresh as a daisy
the next day, only that it is unlikely that you will require a
recovery day, i.e., you should be able to get in at least some
productive training.
2) Having said the above, note that those single-workout guidelines
have been largely superceded by CTL.
3) What objective evidence can you present to demonstrate that the
above schedule is *not* the equivalent of doing an hour a day at
functional threshold power?
Andy Coggan
> On Sat, Nov 28, 2009 at 11:01 PM, Andy Coggan <acog...@earthlink.net> wrote:
> > My point is that if you trust your subjective judgement so much, you
> > should just use session RPE.
>
> You're still ignoring my point about the 800 TSS week.
>
> Here's another example. You have described the impact of a workout
> with TSS < 150 "on an athlete’s subsequent performance ability" as
> "low (relatively easy to recover by following day)" [1]. Likewise,
> you've described the impact of workouts with TSS of 150-300 as "medium
> (some residual fatigue may be present the next day, but gone by 2nd
> day)" [1]. Given those descriptions, I would expect the following
> training week to be quite reasonable:
>
> Mon: medium, TSS=250
> Tue: off
> Wed: low, TSS=100
> Thu: off
> Fri: medium, TSS=250
> Sat: off
> Sun: low, TSS=100
>
> Weekly TSS: 700
>
> Are you ready to argue that the above week puts a stress on an athlete
> equivalent to riding for 1-hour at FTP daily for seven days in a row?
> Both weeks have the same TSS.
mention, "recovered" doesn't mean that you will feel fresh as a daisy
the next day, only that it is unlikely that you will require a
recovery day, i.e., you should be able to get in at least some
productive training.
2) Having said the above, note that those single-workout guidelines
have been largely superceded by CTL.
3) What objective evidence can you present to demonstrate that the
above schedule is *not* the equivalent of doing an hour a day at
functional threshold power?
Andy Coggan
SteveI
2009年11月30日 14:13:032009/11/30
收件人 golden-cheetah-users
While I agree that the transfer functions have their own issues, I
disagree that we should ignore any clear issues with the measure.
I did a ride yesterday that was a 1 hour max effort to test my FTP. A
couple of minutes from the end I got a puncture. After an aborted
attempt to fix it I ended up walking home, and left the Garmin
recording till I got home, which was an hour after the last non-zero
power reading.
The file as a whole is given a TSS of 138 by WKO+. If I select the bit
up to the last non-zero power reading it gives a TSS of 106. If I
select the bit after, containing only zero power readings, it gives a
TSS of 0. But selecting the whole lot at once gives a TSS of 138. I
cannot see any possible physiological justification for this. It's
nothing to do with RPE, it is just nonsense to have the TSS increase
by 30% based on leaving my Garmin recording zero power data after the
end of my workout.
Surely we want TSS(A) + TSS(B) = TSS(A+B) apart from a possible small
difference due to boundary effects from the smoothing? This does seem
to be true in general, e.g. my ride today was 68 minutes with only
brief periods of coasting. TSS for the first 34 minutes in isolation
is 59. Last 34 minutes in isolation is 65. Total 124, which is what it
gives for the whole file. It just seems to have a particular problem
with periods of zero power data.
disagree that we should ignore any clear issues with the measure.
I did a ride yesterday that was a 1 hour max effort to test my FTP. A
couple of minutes from the end I got a puncture. After an aborted
attempt to fix it I ended up walking home, and left the Garmin
recording till I got home, which was an hour after the last non-zero
power reading.
The file as a whole is given a TSS of 138 by WKO+. If I select the bit
up to the last non-zero power reading it gives a TSS of 106. If I
select the bit after, containing only zero power readings, it gives a
TSS of 0. But selecting the whole lot at once gives a TSS of 138. I
cannot see any possible physiological justification for this. It's
nothing to do with RPE, it is just nonsense to have the TSS increase
by 30% based on leaving my Garmin recording zero power data after the
end of my workout.
Surely we want TSS(A) + TSS(B) = TSS(A+B) apart from a possible small
difference due to boundary effects from the smoothing? This does seem
to be true in general, e.g. my ride today was 68 minutes with only
brief periods of coasting. TSS for the first 34 minutes in isolation
is 59. Last 34 minutes in isolation is 65. Total 124, which is what it
gives for the whole file. It just seems to have a particular problem
with periods of zero power data.
Jerry Zornes
2009年11月30日 14:26:452009/11/30
收件人 SteveI、golden-cheetah-users
I don't have issues with zero power that occur while riding, ie. coasting. As they certainly incur some some metabolic expense. It would be advantageous to be edit out long pauses of no work. like when you walked home as they were not part of the ride in a definable way. This is the group ride regroup at the top of the hill question. How long is so long that it needs to be accounted for? On the other hand if it was a very hilly course no one would think that the the downhill sections would render the numbers invalid.
Jerry
Jerry
Andy Froncioni
2009年11月30日 14:33:532009/11/30
收件人 SteveI、golden-cheetah-users
Hi Stevel,
I've been working on this problem for a little while. Here are some very
early results...
> The file as a whole is given a TSS of 138 by WKO+. If I select the bit
> up to the last non-zero power reading it gives a TSS of 106. If I
> select the bit after, containing only zero power readings, it gives a
> TSS of 0. But selecting the whole lot at once gives a TSS of 138. I
> cannot see any possible physiological justification for this. It's
> nothing to do with RPE, it is just nonsense to have the TSS increase
> by 30% based on leaving my Garmin recording zero power data after the
> end of my workout.
The issue is related to the fact that IF^2 does not decay as 1/T when you
pad a workout with zeroes. I'm still working out the details, but the definition
of TSS is somehow dimensionally incorrect.
Using, for example, TSS(*) = IF^4 * T gives us the desired property of
additiviity. Check it out for yourselves. Now whether this is physiologically
justififed remains another matter altogether. I don't really know if IF^4
is a meaningful as a workout intensity. But it is asymptotically correct
because it allows TSS to remain constant when zeroes are added.
The way I see it, mathematically, either the IF^4 redefinition of TSS(*) will
have to be made, or an additional weighting factor will have to be inserted
into the definition of NP so that NP^2 scales as 1/T when zeroes are added.
Cheers,
Andy
Andy Froncioni
---------------------------------------------------------------
My other signature is a pun.
---------------------------------------------------------------
a.fro...@sympatico.ca
(514) 829-0255
I've been working on this problem for a little while. Here are some very
early results...
> The file as a whole is given a TSS of 138 by WKO+. If I select the bit
> up to the last non-zero power reading it gives a TSS of 106. If I
> select the bit after, containing only zero power readings, it gives a
> TSS of 0. But selecting the whole lot at once gives a TSS of 138. I
> cannot see any possible physiological justification for this. It's
> nothing to do with RPE, it is just nonsense to have the TSS increase
> by 30% based on leaving my Garmin recording zero power data after the
> end of my workout.
pad a workout with zeroes. I'm still working out the details, but the definition
of TSS is somehow dimensionally incorrect.
Using, for example, TSS(*) = IF^4 * T gives us the desired property of
additiviity. Check it out for yourselves. Now whether this is physiologically
justififed remains another matter altogether. I don't really know if IF^4
is a meaningful as a workout intensity. But it is asymptotically correct
because it allows TSS to remain constant when zeroes are added.
The way I see it, mathematically, either the IF^4 redefinition of TSS(*) will
have to be made, or an additional weighting factor will have to be inserted
into the definition of NP so that NP^2 scales as 1/T when zeroes are added.
Cheers,
Andy
Andy Froncioni
---------------------------------------------------------------
My other signature is a pun.
---------------------------------------------------------------
a.fro...@sympatico.ca
(514) 829-0255
Andy Coggan
2009年11月30日 15:03:202009/11/30
收件人 golden-cheetah-users
On Nov 30, 1:13 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
> Surely we want TSS(A) + TSS(B) = TSS(A+B)
Why?
> Surely we want TSS(A) + TSS(B) = TSS(A+B)
Andy Coggan
Andy Coggan
2009年11月30日 15:05:212009/11/30
收件人 golden-cheetah-users
On Nov 30, 1:33 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> TSS(*) = IF^4 * T gives us the desired property of
> additiviity.
As has been known for years.
> TSS(*) = IF^4 * T gives us the desired property of
> additiviity.
> whether this is physiologically justififed remains another matter altogether.
sort of interaction between intensity and duration.
Andy Coggan
Andy Coggan
2009年11月30日 15:09:192009/11/30
收件人 golden-cheetah-users
On Nov 28, 3:39 pm, Kevin in MD <kpjoub...@gmail.com> wrote:
> From my own few observations, the fatigue term of the Banister model
> doesn't match up with the incidence of overtraining type complaints.
I wouldn't expect that it would. Banister's impulse-response model
> From my own few observations, the fatigue term of the Banister model
> doesn't match up with the incidence of overtraining type complaints.
assumes that more training is always better, i.e., overtraining is not
mathematically possible.
Andy Coggan
Andy Froncioni
2009年11月30日 15:14:172009/11/30
收件人 Andy Coggan、golden-cheetah-users
On 2009-11-30, at 3:03 PM, Andy Coggan wrote:
> On Nov 30, 1:13 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
>
>> Surely we want TSS(A) + TSS(B) = TSS(A+B)
>
> Why?
TSS(A+0) be? My guess is it's pretty close to TSS(A) + TSS(0)
which should be a net TSS(A). No?
TSS(A+0) amounts to leaving your power meter running when
you stop. If that has a physiological impact, then you can knock
me over with a feather... :-)
Andy Coggan
2009年11月30日 15:20:022009/11/30
收件人 golden-cheetah-users
On Nov 30, 2:14 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> On 2009-11-30, at 3:03 PM, Andy Coggan wrote:
>
> > On Nov 30, 1:13 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
>
> >> Surely we want TSS(A) + TSS(B) = TSS(A+B)
>
> > Why?
>
> Ok, let's forget about TSS(A+B) for a second. What should
> TSS(A+0) be? My guess is it's pretty close to TSS(A) + TSS(0)
> which should be a net TSS(A). No?
>
> TSS(A+0) amounts to leaving your power meter running when
> you stop. If that has a physiological impact, then you can knock
> me over with a feather... :-)
Next time you go for a long, hard ride, don't start refueling
>
> > On Nov 30, 1:13 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
>
> >> Surely we want TSS(A) + TSS(B) = TSS(A+B)
>
> > Why?
>
> Ok, let's forget about TSS(A+B) for a second. What should
> TSS(A+0) be? My guess is it's pretty close to TSS(A) + TSS(0)
> which should be a net TSS(A). No?
>
> TSS(A+0) amounts to leaving your power meter running when
> you stop. If that has a physiological impact, then you can knock
> me over with a feather... :-)
immediately. Instead, wait a couple of hours before eating, then tell
me that the passage of time alone never has any physiological
impact. :-)
Andy Coggan
Brian Ratliff
2009年11月30日 15:24:592009/11/30
收件人 Andy Froncioni、SteveI、golden-cheetah-users
The issue is actually pretty easy to see as you run through the math.
When you calculate NP, you are really taking the average of a function proportional to P^4 and back-calculating a steady state value, NP, which results in this average. Call this function:
G = C*P^4, this is the function proportional to P^4.
ave(G) = C*(1/T*int(G,t)) = C*(1/T*int(P^4,t)) = C*NP^4
where ave(G) is the average of 'G', t=time, T=total workout time, C=unspecified constant, P=power, NP=normalized power. The value "int(P^4,t)" is the integral of P^4 over time.
TSS = T*NP^2 = T*sqrt(ave(G)) = T*sqrt(1/T)*sqrt(int(P^4,t)) = sqrt(T)*sqrt(C*int(P^4,t))
If you look closely at the right side of the equation, you can see that TSS is proportional to sqrt(T). Hence, your addition of workout time without changing the value of "int(P^4,t)" results in the addition of TSS points. (The unspecified constant, 'C', goes away when you scale the equation to 100 TSS at FTP for one hour.)
The Daniels Points function goes like follows:
DP = T*C*NP^4 = T*(ave(G)) = T*(C/T*int(P^4,t)) = C*int(P^4,t)
Looking at the right side of the DP equation, you see that DP is the straight up integration of P^4 over time with no dependence on workout time. Again, the unspecified proportionality constant, "C", goes away when you scale the equation to FTP.
Anyway, this is the math behind NP. Draw what conclusions you will from it.
Brian Ratliff
Andy Froncioni
2009年11月30日 15:39:552009/11/30
收件人 Andy Coggan、golden-cheetah-users
More thoughts...
> On Nov 30, 1:33 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
>
>> TSS(*) = IF^4 * T gives us the desired property of
>> additiviity.
>
> As has been known for years.
Terrific! I'm not trying to be novel - just to help the algorithm along
for zero-padded workouts.
>
>> whether this is physiologically justififed remains another matter altogether.
>
> At least at present, I can't justify anything other than there is some
> sort of interaction between intensity and duration.
There was another route to additivity and that was to embed a
faster-decaying windowing term in the NP calculation. I'm still looking
for the functional form, but if all this has been done before (publicly) and
you know about it, can you please point us in the right direction? :-)
If the ultimate piece of cheese is to find a predictive, long-term
metric for fitness and fatigue then the intermediate calculation of
NP might not be necessary. TSS or something like it might be
better computed from a sum of lactate, or lactate-weighted power,
rather than through the use of the IF^2*T formula.
Brian's brought up the scaling issues, too. Cool!
> On Nov 30, 1:33 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
>
>> TSS(*) = IF^4 * T gives us the desired property of
>> additiviity.
>
> As has been known for years.
for zero-padded workouts.
>
>> whether this is physiologically justififed remains another matter altogether.
>
> At least at present, I can't justify anything other than there is some
> sort of interaction between intensity and duration.
faster-decaying windowing term in the NP calculation. I'm still looking
for the functional form, but if all this has been done before (publicly) and
you know about it, can you please point us in the right direction? :-)
If the ultimate piece of cheese is to find a predictive, long-term
metric for fitness and fatigue then the intermediate calculation of
NP might not be necessary. TSS or something like it might be
better computed from a sum of lactate, or lactate-weighted power,
rather than through the use of the IF^2*T formula.
Brian's brought up the scaling issues, too. Cool!
Brian Ratliff
2009年11月30日 16:18:442009/11/30
收件人 Andy Froncioni、SteveI、golden-cheetah-users
And one more point...
The reason why:
TSS(A) + TSS(B) != TSS(A+B)
is the same reason why:
sqrt(A) + sqrt(B) != sqrt(A+B)
As for which, TSS or DP is a better model for training stress; I think one must decide whether training stress is proportional to P^4 or P^2. The NP model is based on a P^4 relationship between stress and power, while TSS is based on a P^2 relationship. As it stands, these are two separate conceptual models that are somewhat in conflict with each other. The TSS calculation joins these two disparate models kind of awkwardly at the hip (from a mathmatical perspective), which is why you get this "zero-padded workout" problem.
Brian Ratliff
Sean Rhea
2009年11月30日 16:22:032009/11/30
收件人 Andy Coggan、golden-cheetah-users
On Mon, Nov 30, 2009 at 11:09 AM, Andy Coggan <aco...@earthlink.net> wrote:
> 3) What objective evidence can you present to demonstrate that the
> above schedule is *not* the equivalent of doing an hour a day at
> functional threshold power?
What objective evidence can you present to demonstrate that it *is*?
> 3) What objective evidence can you present to demonstrate that the
> above schedule is *not* the equivalent of doing an hour a day at
> functional threshold power?
Correct me if I'm wrong, but a TSS of 700 is about 14 hours of riding
along at an IF of 70%--in the upper half of your Zone 2. That's not a
recovery week, for sure, but I doubt we can find a single cyclist
who's willing to argue that he or she would be equally exhausted by
riding an hour at FTP every day for a week. Instead, I think most of
us would suspect anyone who claimed to have completed the latter week
must have underestimated his or her FTP.
Sean
> --
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
Andy Coggan
2009年11月30日 16:33:022009/11/30
收件人 golden-cheetah-users
On Nov 30, 3:22 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 11:09 AM, Andy Coggan <acog...@earthlink.net> wrote:
> > 3) What objective evidence can you present to demonstrate that the
> > above schedule is *not* the equivalent of doing an hour a day at
> > functional threshold power?
>
> What objective evidence can you present to demonstrate that it *is*?
Well for starters, I suggest searching the wattage list for graphs
I've posted showing the correlation between TSS and glycogen
utilization.
> Correct me if I'm wrong
Okay (see below). :-)
> but a TSS of 700 is about 14 hours of riding
> along at an IF of 70%--in the upper half of your Zone 2.
An IF of 0.70 is actually characteristic of rides on the border of
level 1 and level 2, not the upper half of level 2.
Andy Coggan
> On Mon, Nov 30, 2009 at 11:09 AM, Andy Coggan <acog...@earthlink.net> wrote:
> > 3) What objective evidence can you present to demonstrate that the
> > above schedule is *not* the equivalent of doing an hour a day at
> > functional threshold power?
>
> What objective evidence can you present to demonstrate that it *is*?
I've posted showing the correlation between TSS and glycogen
utilization.
> Correct me if I'm wrong
> but a TSS of 700 is about 14 hours of riding
> along at an IF of 70%--in the upper half of your Zone 2.
level 1 and level 2, not the upper half of level 2.
Andy Coggan
Andy Coggan
2009年11月30日 16:36:392009/11/30
收件人 golden-cheetah-users、golden-cheetah-users
On Nov 30, 3:18 pm, Brian Ratliff <ratli...@gmail.com> wrote:
> I think one
> must decide whether training stress is proportional to P^4 or P^2. The NP
> model is based on a P^4 relationship between stress and power, while TSS is
> based on a P^2 relationship.
Thank you for that introduction. :-)
> I think one
> must decide whether training stress is proportional to P^4 or P^2. The NP
> model is based on a P^4 relationship between stress and power, while TSS is
> based on a P^2 relationship.
Andy Coggan
Sean Rhea
2009年11月30日 16:47:322009/11/30
收件人 Andy Coggan、golden-cheetah-users
On Mon, Nov 30, 2009 at 4:33 PM, Andy Coggan <aco...@earthlink.net> wrote:
> An IF of 0.70 is actually characteristic of rides on the border of
> level 1 and level 2, not the upper half of level 2.
Very well. Can you please identify the cyclist who claims that riding
> An IF of 0.70 is actually characteristic of rides on the border of
> level 1 and level 2, not the upper half of level 2.
seven 1-hour rides at FTP in a single week would be as easy as 14
hours on the gentle border of zones 1 and 2?
If it's true, we should be able to find such cyclists in droves.
Sean
Andy Coggan
2009年11月30日 16:57:152009/11/30
收件人 golden-cheetah-users
On Nov 30, 3:47 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
perceptions that much, you don't need a powermeter, i.e., you can just
> On Mon, Nov 30, 2009 at 4:33 PM, Andy Coggan <acog...@earthlink.net> wrote:
> > An IF of 0.70 is actually characteristic of rides on the border of
> > level 1 and level 2, not the upper half of level 2.
>
> Very well. Can you please identify the cyclist who claims that riding
> seven 1-hour rides at FTP in a single week would be as easy as 14
> hours on the gentle border of zones 1 and 2?
>
> If it's true, we should be able to find such cyclists in droves.
Which brings us back to my original point: if you trust your
> > An IF of 0.70 is actually characteristic of rides on the border of
> > level 1 and level 2, not the upper half of level 2.
>
> Very well. Can you please identify the cyclist who claims that riding
> seven 1-hour rides at FTP in a single week would be as easy as 14
> hours on the gentle border of zones 1 and 2?
>
> If it's true, we should be able to find such cyclists in droves.
perceptions that much, you don't need a powermeter, i.e., you can just
Sean Rhea
2009年11月30日 17:02:052009/11/30
收件人 Andy Coggan、golden-cheetah-users
Yes, but it's not just my perception, Andy. It's everyone's. Even
you haven't piped up to say you could do the week of 1-hour FTP
intervals.
Sean
you haven't piped up to say you could do the week of 1-hour FTP
intervals.
Sean
Andy Coggan
2009年11月30日 17:12:002009/11/30
收件人 golden-cheetah-users
On Nov 30, 4:02 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> Yes, but it's not just my perception, Andy. It's everyone's.
So are you now proposing that you can develop a new, better metric by
> Yes, but it's not just my perception, Andy. It's everyone's.
taking a poll?
> Even
> you haven't piped up to say you could do the week of 1-hour FTP
> intervals.
single day, and whose yearly average IF is ~0.9.
Andy Coggan
Sean Rhea
2009年11月30日 17:14:362009/11/30
收件人 Andy Coggan、golden-cheetah-users
Were all three of those TTs at your maximum 1-hour average wattage?
Sean
Sean
Andy Coggan
2009年11月30日 17:24:062009/11/30
收件人 golden-cheetah-users
On Nov 30, 4:14 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> Were all three of those TTs at your maximum 1-hour average wattage?
They were certainly all maximum efforts, but as you might expect, my
> Were all three of those TTs at your maximum 1-hour average wattage?
power drops with each successive TT, e.g., by 5-7% from the 1st to the
2nd. While I've done back-to-back 40 km TTs on multiple occasions,
I've only done three in a row once and the 3rd was on a tandem, so I
can't tell you how much it falls from the 2nd to the 3rd.
Of course, your scenario allows for 23 h recovery between efforts,
whereas I only had 30-60 min...Graham Obree, OTOH, had about 12 h
between his full-length just-failed attempt and his follow-up ride
when he set the hour record.
Andy Coggan
Sean Rhea
2009年11月30日 20:35:292009/11/30
收件人 Andy Coggan、golden-cheetah-users
I bet Graham Obree could do a lot of things. I'm also sure that some
cyclists can do an hour at FTP three or maybe even four days in a
week. But at the point where we're reaching for a world hour record
holder just to find an exemplar who can do two days in a row, I think
it's safe to conclude that no one is likely to do seven. Combine that
with the fact that lots of us routinely do 14 hours or more per week
in zones 1 and 2 during base, and I'm happy to call my conclusion
objective.
Sean
cyclists can do an hour at FTP three or maybe even four days in a
week. But at the point where we're reaching for a world hour record
holder just to find an exemplar who can do two days in a row, I think
it's safe to conclude that no one is likely to do seven. Combine that
with the fact that lots of us routinely do 14 hours or more per week
in zones 1 and 2 during base, and I'm happy to call my conclusion
objective.
Sean
Andy Coggan
2009年11月30日 20:41:572009/11/30
收件人 golden-cheetah-users
On Nov 30, 7:35 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> I bet Graham Obree could do a lot of things. I'm also sure that some
> cyclists can do an hour at FTP three or maybe even four days in a
> week. But at the point where we're reaching for a world hour record
> holder just to find an exemplar who can do two days in a row, I think
> it's safe to conclude that no one is likely to do seven. Combine that
> with the fact that lots of us routinely do 14 hours or more per week
> in zones 1 and 2 during base, and I'm happy to call my conclusion
> objective.
<shrug>
> I bet Graham Obree could do a lot of things. I'm also sure that some
> cyclists can do an hour at FTP three or maybe even four days in a
> week. But at the point where we're reaching for a world hour record
> holder just to find an exemplar who can do two days in a row, I think
> it's safe to conclude that no one is likely to do seven. Combine that
> with the fact that lots of us routinely do 14 hours or more per week
> in zones 1 and 2 during base, and I'm happy to call my conclusion
> objective.
I guess we'll all just wait for your poll-derived training metric,
then. You'll have to trust me, though, when I say that you'll have a
very hard time convincing anyone of its validity in the absence of any
new data.
Andy Coggan
Justin F. Knotzke
2009年11月30日 21:12:592009/11/30
收件人 Andy Coggan、golden-cheetah-users
2009/11/30 Andy Coggan <aco...@earthlink.net>
I guess we'll all just wait for your poll-derived training metric,
then. You'll have to trust me, though, when I say that you'll have a
very hard time convincing anyone of its validity in the absence of any
new data.
A little like how some of us following this thread, are finding it very hard to now believe in the validity of TSS.
J
Jerry Zornes
2009年11月30日 21:47:522009/11/30
收件人 Justin F. Knotzke、Andy Coggan、golden-cheetah-users
I'm not sure how going at an avg of .9 seems so odd? It means go out nd get after it and don't mess around. I see it more as a case of focus than anything else.
Jerry
Zach Rogers
2009年11月30日 21:53:272009/11/30
收件人 golden-cheetah-users
Has anyone here with a CTL ~100+ tried to put in a solid week of FTP efforts? I'm looking over some past weeks and I'm not so sure it would be impossible. Now granted, I don't have anything that has day after day of 1hr max AP efforts, but there is a few crit camp type periods in there that have ~1hr NP efforts day after day. Hell, there's a period in there that has 4 days of nearly 1.0IF efforts followed by a 412TSS day (max hour was ~.93IF), 112TSS (2hrs, but finished with a 20min climb at 1.02IF), then a 320TSS day with a 1hr climb of .98IF. Anyone out there done Superweek? That could surely provide more then 7days of ~1hr 1.0IF efforts.
Once upon a time I never did worry about the non-additive nature of TSS, but the more I get the opportunity to ride out in places that have extended climbs, and thus long descents, I'm curious if there shouldn't be some kind of a regenerative term to it all... my mental model is along the lines of a performance manager that is continuous over time (not sure that's a perfect descriptor)... but I have absolutely no basis for such ideas other then the absurdity of the concept that the stroke of midnight is somehow magical in it's regenerative capabilities... but that's not really a problem with TSS & NP (at least not yet), rather a problem with what we are looking to do with those numbers. IOW, until we can improve the performance manager aspect of it all, the precision of the numbers feeding into it are just fine for the task at hand.
All that said - is this really the list to discuss these topics? Shouldn't G.C.'s focus be on making the best possible tool based on the state of the art, regardless of the state of that art?
-Zach
Once upon a time I never did worry about the non-additive nature of TSS, but the more I get the opportunity to ride out in places that have extended climbs, and thus long descents, I'm curious if there shouldn't be some kind of a regenerative term to it all... my mental model is along the lines of a performance manager that is continuous over time (not sure that's a perfect descriptor)... but I have absolutely no basis for such ideas other then the absurdity of the concept that the stroke of midnight is somehow magical in it's regenerative capabilities... but that's not really a problem with TSS & NP (at least not yet), rather a problem with what we are looking to do with those numbers. IOW, until we can improve the performance manager aspect of it all, the precision of the numbers feeding into it are just fine for the task at hand.
All that said - is this really the list to discuss these topics? Shouldn't G.C.'s focus be on making the best possible tool based on the state of the art, regardless of the state of that art?
-Zach
SteveI
2009年11月30日 21:53:432009/11/30
收件人 golden-cheetah-users
Why do we want additivity? I don't think we would in an ideal world.
If someone cycles at a constant x watts for 5 hours, then I see an
ideal model as capturing that the 5th hour at the same power will be
more stressful than the 1st hour. If a model captured this, it
wouldn't be additive, continuous efforts would be modelled as more
stressful than distinct efforts.
But if we're not going to go down that road, and we're going to attach
equal stress to all occurrences of x watts in a file (smoothing
aside), then additivity just "feels" right. I would be interested to
hear your reasons for specifically not wanting additivity (if that is
the case) and what benefits you feel it delivers in terms of better
measuring training stress.
Thanks to the people who have contributed various manipulations of the
formulae. I hadn't looked at in that much detail before, but you
caused me to get pen and paper out to work through it all myself, and
I think I see it clearly now. I would certainly be interested to try a
TSS based on the 4th power rather than the square. As to whether
people could be convinced of the validity of this, I think most of us
would be looking to end up with CTL/TSB matching how well we perform,
and will judge the validity that way. It doesn't really matter to me
how theoretically sound I am assured a model is if I can have day A
with 50% higher CTL than day B, and also a higher TSB on day A, yet
output less power on day A vs day B. I will be happy with a
theoretically unsound model that matches my actual performance.
If someone cycles at a constant x watts for 5 hours, then I see an
ideal model as capturing that the 5th hour at the same power will be
more stressful than the 1st hour. If a model captured this, it
wouldn't be additive, continuous efforts would be modelled as more
stressful than distinct efforts.
But if we're not going to go down that road, and we're going to attach
equal stress to all occurrences of x watts in a file (smoothing
aside), then additivity just "feels" right. I would be interested to
hear your reasons for specifically not wanting additivity (if that is
the case) and what benefits you feel it delivers in terms of better
measuring training stress.
Thanks to the people who have contributed various manipulations of the
formulae. I hadn't looked at in that much detail before, but you
caused me to get pen and paper out to work through it all myself, and
I think I see it clearly now. I would certainly be interested to try a
TSS based on the 4th power rather than the square. As to whether
people could be convinced of the validity of this, I think most of us
would be looking to end up with CTL/TSB matching how well we perform,
and will judge the validity that way. It doesn't really matter to me
how theoretically sound I am assured a model is if I can have day A
with 50% higher CTL than day B, and also a higher TSB on day A, yet
output less power on day A vs day B. I will be happy with a
theoretically unsound model that matches my actual performance.
Andy Froncioni
2009年11月30日 22:13:222009/11/30
收件人 SteveI、golden-cheetah-users
SteveI wrote:
> Why do we want additivity? I don't think we would in an ideal world.
> If someone cycles at a constant x watts for 5 hours, then I see an
> ideal model as capturing that the 5th hour at the same power will be
> more stressful than the 1st hour. If a model captured this, it
> wouldn't be additive, continuous efforts would be modelled as more
> stressful than distinct efforts.
>
> But if we're not going to go down that road, and we're going to attach
> equal stress to all occurrences of x watts in a file (smoothing
> aside), then additivity just "feels" right. I would be interested to
> hear your reasons for specifically not wanting additivity (if that is
> the case) and what benefits you feel it delivers in terms of better
> measuring training stress.
>
Well, I had mentioned it before, but I know I want the Additive Identity
> Why do we want additivity? I don't think we would in an ideal world.
> If someone cycles at a constant x watts for 5 hours, then I see an
> ideal model as capturing that the 5th hour at the same power will be
> more stressful than the 1st hour. If a model captured this, it
> wouldn't be additive, continuous efforts would be modelled as more
> stressful than distinct efforts.
>
> But if we're not going to go down that road, and we're going to attach
> equal stress to all occurrences of x watts in a file (smoothing
> aside), then additivity just "feels" right. I would be interested to
> hear your reasons for specifically not wanting additivity (if that is
> the case) and what benefits you feel it delivers in terms of better
> measuring training stress.
>
Property. Anyone can disagree, but TSS(A+0+0+..+0) should pretty much
equal TSS(A), in my books.
Why? Attached is a plot of NP, Coggan's TSS, and my own TSS2. I
have a long ride padded with a whole day's worth of zeros. Here is
what you should notice:
1. If I use Coggan's TSS formula, TSS (in green) keeps rising when you
pad with zeros.
2. As posted by Brian, if TSS2 = IF4 * T, IF4 decays as 1/T and the
product, TSS2, remains constant (blue line). Zero additional = zero
additional TSS2.
Anyone think that rising TSS curve is due to nutrition? Hmmm...
Andy
SteveI
2009年11月30日 22:33:522009/11/30
收件人 golden-cheetah-users
Having done some more jottings with my pen and paper, I think I am
right in saying that if
TSS2 = 100 * IF^4 * T / 3600
then it can also be stated as
TSS2 = 100 * ( sum ( P^4 ) ) / ( 3600 * ( FTP ^ 4 ) )
which is exactly the same as the Daniels Points formula with an
appropriate constant. So count me in as someone keen to try the
functionality that is the subject of this thread ;)
Apologies if someone else has already said this and I have just been a
bit slow on the uptake.
right in saying that if
TSS2 = 100 * IF^4 * T / 3600
then it can also be stated as
TSS2 = 100 * ( sum ( P^4 ) ) / ( 3600 * ( FTP ^ 4 ) )
which is exactly the same as the Daniels Points formula with an
appropriate constant. So count me in as someone keen to try the
functionality that is the subject of this thread ;)
Apologies if someone else has already said this and I have just been a
bit slow on the uptake.
Andy Coggan
2009年12月1日 07:07:162009/12/1
收件人 golden-cheetah-users
On Nov 30, 8:12 pm, "Justin F. Knotzke" <jknot...@shampoo.ca> wrote:
> 2009/11/30 Andy Coggan <acog...@earthlink.net>
And why, pray tell, is that? The calculation of TSS is based upon on
only three assumptions:
1) that physiological responses to exercise follow a certain time
course;
2) that the physiological (esp. metabolic) responses to exercise are
non-linearly related to intensity, and
3) that the physiological strain resulting a single exercise bout is
the result of an interaction between exercise intensity and exercise
duration.
There is a wealth of data supporting assumptions #1 and #2 (used to
calculate normalized power), so while one might quibble re. the
details, the basic logic can't really be questioned, nor can it be
said that the calculation isn't objective. Along the same lines, I
don't think anyone would really aruge with #3 - it is only the precise
nature of said interaction that is uncertain. As I have described many
times before (and mentioned previously in this thread), in the absence
of any objective data I took the parsimonious approach of simply
multiplying the two together (as opposed to, e.g., subjectively basing
the calculation on I **felt** it should be, as Sean seems to prefer).
This may or may not be the ideal formulation, but as it turns out, TSS
calculated in this manner 1) tracks rather well with session RPE, at
least in terms of how it weights intensity (cf. the slide I posteed to
this thread), and 2) predicts muscle glycogen utiization as well as
Rusko's heart rate based EPOC predicts actual EPOC, even though the
former is a far more variable measurement than the latter. As such,
TSS is the **only** training metric that has been independently
validated against physiological data.
Andy Coggan
> 2009/11/30 Andy Coggan <acog...@earthlink.net>
only three assumptions:
1) that physiological responses to exercise follow a certain time
course;
2) that the physiological (esp. metabolic) responses to exercise are
non-linearly related to intensity, and
3) that the physiological strain resulting a single exercise bout is
the result of an interaction between exercise intensity and exercise
duration.
There is a wealth of data supporting assumptions #1 and #2 (used to
calculate normalized power), so while one might quibble re. the
details, the basic logic can't really be questioned, nor can it be
said that the calculation isn't objective. Along the same lines, I
don't think anyone would really aruge with #3 - it is only the precise
nature of said interaction that is uncertain. As I have described many
times before (and mentioned previously in this thread), in the absence
of any objective data I took the parsimonious approach of simply
multiplying the two together (as opposed to, e.g., subjectively basing
the calculation on I **felt** it should be, as Sean seems to prefer).
This may or may not be the ideal formulation, but as it turns out, TSS
calculated in this manner 1) tracks rather well with session RPE, at
least in terms of how it weights intensity (cf. the slide I posteed to
this thread), and 2) predicts muscle glycogen utiization as well as
Rusko's heart rate based EPOC predicts actual EPOC, even though the
former is a far more variable measurement than the latter. As such,
TSS is the **only** training metric that has been independently
validated against physiological data.
Andy Coggan
Justin F. Knotzke
2009年12月1日 07:22:332009/12/1
收件人 Sean Rhea、Golden Cheetah Mailing List
2009/11/27 Sean Rhea <sean....@gmail.com>
If you want to try using Daniels' points in the PM chart, you can also
apply the attached patch. Just be sure to delete the "stress.cache"
file from your rider home directory after rebuilding.
Sean, will you be applying this use-Daniels-Points-in-PM patch to git ?
Maybe there is a way to track both ?
J
Dave Harris
2009年12月1日 07:59:422009/12/1
收件人 golden-che...@googlegroups.com
> -----Original Message-----
> From: Andy Froncioni [mailto:a.fro...@sympatico.ca]
> Sent: Monday, November 30, 2009 8:39 PM
> To: Dave Harris
> Subject: Re: [Golden-Cheetah-Users] Re: New training metric: Daniels
> Points
>
> Dave,
> > Where are those zeros placed? I don't understand your example.
> >
> Sorry for the rough plot. Attached is a new one that clearly shows
> that
> the zeroes start at 10,800 secs (3hrs). P is in red and is a 220-watt
> constant ride for 3 hours. NP (green) decays, but not fast enough to
> keep TSS from increasing without bound. I'll repeat... without bound.
>
> Just keep your power meter running when you put your bike away and you,
> too, can have Pro-level TSS's.
>
Thanks for the clarification. I have no trouble racking up pro-level TSS
without stopping ;)
I haven't looked at this issue in depth, so forgive me if I'm not up to
date. But, I have used TSS "in anger" since its inception and have found it
invaluable. One of these uses has been to meter out efforts for multi-day
backcountry MTB epic races such as this:
http://www.bikepacking.net/routes/grand-loop/ . These are not stage races -
there is a start time and you ride non-stop (or rest as much as you need to)
until the finish several days later.
Obviously there is a lot more going on in an event like this than just
pedaling, but it becomes pretty obvious to me that the rate at which I can
cover an entire course is somewhat independent of how much time I spend
*not* pedaling. As a human, I can't stay on the gas indefinitely and need
to stop to refuel, rehydrate and get some shuteye. I can lean hard on those
boundaries of need, but it just serves to drop power and alertness enough to
the point that it isn't necessarily advantageous.
This seems to suggest that physiologically speaking, this non-additive
property of TSS is not far off the mark, no? IOW, at least conceptually, I
can see where riding 22 hours/day at .68 IF (TSS = 1017) could end up being
equivalent to 20 hours/day at .7 IF (TSS= 980), where the latter would end
up inflated a bit if the "clock", or 705 <g> was left running while I
rested. Both leave me in the pain cave to similar degrees and I can't say
which ends up being faster - my claim is neither.
Sorry for the thought experiment but that's the best I've got.
Sean Rhea
2009年12月1日 08:10:582009/12/1
收件人 Justin F. Knotzke、Golden Cheetah Mailing List
No, that patch is just for playing around.
I would like to extend the stress.cache code to keep track of both,
and have a combo box on the PM chart that lets the user flip back and
forth. But I probably won't get to that in the next few days at
least.
Sean
I would like to extend the stress.cache code to keep track of both,
and have a combo box on the PM chart that lets the user flip back and
forth. But I probably won't get to that in the next few days at
least.
Sean
Jim Ley
2009年12月1日 08:43:102009/12/1
收件人 Andy Coggan、golden-cheetah-users
2009/12/1 Andy Coggan <aco...@earthlink.net>:
wrong, I've not actually been able to find a detailed description, but
you've said that WKO+ gets it right), it assumes that time not
recording data is time not part of the metabolic response. So if you
stop and don't record data for 30 seconds, the model produces
different results to if you stop and do record data for the 30
seconds. There's no difference in physiological response, but there's
a potentially large difference in TSS value I've previously described
a simple workout delivering a 14% difference.
Jim.
> On Nov 30, 8:12 pm, "Justin F. Knotzke" <jknot...@shampoo.ca> wrote:
>> 2009/11/30 Andy Coggan <acog...@earthlink.net>
>> 2009/11/30 Andy Coggan <acog...@earthlink.net>
> The calculation of TSS is based upon on
> only three assumptions:
>
> 1) that physiological responses to exercise follow a certain time
> course;
>
> 2) that the physiological (esp. metabolic) responses to exercise are
> non-linearly related to intensity, and
>
> 3) that the physiological strain resulting a single exercise bout is
> the result of an interaction between exercise intensity and exercise
> duration.
>
> There is a wealth of data supporting assumptions #1 and #2 (used to
> calculate normalized power),
There are other things that the calculation uses (correct me if I'm
> only three assumptions:
>
> 1) that physiological responses to exercise follow a certain time
> course;
>
> 2) that the physiological (esp. metabolic) responses to exercise are
> non-linearly related to intensity, and
>
> 3) that the physiological strain resulting a single exercise bout is
> the result of an interaction between exercise intensity and exercise
> duration.
>
> There is a wealth of data supporting assumptions #1 and #2 (used to
> calculate normalized power),
wrong, I've not actually been able to find a detailed description, but
you've said that WKO+ gets it right), it assumes that time not
recording data is time not part of the metabolic response. So if you
stop and don't record data for 30 seconds, the model produces
different results to if you stop and do record data for the 30
seconds. There's no difference in physiological response, but there's
a potentially large difference in TSS value I've previously described
a simple workout delivering a 14% difference.
Jim.
Andy Coggan
2009年12月1日 08:49:332009/12/1
收件人 golden-cheetah-users
On Nov 30, 8:53 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
> Why do we want additivity? I don't think we would in an ideal world.
> If someone cycles at a constant x watts for 5 hours, then I see an
> ideal model as capturing that the 5th hour at the same power will be
> more stressful than the 1st hour. If a model captured this, it
> wouldn't be additive, continuous efforts would be modelled as more
> stressful than distinct efforts.
>
> But if we're not going to go down that road, and we're going to attach
> equal stress to all occurrences of x watts in a file (smoothing
> aside), then additivity just "feels" right. I would be interested to
> hear your reasons for specifically not wanting additivity (if that is
> the case) and what benefits you feel it delivers in terms of better
> measuring training stress.
I didn't give additivity a single thought when developing TSS (since
> Why do we want additivity? I don't think we would in an ideal world.
> If someone cycles at a constant x watts for 5 hours, then I see an
> ideal model as capturing that the 5th hour at the same power will be
> more stressful than the 1st hour. If a model captured this, it
> wouldn't be additive, continuous efforts would be modelled as more
> stressful than distinct efforts.
>
> But if we're not going to go down that road, and we're going to attach
> equal stress to all occurrences of x watts in a file (smoothing
> aside), then additivity just "feels" right. I would be interested to
> hear your reasons for specifically not wanting additivity (if that is
> the case) and what benefits you feel it delivers in terms of better
> measuring training stress.
the goal of TSS, as with all such metrics, is to pin a *single* number
on a workout *in its entirety*). That said, I don't think additivity
is a desirable property to pursue, as it makes little sense from a
physiological perspective for the reasons you mention above. Most of
all, I think it is completely illogical to attempt to develop or
modify what is supposed to be an *objective* measure of training
"dose" based on *subjective* feelings. As I've said over and over
again, if you trust your perceptions that much you might as well just
ditch the powermeter and use Foster's session RPE.
> Thanks to the people who have contributed various manipulations of the
> formulae. I hadn't looked at in that much detail before, but you
> caused me to get pen and paper out to work through it all myself, and
> I think I see it clearly now. I would certainly be interested to try a
> TSS based on the 4th power rather than the square. As to whether
> people could be convinced of the validity of this, I think most of us
> would be looking to end up with CTL/TSB matching how well we perform,
> and will judge the validity that way. It doesn't really matter to me
> how theoretically sound I am assured a model is if I can have day A
> with 50% higher CTL than day B, and also a higher TSB on day A, yet
> output less power on day A vs day B. I will be happy with a
> theoretically unsound model that matches my actual performance.
this thread, the "way forward" is via improving the actual model, not
the input function.
2) If your goal is to predict performance (or rather, training-induced
adaptations that contribute to improved performance) instead of
physiological strain, then I think that the weighting on intensity
should actually be lower (i.e., <2), not higher (i.e., 4).
Andy Coggan
Andy Coggan
Brian Ratliff
2009年12月1日 10:15:212009/12/1
收件人 Andy Coggan、golden-cheetah-users
The real problem with this "additive" issue, is if you take an arbitrary, non-stopping ride and cut it somewhere. No stopping or anything. Just randomly pick a point in time and split the ride. Calculate the NP for both parts and calculate the TSS of each part and you'll find that TSS(A) + TSS(B) will not equal TSS(A+B)!
This has nothing to do at all with physiology, it's just a mathematical artifact of combining a P^4 model within a P^2 model.
And as for the three objectives, both TSS and DP achieve the same ends. They both combine workout length and intensity into one number to describe the ride. The only problem with TSS is it assumes an NP model that is built on a P^2 model, as opposed to the 4th power relationship.
It seems the only issue that DP has is legacy and NIH issues. I would love to see DP (though normalized to 100 at FT) built into GC.
Brian Ratliff
Andy Coggan
Andy Coggan
2009年12月1日 10:22:592009/12/1
收件人 golden-cheetah-users
On Dec 1, 9:15 am, Brian Ratliff <ratli...@gmail.com> wrote:
> The real problem with this "additive" issue, is if you take an arbitrary,
> non-stopping ride and cut it somewhere. No stopping or anything. Just
> randomly pick a point in time and split the ride. Calculate the NP for both
> parts and calculate the TSS of each part and you'll find that TSS(A) +
> TSS(B) will not equal TSS(A+B)!
>
> This has nothing to do at all with physiology
Actually, it has everything to do with physiology: you wouldn't expect
> The real problem with this "additive" issue, is if you take an arbitrary,
> non-stopping ride and cut it somewhere. No stopping or anything. Just
> randomly pick a point in time and split the ride. Calculate the NP for both
> parts and calculate the TSS of each part and you'll find that TSS(A) +
> TSS(B) will not equal TSS(A+B)!
>
> This has nothing to do at all with physiology
the global strain to be the sum of the individual segments, so
additivity of segments isn't really a logically desirable property.
>, it's just a mathematical
> artifact of combining a P^4 model within a P^2 model.
sometimes you just get lucky. :-)
> And as for the three objectives, both TSS and DP achieve the same ends.
> They both combine workout length and intensity into one number to describe
> the ride. The only problem with TSS is it assumes an NP model that is built
> on a P^2 model, as opposed to the 4th power relationship.
glycogen utilization than weighting using any other integer (the best-
fit exponent is 1.96).
> It seems the only issue that DP has is legacy and NIH issues.
Andy Coggan
Justin F. Knotzke
2009年12月1日 10:26:262009/12/1
收件人 Brian Ratliff、golden-cheetah-users
2009/12/1 Brian Ratliff <ratl...@gmail.com>
I would love to see DP (though normalized to 100 at FT) built into GC.
I suggest taking the next step. Come up with the algo based on how we currently do things (and you don't even need to know the code) and someone might code it.
The idea is that if you would like to see a feature implemented, and you aren't a programmer, bring the programmer as close as humanly possible to the water and he might drink! ;-)
In all seriousness, if you explain how to calculate the metric in laymen's terms, it will make the job easier, thus increasing the possibility of seeing it implemented.
If you need help, ping me off line.
But think this is a good way to go for anyone looking to see a feature.
J
Andy Coggan
2009年12月1日 10:27:412009/12/1
收件人 golden-cheetah-users
On Nov 30, 9:33 pm, SteveI <stephenir...@yahoo.co.uk> wrote:
> Apologies if someone else has already said this
FWIW, essentially all of this thread is a rehash of things that have
> Apologies if someone else has already said this
previously been discussed on the wattage list. I say that not to
discourage further discussion, but simply to encourage people to take
the time to dig through the archives there so that they are fully "up
to speed".
Andy Coggan
Justin F. Knotzke
2009年12月1日 10:30:462009/12/1
收件人 Andy Coggan、golden-cheetah-users
2009/12/1 Andy Coggan <aco...@earthlink.net>
Good idea. Then maybe we can get on with writing great software.
J
Andy Coggan
2009年12月1日 10:40:292009/12/1
收件人 golden-cheetah-users
On Dec 1, 9:30 am, "Justin F. Knotzke" <jknot...@shampoo.ca> wrote:
> 2009/12/1 Andy Coggan <acog...@earthlink.net>
I'm not the one who started a thread on the relative merit of various
training metrics on this list. If people want to move back over to the
wattage list (which I agree is where it would be more appropriate),
though, that's fine with me.
Andy Coggan
> 2009/12/1 Andy Coggan <acog...@earthlink.net>
training metrics on this list. If people want to move back over to the
wattage list (which I agree is where it would be more appropriate),
though, that's fine with me.
Andy Coggan
Andy Coggan
2009年12月1日 10:53:562009/12/1
收件人 golden-cheetah-users
On Dec 1, 7:43 am, Jim Ley <jim....@gmail.com> wrote:
> 2009/12/1 Andy Coggan <acog...@earthlink.net>:
> I've not actually been able to find a detailed description
The algorithm has been described in a number of places, but most
accessible would probably be the chapter that I wrote for USA Cycling
- a Google search should turn it up.
>, but
> you've said that WKO+ gets it right),
No, I said that you would *assume* that WKO+ gets it right, and that I
have not ever reviewed the code or attempted to verify the
calculations it provides (I did verify them back when it was
CyclingPeaks).
> it assumes that time not
> recording data is time not part of the metabolic response.
No, it does not.
> So if you
> stop and don't record data for 30 seconds, the model produces
> different results to if you stop and do record data for the 30
> seconds.
No, the *algorithm* does not (although certain powermeters may give
such results, depending in part on what program you use to download
the data).
Andy Coggan
> 2009/12/1 Andy Coggan <acog...@earthlink.net>:
>
> > The calculation of TSS is based upon on
> > only three assumptions:
>
> > 1) that physiological responses to exercise follow a certain time
> > course;
>
> > 2) that the physiological (esp. metabolic) responses to exercise are
> > non-linearly related to intensity, and
>
> > 3) that the physiological strain resulting a single exercise bout is
> > the result of an interaction between exercise intensity and exercise
> > duration.
>
> > There is a wealth of data supporting assumptions #1 and #2 (used to
> > calculate normalized power),
>
> There are other things that the calculation uses (correct me if I'm
> wrong,
Okay: you're wrong. :-)
> > The calculation of TSS is based upon on
> > only three assumptions:
>
> > 1) that physiological responses to exercise follow a certain time
> > course;
>
> > 2) that the physiological (esp. metabolic) responses to exercise are
> > non-linearly related to intensity, and
>
> > 3) that the physiological strain resulting a single exercise bout is
> > the result of an interaction between exercise intensity and exercise
> > duration.
>
> > There is a wealth of data supporting assumptions #1 and #2 (used to
> > calculate normalized power),
>
> There are other things that the calculation uses (correct me if I'm
> wrong,
> I've not actually been able to find a detailed description
accessible would probably be the chapter that I wrote for USA Cycling
- a Google search should turn it up.
>, but
> you've said that WKO+ gets it right),
have not ever reviewed the code or attempted to verify the
calculations it provides (I did verify them back when it was
CyclingPeaks).
> it assumes that time not
> recording data is time not part of the metabolic response.
> So if you
> stop and don't record data for 30 seconds, the model produces
> different results to if you stop and do record data for the 30
> seconds.
such results, depending in part on what program you use to download
the data).
Andy Coggan
Jim Ley
2009年12月1日 11:29:392009/12/1
收件人 Andy Coggan、golden-cheetah-users
2009/12/1 Andy Coggan <aco...@earthlink.net>:
say how I'm wrong.
>> I've not actually been able to find a detailed description
>
> The algorithm has been described in a number of places, but most
> accessible would probably be the chapter that I wrote for USA Cycling
> - a Google search should turn it up.
This one?
http://home.trainingpeaks.com/media/68517/pmc_summit.pdf
Doesn't cover how gaps in data should be handled, so I'm guessing it's
another, but that's the only chapter I can find.
>> it assumes that time not
>> recording data is time not part of the metabolic response.
>
> No, it does not.
[...]
There should be no difference in the calculated TSS and NP of two
identical rides where 30seconds of zero power production was recorded
in one ride, and not recorded in another?
In WKO+ currently if the data is not recorded for 30 seconds, that
time is ignored in all calculations, a ride with and without that data
point calculate different NP and TSS, the 30seconds happened, but the
calculation results in different values.
Cheers,
Jim.
>> There are other things that the calculation uses (correct me if I'm
>> wrong,
>
> Okay: you're wrong. :-)
You haven't corrected me, please do so, don't just say I'm wrong, ie
>> wrong,
>
> Okay: you're wrong. :-)
say how I'm wrong.
>> I've not actually been able to find a detailed description
>
> The algorithm has been described in a number of places, but most
> accessible would probably be the chapter that I wrote for USA Cycling
> - a Google search should turn it up.
http://home.trainingpeaks.com/media/68517/pmc_summit.pdf
Doesn't cover how gaps in data should be handled, so I'm guessing it's
another, but that's the only chapter I can find.
>> it assumes that time not
>> recording data is time not part of the metabolic response.
>
> No, it does not.
> No, the *algorithm* does not
So you would say, that in a correct implementation of the algorithm,
There should be no difference in the calculated TSS and NP of two
identical rides where 30seconds of zero power production was recorded
in one ride, and not recorded in another?
In WKO+ currently if the data is not recorded for 30 seconds, that
time is ignored in all calculations, a ride with and without that data
point calculate different NP and TSS, the 30seconds happened, but the
calculation results in different values.
Cheers,
Jim.
Andy Coggan
2009年12月1日 12:05:272009/12/1
收件人 golden-cheetah-users
>From: Jim Ley <jim...@gmail.com>
>Sent: Dec 1, 2009 11:29 AM
>To: Andy Coggan <aco...@earthlink.net>
>Cc: golden-cheetah-users <golden-che...@googlegroups.com>
>>> I've not actually been able to find a detailed description
>>
>> The algorithm has been described in a number of places, but most
>> accessible would probably be the chapter that I wrote for USA Cycling
>> - a Google search should turn it up.
>
>This one?
>http://home.trainingpeaks.com/media/68517/pmc_summit.pdf
>
>Doesn't cover how gaps in data should be handled, so I'm guessing it's
>another, but that's the only chapter I can find.
The link you followed to that presenation *should* take you to the chapter in question, but it doesn't (which is why I didn't mention it). Try this instead:
http://velo-fit.com/articles/coggan-power.pdf
>>> it assumes that time not
>>> recording data is time not part of the metabolic response.
>>
>> No, it does not.
>[...]
>> No, the *algorithm* does not
>
>So you would say, that in a correct implementation of the algorithm,
>There should be no difference in the calculated TSS and NP of two
>identical rides where 30seconds of zero power production was recorded
>in one ride, and not recorded in another?
The algorithm is based on the assumption that power data are recorded continuously at least once every 30 s and that each value represents a true average over the time period in question. How a computer program handles exceptions to these assumptions 1) IMO depends on the circumstance, and more importantly 2) is really beyond my control.
Andy Coggan
>Sent: Dec 1, 2009 11:29 AM
>To: Andy Coggan <aco...@earthlink.net>
>Cc: golden-cheetah-users <golden-che...@googlegroups.com>
>Subject: Re: [Golden-Cheetah-Users] Re: New training metric: Daniels Points
>
>
>2009/12/1 Andy Coggan <aco...@earthlink.net>:
>>> There are other things that the calculation uses (correct me if I'm
>>> wrong,
>>
>> Okay: you're wrong. :-)
>
>You haven't corrected me, please do so, don't just say I'm wrong, ie
>say how I'm wrong.
I thought it was apparent from the info I provided below.
>>> There are other things that the calculation uses (correct me if I'm
>>> wrong,
>>
>> Okay: you're wrong. :-)
>
>You haven't corrected me, please do so, don't just say I'm wrong, ie
>say how I'm wrong.
>>> I've not actually been able to find a detailed description
>>
>> The algorithm has been described in a number of places, but most
>> accessible would probably be the chapter that I wrote for USA Cycling
>> - a Google search should turn it up.
>
>This one?
>http://home.trainingpeaks.com/media/68517/pmc_summit.pdf
>
>Doesn't cover how gaps in data should be handled, so I'm guessing it's
>another, but that's the only chapter I can find.
http://velo-fit.com/articles/coggan-power.pdf
>>> it assumes that time not
>>> recording data is time not part of the metabolic response.
>>
>> No, it does not.
>[...]
>> No, the *algorithm* does not
>
>So you would say, that in a correct implementation of the algorithm,
>There should be no difference in the calculated TSS and NP of two
>identical rides where 30seconds of zero power production was recorded
>in one ride, and not recorded in another?
Andy Coggan
Jim Ley
2009年12月1日 12:14:512009/12/1
收件人 Andy Coggan、golden-cheetah-users
2009/12/1 Andy Coggan <aco...@earthlink.net>:
correct in the situation where there's not data every 30 seconds and
it's not a true average! Hopefully we can now start educating users
of the software of its deficiencies. And more importantly ensure that
Golden Cheetah does not fall down the path of following WKO+'s
implementation towards more broken results.
Cheers,
Jim.
> The algorithm is based on the assumption that power data are recorded
> continuously at least once every 30 s and that each value represents a
>true average over the time period in question. How a computer program
>handles exceptions to these assumptions 1) IMO depends on the
>circumstance, and more importantly 2) is really beyond my control.
Excellent, thanks! I am very pleased learn WKO+'s metrics are not
> continuously at least once every 30 s and that each value represents a
>true average over the time period in question. How a computer program
>handles exceptions to these assumptions 1) IMO depends on the
>circumstance, and more importantly 2) is really beyond my control.
correct in the situation where there's not data every 30 seconds and
it's not a true average! Hopefully we can now start educating users
of the software of its deficiencies. And more importantly ensure that
Golden Cheetah does not fall down the path of following WKO+'s
implementation towards more broken results.
Cheers,
Jim.
Brian Ratliff
2009年12月1日 12:18:362009/12/1
收件人 Andy Coggan、golden-cheetah-users
Actually, it has everything to do with physiology: you wouldn't expect
the global strain to be the sum of the individual segments, so
additivity of segments isn't really a logically desirable property.
I have no idea what this means. If the whole is not the sum of the parts... The body doesn't store information about it's stresses (it doesn't "know" how long your exercise bout lasted, just that you are at a certain state of fatigue and a point in time) but just moves from one stress state to the next. This is naturally an integration of segments.
>, it's just a mathematicalNow this is true. But, as I said a long time ago on the wattage list:
> artifact of combining a P^4 model within a P^2 model.
sometimes you just get lucky. :-)
Not terribly often, especially when you are attempting to model a very complicated system with simple models. I, perhaps, don't know a huge amount about sports physiology, but I do know a fair amount about modeling systems. One of the things I know is that a model should be continuous across its independent variables (in this case: time).
Think about this: Say you have a computer on your bike that calculates TSS as you ride and at every point in time it measures power and the change in time from the point previous and those are the only things it measures. The only thing in memory is the TSS from the previous instant in time. How would you complete the calculation?
TSS = sqrt(T)*sqrt(int(P^4,t)) is your algorithm.
It is dependent on T, which you don't have until you are done:
sqrt(dt1) + sqrt(dt2) + ... != sqrt(T)
It is also dependent on the sqrt of the integral of P^4, which suffers the same problem:
int(sqrt(P^4),t) != sqrt(int(P^4,t))
There is no way of doing a rolling calculation of TSS using only the previous value and information from the new point in time. You are forced to store data from the entire workout in your computer and do the calculation afterwards.
Now, substitute "computer" for "body" and you see the problem. Your body doesn't store information from previous time periods. It is just a continuous evolution of states. The TSS calculation relies on stored information and thus cannot really be mirroring what's going on in the body during a training session.
Andy Coggan
2009年12月1日 12:33:172009/12/1
收件人 golden-cheetah-users
On Dec 1, 11:18 am, Brian Ratliff <ratli...@gmail.com> wrote:
> The body doesn't store information about it's stresses (it doesn't
> "know" how long your exercise bout lasted
Actually, it does "know", just as it "knows", e.g., how much glycogen
> The body doesn't store information about it's stresses (it doesn't
> "know" how long your exercise bout lasted
you had stored in your muscles and liver when you started exercise.
> I, perhaps, don't know a huge amount
> about sports physiology, but I do know a fair amount about modeling systems.
> One of the things I know is that a model should be continuous across its
> independent variables (in this case: time).
only question is how well a model works in practice (and as I've
pointed out several times, TSS predicts glycogen utilization rather
well, even though that wasn't the goal). The fact that non-additivity
is offensive to engineering and/or accountant types is unfortunate,
but that property is a better reflection of reality than forcing
things to be additive.
> Think about this: Say you have a computer on your bike that calculates TSS
> as you ride and at every point in time it measures power and the change in
> time from the point previous and those are the only things it measures.
> The
> only thing in memory is the TSS from the previous instant in time. How
> would you complete the calculation?
>
> TSS = sqrt(T)*sqrt(int(P^4,t)) is your algorithm.
>
> It is dependent on T, which you don't have until you are done:
>
> sqrt(dt1) + sqrt(dt2) + ... != sqrt(T)
>
> It is also dependent on the sqrt of the integral of P^4, which suffers the
> same problem:
>
> int(sqrt(P^4),t) != sqrt(int(P^4,t))
>
> There is no way of doing a rolling calculation of TSS using only the
> previous value and information from the new point in time. You are forced
> to store data from the entire workout in your computer and do the
> calculation afterwards.
the stored raw data.
> Now, substitute "computer" for "body" and you see the problem. Your body
> doesn't store information from previous time periods. It is just a
> continuous evolution of states. The TSS calculation relies on stored
> information and thus cannot really be mirroring what's going on in the body
> during a training session.
to do is compare, e.g., the neurohormonal response to a fixed duration
of exercise at a fixed intensity initiated with either high or low
glycogen stores to realize that our bodies do indeed have ways of
"knowing" its "history".
Andy Coggan
Andy Coggan
2009年12月1日 12:39:212009/12/1
收件人 golden-cheetah-users
On Dec 1, 11:14 am, Jim Ley <jim....@gmail.com> wrote:
> 2009/12/1 Andy Coggan <acog...@earthlink.net>:
>
> 2009/12/1 Andy Coggan <acog...@earthlink.net>:
>
> > The algorithm is based on the assumption that power data are recorded
> > continuously at least once every 30 s and that each value represents a
> >true average over the time period in question. How a computer program
> >handles exceptions to these assumptions 1) IMO depends on the
> >circumstance, and more importantly 2) is really beyond my control.
>
> Excellent, thanks! I am very pleased learn WKO+'s metrics are not
> correct in the situation where there's not data every 30 seconds and
> it's not a true average!
Well it has always been known that you can't calculate normalized
> > continuously at least once every 30 s and that each value represents a
> >true average over the time period in question. How a computer program
> >handles exceptions to these assumptions 1) IMO depends on the
> >circumstance, and more importantly 2) is really beyond my control.
>
> Excellent, thanks! I am very pleased learn WKO+'s metrics are not
> correct in the situation where there's not data every 30 seconds and
> it's not a true average!
power when data haven't been recorded frequently enough and/or the
datastream has been excessively "down sampled" (just as it has always
been known that, e.g., CTL and ATL are calculated using exponentially-
weighted rolling averages).
As for how WKO+ handles breaks/interruptions, you really should take
that argument up with them. As I said, though, IMO the rules governing
such things should depend on the circumstances, so for all you know
they *are* doing things "correctly".
Andy Coggan
Sean Rhea
2009年12月1日 17:15:132009/12/1
收件人 Andy Coggan、golden-cheetah-users
On Tue, Dec 1, 2009 at 10:40 AM, Andy Coggan <aco...@earthlink.net> wrote:
> I'm not the one who started a thread on the relative merit of various
> training metrics on this list. If people want to move back over to the
> wattage list (which I agree is where it would be more appropriate),
> though, that's fine with me.
I *am* the one who started this thread, and I did so because I had
> I'm not the one who started a thread on the relative merit of various
> training metrics on this list. If people want to move back over to the
> wattage list (which I agree is where it would be more appropriate),
> though, that's fine with me.
introduced new functionality into GoldenCheetah that I wanted to
describe to the community. Whether you're fond of that new
functionality is of no importance. There are others who are, and
we're running a big tent here.
In case it isn't clear to anyone, the purpose of this list is to act
as a forum where the developers and users of GoldenCheetah can discuss
how to make it even more awesome than it already is. That includes
bug reports, patches, feature requests and descriptions, crazy ideas,
brainstorming, requests for code review, and constructive criticism.
Those without interest in such topics are welcome to move on.
Sean
SteveI
2009年12月1日 18:10:082009/12/1
收件人 golden-cheetah-users
On Dec 1, 10:15 pm, Sean Rhea <sean.c.r...@gmail.com> wrote:
> In case it isn't clear to anyone, the purpose of this list is to act
> as a forum where the developers and users of GoldenCheetah can discuss
> how to make it even more awesome than it already is. That includes
> bug reports, patches, feature requests and descriptions, crazy ideas,
> brainstorming, requests for code review, and constructive criticism.
> Those without interest in such topics are welcome to move on.
I think what you're saying is you're quite happy for this discussion
> In case it isn't clear to anyone, the purpose of this list is to act
> as a forum where the developers and users of GoldenCheetah can discuss
> how to make it even more awesome than it already is. That includes
> bug reports, patches, feature requests and descriptions, crazy ideas,
> brainstorming, requests for code review, and constructive criticism.
> Those without interest in such topics are welcome to move on.
to continue, so I will add some further thoughts.
I have just constructed a spreadsheet to experiment with a few
scenarios. I calculated NP, TSS, and TSS2 (using IF^4). FTP is assumed
at 300W.
Scenario 1: Cyclist outputs 500W for 10 seconds, then 0W for 50
seconds, repeated 6 times. I had some zeroes before the start and
after the end to make sure nothing got lost in the smoothing. Total
duration 420 seconds.
Scenario 2: Cyclist outputs 500W for 60 seconds, 0W at all other
times. Total duration 420 seconds as above, i.e. lots of recorded
zeroes on the end.
Scenario 3: As scenario 2 but trimmed to 150seconds.
Results:
1: NP = 130W, TSS = 2.04, TSS2 = 0.38
2: NP = 286W, TSS = 9.89, TSS2 = 9.01
3: NP = 384W, TSS = 5.50, TSS2 = 9.01
The reason for choosing these 3 scenarios is that in all 3 cases the
cyclist has spent 60 seconds outputting 500W. You can see that neither
model is additive, due to the effect of the 30 second smoothing.
Scenario 2 shows how TSS is inflated by the zeroes at the end. I think
the people who consider this a desirable effect are very much in a
minority. I don't accept that this is a realistic model of glycogen
depletion in those minutes of outputting zero watts, as I don't see
how the model can know whether or not I'm stuffing myself with cake in
the middle of a club run.
Setting that aside for now, the real comparison is between TSS giving
5.50 for 3 vs 2.04 for 1, whereas TSS2 gives 9.01 for 3 vs 0.38 for 1.
This is a very significant difference, and I'm not sure the choice
between these two options should be made based on the zero padding
issue.
I have a suggestion for TSS3 as follows:
In addition to calculating NP, also calculate NP' by taking the 30
second smoothed data, and eliminating any data points that have a
smoothed value of 0W. Calculate TSS3 in the same way as TSS, but using
NP' instead of NP.
Here is my table again with NP' and TSS3 incorporated:
Results:
1: NP = 130W, NP' = 148W, TSS = 2.04, TSS2 = 0.38, TSS3 = 1.58
2: NP = 286W, NP' = 414W, TSS = 9.89, TSS2 = 9.01, TSS3 = 4.72
3: NP = 384W, NP' = 414W, TSS = 5.50, TSS2 = 9.01, TSS3 = 4.72
NP' will always be greater than NP, due to eliminating the zero values
(after smoothing) from the average. TSS3 will always be smaller than
TSS.
As you can see, TSS3 eliminates the zero padding problem without
introducing a drastic change in the relative stress score of the two
workouts compared to TSS.
The other thing to note is that NP' is the same between scenarios 2
and 3, unlike NP. If NP' is displayed to the user, then the duration
it is based on would also need to be displayed alongside it. I am not
suggesting it should replace NP, as that has its own uses.
The version of GoldenCheetah I'm using is the last pre-built, 1.2.0.
xPower and BikeScore in that version have a similar issue with zeroes
on the end of a ride, so while I've talked about NP and TSS I'm
assuming it is also relevant to xPower and BikeScore.
Andy Froncioni
2009年12月1日 19:17:482009/12/1
收件人 SteveI、golden-cheetah-users
>
> I have just constructed a spreadsheet to experiment with a few
> scenarios. I calculated NP, TSS, and TSS2 (using IF^4). FTP is assumed
> at 300W.
> Scenario 1: Cyclist outputs 500W for 10 seconds, then 0W for 50
> seconds, repeated 6 times. I had some zeroes before the start and
> after the end to make sure nothing got lost in the smoothing. Total
> duration 420 seconds.
> Scenario 2: Cyclist outputs 500W for 60 seconds, 0W at all other
> times. Total duration 420 seconds as above, i.e. lots of recorded
> zeroes on the end.
> Scenario 3: As scenario 2 but trimmed to 150seconds.
>
I can see what you're getting at, but I'm having trouble with some of it
> I have just constructed a spreadsheet to experiment with a few
> scenarios. I calculated NP, TSS, and TSS2 (using IF^4). FTP is assumed
> at 300W.
> Scenario 1: Cyclist outputs 500W for 10 seconds, then 0W for 50
> seconds, repeated 6 times. I had some zeroes before the start and
> after the end to make sure nothing got lost in the smoothing. Total
> duration 420 seconds.
> Scenario 2: Cyclist outputs 500W for 60 seconds, 0W at all other
> times. Total duration 420 seconds as above, i.e. lots of recorded
> zeroes on the end.
> Scenario 3: As scenario 2 but trimmed to 150seconds.
>
1. The TSS/TSS2/TSS3 behaviour you've brought up are artifacts of the
smoothing algorithm, not the TSS formula in question. I would try to
stay away from anything with that short a time-scale. Time scales
should be longer than 5 or 10 minutes, in my opinion. By playing around
with these short bursts, you're just complicating the problem of
debugging the TSS algorithm. It should be possible to construct a toy
problem without the complication of smoothing.
2. My own experience with dynamics is that embedding 'if-statements" in
the code is deadly. There should be enough mathematical tools around
to use formal constructs (avg, weighted avg, etc...). The "if( p ==
0.0 )" stuff is not easily differentiable, not physical, and on top of
that, not elegant .
Andy (no, not that one)
Justin F. Knotzke
2009年12月1日 19:19:422009/12/1
收件人 SteveI、golden-cheetah-users
2009/12/1 SteveI <stephe...@yahoo.co.uk>
The version of GoldenCheetah I'm using is the last pre-built, 1.2.0.
xPower and BikeScore in that version have a similar issue with zeroes
on the end of a ride, so while I've talked about NP and TSS I'm
assuming it is also relevant to xPower and BikeScore.
So are you saying there is a bug in how GC implemented BikeScore?
Or are you saying there is a possible flaw in BikeScore itself ?
J
Andy Froncioni
2009年12月1日 19:36:342009/12/1
收件人 Andy Coggan、golden-cheetah-users
> And as it so happens, for n=17 that P^2 weighting better predicts
> glycogen utilization than weighting using any other integer (the best-
> fit exponent is 1.96).
>
int(d/dt) [ P IF^4 ] / int(d/dt) [ IF^4 ]
would "mimic" an exponent that is somewhere between 1 and 2.
Don't know if this is anything worth looking into, though.
Jim Ley
2009年12月1日 19:56:162009/12/1
收件人 Justin F. Knotzke、SteveI、golden-cheetah-users
2009/12/2 Justin F. Knotzke <jkno...@shampoo.ca>:
I would say for the purposes of calculating BikeScore, leading and
trailing zeros should be removed. (other than 24seconds worth of
leading zero's to ensure that the weighting of all seconds of work in
the file carry the the same weight in the result). That is a very
quick "win" to remove the majority of the most normal scenarios where
BikeScore (and TSS) is inflated - the walking home pushing your broken
bike situation.
Next is the problem of in-ride long zero-watt periods in the data, and
how these are handled. If it's a long gap (how long is a topic of
debate) then the ride needs to be split into seperate rides - or the
long gap periods removed from the calculation so the result is as if
they were seperate rides. Shorter gaps should be considered all zero
power and form part of the data (since if you stop for a minute, the
recovery you get is very real, and no different from a minute not
pedalling.) The exact length of these short and long gaps are
likely to be the biggest debate, personally I would say 30minutes
should be counted as a gap, but a 1 minute stop included as a zero
power time, in between I'm not so sure.
Currently I remove any stop longer than 10 minutes down to 1minute
(30seconds of 0's recorded at the beginning and end of the gap. With
that done, I am generally happy with the TSS / bikescore results - and
it matches to a high degree of confidence to the HR based TRIMP I also
track. I would certainly be interested in having other scores
available to compare and contrast, but I do not currently think
they're likely to be materially different to the result of using
TSS/bikescore once these artefacts of recording have been taken care
of.
Cheers,
Jim.
trailing zeros should be removed. (other than 24seconds worth of
leading zero's to ensure that the weighting of all seconds of work in
the file carry the the same weight in the result). That is a very
quick "win" to remove the majority of the most normal scenarios where
BikeScore (and TSS) is inflated - the walking home pushing your broken
bike situation.
Next is the problem of in-ride long zero-watt periods in the data, and
how these are handled. If it's a long gap (how long is a topic of
debate) then the ride needs to be split into seperate rides - or the
long gap periods removed from the calculation so the result is as if
they were seperate rides. Shorter gaps should be considered all zero
power and form part of the data (since if you stop for a minute, the
recovery you get is very real, and no different from a minute not
pedalling.) The exact length of these short and long gaps are
likely to be the biggest debate, personally I would say 30minutes
should be counted as a gap, but a 1 minute stop included as a zero
power time, in between I'm not so sure.
Currently I remove any stop longer than 10 minutes down to 1minute
(30seconds of 0's recorded at the beginning and end of the gap. With
that done, I am generally happy with the TSS / bikescore results - and
it matches to a high degree of confidence to the HR based TRIMP I also
track. I would certainly be interested in having other scores
available to compare and contrast, but I do not currently think
they're likely to be materially different to the result of using
TSS/bikescore once these artefacts of recording have been taken care
of.
Cheers,
Jim.
Justin F. Knotzke
2009年12月1日 20:15:382009/12/1
收件人 Jim Ley、sean. Rhea、golden-cheetah-users
2009/12/1 Jim Ley <jim...@gmail.com>
I would say for the purposes of calculating BikeScore, leading and
trailing zeros should be removed. (other than 24seconds worth of
leading zero's to ensure that the weighting of all seconds of work in
the file carry the the same weight in the result). That is a very
quick "win" to remove the majority of the most normal scenarios where
BikeScore (and TSS) is inflated - the walking home pushing your broken
bike situation.
Sean, didn't you just fix this ? Or was it something else ?
J
Sean Rhea
2009年12月1日 20:42:222009/12/1
收件人 Justin F. Knotzke、Jim Ley、golden-cheetah-users
I don't currently remove any samples from a ride, and I only add
samples as necessary to wait for the exponentially weighted average
power to decay to 0.1 watts. So if the powermeter turns off, we won't
record data, and if it stays on, we will. That leaves the time at
which to declare a ride finished up to the meter, which is probably
not the best place to leave it. Still, like Jim, I'm not sure what a
good value is, except that it's probably between 1 minute and 60, like
he said, so I'm okay leaving it up to the meter for now.
Sean
samples as necessary to wait for the exponentially weighted average
power to decay to 0.1 watts. So if the powermeter turns off, we won't
record data, and if it stays on, we will. That leaves the time at
which to declare a ride finished up to the meter, which is probably
not the best place to leave it. Still, like Jim, I'm not sure what a
good value is, except that it's probably between 1 minute and 60, like
he said, so I'm okay leaving it up to the meter for now.
Sean
Andy Froncioni
2009年12月1日 21:04:162009/12/1
收件人 Andy Coggan、golden-cheetah-users
> Actually, it does "know", just as it "knows", e.g., how much glycogen
> you had stored in your muscles and liver when you started exercise.
>
You're saying that intra-TSS calculations are linked via a "state". So
where is this state before you start working out? Shouldn't there be a
carry-over of this state from the previous workout? If you start your
workout tired, then the non-additivity principal should definitely kick
in right from the start, no? So where is this carry-over term in the
present Coggan model?
>> One of the things I know is that a model should be continuous across its
>> independent variables (in this case: time).
>>
>
> When it comes to modeling, there really is no right or wrong - the
> only question is how well a model works in practice (and as I've
> pointed out several times, TSS predicts glycogen utilization rather
> well, even though that wasn't the goal). The fact that non-additivity
> is offensive to engineering and/or accountant types is unfortunate,
> but that property is a better reflection of reality than forcing
> things to be additive.
>
common in the biological sciences, I guess. Engineers will still
expect that your model makes TSS(A+0+0+...+0) = TSS(A), however. :-)
SteveI
2009年12月2日 20:50:382009/12/2
收件人 golden-cheetah-users
On Dec 2, 12:17 am, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> I can see what you're getting at, but I'm having trouble with some of it
>
> 1. The TSS/TSS2/TSS3 behaviour you've brought up are artifacts of the
> smoothing algorithm, not the TSS formula in question. I would try to
> stay away from anything with that short a time-scale. Time scales
> should be longer than 5 or 10 minutes, in my opinion. By playing around
> with these short bursts, you're just complicating the problem of
> debugging the TSS algorithm. It should be possible to construct a toy
> problem without the complication of smoothing.
The smoothing is a crucial part of the algorithm, though, it's what
> I can see what you're getting at, but I'm having trouble with some of it
>
> 1. The TSS/TSS2/TSS3 behaviour you've brought up are artifacts of the
> smoothing algorithm, not the TSS formula in question. I would try to
> stay away from anything with that short a time-scale. Time scales
> should be longer than 5 or 10 minutes, in my opinion. By playing around
> with these short bursts, you're just complicating the problem of
> debugging the TSS algorithm. It should be possible to construct a toy
> problem without the complication of smoothing.
correctly recognises that a sustained effort is more taxing than the
same work done as a series of separate efforts, particularly
effectively for short bursts as in my previous scenarios. However I do
agree that more scenarios are useful, so I have just looked at three
more:
1. 4 x 5 mins at FTP with 2 mins rest between each
2. 4 x 5 mins at FTP with 10 mins rest between each
3. 20 mins at FTP
I would say that the relative stress of performing those workouts is 3
is the hardest, then 1 then 2. Here are the values for TSS, TSS2,
TSS3:
1. TSS 37.20, TSS2 31.34, TSS3 34.90
2. TSS 51.36, TSS2 31.34, TSS3 34.90
3. TSS 33.49, TSS2 32.83, TSS3 33.49
So TSS ranks them exactly the opposite to my suggestion, with TSS
being inversely related to what I would regard as the stress of each
workout. TSS3 rates them almost equal, but gets it wrong by ranking 3
as slightly easier and not differentiating between 1 and 2. TSS2 also
ranks them almost equal, but at least correctly ranks 3 as the
hardest, though still fails to rank 1 as harder than 2.
If I had to choose from the 3 algorithms for these 3 scenarios, then I
would rate TSS2 as best, with TSS3 not that much worse as the numbers
are close, and TSS a long way behind due to having significant
differentiation in the opposite manner to what we would want.
> 2. My own experience with dynamics is that embedding 'if-statements" in
> the code is deadly. There should be enough mathematical tools around
> to use formal constructs (avg, weighted avg, etc...). The "if( p ==
> 0.0 )" stuff is not easily differentiable, not physical, and on top of
> that, not elegant .
the cyclist pedals at 1W for an hour, we'd still have a problem there.
I certainly like TSS2 a lot more after looking at these 3 scenarios,
which just shows how careful you have to be in establishing an
appropriate set of test cases.
Re Jim's point about trimming out periods of zeroes between 1 min and
30 mins, it depends whether your focus is on getting NP right or
getting TSS right. Trimming out more will increase NP, but decrease
TSS. Trimming out less will decrease NP but increase TSS. So you have
to choose whether you want to inflate NP, or inflate TSS, or try to
choose a point of balance between the two.
I'm just increasingly convinced that the response characteristic of
TSS is all wrong in this respect as shown by these 3 scenarios. If you
do the same work, but with more rest intervals interspersed, it makes
it easier not harder like the TSS values would have us believe.
David Brower
2009年12月2日 23:11:562009/12/2
收件人 SteveI、golden-cheetah-users
I think the point/claim that Andy Coggan has been trying to make is
that what TSS really does reflect what the body is
experiencing in terms of training stress, for physiological reasons
that don't make immediate sense to those looking only at the math.
That is, I believe he's saying that the 5FTP/2rest X 4 does, in fact,
stress the body more than 20FTP. Why isn't entirely clear to me --
perhaps the lack of steady output with stops and starts that stresses
more than holding the same power continuously. I can accept there's
something going on there.
Intuitively there is something that makes the additive property seem like it should make sense and be the "right" thing, but Coggan is saying the body isn't working that way. I'll also accept that based on the validations he's done, especially regarding intervals with rest.
At the same time, I'm disturbed by 'zeros at the end' raising TSS, and I haven't felt that Coggan has explained that away satisfactorily. I think zeros (or other trivial data) at the end are algorithm busters, and are 'gaming' the scoring rather than reflecting true stress. Otherwise I can do 30 minutes at FTP and nap on the couch for 9.5 hours and have a 10 hour workout, and that seems, well, wrong. Changing my power meter to keep recording based on receiving HR data shouldn't lead to this effect.
I think an argument can be made that there should be something in the algorithm that detects and "ends" the effective workout, and that data beyond that is beyond the accurate capabilities of the TSS-like models. I think Coggan has said that none of the models really adequately account for more than one workout a day. Some of these problems probably derive from that.
I see nothing wrong with the Daniels Points considered part of a multidimensional analysis. The traditional TSS/BikeScore model approach works well, reproducibly for single workout cases where there isn't junk data taking it into the weeds. DP's might be a way of detecting when the weeds are approaching. I like being able to compare two different metrics, because where they don't correlate defines areas that are interesting.
From Coggan's point of view, a single metric is a simple, good thing to tell people who are just pounding away to use, as other scoring will just confuse them and add unnecessary doubt. To the first order, TSS works, and the things that are being discussed here are, by definition, the interests of developers who are looking deeper into it than is probably useful for most power meter users.
-dB
Intuitively there is something that makes the additive property seem like it should make sense and be the "right" thing, but Coggan is saying the body isn't working that way. I'll also accept that based on the validations he's done, especially regarding intervals with rest.
At the same time, I'm disturbed by 'zeros at the end' raising TSS, and I haven't felt that Coggan has explained that away satisfactorily. I think zeros (or other trivial data) at the end are algorithm busters, and are 'gaming' the scoring rather than reflecting true stress. Otherwise I can do 30 minutes at FTP and nap on the couch for 9.5 hours and have a 10 hour workout, and that seems, well, wrong. Changing my power meter to keep recording based on receiving HR data shouldn't lead to this effect.
I think an argument can be made that there should be something in the algorithm that detects and "ends" the effective workout, and that data beyond that is beyond the accurate capabilities of the TSS-like models. I think Coggan has said that none of the models really adequately account for more than one workout a day. Some of these problems probably derive from that.
I see nothing wrong with the Daniels Points considered part of a multidimensional analysis. The traditional TSS/BikeScore model approach works well, reproducibly for single workout cases where there isn't junk data taking it into the weeds. DP's might be a way of detecting when the weeds are approaching. I like being able to compare two different metrics, because where they don't correlate defines areas that are interesting.
From Coggan's point of view, a single metric is a simple, good thing to tell people who are just pounding away to use, as other scoring will just confuse them and add unnecessary doubt. To the first order, TSS works, and the things that are being discussed here are, by definition, the interests of developers who are looking deeper into it than is probably useful for most power meter users.
-dB
回复全部
回复作者
转发
0 个新帖子