Redesign UnitSystem to support non-SI systems and configurable default units #709

lipchev · 2019-09-28T11:56:52Z

(WIP) for #651

1. Redesign/Remove BaseUnits type and remove related from JSON and UnitSystem (breaking change)
2. UnitSystem: Add mapping of default unit, such as QuantityType.Length => LengthUnit.Centimeter
3. UnitSystem: Add mapping of default abbreviation per unit enum value, such as LengthUnit.Feet => "ft" (optional- also a breaking change if UnitAbbreviationCache is to become part of the UnitSystem)
4. Length.ctor(double, UnitSystem) constructs with unit system's default unit for Length
5. double val = myLength.As(UnitSystem) converts to unit system's default unit for Length
6. UnitSystem should remain immutable, so to change its configuration at runtime you create a new instance either manually or by cloning an existing system with extension methods for adding/modifying mappings like in use case 5. Then you inject this instance into your view or whatever.
7. Add UnitSystem.SI and UnitSystem.EnglishEngineering with mappings
8. Add tests for the the new public methods in UnitSystem (got one in LenghtTests- but none that test for the "exceptional" cases)

…stem - UnitSystem holds the list of default units for each (compatible?) quantity type and a method (GetDefaultUnitInfo) that provides the corresponding UnitInfo given a QuantityType - All methods in Quantity that use a UnitSystem now use the new GetDefaultUnitInfo - Added a method (in UnitSystem) for creating derived unit systems(WithDefaultUnit), providing a new QuantityType->UnitInfo association and optionally a new BaseUnits definition (as currently used by Equals and visible in public ctor- otherwise obsolete?)

codecov-io · 2019-09-28T12:01:53Z

Codecov Report

Merging #709 (e45efe8) into master (0f39bec) will increase coverage by 84%.
The diff coverage is 83%.

❗ Current head e45efe8 differs from pull request most recent head dfe0bd2. Consider uploading reports for the commit dfe0bd2 to get more accurate results

@@            Coverage Diff            @@
##           master    #709      +/-   ##
=========================================
+ Coverage        0     84%     +84%     
=========================================
  Files           0     308     +308     
  Lines           0   43886   +43886     
=========================================
+ Hits            0   36938   +36938     
- Misses          0    6948    +6948

Impacted Files	Coverage Δ
...tsNet/GeneratedCode/Quantities/AmplitudeRatio.g.cs	`79% <80%> (ø)`
UnitsNet/GeneratedCode/Quantities/Angle.g.cs	`83% <80%> (ø)`
...tsNet/GeneratedCode/Quantities/ApparentEnergy.g.cs	`79% <80%> (ø)`
...itsNet/GeneratedCode/Quantities/ApparentPower.g.cs	`79% <80%> (ø)`
UnitsNet/GeneratedCode/Quantities/AreaDensity.g.cs	`76% <80%> (ø)`
.../GeneratedCode/Quantities/AreaMomentOfInertia.g.cs	`80% <80%> (ø)`
UnitsNet/GeneratedCode/Quantities/BitRate.g.cs	`86% <80%> (ø)`
...dCode/Quantities/BrakeSpecificFuelConsumption.g.cs	`79% <80%> (ø)`
UnitsNet/GeneratedCode/Quantities/Capacitance.g.cs	`81% <80%> (ø)`
...Code/Quantities/CoefficientOfThermalExpansion.g.cs	`79% <80%> (ø)`
... and 354 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

lipchev · 2019-09-28T12:04:08Z

Initially I went with a dictionary (as proposed in #651) but being stunned by the lack of improvement in performance compared with the test in #708 I dropped it in favor of an array (of QuantityInfo), indexed by the (int)QuantityType - 1, which gave me some improvement- but not nearly as much as I expected initially..

lipchev · 2019-09-28T12:12:41Z

Method	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
Constructor	10.261 ns	0.2568 ns	0.3683 ns	10.102 ns	-	-	-	-
Constructor_SI	341.489 ns	20.1771 ns	57.5664 ns	300.000 ns	-	-	-	-
FromMethod	23.169 ns	0.1087 ns	0.0907 ns	23.156 ns	-	-	-	-
ToProperty	7.105 ns	0.0894 ns	0.0836 ns	7.111 ns	-	-	-	-
As	7.171 ns	0.1547 ns	0.1447 ns	7.095 ns	-	-	-	-
As_SI	336.364 ns	19.1489 ns	56.1604 ns	300.000 ns	-	-	-	-
ToUnit	16.206 ns	0.1705 ns	0.1424 ns	16.205 ns	-	-	-	-
ToUnit_SI	456.667 ns	23.4713 ns	65.4286 ns	400.000 ns	-	-	-	-
ToStringTest	2,022.562 ns	14.2156 ns	13.2973 ns	2,020.125 ns	0.1945	-	-	832 B
Parse	51,561.651 ns	990.9471 ns	1,179.6520 ns	51,123.584 ns	10.1929	-	-	43000 B
TryParseValid	49,676.343 ns	808.6956 ns	756.4544 ns	49,425.769 ns	10.1929	-	-	42976 B
TryParseInvalid	52,532.164 ns	612.5532 ns	543.0125 ns	52,483.185 ns	10.1318	-	-	42576 B
QuantityFrom	68.093 ns	1.4228 ns	1.5814 ns	67.222 ns	0.0132	-	-	56 B
IQuantity_As	15.401 ns	0.2076 ns	0.1942 ns	15.320 ns	0.0057	-	-	24 B
IQuantity_As_SI	380.723 ns	14.8686 ns	39.6873 ns	400.000 ns	-	-	-	-
IQuantity_ToUnit	23.538 ns	0.2679 ns	0.2506 ns	23.453 ns	0.0133	-	-	56 B
IQuantity_ToStringTest	2,037.505 ns	39.4539 ns	61.4250 ns	2,013.519 ns	0.1945	-	-	832 B

Note that the performance of my machine is slightly lower today (I think it's either the room temperature or some process eating up my resources).

- updated the comments and invalid arguments checks - added a few tests for those cases a few question marks remain (marked with TODOs)

lipchev · 2019-09-29T08:10:17Z

Still some things I'm not sure about:

what would be the expected equality comparison for two UnitSystems (currently depends on the BaseType)
previous tests state that for example "AmplitudeRatio is unitless. Can't have any matches" (when constructing AmplituedRatio using SI)- yet it seems there are 4 "dimensionless units" to chose from when selecting a default unit
I struggled to validate within WithDefaultUnit(QuantityType, UnitInfo) that UnitInfo corresponds to the provided QuantityType (any ideas? lookup the list of Info's again? change the signiture?)
I struggled to create the generic overload corresponding to WithDefaultUnit(QuantityType, UnitInfo):
WithDefaultUnit<TUnit>(UnitInfo<TUnit>) // how do I get the QuantityType value from this

angularsen · 2019-09-29T09:17:51Z

We can't merge this into master branch until all breaking changes are ready, so I just created release/v5 branch. Please point this PR to that branch instead, or create a new PR if it can't be changed.

Other breaking changes: #666

angularsen · 2019-09-29T09:52:36Z

which gave me some improvement- but not nearly as much as I expected initially..

I think this basically comes down to the fact that we have ~100 quantities today, and enumerating 100 items with a simple condition check is really really fast to begin with. At any rate, a lookup of sorts seems reasonable anyway.

angularsen · 2019-09-29T10:50:48Z

Still some things I'm not sure about:

what would be the expected equality comparison for two UnitSystems (currently depends on the BaseType)

I propose using the default implementation that class brings, which checks if they are the exact same object reference. We could compare all the mappings and any values, but I really question the value of this.

previous tests state that for example "AmplitudeRatio is unitless. Can't have any matches" (when constructing AmplituedRatio using SI)- yet it seems there are 4 "dimensionless units" to chose from when selecting a default unit

I believe you are referencing this test:
https://github.com/angularsen/UnitsNet/blob/master/UnitsNet.Tests/CustomCode/LengthTests.cs#L189-L194

First, I don't understand why we are testing AmplitudeRatio in LengthTests.
Second, it's likely a limitation of the old unit system design where it's not possible to uniquely map from SI base units to dimensionless units. I don't see why we shouldn't preserve this behavior in the new design, so this test can be removed I think.

I struggled to validate within WithDefaultUnit(QuantityType, UnitInfo) that UnitInfo corresponds to the provided QuantityType (any ideas? lookup the list of Info's again? change the signiture?)

I'll have to look closer on this one.

I struggled to create the generic overload corresponding to WithDefaultUnit(QuantityType, UnitInfo):
WithDefaultUnit<TUnit>(UnitInfo<TUnit>) // how do I get the QuantityType value from this

I'll have to look closer on this one.

angularsen

I know this is work in progress, but here are some early comments after reading through the first time.

angularsen · 2019-09-29T10:57:25Z

UnitsNet.Tests/UnitSystemTests.cs

+        {
+            // TODO do we expect to preserve this behavior?
+            // AmplitudeRatio might be unitless- but there are (more than one) ways to express ratios. 
+            Assert.Null(UnitSystem.SI.GetDefaultUnitInfo(AmplitudeRatio.QuantityType));


Preserve returning null if no mapping is defined.

AmplitudeRatio should have a mapping defined in SI, I think.

Right- so, in theory, the only way to get a null here would be if one creates a custom unit system, explicitly setting the association to null (as presumable the original unit system would have all of its associations defined).

Sounds about right. We should also create some unit tests that breaks as soon as a new quantity is added and if one forgets to add a mapping of default unit for included unit systems such as SI and EnglishEngineering. I don't think we need to add a mapping for default abbreviation, since I think it's natural to default to the first abbreviation defined in JSON as we already do.

UnitsNet.Tests/CustomCode/LengthTests.cs

UnitsNet.Tests/UnitSystemTests.cs

angularsen · 2019-09-29T11:05:28Z

UnitsNet.Tests/UnitSystemTests.cs

+        [InlineData(LengthUnit.Meter, MassUnit.Kilogram, DurationUnit.Second, ElectricCurrentUnit.Ampere, TemperatureUnit.Undefined, AmountOfSubstanceUnit.Mole, LuminousIntensityUnit.Candela)]
+        [InlineData(LengthUnit.Meter, MassUnit.Kilogram, DurationUnit.Second, ElectricCurrentUnit.Ampere, TemperatureUnit.Kelvin, AmountOfSubstanceUnit.Undefined, LuminousIntensityUnit.Candela)]
+        [InlineData(LengthUnit.Meter, MassUnit.Kilogram, DurationUnit.Second, ElectricCurrentUnit.Ampere, TemperatureUnit.Kelvin, AmountOfSubstanceUnit.Mole, LuminousIntensityUnit.Undefined)]
+        public void WithDefaultUnitThrowsIfSpecifiedBaseUnitsNotFullyDefined(LengthUnit length, MassUnit mass, DurationUnit time, ElectricCurrentUnit current,


Same here, aren't we removing BaseUnits?

UnitsNet/UnitSystem.cs

angularsen · 2019-09-29T11:18:03Z

UnitsNet/UnitSystem.cs

+        /// <exception cref="ArgumentException">
+        ///     Quantity type can not be undefined.
+        /// </exception>
+        public UnitSystem WithDefaultUnit(QuantityType quantityType, UnitInfo defaultUnitInfo, BaseUnits baseUnits = null)


BaseUnits is going away here too, right?

UnitsNet/UnitSystem.cs

- renamed some tests, added comments here and there - WithDefaultUnit : added a check for the compatibility between QuantityType and UnitInfo passed in (also added a test for this)

- had missed this one

lipchev · 2019-09-29T13:13:33Z

Regarding all comments about BaseUnits going away- you are right- they should be going away in v5.

I just thought I might make this a two step PR (as to not make it too difficult to review)- where the first part would be the 'non-breaking' change (that allows for issue like the one described in #700 to be patched in the client code).

However, now that I think of it- I'm not sure how good a fix is to pollute one's code with something like SI_Ex (having correctly mapped all necessary defaults by hand) just to have it fixed in the next major release (and going about changing back to SI once more)...

angularsen · 2019-09-29T13:15:31Z

Regarding all comments about BaseUnits going away- you are right- they should be going away in v5.

I just thought I might make this a two step PR (as to not make it too difficult to review)- where the first part would be the 'non-breaking' change (that allows for issue like the one described in #700 to be patched in the client code).

However, now that I think of it- I'm not sure how good a fix is to pollute one's code with something like SI_Ex (having correctly mapped all necessary defaults by hand) just to have it fixed in the next major release (and going about changing back to SI once more)...

Got it, good thinking, but I suspect the PR might be easier to review if we do a clean break to begin with instead of having both old and new designs in our head at the same time. It's up to you, just do whatever you feel makes the most sense.

- added an association (1:0..1) between UnitSystem and Unit (kept the name 'BaseUnit' instead of the previously considered 'DefaultUnit') - added an association (1:0..n) between Unit and UnitSystem- this would be used to generate list of units for a quantity in a particular unit system (not an exhaustive list, needs a review)

lipchev · 2019-10-05T19:32:29Z

Here is an example of the modified unit definition schema (haven't removed the BaseUnits from the CubicHectometer & ImperialPint as to not trigger the code-regeneration)- tell me what you think.

The two associations would be used to construct the corresponding list of UnitInfo's and default UnitInfo for a given quantity and unit system.

Modifying the whole list of UnitDefinitions in such a way would be quite the task- but as long as there is some review process- I think we can manage.

As we do that- what I think would be really cool is to associate units & quantities with their actual ontological references: like for instance our MassFraction is defined in UO as MassPercentage and again as MassFraction in OM.

We could thus (maybe in the future) run some ontological alignment validations on our unit definitions, as described in this awesome paper: Comparison and Evaluation of Ontologies for Units of Measurement.

Not to mention the nice extension methods that one could think of..

angularsen · 2019-10-09T19:39:04Z

I like it. Explicit and much simpler to reason about than before. I originally thought about defining unit system as its own file, but keeping it per quantity is actually a much better idea since it's much more visible and just a single JSON file to edit when adding new units.

It's still something new that contributors will have to think about, but with some updated steps in the wiki I think we should manage.

Also, unit systems are really opt-in the way I see it. Meaning, if we decide to not map all units they should still continue to work for everything else but methods that take a unit system as argument.

- refactored the UnitSystem- moving the BaseUnits to BaseUnitSystem (SI derived from BaseUnitSystem), extended the unit mappings with the UnitSystemInfo class (containing both default and common/derived units) - updated the JsonTypes and created the UnitSystemInfoGenerator (TODO WRC) - updated existing UnitSystemTests that tested for equality/BaseUnits (almost all in fact) to use the BaseUnitSystem instead (as the IEquatble/BaseUnits interface was pushed down) - added several more unit-system mappings to the UnitDefinitions (Acceleration, AmountOfSubstance, Area, Energy & Length) - commented (temporary) part of the Ctor_WithValueAndSIUnitSystem_ReturnsQuantityWithSIUnitOrThrowsArgum test (testing for support SI support)

lipchev · 2019-11-12T00:29:59Z

Ok, so I refactored UnitSystem- I couldn't bear to remove the BaseUnits so I moved it the BaseUnitSystem extension of the UnitSystem (along with the IEquatable interface). It is thus still present for UnitSystem.SI (which is a BaseUnitSystem)- I don't yet know how we could is use- but I don't think it hurts to keep it for now. I've also left out the original BaseUnits constructor (and the corresponding mapping behavior)- marked as obsolete. Thus it seems we are mostly backward-compatible. (still I presume we will move this to v5?)

I've replaced the previous a UnitInfo[] mapping (in the UnitSystem) with a UnitSystemInfo- that includes the default unit (optional) and list of "common" (also "derived" or "named") units for a quantity in a unit system. This class itself is currently not exposed (maybe make internal)- only the UnitInfos are exposed via the GetDefaultUnitInfo(QuantityType quantityType) & GetCommonUnitsInfo(QuantityType quantityType) methods in the UnitSystem.

Next I updated the JSON types & added UnitSystem generator- that completes the partial part of the concrete UnitSystem implementations (SI, GGS, EE etc..) and finally added several more UnitSystem mappings to the UnitDefinitions of Acceleration, AmountOfSubstance, Area, Energy & Length (pretty much the same thing as with Volume- note however that CGS often maps default unit to prefixed-quantities).

Still some tests need to be added (note for instance how it's not really possible to argument check the Lazy in the constructor). Also I've commented(temporary) parts of the Ctor_WithValueAndSIUnitSystem_ReturnsQuantityWithSIUnitOrThrowsArgum, and two of my own tests for the WithDefaultUnit registration- that used to test for the BaseUnit- haven't created an overload for it in BaseUnitSystem yet)

lipchev · 2019-11-12T00:40:28Z

Also- the benchmark showed some unexpected results- I didn't expect to see any change over the previous tests (we are still doing the same array lookup) - yet the results turned up even faster than the original As/ToUnit methods- what, am I not doing enough argument checking somewhere? Or maybe it is something worse :)

lipchev · 2019-11-12T00:41:19Z

Method	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
Constructor	9.703 ns	0.1571 ns	0.1469 ns	9.747 ns	-	-	-	-
Constructor_SI	14.399 ns	0.2823 ns	0.3138 ns	14.327 ns	-	-	-	-
FromMethod	22.979 ns	0.3424 ns	0.3036 ns	22.930 ns	-	-	-	-
ToProperty	7.132 ns	0.1730 ns	0.2188 ns	7.109 ns	-	-	-	-
As	7.117 ns	0.1795 ns	0.2631 ns	7.158 ns	-	-	-	-
As_SI	8.965 ns	0.1758 ns	0.1727 ns	8.984 ns	-	-	-	-
ToUnit	16.113 ns	0.3489 ns	0.5634 ns	16.020 ns	-	-	-	-
ToUnit_SI	19.220 ns	0.5484 ns	1.5909 ns	18.631 ns	-	-	-	-
ToStringTest	2,143.655 ns	42.0048 ns	72.4562 ns	2,124.925 ns	0.1945	-	-	832 B
Parse	50,824.466 ns	1,167.4845 ns	1,674.3713 ns	50,253.683 ns	10.1929	-	-	43000 B
TryParseValid	50,085.794 ns	1,109.7561 ns	1,519.0467 ns	49,460.004 ns	10.1929	-	-	42976 B
TryParseInvalid	51,682.055 ns	1,388.3917 ns	1,946.3312 ns	51,121.497 ns	10.1318	-	-	42576 B
QuantityFrom	64.901 ns	1.1769 ns	1.0433 ns	64.964 ns	0.0132	-	-	56 B
IQuantity_As	14.626 ns	0.2431 ns	0.2274 ns	14.591 ns	0.0057	-	-	24 B
IQuantity_As_SI	10.176 ns	0.1887 ns	0.1576 ns	10.154 ns	-	-	-	-
IQuantity_ToUnit	23.791 ns	0.4649 ns	0.4348 ns	23.867 ns	0.0133	-	-	56 B
IQuantity_ToStringTest	1,985.983 ns	34.6024 ns	27.0153 ns	1,994.777 ns	0.1945	-	-	832 B

angularsen · 2019-12-26T18:41:13Z

I've kind of forgotten to follow up on this. Will try to get to it sometime soon.

stale · 2020-02-24T19:05:34Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

angularsen · 2020-06-07T20:19:36Z

I added the pinned label to prevent bot from stale-closing it.

- UnitSystem/BaseUnitSystem Equality contract based on the base (default) unit for each quantity - BaseUnits for BaseUnitSystem created from the provided unit associations - added unit system associations for all SI base types (Length, Mass, Duration etc.) - tests for the UnitSystem construction/derivation

- updated the default units (as per https://en.wikipedia.org/wiki/Astronomical_system_of_units) - fixed the docstring

in order to avoid breaking the namespace (UnitSystem.SI) all static instances were added to the UnitSystem.Definition (partial class)

- fixed typo in unit system for Length - Ctor_UnitSystem_ThrowsArgumentExceptionIfNotSupported - Ctor_WithNullUnitSystem_ThrowsArgumentNullException - As_UnitSystem_ThrowsArgumentExceptionIfNotSupported - As_WithNullUnitSystem_ThrowsArgumentNullException - To_UnitSystem_ThrowsArgumentExceptionIfNotSupported - ToUnit_WithNullUnitSystem_ThrowsNullException

- merged all upstream modifications - fixed nullability issues in UnitSystem - the Lazy<..> BaseUnits constructor was made protected - marked all tests that rely solely on BaseUnits as Obsolete (with error=false) - removed some obsolete tests from MassConcentration (tesing for default unit system units)

lipchev · 2020-10-06T02:47:11Z

This is almost done- still need to complete mapping in the JSON files, but as it stands I can only see one client call that is breaking : new UnitSystem(baseUnits).BaseUnits - the constructor works as before(marked as obsolete)- it is only the BaseUnits property that was moved to BaseUnitSystem- so UnitSystem.SI.BaseUnits is still valid.

I've kept the equality contract for BaseUnitSystem as before- only comparing the default SI base units, where as for all other unit systems (not derived from BaseUnitSystem) we compare all unit associations.

I've added tests akin to the ones you've suggested in #844.
There are a few more tests that can be added to UnitSystemTests (I don't think that those that I've marked as Obsolete contribute to the coverage- while the constructor they relied on is indeed obsolete- the tested behavior is still valid).

angularsen · 2020-10-06T20:41:37Z

Awesome, I'll try to take a closer look this weekend.

angularsen · 2020-12-16T19:37:14Z

@lipchev I have totally neglected this one, but stumbled over it today. Would you like me to review this still?

angularsen · 2020-12-16T19:39:34Z

Also, related #864.

Here we deprecate QuantityType in favor of strings, which is more extensible. It seems like something this PR should take into account as well.

inflectionpoint · 2021-01-15T17:27:35Z

I would suggest the naming the alternative Unit System of "EnglishEngineering" units be defined as "USCustomary" as I believe that is the proper name. I believe the "English" or "Imperial" is historical naming and not used anymore.

angularsen · 2021-01-18T19:45:14Z

Thank you @inflectionpoint , I didn't know that!

…mentExceptionIfNotSupported tests

lipchev · 2021-03-07T09:48:10Z

@angularsen I've merged everything from upstream, removing the SupportsSIUnitSystem tests in favor of the auto-generated equivalents.
There is one small thing that's been bugging me for a while- that is the Undefined unit. As far as I can tell this is only used for the SI BaseUnit definitions (where I think it could easily be replaced it with a nullable property). Do you know of any other reason for having it? Wouldn't it be better if we made BaseUnit the zero-index (default) unit for all quantities? At the very least- this would allow us to remove the nullable _unit field (well maybe not remove it, but at least make it non-nullable :)).

angularsen · 2021-03-21T15:22:33Z

@lipchev I think the reasoning for Undefined was to catch bugs where someone didn't specify a value, such as when deserializing JSON.
I'm fine with making it nullable instead since we are already making breaking changes, and I don't expect anyone to use Undefined for anything meaningful that can't be replaced with null.

where is the run button!?

This reverts commit e027e7c.

…UnitSystemWithOldDerivedUnits_IncludingTheNewBaseUnit

lipchev · 2022-09-03T15:01:02Z

I don't know where to put this (maybe a discussion?) but here's a great explanation of the linear algebra behind the BaseUnits of different UnitSystems.

lipchev changed the title ~~Create QuantityType -> UnitInfo associations (DefaultUnits) in UnitSy…~~ Create QuantityType -> UnitInfo associations in UnitSystem Sep 28, 2019

Added tests for the new public methods in UnitSystem

75175e7

- updated the comments and invalid arguments checks - added a few tests for those cases a few question marks remain (marked with TODOs)

angularsen added this to the 5.0 milestone Sep 29, 2019

angularsen requested a review from tmilnthorp September 29, 2019 09:47

angularsen reviewed Sep 29, 2019

View reviewed changes

lipchev added 2 commits September 29, 2019 15:50

mostly cosmetic modifications

4dcc1ac

- renamed some tests, added comments here and there - WithDefaultUnit : added a check for the compatibility between QuantityType and UnitInfo passed in (also added a test for this)

use existing GetInfo(quantityType) method

0b69e3b

- had missed this one

angularsen mentioned this pull request Jan 21, 2020

Add Environmental Reference type for Temperature and Pressure References #741

Closed

stale bot added the wontfix label Feb 24, 2020

lipchev self-assigned this Feb 25, 2020

stale bot removed the wontfix label Feb 25, 2020

stale bot removed the wontfix label Jun 5, 2020

angularsen added the pinned Issues that should not be auto-closed due to inactivity. label Jun 7, 2020

lipchev mentioned this pull request Jun 10, 2020

SI Units Filtering #809

Closed

lipchev added 5 commits October 5, 2020 05:44

updated the Astronomical unit system

b844f26

- updated the default units (as per https://en.wikipedia.org/wiki/Astronomical_system_of_units) - fixed the docstring

added static acess variables for all UnitSystems

6ef823f

in order to avoid breaking the namespace (UnitSystem.SI) all static instances were added to the UnitSystem.Definition (partial class)

lipchev mentioned this pull request Feb 17, 2021

Any (planned) relationship to QUDT? http://www.qudt.org/2.1/vocab/unit #894

Closed

lipchev added 2 commits March 7, 2021 11:25

merged from upstream

9d5c86f

removed SupportsSIUnitSystem in favor of the As_UnitSystem_ThrowsArgu…

e45efe8

…mentExceptionIfNotSupported tests

angularsen mentioned this pull request Apr 4, 2021

Fix deserializing decimal quantities regardless of local culture #911

Merged

lipchev added 4 commits April 27, 2021 15:15

Create manual.yml

e027e7c

where is the run button!?

Revert "Create manual.yml"

cbdbe19

This reverts commit e027e7c.

Merge remote-tracking branch 'upstream/master'

c3585da

Merge remote-tracking branch 'upstream/master'

cb3c603

angularsen mentioned this pull request Sep 18, 2021

Overload * operator for BitRate and Duration #968

Closed

- fixed the test for WithDefaultUnit_GivenNullForDerivedUnits_Returns…

dfe0bd2

…UnitSystemWithOldDerivedUnits_IncludingTheNewBaseUnit

angularsen modified the milestones: 5.0, vNext Feb 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redesign UnitSystem to support non-SI systems and configurable default units #709

Redesign UnitSystem to support non-SI systems and configurable default units #709

lipchev commented Sep 28, 2019 •

edited

Loading

codecov-io commented Sep 28, 2019 •

edited by codecov bot

Loading

lipchev commented Sep 28, 2019

lipchev commented Sep 28, 2019

lipchev commented Sep 29, 2019

angularsen commented Sep 29, 2019

angularsen commented Sep 29, 2019

angularsen commented Sep 29, 2019 •

edited

Loading

angularsen left a comment

angularsen Sep 29, 2019

lipchev Sep 29, 2019

angularsen Sep 29, 2019 •

edited

Loading

angularsen Sep 29, 2019

angularsen Sep 29, 2019

lipchev commented Sep 29, 2019

angularsen commented Sep 29, 2019

lipchev commented Oct 5, 2019

angularsen commented Oct 9, 2019

lipchev commented Nov 12, 2019

lipchev commented Nov 12, 2019

lipchev commented Nov 12, 2019

angularsen commented Dec 26, 2019

stale bot commented Feb 24, 2020

angularsen commented Jun 7, 2020 •

edited

Loading

lipchev commented Oct 6, 2020

angularsen commented Oct 6, 2020

angularsen commented Dec 16, 2020

angularsen commented Dec 16, 2020

inflectionpoint commented Jan 15, 2021

angularsen commented Jan 18, 2021

lipchev commented Mar 7, 2021

angularsen commented Mar 21, 2021

lipchev commented Sep 3, 2022

Redesign UnitSystem to support non-SI systems and configurable default units #709

Are you sure you want to change the base?

Redesign UnitSystem to support non-SI systems and configurable default units #709

Conversation

lipchev commented Sep 28, 2019 • edited Loading

codecov-io commented Sep 28, 2019 • edited by codecov bot Loading

Codecov Report

lipchev commented Sep 28, 2019

lipchev commented Sep 28, 2019

lipchev commented Sep 29, 2019

angularsen commented Sep 29, 2019

angularsen commented Sep 29, 2019

angularsen commented Sep 29, 2019 • edited Loading

angularsen left a comment

Choose a reason for hiding this comment

angularsen Sep 29, 2019

Choose a reason for hiding this comment

lipchev Sep 29, 2019

Choose a reason for hiding this comment

angularsen Sep 29, 2019 • edited Loading

Choose a reason for hiding this comment

angularsen Sep 29, 2019

Choose a reason for hiding this comment

angularsen Sep 29, 2019

Choose a reason for hiding this comment

lipchev commented Sep 29, 2019

angularsen commented Sep 29, 2019

lipchev commented Oct 5, 2019

angularsen commented Oct 9, 2019

lipchev commented Nov 12, 2019

lipchev commented Nov 12, 2019

lipchev commented Nov 12, 2019

angularsen commented Dec 26, 2019

stale bot commented Feb 24, 2020

angularsen commented Jun 7, 2020 • edited Loading

lipchev commented Oct 6, 2020

angularsen commented Oct 6, 2020

angularsen commented Dec 16, 2020

angularsen commented Dec 16, 2020

inflectionpoint commented Jan 15, 2021

angularsen commented Jan 18, 2021

lipchev commented Mar 7, 2021

angularsen commented Mar 21, 2021

lipchev commented Sep 3, 2022

lipchev commented Sep 28, 2019 •

edited

Loading

codecov-io commented Sep 28, 2019 •

edited by codecov bot

Loading

angularsen commented Sep 29, 2019 •

edited

Loading

angularsen Sep 29, 2019 •

edited

Loading

angularsen commented Jun 7, 2020 •

edited

Loading