Proposal: Unilateral movement notation

[OliverCardoza]

Motivation

Some exercises perform reps per side (left/right). For example, one common exercise is lunges holding dumbbells. Let's say you're trying to represent 8 reps a side holding 20 lb DBs for 3 sets.

Current Solutions

The following is simple but ambiguous. Does it represent 8 reps per side or 8 reps total (4 left, 4 right)?

Lunges: 40 8r 3s

This can be made more explicit using a note or metadata:

Lunges:
  # unilateral:
  40 8r 3s

Proposal

Lunges: 40 8re 3s

Note the e in 8re. The above would read as lunges performed with 40 lbs (assumed units) for 8 reps each side for 3 sets. The JSON representation would be something like:

{
  "Name": "Lunges",
  "Performances": [
    {
      "Load": 40,
      "Reps": 8,
      "Sets": 3,
      "Unilateral": true
    }
  ]
}

If Unilateral is considered too technical it could be swapped out for something more intuitive like "RepsPerSide": true.

Feedback

At the moment this is a very rough idea. The benefit I see is improved clarity and ease of writing since my current usage of # unilateral: metadata is not very ergonomic. However, the main downside I see is that this opens up the door for more data to get similar qualifiers in the spec rather than relying on metadata.

I'm curious how other folks deal with this problem. Do most people just accept the convention that the unilateral movements record the reps per side?

[scottt2]

Dude, @OliverCardoza this is such a well written proposal! Thanks for taking the time to present your idea like this.

I really like the simplicity of the additional operator re though I do (and it could be a mistake) always bias toward fewer keywords in a language rather than more.

To be clear--I am not opposed to this idea because you are solving for something that is a super common pain point.

How I have been expressing this is like so

one arm barbell curl:
  # reps left: 10
  # reps right: 10
  45 20r 3s

I do not like how much I have to type but I have found success in leaning into metadata. Metadata is carte blanche--folks can bend it to whatever shape they need. In this example, I wanted to record the total combined volume but I also wanted to note how it is a composite of two unilateral mini-sets.

If I am doing something where I don't want the total volume to be composite (say I don't feel as though the additional recorded volume is actually indicative of training stimulus), I do something like this

one arm barbell curl:
  # reps left: 10
  # reps right: 10
  45 10r 3s

Note the 10r in place of the 20r. This gives me flexibility in how I want to analyze this data later on. I have been working on software for analytics for a bit and this has proven to be quite useful.

Now rolling back to your Current Solution example, you are doing the same thing but in a more (like you said) ergonomic manner. I really like the # unilateral: true. I have also done something like # type: unilateral. That works well when you have symmetrical volume--i.e., both sides completed the same number of reps.

However, the main downside I see is that this opens up the door for more data to get similar qualifiers in the spec rather than relying on metadata.

And that's why I feel that we do not want to reach for the re yet. I learned early on that metadata really is the secret sauce w.r.t analyzing later and that sauce is basically a unique flavor to the individual.

---

Sorta Related

I don't often have the opportunity to chat with someone using TD so I am super curious to see how else you are using it. One thing I wanted to bring up as this is a pain point I have hit with some exercises and I was curious your thoughts on it.

I have a reverse hyper machine. I absolutely love that thing. My back does, too. Anyhow, if your unfamiliar with a reverse hyper, it's basically a pendulum you swing by using your lower back muscle. Now the issue is that you can quite easily load a decent amount of weight on there and swing it for alot of reps.

Example

reverse hyper: 350 25r 3s

This volume is NOT what I would consider in the same tier as something like a squat. That 26,250 in volume throws all my historical analysis way off.

What I have been doing is using metadata to record what I call a "volume index" in an effort to record what I perceive to be the true training stimulus. Basically a means of "coloring" volume such that I can tune my analytics.

Anyhow, I had been considering (like you with your awesome proposal) to bake this into the language. I have never been able to pull the trigger yet as I feel like this is not universal enough to qualify into the language itself.

I have a few variants of TD I work with and in every case so far, I felt it better to defer to the analytic software for these additional features. Not that the language is complete by any means but I hold simplicity very highly.

I suppose I should get off my ass and release the analytic software to start getting more feedback from folks. I truly appreciate you taking the time to spitball about this little tool I've built. I hope you find value in using it and I also hope to keep in touch with more ideas and feature requests!

Thanks again,
-Tyler

[OliverCardoza]

I feel where you're coming from on keeping the language very tight and simple. Especialy given that you've implemented the spec in 5 languages 😆

As I wrote out this proposal I partially convinced myself that this was unnecessary. You could embed unilateral in any number of places:

• movement name: Bicep curl per side:
• metadata: # unilateral: true
• note: * reps are per side
  So I'm in total agreement it's not necessary.

I only have 1 lingering piece of doubt which is that repeating # unilateral: true many, many times may become a significant pain point. I'm converting a few years of training data over to traindown so I'm feeling this a lot atm. It may be good to come up with some principles for when you feel something is worthwhile to add into the spec vs. using metadata/notes/name embedding. For example, the + superset and | circuit operator (#3) seem to have passed the bar. It would definitely help me as I have a few other ideas to know whether the seem like good fits for new operators or should be kept as metadata.

I'd like to sit on this proposal for a bit longer to let it stew a bit. Movement name may end up being easier?

---

RE: reverse hyper volumes

I'm also thinking of doing similar analytics. One toy idea is to report calories burned per workout. I was planning on building a mapping from movement to metabolic equivalent for task (MET) [1]. Then the combination of movement MET and weight can be used to calculate calories [2].

IMO - This doesn't need to be in the language, at least within the session/movement/performance stanzas. It could just be a separate config file used for analytics/reporting but would be considered a layer on top of base traindown.

[1] https://www.verywellfit.com/met-the-standard-metabolic-equivalent-3120356
[2] https://www.verywellfit.com/how-many-calories-you-burn-during-exercise-4111064

---

Obligatory, thanks for building traindown! I'm happy to chat more about traindown things if you'd like to bounce ideas off of someone. I think I have 1 more proposal to be written for review which I'll create a separate issue for.

[scottt2]

haha one of those was community provided and you have also contributed to the Go one so it's definitely not me doing all the bit twiddling. That said, the motivation for simplicity is due in part to the "porting" consideration you mention.

As I wrote out this proposal I partially convinced myself that this was unnecessary

I have done this same thing many a times.

It may be good to come up with some principles for when you feel something is worthwhile to add into the spec vs. using metadata/notes/name embedding.

That's a great idea because my current heuristic is admittedly opaque. I honestly don't have an explicitly defined rubric which is not acceptable now that more folks (like you) are using Traindown.

Taking the + example, I reasoned that the concept of associating one movement with another is very common as it applies to many types of training.

The | has yet to be implemented upstream though I did have a working version at some point. I just didn't feel comfortable committing to it but I still feel it is generalizable enough to be a first class operator. The concept of circuits could replace the simple + in theory. In practice, the complexity is akin to recursion ergonomics in a language and I never felt like I nailed all the corner cases.

Back to re--the more I thought about it, the more I think this should be a first class operator. I feel given the reasoning above it does qualify. Unilateral movements are very common like supersets and it is rare to have asymmetrical rep counts between sides. In the latter case, you could revert to the metadata approach to capture the delta.

I say why not slap the re in the Go library and see how it feels?

If we think it's rad, I can upstream that into the Dart (reference implementation just due to being able to use it in Flutter) and the other libraries. We can then update the formal spec once we are sure it feels right (I think it will).

Obligatory, thanks for building traindown! I'm happy to chat more about traindown things if you'd like to bounce ideas off of someone.

Man, I am just happy others are finding it useful so really thank you for giving it a try. I would love to be able to bounce ideas off you (like we are now!).