v6 Wishlist

[angularsen]

This issue serves as a place to discuss what to include in this version, since major version bumps allow us to make breaking changes we think are necessary or worth it.

The wishlist keeps track of the items to include, but items may be added or removed at any time.

As changes are completed, they are added to https://github.com/angularsen/UnitsNet/wiki/Upgrading-from-5.x-to-6.x

Wishlist

• Remove BtuPerSquareFootDegreeFahrenheit Remove obsolete units #1372
• Fix plural form of Speed.MeterPerMinute
• Rename/fix calorie/btu units to specify their definition as International Steam Table (IT) or Thermochemical (th), see https://github.com/angularsen/UnitsNet/pull/1196/files#r1105112205
• Consistent imperial/UK/US unit namings v6 Wishlist #1200 (comment)
• UnitAbbreviationsCache.ctor() should create empty cache, not load default abbreviations
• UnitParser.ctor(UnitAbbreviationsCache) should not fallback to built-in units if given null
• Rename AbsorbedDoseOfIonizingRadiation to RadiationAbsorbedDose Add radiation equivalent dose #1352 (comment)
• Review all [Obsolete] in code and add to this list
  • Remove obsolete Equals overloads 🐛ComparisonType ignored in obsolete Equals method #1396 (comment)
• Fix typo in TonneSquareMilimeter, missing l
• Remove TorquePerLength: dimensionless, domain specific, conflicts with Force = Torque / Length
• Rename ThermalResistance to ThermalInsulance: enables future conversions between thermal conductivity, resistivity if added
• Change Angle base unit from Degree to Radian

[maxreb]

Add System.Text.Json support #966

[angularsen]

Decide on a naming and abbreviation convention for imperial/UK units and US units; like gallon, ounces, cup etc.

It is a bit of a mess right now:

LINQPad sample

void ListUnits(string withPartialName)
{
    Quantity.Infos
        .SelectMany(i => i.UnitInfos
            .Where(n => n.Name.Contains(withPartialName))
            .Select(u => new 
            { 
                u.Name, 
                Abbrev = UnitAbbreviationsCache.Default.GetDefaultAbbreviation(u.Value.GetType(), Convert.ToInt32(u.Value)) 
            }))
        .Dump(withPartialName);
}

ListUnits("Uk");
ListUnits("Imperial");
ListUnits("Us");

I personally like "UK", since it is shorter and better matches "US".
Wolfram also uses US gallon and UK gallon.

Some conventions for imperial gallons:
https://en.wikipedia.org/wiki/Gallon#:~:text=the%20imperial%20gallon%20(imp%20gal,American%20and%20Caribbean%20countries%3B%20and

Today the abbreviation convention is gal (U.S.) and gal (imp.).
Depending on landing on UK or imperial naming, we could go with one of these pairs:

• US gal and UK gal
• US gal and imp gal
• gal (US) and gal (UK)

We can support multiple of these plus the old ones, but the primary form should be standardized across the different units.

[ebfortin]

Do not throw ArgumentException on NaN, Inf+ or Inf- or give a way to configure the behavior globally.

Context:
#1268 (comment)

[MisinformedDNA]

I think UnitsNet should be more extensible. Perhaps there could be a base package, but separate NuGet packages for US measurements, Imperial, UK, etc. Alternatively, customizable abbreviations could be a solution. I would never expect me or my users to see "gal (US)" instead of "gal". This would also help the debate here.

UPDATE:

Custom abbreviations already exist: UnitAbbreviationsCache.Default.MapUnitToDefaultAbbreviation(HowMuchUnit.Some, "sm");

[angularsen]

I think UnitsNet should be more extensible.

Conceptually, I agree.

Customizable abbreviations is already supported as you found, and we support custom quantities and units with some limited functionality: https://github.com/angularsen/UnitsNet/wiki/Extending-with-Custom-Units

Splitting up in packages is not so easy though. Things like Torque = Force * Length becomes problematic when types exist in different packages and they can't have circular dependencies. Imperial is even worse, splitting some units of a quantity to different packages. The main problem is static typing, which is also one of the main features of UnitsNet.

One benefit of splitting up in packages is smaller binary size to only bring in what you need.
Some prototyping here: #1181

[Markussp256]

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

[angularsen]

@Markussp256

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

Some more fixes were made recently in
#1351

[lipchev]

MassMomentOfInertia.json has the unit TonneSquareMilimeter (with as single "l")

PS I'm surprised this is the only one- I often miss the second "l" as well.. Should I we add it for v6?

[lipchev]

In #721 it was (I think correctly) suggested that the ThermalResistance.json should be renamed to ThermalInsulance, what do you think about it? That would open up the "name" for the actual quantity (which I think was never added just because of the naming collision). There looks to be a nice triangle of relations that could be formed between these (also there are also the Thermal Conductivity/Resistivity etc..).

[lipchev]

Finally, I think we should change the BaseUnit of the Angle from Degrees to Radians (as per the SI definition), but more importantly, since SI doesn't have a base dimension for the Angle it relies on the fact that:

the SI radian is a dimensionless unit equal to 1. In SI 2019, the SI radian is defined accordingly as 1 rad = 1.

This is similar to how the Ratio or the MassFraction have their BaseUnit to the DecimalFraction (i.e. the "unit-less 1").

This would enable (and speed up) the "generic-conversions" with all other Rotational quantities (which are all based on the Radian).

[lipchev]

Ok, one more: what do you think about removing the TorquePerLength (added in #712 ) - I've been looking for half an hour already, and cannot find a single reference to any of it's units on the internet. The only document that was found using the XmlDocSummary:

"The magnitude of torque per unit length."

Was found on this page, where they say that

The torque coefficient is a dimensionless physical quantity that represents the magnitude of torque per unit length.

And down below there's a table with unit-less values.
Finally, there it isn't even possible to have a Torque / Length operator, as it is already taken (resulting in Force).

@dschuermans Is this quantity still useful to you? Do you think this is actually used by anyone else?

[dschuermans]

@lipchev i'm no longer working at that company, so I honestly don't care 😅
I don't think they'll be able to upgrade to v6 anyway with the breaking change in equality comparison (1m != 100cm) so meh 🤷

[angularsen]

I agree with all above suggestions.

Finally, I think we should change the BaseUnit of the Angle from Degrees to Radians (as per the SI definition)

Sure, we can do that. I think it's fairly safe to change base unit since it should be considered an implementation detail, although I'm not sure I see a huge benefit here.

I'll add these todo items to the top description:

• Fix typo in TonneSquareMilimeter, missing l
• Remove TorquePerLength: dimensionless, domain specific, conflicts with Force = Torque / Length
• Rename ThermalResistance to ThermalInsulance: enables future conversions between thermal conductivity, resistivity if added
• Change Angle base unit from Degree to Radian

[lipchev]

I'd like to also suggest a few modifications to the operators / UnitRelations.json:

double = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule

Here's an interpretation from the AI about it:

The result is a dimensionless value, which is effectively a conversion efficiency factor. It represents how efficiently the energy in the fuel is being converted into useful work (in terms of specific energy and fuel consumption).

If the result equals 1, it indicates a perfect match between the energy content of the fuel and the amount consumed to produce energy. If the result is less than 1, it could indicate some inefficiency or losses in the energy conversion process.

I would therefore suggest that we change it accordingly:

• Ratio.DecimalFraction = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule -- NoInferredDivision

I think the same reasoning would also apply to:
double = TemperatureDelta.Kelvin * CoefficientOfThermalExpansion.PerKelvin

The result is dimensionless and represents the relative expansion or contraction of a material when its temperature changes by a given amount.

• If the result is 0.01, for example, it means that the material expands (or contracts) by 1% of its original size due to the given temperature change.
• This result could be used to calculate the actual size change of an object by multiplying this coefficient by its initial size (e.g., length, volume).

• Ratio.DecimalFraction = TemperatureDelta.Kelvin * CoefficientOfThermalExpansion.PerKelvin -- NoInferredDivision

[lipchev]

And finally, I think that instead of
double = Density.KilogramPerCubicMeter * SpecificVolume.CubicMeterPerKilogram
we should have an inverse relationship:
1 = Density.KilogramPerCubicMeter * SpecificVolume.CubicMeterPerKilogram

"XmlDocSummary": "In thermodynamics, the specific volume of a substance is the ratio of the substance's volume to its mass. It is the reciprocal of density and an intrinsic property of matter as well.",

This would remove the last of the doubles from the UnitRelations.json.

PS What do you think about having an implicit operator for these relationships:

"1 = Area.SquareMeter * ReciprocalArea.InverseSquareMeter",
"1 = Density.KilogramPerCubicMeter * SpecificVolume.CubicMeterPerKilogram",
"1 = ElectricResistivity.OhmMeter * ElectricConductivity.SiemensPerMeter",
"1 = Length.Meter * ReciprocalLength.InverseMeter",

I don't there is anything stopping us from having:
var length = Length.FromMeters(10);
ReciprocalLength inverseOfLength = length; // same as calling length.Inverse()

[tm-ren]

I'd like to also suggest a few modifications to the operators / UnitRelations.json:

double = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule

Here's an interpretation from the AI about it:

The result is a dimensionless value, which is effectively a conversion efficiency factor. It represents how efficiently the energy in the fuel is being converted into useful work (in terms of specific energy and fuel consumption).
If the result equals 1, it indicates a perfect match between the energy content of the fuel and the amount consumed to produce energy. If the result is less than 1, it could indicate some inefficiency or losses in the energy conversion process.

I would therefore suggest that we change it accordingly:

• Ratio.DecimalFraction = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule -- NoInferredDivision

I think the same reasoning would also apply to: double = TemperatureDelta.Kelvin * CoefficientOfThermalExpansion.PerKelvin

The result is dimensionless and represents the relative expansion or contraction of a material when its temperature changes by a given amount.

• If the result is 0.01, for example, it means that the material expands (or contracts) by 1% of its original size due to the given temperature change.
• This result could be used to calculate the actual size change of an object by multiplying this coefficient by its initial size (e.g., length, volume).

• Ratio.DecimalFraction = TemperatureDelta.Kelvin * CoefficientOfThermalExpansion.PerKelvin -- NoInferredDivision

My only comment on the above is consistency throughout the project.
For example, currently Length / Length is a double not a Ratio (it could be an Angle which is also technically a ratio.)
The use of the Ratio type is not particularly consistent throughout the project.
Why/when would you use double over ratio or vice versa?

[lipchev]

@tm-ren I agree, personally I'd say that all of these should return a Ratio, but that would be much more impactful of a change..

On the other hand, I actually consider the operations like Q3 Divide<Q1, Q2, Q3>(Q1 left, Q2 right), and Q2 Convert<Q1, Q2>(Q1 from) as being part of the "relations" (or the custom mapping functions), which I really want to constrain to operate on descendants of IQuantity..

[lipchev]

@tm-ren I agree, personally I'd say that all of these should return a Ratio, but that would be much more impactful of a change..

Although, this would require also replacing the * operators with double (or QuantityValue).. Note however that, there is a very natural implicit conversion between my fraction-based QuantityValue and the Ratio..

[lipchev]

I'd like to also suggest a few modifications to the operators / UnitRelations.json:

double = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule

Here's an interpretation from the AI about it:

The result is a dimensionless value, which is effectively a conversion efficiency factor. It represents how efficiently the energy in the fuel is being converted into useful work (in terms of specific energy and fuel consumption).
If the result equals 1, it indicates a perfect match between the energy content of the fuel and the amount consumed to produce energy. If the result is less than 1, it could indicate some inefficiency or losses in the energy conversion process.

I would therefore suggest that we change it accordingly:

* [ ]    `Ratio.DecimalFraction = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule -- NoInferredDivision`

Oh, I just realized that this isn't a straightforward Ratio- the direct multiplication actually represents:

a scalar, which reflects how much energy is used in terms of fuel consumption per unit energy produced.

In most cases, what you’re really interested in is efficiency, i.e., how well fuel energy is converted into useful work. If you multiply these two values directly and get something like 8800, you’ve got an inverse efficiency in a sense because it’s showing how much extra energy is consumed compared to what you’re inputting.

To get an efficiency measure, you can invert this result to express it as a ratio (or percentage) of how much of the fuel’s energy is being used efficiently:

Efficiency=1 / Result

However this type of relationship isn't directly supported with the UnitRelations.json, and I'm not even sure that the "efficiency ratio" should be the default result here..

The direct fuel energy factor represents how much energy you get for a given amount of fuel. It could be used in calculations where you’re trying to scale fuel consumption based on the required energy output. This would be more useful in applications where you need to estimate fuel usage rather than focusing on efficiency directly.

The tests are called BrakeSpecificFuelConsumptionTimesSpecificEnergyEqualsEnergy, but that should probably be something like BrakeSpecificFuelConsumptionTimesSpecificEnergyEqualsEnergyFactor.

If we were to stick with IQuantity - then perhaps this should instead be defined as:

• Scalar.Amount = SpecificEnergy.JoulePerKilogram * BrakeSpecificFuelConsumption.KilogramPerJoule

Alternatively we could keep it as it is, and I'll just ignore it in the QuantityConverter..

[lipchev]

@angularsen What would you say about adding the System.Runtime.CompilerServices.Unsafe package for netstandard2.0? It's dll size is only 18 KB, version 6.0.0 hasn't changed since 2021 and this would give a significant boost in performance (and remove some #if NET .. #else.. optimizations I've got setup at the moment).
I haven't got the final size of my proposal for UnitsNet v6 as I'm still keeping some of the old code (for testing), but I can guarantee an overall reduction in size (we're talking a lot more than 100K)..

[ebfortin]

I aggressively agree! Le mar. 15 oct. 2024, 08 h 09, lipchev ***@***.***> a écrit :

…

@angularsen <https://github.com/angularsen> What would you say about adding the System.Runtime.CompilerServices.Unsafe <https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe> package for netstandard2.0? It's dll size is only 18 KB, version 6.0.0 hasn't changed since 2021 and this would give a significant boost in performance (and remove some #if NET .. #else.. optimizations I've got setup at the moment). I haven't got the final size of my proposal for UnitsNet v6 as I'm still keeping some of the old code (for testing), but I can guarantee an overall reduction in size (we're talking a lot more than 100K).. — Reply to this email directly, view it on GitHub <#1200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNYDWKM2WNALEQCOUJOVPTZ3UAYPAVCNFSM6AAAAAAUZHZAOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJTG4ZTOMRRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[angularsen]

@lipchev Can you explain like I'm 5, please? 😅

How would we use this package to save binary size?
This is not needed for net8.0 target then, I assume?

[lipchev]

@lipchev Can you explain like I'm 5, please? 😅

How would we use this package to save binary size? This is not needed for net8.0 target then, I assume?

@angularsen This isn't about reducing the binary size, in fact the dependency would add the System.Runtime.CompilerServices.Unsafe.dll (which is 18 KB) to the netstandard release only, but note that the nuget is fairly popular, and is often referenced by other libraries / larger projects) (the Fractions.dll, if included is another 45KB).

The reduction in size I was talking about comes from other means, notably removing as much code-duplication as possible (mostly using extension methods and exception helpers). I have the still-unreleased v6 with a lot more "actual code" than before down to 2 070 528 bytes (the v5 shows as 2 343 936 bytes). Its a shame that the extension properties didn't get released in this cycle, that would have had a huge impact on the size of the core library...

As for the benefits of the nuget itself, well.. other than the Span<T> which should definitely come in handy when optimizing the the string-related stuff, there are a few operations in the Unsafe class which would significantly reduce the amount of allocations we get from working with the T: Enum method (which is a lot).

Here are a few benchmarks to showcase the difference:

[ShortRunJob(RuntimeMoniker.Net48)]
[ShortRunJob(RuntimeMoniker.Net80)]
public class EnumToIntegerBenchmarks
{
    private static readonly MassUnit Unit = MassUnit.Gram;

    private static readonly int NbIterations = 500;

    [Benchmark(Baseline = true)]
    public int ConvertToInt32()
    {
        var unit = Unit;
        var total = 0;
        for (var i = 0; i < NbIterations; i++)
        {
            total += Convert.ToInt32(unit);
        }

        return total;
    }

    [Benchmark(Baseline = false)]
    public int ConvertWithCast()
    {
        var unit = Unit;
        var total = 0;
        for (var i = 0; i < NbIterations; i++)
        {
            total += (int)(unit);
        }

        return total;
    }

    // #if NET
    [Benchmark(Baseline = false)]
    public int ConvertWithUnsafe()
    {
        var unit = Unit;
        var total = 0;
        for (var i = 0; i < NbIterations; i++)
        {
            total += (Unsafe.As<MassUnit, int>(ref unit));
        }
    
        return total;
    }
    // #endif
}

And here are the results:

Method	Job	Runtime	Mean	Error	StdDev	Ratio
ConvertToInt32	ShortRun-.NET 8.0	.NET 8.0	3,332.85 ns	251.935 ns	13.809 ns	1.00
ConvertWithCast	ShortRun-.NET 8.0	.NET 8.0	98.14 ns	1.980 ns	0.109 ns	0.03
ConvertWithUnsafe	ShortRun-.NET 8.0	.NET 8.0	98.04 ns	2.834 ns	0.155 ns	0.03
ConvertToInt32	ShortRun-.NET Framework 4.8	.NET Framework 4.8	9,150.37 ns	1,283.718 ns	70.365 ns	1.00
ConvertWithCast	ShortRun-.NET Framework 4.8	.NET Framework 4.8	98.38 ns	0.504 ns	0.028 ns	0.01
ConvertWithUnsafe	ShortRun-.NET Framework 4.8	.NET Framework 4.8	98.60 ns	0.909 ns	0.050 ns	0.01

For the already boxed Enum there is also the Unsafe.Unbox<int>(unit) (which although better than the ConvertTo version, ended up having the same performance as (int)(object)unit:

Method	Job	Runtime	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
ConvertToInt32	.NET 8.0	.NET 8.0	2.775 μs	0.0364 μs	0.0340 μs	1.00	0.02	0.7172	12000 B	1.00
ConvertWithCast	.NET 8.0	.NET 8.0	1.694 μs	0.0069 μs	0.0065 μs	0.61	0.01	-	-	0.00
ConvertWithUnsafe	.NET 8.0	.NET 8.0	1.694 μs	0.0088 μs	0.0082 μs	0.61	0.01	-	-	0.00
ConvertToInt32	.NET Framework 4.8	.NET Framework 4.8	9.228 μs	0.0652 μs	0.0610 μs	1.00	0.01	1.9073	12035 B	1.00
ConvertWithCast	.NET Framework 4.8	.NET Framework 4.8	3.402 μs	0.0252 μs	0.0236 μs	0.37	0.00	-	-	0.00
ConvertWithUnsafe	.NET Framework 4.8	.NET Framework 4.8	3.417 μs	0.0175 μs	0.0164 μs	0.37	0.00	-	-	0.00

Funny enough, on net48, using an "Unsafe" implementation of a UnitEqualityComparer<TUnit> (that casts TUnit to int) has the exact performance as the == operator, which is 5x faster than the default equality comparer: EqualityComparer<MassUnit>.Default.Equals(unit, targetUnit).

[lipchev]

I also have a bit of an issue with GenericMathExtensions- I'd like to add IQuantity to the constraint, as the way it stands- the constraint is also a match for an array of integers, which have the same prototype in System.Linq.Enumerable.. I don't think we'd want anybody depending on UnitsNet for that kind of sums..
Also, there is slight performance gain to be had from converting the aggregation with an iterator based implementation:

        using IEnumerator<T> e = source.GetEnumerator();
        if (!e.MoveNext())
        {
            return T.AdditiveIdentity;
        }

        T result = e.Current;
        while (e.MoveNext())
        {
            result += e.Current;
        }

        return result;

Method	NbOperations	Mean	Error	StdDev	Ratio	Gen0	Allocated	Alloc Ratio
SumOfVolumes	10	548.3 ns	2.30 ns	2.04 ns	1.00	0.0277	464 B	1.00
SumOfVolumesWithIterator	10	446.9 ns	1.98 ns	1.75 ns	0.82	0.0277	464 B	1.00
SumOfVolumes	100	5,994.4 ns	40.33 ns	35.75 ns	1.00	0.2670	4544 B	1.00
SumOfVolumesWithIterator	100	5,080.8 ns	17.51 ns	15.53 ns	0.85	0.2670	4592 B	1.01
SumOfVolumes	1000	61,025.7 ns	238.20 ns	222.82 ns	1.00	2.6855	45392 B	1.00
SumOfVolumesWithIterator	1000	55,652.2 ns	274.11 ns	242.99 ns	0.91	2.7466	46256 B	1.02

There is also a potential for misuse of the UnitMath extensions if passed a list of the "logarithmic" quantities such as PowerRatio and AmplitudeRatio. I believe we've already talked about the operations with Temperature before (which should not be acceptable for the Sum method, but would be fine to Average)...

I've been thinking about splitting the IArithmeticQuantity interface into 3 sub-types:

1. IAffineArithmeticQuantity - the standard stuff, contains the Zero (IAdditiveIdentity)
2. ILogarithmicArithmeticQuantity - this can have a LogBase, not sure about whether there should be a Zero - but in any way, I don't think we're allowed to use an IAdditiveIdentity of 0 ,
3. INonAffineArithmeticQuantity - this wouldn't have an explicit Zero but can have an IAdditionOperators<TSelf, TOffet, TSelf> (with the Temperature being the only implementation I can think of right now)

With these 3 interfaces we can have safe implementations for the extension methods, even without the INumber interface (we could keep the non-specific IQuantity overload and switch-cast the input).

And while we're on the subject, I'd really love to remove the Zero property from the QuantityInfo - which I don't think is very useful (especially given that it doesn't really apply to all types).. If you want, we could even have a some "ArithmeticCategory" enum in its stead..

[angularsen]

Unsafe package

I'm fine adding this to netstandard2.0 if it does significantly help in some common use cases, but I don't see the performance gain in the benchmarks? It seems the mean is pretty much equivalent for ConvertWithUnsafe and ConvertWithCast, or did I miss it?

GenericMathExtensions

I'd like to add IQuantity to the constraint

Sounds good to me, if it supports adding numbers I think that is an oversight more than a conscious decision. It's been a long while and I don't recall the details anymore, but these extensions are still experimental in my mind and improvements are welcome.

I've been thinking about splitting the IArithmeticQuantity interface into 3 sub-types:

Yes, we probably need to introduce something like this to better support generic arithmetic.
On the surface this proposal looks good, but the design should be battle tested by someone actually needing generic math. For me, it's a theoretic exercise as I have never really need this feature myself for anything so I can't really contribute much in this direction. I'm happy to help review it, if you want to take a stab at it.

I'd really love to remove the Zero property from the QuantityInfo

I actually find it useful, since it works for most quantities. However, if we introduce more granular arithmetic interfaces as you propose, then I guess it can make sense to rethink this and only offer Zero where appropriate 👍

[lipchev]

@angularsen
Are you ok with renaming the IArithmeticQuantity to IAffineQuantity or would you rather we keep it (mark it as obsolete)? For the other two interfaces I was thinking of INonAffineQuantity and ILogarithmicQuantity with the latter having an additional read-only property called LogarithmicScalingFactor (this could be static for net8.0, but for netstandard it would have to be non-static for the extensions to work). Also, I previously mentioned having a LogBase but I guess we could start with the base-10 assumption and extend it later if needed.

Also, last night I realized that there isn't any point in having the Min/Max methods that take the extra Unit parameter- there isn't any good reason to use them (performance-wise), instead of the default Min/Max extensions from System.Linq (I must have just copy pasted the code from the Sum extensions when I first added them). I think you'll agree that these can be deprecated with "Duplicate of System.Linq.Min/Max".

[lipchev]

@angularsen Are you ok with renaming the IArithmeticQuantity to IAffineQuantity or would you rather we keep it (mark it as obsolete)? For the other two interfaces I was thinking of INonAffineQuantity and ILogarithmicQuantity with the latter having an additional read-only property called LogarithmicScalingFactor (this could be static for net8.0, but for netstandard it would have to be non-static for the extensions to work). Also, I previously mentioned having a LogBase but I guess we could start with the base-10 assumption and extend it later if needed.

Oh, there is a good explanation (and a better naming IMO) here:

• Vector quantities may be added to each other, yielding a new vector quantity, and a vector quantity may be added to a suitable affine quantity (a vector space acts on an affine space), yielding a new affine quantity.
• Affine quantities cannot be added, but may be subtracted, yielding relative quantities which are vectors, and these relative differences may then be added to each other or to an affine quantity.

So, I guess the proper interface would be IVectorQuantity or IVectorialQuantity if we want to be fancy :)

[angularsen]

Great article! It perfectly captures the confusion we've had with Temperature in the past. The term affine is unfamiliar to me and I suspect to most people. I'm all for following well defined terms and concepts on this, but I also want to ensure the library stays easy to use and understand. Ideally, most people won't ever have to know about affine vs vectorial to be able to use our Temperature quantity correctly and intuitively.

Then again, most are not using the interfaces anyway since it's usually only relevant when dealing with quantities generically, so maybe it's not a big deal.

At first glance, IAffineQuantity and IVectorQuantity seems like good names based on the article, plus the ILogarithmicQuantity you proposed. Maybe IVectorialQuantity is a more consistent naming along with the other two though. Then again, in the article and on google it seems they mostly talk about "affine space" vs "vector space", not anything vectorial. 🤷

Are you ok with renaming the IArithmeticQuantity to IAffineQuantity or would you rather we keep it (mark it as obsolete)?

Let's avoid breaking changes where we can, keep it and mark it obsolete. We can remove it later, as long as it doesn't add too much friction for us in the meantime.