Adding new ratio unit: Strain (ε)

[n-tiz]

Adding new ratio unit:

Strain (ε): Unit used in continuum mechanichs to define the amount of deformation per unit length of an object when a load is applied, it is equivalent to DecimalFraction, but with abbreviation (it's a ratio of Length per Length).
This unit is especially used with strain gauges.

I hesitated to create a new "LenghtRatio" unit, but i'm not sure it's a good idea to type ratio.

You can find more information about this unit here:
https://www.omega.co.uk/literature/transactions/volume3/strain.html
or here:
https://www.ni.com/fr-fr/innovations/white-papers/07/measuring-strain-with-strain-gages.html

I also added the french localization (def) for this unit.

[angularsen]

Thanks @n-tiz !

I believe strain is quite widely used and that we should include it. Although I agree it doesn't fit 100% into Ratio, I can't think of any better way to include it. I don't like the idea of having several dimensionless quantities like LengthPerLength, I would rather bucket these units into Ratio.

Thoughts @lipchev @tmilnthorp ?

[lipchev]

I am much more in favor of introducing a separate Strain quantity.

The most basic argument stems from the question: "where would you put the description of what Strain is?" If we agree that this cannot be a comment that is part of the Ratio then the case is settled.

If not, then there is another argument about having a number of custom operations that could be introduced into it- expressing clearly the relationship to Length: like a FromMeasuredDeformation method (or something like it) that is not just a the result of Lenght1 & Lenght2- but is clear about what those represents (I didn't really stop to read on it).

Also I noticed some relationship with Current/Resistance- that is maybe not relevant- I didn't stop to read it either, but somebody else might..

[lipchev]

Also if we ever had to produce a subset of quantities (like the Commonly-Use-Quantities with the nanoFramework) it would seem much easier to do so on a per-quantity level, rather than having to carve stuff on a per-unit-basis..

[angularsen]

The biggest counter argument I see, is that there are a bunch of dimensionless units out there. Ratios are used everywhere. We have declined some in the past, telling them to use Ratio instead.

For dimensionless units with a unit abbreviation, the benefit of adding a Ratio unit is to support ToString() and Parse(). I don't really know how many such ratios units with abbrevations exist and are widely used, but I have a feeling there are many. I could be wrong though.

There is a much larger cost on binary size by adding a new quantity vs a new unit. It is probably 10-100x the size, but I don't have the number. So size and bloat concerns me a bit.

If there good use cases for using strain in arithmetic operations to/from other quantities, then that increases the benefit of making it a separate quantity.

[n-tiz]

I could add a Strain quantity, with a single unit with the same name (I think ?)
Maybe I could also add some operators for implicit conversion from/to Ratio.

But actually we can also measure a strain with ratio quantity, percent or even decimal fraction are widely used in Mechanical testing (which is a fundamental materials science), so i should add theses units too in the new Strain Quantity..

That make me notice that to calculate strain with strain gauges, we use another Ratio "typed" quantity : mV/V (Millivolt per Volt)

Excitation voltage is applied to the input of gauge (in Volts) and another voltage is taken from the output (in milliVolt), and we use that ratio to determinate the physical strain.
And that's why there is a "relationship" with Current/Resistance, because in this case the electrical resistance change when the gauge is deformed.

It reminded me of an old PR i opened in 2019: #697 to add.. Deformation (strain) and "ElectricRatio" an ElectricPotential Ratio quantity.

And we had a similar conversation about the fact that current Ratio quantity is not linked to physical quantities when these units are linked to Length/ElectricPotential.
I clearly agree that there are a bunch of dimensionless units (and some of them are linked to physical quantities) and we can't add all of them to Ratio.

Do you have any idea about how to add them and keep it consistent ? Maybe by inheriting from Ratio ?

[lipchev]

No inheritance with structs I'm afraid. But I wouldn't mind the redundancy of units- Density.GrammsPerLiter is not the same as MassConcentration.GrammsPerLiter even if the units match.

Granted, 1.5 mb is probably bigger than the size of any of the the binaries I've ever produced- but still doesn't seem like that much in practice. I bet you 90% of the people wouldn't even look at the binary size of a library like that- even if it grew twice in size (which doesn't seem likely to happen anytime soon).

On the other hand, the Ratio is likely to be one of the most widely used quantities- here it seems more likely that people (like myself) might notice the-extra-long-auto-completion list that pops up when you type Ratio.

[lipchev]

PS I'm even in favor of (and was planning to re-open that topic) introducing additional operators to the Ratio (the most useful of them being the Q + R (%) operator).

Also I think we can have implicit conversions to/from Ratio for some (if not all) dimensionless quantities (would have to double check if some nasty ambiguity would emerge, but for the most part I think it would be safe). This would be the equivalent of inheritance- if we really didn't want to duplicate stuff from Ratio.

[angularsen]

I bet you 90% of the people wouldn't even look at the binary size of a library like that

Sure, maybe, but I also suspect 90% only use length, mass, and a couple other quantities. They are getting quite a load of quantities they typically won't need.

I think 1.5MB is obscenely large already, and I fear it is a slippery slope towards doubling the quantities if we start adding various ratios and X-per-Y units as quantities.

I try to fall back to 80/20 rule for what to include and not. If we add strain to ratio (mV/V, mm/mm etc) then I think it will be even harder to reject the next ratio asking the same thing. Maybe it is be better to just implement these ratios per application, or use Ratio without the abbreviations.

If we found a better way to keep the binary size low I would be all for adding it all, but for now I'm starting to think this is a no 😕

[lipchev]

We should definitely look into the source-generators approach- there is nothing that could possibly give you a better size reduction, than handpicking the quantities you need from a json file.

We'd still need to tweak the interoperability issues, the operators etc but I'm pretty sure it's doable. Unless of course this turns out to really affect the VS experience- but even so, if we manage to solve the first two issues, then many alternatives would open up.

[n-tiz]

I dont know enough the project to help you about that..

But I don't really understand why you're focused on the binaries size, I think your're right when you say that 90% of devellopers doesn't even look at library size (especially in .Net).

But I can cleary understand that you don't want to add quantities that won't be used by 99% of people.

I don't know if you already talked about that, but did you think about splitting UnitsNet in multiple packages ?
Maybe something like :
UnitsNet.SI (only International System of Units)
UnitsNet.Imperial (imperial and US customary measurement systems)
UnitsNet.Extended (all of exotic units)
Etc.

Or maybe by splitting it by domain ? (Fondemental sciences, Navigation, cooking, etc.)

[angularsen]

I know opinions are split on what is too large a binary size, but we have had that concern raised here before by users and I also agree that for a library of this kind, I would expect hundreds of kilobytes, not megabytes.

Background on binary size

IoT scenarios in particular have constraints, one solution to that is being solved here:
#836

Docker images are also generally kept slim and large nugets don't help on that.
The many applications I've been part of uses 100+ nugets, so the total size does start to add up. As a library contributor, I feel responsible to keep it at a reasonable size.

We have taken several measures before to keep size down:

• Move code out into separate nugets: Add UnitsNet.NumberExtensions nuget #742
• Reduce overload explosion of int, double, decimal with implicit cast to our own value type, this actually had a big impact due to 1000+ units.

Some previous ideas we have not gone for:

• Change from struct to class and inheritance Switching quantity to class from struct #500, but there are pros and cons.
• Split into domain nugets or SI/imperial Proposal: Reducing size of library (WIP) #372 , but it seems hard to find good cuts of domains that don't overlap in quantities, and we would lose out on arithmetic between quantities of different domains.

Back to this topic

You mentioned strain could be measured both as length-per-length and mV/V.
Can they be converted between with a function?
If so, then maybe it warrants a separate quantity for Strain.

[n-tiz]

You mentioned strain could be measured both as length-per-length and mV/V.
Can they be converted between with a function?
If so, then maybe it warrants a separate quantity for Strain.

Hum not really, both of them are related to Strain but they can't be converted between.
Actually it could work for my case, but it's not really accurate and should not be added to the library.
And IMO Strain without Ratio units is not really interesting.

I think until there is a better way to integrate these units, i will fork the project to add them, and use this fork in my project.

[angularsen]

Thank you. For now I don't see a good way to proceed with this, sorry. Let's revisit in the future.