Inferred division from defined multiplication relations #1354

Muximize · 2024-01-07T00:34:02Z

In #1329 this proposal came up:

Another idea: generate division operators based on multiplication. Right now we define:
ElectricPotential.Volt = ElectricCurrent.Ampere * ElectricResistance.Ohm (and generate the reverse)
ElectricCurrent.Ampere = ElectricPotential.Volt / ElectricResistance.Ohm
ElectricResistance.Ohm = ElectricPotential.Volt / ElectricCurrent.Ampere
But those last two could also be generated based on the first.

This PR is an experiment implementing this.

Breaking changes:

TimeSpan = Volume / VolumeFlow => Duration = Volume / VolumeFlow

Muximize · 2024-01-25T18:51:27Z

I rebased this on the latest changes in #1329 which makes it much cleaner.

Example of an interesting situation that occurs here, we previously defined:

MassFlow.GramPerSecond = Area.SquareMeter * MassFlux.GramPerSecondPerSquareMeter
MassFlux.KilogramPerSecondPerSquareMeter = MassFlow.KilogramPerSecond / Area.SquareMeter

If we infer division from multiplication, one of those has to add or lose a kilo 😅

angularsen · 2024-02-05T06:42:49Z

Will review this next, hopefully in the next few days.

If we infer division from multiplication, one of those has to add or lose a kilo 😅

Haha 😆 But it will still work, right?
The inferred division will just use grams instead?

Muximize · 2024-02-05T16:23:02Z

Yes, it will work, except we're not sure why the original contributor chose a particular unit for an operator and if it matters, with precision for example.

Also, this PR is more of an experiment than a serious proposal. There's some questions about the "magic" of it, and I took some liberties with implicit/explicit conversion between Density and MassConcentration that I'm not quite sure about. Maybe @lipchev can chime in on this?

lipchev · 2024-02-05T22:12:39Z

Yes, it will work, except we're not sure why the original contributor chose a particular unit for an operator and if it matters, with precision for example.

Also, this PR is more of an experiment than a serious proposal. There's some questions about the "magic" of it, and I took some liberties with implicit/explicit conversion between Density and MassConcentration that I'm not quite sure about. Maybe @lipchev can chime in on this?

Although the Density and Mass Concentration share the same units, they are not interchangeable- they describe different types of ratios. Casting between them (either implicitly or explicitly) makes no sense..

Muximize · 2024-02-06T12:57:34Z

Thanks for the explanation! That makes the concept of inferred division a bit harder, given that we currently have:

Mass.Kilogram = Density.KilogramPerCubicMeter * Volume.CubicMeter
Mass.Kilogram = MassConcentration.KilogramPerCubicMeter * Volume.CubicMeter

which leads to these inferred ambiguous operators, which is what I tried to solve with my casting shenanigans:

Density.KilogramPerCubicMeter           = Mass.Kilogram / Volume.CubicMeter
MassConcentration.KilogramPerCubicMeter = Mass.Kilogram / Volume.CubicMeter

The latter is currently not defined, so skipping it would not be a breaking change. I've reworked this PR to do that and removed the casting stuff.

angularsen

I like where this is going and would like to get it merged.
Some comments so far.

UnitsNet.Tests/CustomCode/VolumeTests.cs

angularsen · 2024-02-17T13:52:07Z

UnitsNet/GeneratedCode/Quantities/ReciprocalLength.g.cs

@@ -630,11 +638,10 @@ public static bool TryParseUnit(string str, IFormatProvider? provider, out Recip
            return ReciprocalArea.FromInverseSquareMeters(left.InverseMeters * right.InverseMeters);
        }

-        /// <summary>Calculates the inverse of this quantity.</summary>
-        /// <returns>The corresponding inverse quantity, <see cref="Length"/>.</returns>
-        public Length Inverse()


Can you move Inverse() back to its original position? It'll reduce the diff in PR.

Maybe this was just this one file, you can disregard this.

Not just this one, this happens in Area, ReciprocalArea, Length and ReciprocalLength.

But I think it's an improvement, Inverse is now always the first operator in the #region because it's now defined as

1 = Area.SquareMeter * ReciprocalArea.InverseSquareMeter

instead of

ReciprocalArea.InverseSquareMeter = 1 / Area.SquareMeter

and sorted on that string alphanumerically.

angularsen · 2024-02-17T14:07:58Z

CodeGen/Generators/QuantityRelationsParser.cs

+                .ToList());
+
+            // Remove inferred relation "MassConcentration = Mass / Volume" because it duplicates "Density = Mass / Volume"
+            relations.RemoveAll(r => r is { Operator: "/", ResultQuantity.Name: "MassConcentration", LeftQuantity.Name: "Mass", RightQuantity.Name: "Volume" });


Maybe we can solve this in a way that makes it more discoverable by moving this into the JSON file, how about this:

Option 1) Skip division if multiple competing definitions

If there more than one inferred division definition QuantityA / QuantityB with different resulting quantity type, then skip all of them. They will have to be manually defined in the JSON file.

Option 2) Allow defining opt-out in the JSON file

We could move the array to a structure like this:

{ "skipInferredDivisionForDefinitions": [ "Mass.Kilogram = MassConcentration.KilogramPerCubicMeter * Volume.CubicMeter" ], "definitions": [ "1 = Area.SquareMeter * ReciprocalArea.InverseSquareMeter", "1 = ElectricResistivity.OhmMeter * ElectricConductivity.SiemensPerMeter", "1 = Length.Meter * ReciprocalLength.InverseMeter", "Acceleration.MeterPerSecondSquared = Jerk.MeterPerSecondCubed * Duration.Second", "AmountOfSubstance.Kilomole = MolarFlow.KilomolePerSecond * Duration.Second", "AmountOfSubstance.Mole = Molarity.MolePerCubicMeter * Volume.CubicMeter", "Mass.Kilogram = MassConcentration.KilogramPerCubicMeter * Volume.CubicMeter" ] }

Or add a structure for each definition, allowing us to configure stuff for each entry:

{ "definitions": [ { "d": "1 = Area.SquareMeter * ReciprocalArea.InverseSquareMeter" }, { "d": "1 = ElectricResistivity.OhmMeter * ElectricConductivity.SiemensPerMeter" }, { "d": "1 = Length.Meter * ReciprocalLength.InverseMeter" }, { "d": "Acceleration.MeterPerSecondSquared = Jerk.MeterPerSecondCubed * Duration.Second" }, { "d": "AmountOfSubstance.Kilomole = MolarFlow.KilomolePerSecond * Duration.Second" }, { "d": "AmountOfSubstance.Mole = Molarity.MolePerCubicMeter * Volume.CubicMeter" }, { "d": "Mass.Kilogram = MassConcentration.KilogramPerCubicMeter * Volume.CubicMeter", "skipInferredDivision": true } ] }

I like option 2.2, but I also like the simple json structure we have now, so I propose a string-based solution of just appending NoInferredDivision to the relation, see last commits.

UnitsNet/GeneratedCode/Quantities/Force.g.cs

### Changes - Change `Duration` from explicit to implicit cast to/from `TimeSpan` - Remove operator overloads for `TimeSpan` now covered by implicit cast for all but left operands ### Background See #1354 (comment) One issue is that the operator overloads only work when `TimeSpan` is the right operand. I changed the code generation to take this into account, but another option would be to make a breaking change where we just don't support `TimeSpan` as the left operand at all. Then users would have to cast explicitly, or for multiplication just reverse the operands. This would affect 13 operators: ``` TimeSpan * Acceleration TimeSpan * ElectricCurrent TimeSpan * ElectricCurrentGradient TimeSpan * ForceChangeRate TimeSpan * KinematicViscosity TimeSpan * MassFlow TimeSpan * MolarFlow TimeSpan * Power TimeSpan * PressureChangeRate TimeSpan * RotationalSpeed TimeSpan * Speed TimeSpan * TemperatureChangeRate TimeSpan * VolumeFlow ``` Of which only 6 are used in tests so I assume are supported in v5: ``` TimeSpan * KinematicViscosity TimeSpan * MassFlow TimeSpan * Power TimeSpan * RotationalSpeed TimeSpan * TemperatureChangeRate TimeSpan * Speed ``` --------- Co-authored-by: Andreas Gullberg Larsen <[email protected]>

…ssing ones

angularsen

Looks good to me, just one minor comment we can address later.

CodeGen/Generators/QuantityRelationsParser.cs

angularsen · 2024-03-01T19:49:06Z

UnitsNet/GeneratedCode/Quantities/TemperatureDelta.g.cs

@@ -576,7 +590,7 @@ public static bool TryParseUnit(string str, IFormatProvider? provider, out Tempe
        /// <summary>Get <see cref="Length"/> from <see cref="TemperatureDelta"/> / <see cref="TemperatureGradient"/>.</summary>
        public static Length operator /(TemperatureDelta temperatureDelta, TemperatureGradient temperatureGradient)
        {
-            return Length.FromKilometers(temperatureDelta.Kelvins / temperatureGradient.DegreesCelsiusPerKilometer);
+            return Length.FromKilometers(temperatureDelta.DegreesCelsius / temperatureGradient.DegreesCelsiusPerKilometer);
        }


This is from before, but isn't PerKilometer an odd choice here?
I'd expect DegreesCelciusPerMeter.
Same below.

Can fix in separate PR.

@Muximize Just an extra ping to make sure you saw this:

This is from before, but isn't PerKilometer an odd choice here?
I'd expect DegreesCelciusPerMeter.
Same below.

Can fix in separate PR.

I agree it seems odd, but it was added this way in #991. I guess this is used in meteorology, where kilometers make more sense?

The Kelvin part is weird tho. Previously we had:

TemperatureDelta.DegreeCelsius = TemperatureGradient.DegreeCelsiusPerKilometer * Length.Kilometer TemperatureGradient.KelvinPerMeter = TemperatureDelta.Kelvin / Length.Meter Length.Kilometer = TemperatureDelta.Kelvin / TemperatureGradient.DegreeCelsiusPerKilometer

We dropped the last two because they now get inferred, but with Celsius instead of Kelvin. I guess we need a domain expert to answer both these concerns?

Edit: just checked TemperatureDelta.json, Kelvin and DegreeCelsius both have {x} so they're basically aliases.

Division now inferred by f7ce00b - Inferred division from defined multiplication relations (angularsen#1354)

angularsen · 2024-03-03T19:49:14Z

Nuget on the way

Release UnitsNet/6.0.0-pre003 · angularsen/UnitsNet

Muximize mentioned this pull request Jan 7, 2024

Generate operators from unit relations defined in JSON #1329

Merged

Muximize force-pushed the inferred-division branch from b7456ea to a256eab Compare January 25, 2024 18:38

Muximize force-pushed the inferred-division branch from a256eab to df96c8e Compare February 4, 2024 19:54

Muximize changed the base branch from master to release/v6 February 4, 2024 19:54

Muximize force-pushed the inferred-division branch from df96c8e to 0491bfb Compare February 6, 2024 12:55

angularsen requested changes Feb 17, 2024

View reviewed changes

Muximize mentioned this pull request Feb 19, 2024

Implicit cast between Duration and TimeSpan #1365

Merged

Muximize marked this pull request as ready for review February 24, 2024 12:56

Muximize force-pushed the inferred-division branch 2 times, most recently from 44bd139 to 1950b51 Compare February 24, 2024 13:08

Muximize added 5 commits February 26, 2024 10:42

Remove all division relations, add some multiplications to replace mi…

cd819d5

…ssing ones

Add inferred division to CodeGen

a44d76a

Replace TimeSpan with Duration as return type

0fe25aa

Add NoInferredDivision option

c4ebb8c

Generate code

6a5ad04

Muximize force-pushed the inferred-division branch from 1950b51 to 6a5ad04 Compare February 26, 2024 09:48

angularsen approved these changes Mar 1, 2024

View reviewed changes

angularsen merged commit f7ce00b into angularsen:release/v6 Mar 1, 2024
1 check passed

angularsen added a commit to Tim-Borcherding/UnitsNet that referenced this pull request Mar 1, 2024

Remove redundant

649a56a

Division now inferred by f7ce00b - Inferred division from defined multiplication relations (angularsen#1354)

angularsen mentioned this pull request Mar 1, 2024

Added TemperatureChangeRate unit relation #1371

Merged

Muximize deleted the inferred-division branch March 2, 2024 17:48

Muximize mentioned this pull request Jul 29, 2024

Removing the operators with TimeSpan in v6? #1413

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Inferred division from defined multiplication relations #1354

Inferred division from defined multiplication relations #1354

Muximize commented Jan 7, 2024 •

edited

Loading

Muximize commented Jan 25, 2024 •

edited

Loading

angularsen commented Feb 5, 2024

Muximize commented Feb 5, 2024

lipchev commented Feb 5, 2024

Muximize commented Feb 6, 2024

angularsen left a comment

angularsen Feb 17, 2024

angularsen Feb 17, 2024

Muximize Feb 19, 2024

angularsen Feb 17, 2024

Muximize Feb 19, 2024

angularsen left a comment

angularsen Mar 1, 2024

angularsen Mar 2, 2024

Muximize Mar 2, 2024 •

edited

Loading

angularsen commented Mar 3, 2024

Inferred division from defined multiplication relations #1354

Inferred division from defined multiplication relations #1354

Conversation

Muximize commented Jan 7, 2024 • edited Loading

Breaking changes:

Muximize commented Jan 25, 2024 • edited Loading

angularsen commented Feb 5, 2024

Muximize commented Feb 5, 2024

lipchev commented Feb 5, 2024

Muximize commented Feb 6, 2024

angularsen left a comment

Choose a reason for hiding this comment

angularsen Feb 17, 2024

Choose a reason for hiding this comment

angularsen Feb 17, 2024

Choose a reason for hiding this comment

Muximize Feb 19, 2024

Choose a reason for hiding this comment

angularsen Feb 17, 2024

Choose a reason for hiding this comment

Option 1) Skip division if multiple competing definitions

Option 2) Allow defining opt-out in the JSON file

Muximize Feb 19, 2024

Choose a reason for hiding this comment

angularsen left a comment

Choose a reason for hiding this comment

angularsen Mar 1, 2024

Choose a reason for hiding this comment

angularsen Mar 2, 2024

Choose a reason for hiding this comment

Muximize Mar 2, 2024 • edited Loading

Choose a reason for hiding this comment

angularsen commented Mar 3, 2024

Muximize commented Jan 7, 2024 •

edited

Loading

Muximize commented Jan 25, 2024 •

edited

Loading

Muximize Mar 2, 2024 •

edited

Loading