I do not understand, average wattage/power would be integration of wattage (joules) divided by time (so back to watts), it’s still watts? Under what implementation would you end up with joules that isn’t just oddly broken in general?

I guess I could see a naive implementation (confusing integration/sampling and discrete summation) going the other way, erroneously ending up with a nonsensical W/s.

Also don’t understand what it has to do with eponyms, which are just substitutes for base units, either your DA works or not, no? Average wattage is kg⋅m²⋅s⁻³ not kg⋅m²⋅s⁻² (joules) or kg⋅m²⋅s⁻⁴

> I do not understand, average wattage/power would be integration of wattage (joules) divided by time (so back to watts), it’s still watts?

Average wattage is measured in watts. You compute it by integrating and then dividing by the measure of the domain of integration.

I used javax.measure a few years ago on a project that was about building a material search engine. It featured search by all sorts of chemical and physical properties. Complete with all the wonderful units that are used around the globe to measure tensile strength, breaking point, conductivity, magnetic properties, etc. To avoid comparing apples to oranges when searching, being able to normalize and convert between different units is key. Additionally, allowing to user to search with their preferred units is also important. We supported hundreds of different properties for a wide range of ceramics, metal alloys and other materials.

Not the easiest framework to work with but pretty well thought out. A good starting point if you are looking to reinvent that wheel.

Yeah, but equivalent units with different names is sort of only a display/formatting issue, right?

This is a matter of perspective.

For example the unit Sievert is an official SI unit despite being just J/kg. This is because confusing equivalent dose and absorbed dose, which also has the unit of J/kg, could be very dangerous.

Note, that this is different from J sometimes being written as Ws. While there are informal conventions, when we use J and when Ws, using the unconventional one would not be technically wrong because 1 J is simply 1 Ws, whereas 1 Sv is not necessarily 1 J/kg when the later is an absorbed dose.

I think one could reasonably disagree with these decisions but that is how the SI people see it.

Sievert is more of a "newtype" in Rust/Haskell terminology than a separate unit. Likewise for radians and moles.

Torque is actually J/rad.

Not in freedom units.

Sure, but I think this is still better than declaring type system bankruptcy because determining whether trees of units are equivalent is hard. You could do newtype wrappers in situations where it is warranted.

> This is a matter of perspective.

I'd make a stronger statement here; this is a specific example of when having units is most powerful. When even though two things are expressed in some common form, they nevertheless represent something different.

> Yeah, but equivalent units with different names is sort of only a display/formatting issue, right?

This could be said of two u32s as well.

> When even though two things are expressed in some common form, they nevertheless represent something different.

This is where people go wrong trying to DRY and other refactors. Slightly forced example but

  function averagePerClassroom(total) { return total / 30; } // 30 kids per class
  function averagePerMonth(total) { return total / 30; }  // assume 30

"Oh, the function body is the same therefore lets refactor this into an "averagePer" function" expect its two completely different concepts and once the code calculates the actual days per month or once classes are no longer 30 people suddenly things need to be un-refactored, or what I see more often, is just branching off inside the new single function based on an argument flag. Horrible.

A joule, notably, is a newton-meter. Torque is also measured in newton-meters, but the meters are perpendicular to the newtons.

Adding energy to torque is rarely going to be intentional.