Convert Power to double

[tmilnthorp]

Fixes #1194

[tmilnthorp]

Fails in json tests. Unsure what to do here.

[angularsen]

3 tests failing in CI it seems, all related to JSON converters. We probably handpicked decimal quantities for these tests, but we would have to create a new dummy quantity for testing purposes I guess if we want to keep the decimal JSON functionality around.

It would also be important to verify that old serialized JSON for Power/BitRate/Information can still be deserialized after switching to double.

https://dev.azure.com/unitsnet/Units.NET/_build/results?buildId=311&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=9d4476d9-f6e2-5f97-1036-4124d48c41e1

[tmilnthorp]

3 tests failing in CI it seems, all related to JSON converters. We probably handpicked decimal quantities for these tests, but we would have to create a new dummy quantity for testing purposes I guess if we want to keep the decimal JSON functionality around.

It would also be important to verify that old serialized JSON for Power/BitRate/Information can still be deserialized after switching to double.

https://dev.azure.com/unitsnet/Units.NET/_build/results?buildId=311&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=9d4476d9-f6e2-5f97-1036-4124d48c41e1

Yea the tests were just using Power to test decimal types. I just convered them to another existing decimal type.

Def should add a test to test old output.

[angularsen]

Looks good, just a few minor suggestions.

Question; what do you think of also changing Information/BitRate from decimal to double?

On one hand, it is sort of weird to risk getting rounding errors like 8.00000001 bits. On the other hand, for all other units (kilobyte, etc) that are probably way more used, floating point is perhaps the expected value representation.

If we change all 3 quantities to double, we have the potential to clean up a LOT of QuantityValue complexity.

[tmilnthorp]

Question; what do you think of also changing Information/BitRate from decimal to double?

As much as it pains me, I think these actually do make sense as decimal by default. If we had generic support, it could be whatever the client wishes.

[angularsen]

I'm still not sure about Information, there's a lot of code just to avoid rounding errors on the unit Bit. For all other units Kilobyte etc, a non-integer value is probably expected anyway.

Although, with #1206 it would probably read 5.299999999 kB instead of 5.3 kB in some cases.
But, with #1206 we kind of force everyone to use ToString("s2") anyway, and that would return 5.30 kB.

Come to think ofit, isn't s2 almost equal to n2? Or actually, more like 0.## custom format.
Do we need s?

Here tested with current implementation in master, where g equals our special implementation rounding to 2 decimals.

CultureInfo.CurrentCulture = CultureInfo.InvariantCulture;
1000.2.ToString("g2").Dump();                    // 1e+03
1000.2.ToString("n2").Dump();                    // 1,000.20
Length.FromFeet(1000.2).ToString("s2").Dump();   // 1,000.2 ft
Length.FromFeet(1000.2).ToString("g2").Dump();   // 1,000.2 ft
Length.FromFeet(1000.2).ToString("n2").Dump();   // 1,000.20 ft
Length.FromFeet(1000.2).ToString("f2").Dump();   // 1000.20 ft

1000.234.ToString("g2").Dump();                  // 1e+03
1000.234.ToString("n2").Dump();                  // 1,000.23
Length.FromFeet(1000.234).ToString("s2").Dump(); // 1,000.23 ft
Length.FromFeet(1000.234).ToString("g2").Dump(); // 1,000.23 ft
Length.FromFeet(1000.234).ToString("n2").Dump(); // 1,000.23 ft
Length.FromFeet(1000.234).ToString("f2").Dump(); // 1000.23 ft

[stale]

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.

[ebfortin]

Looks good, just a few minor suggestions.

Question; what do you think of also changing Information/BitRate from decimal to double?

On one hand, it is sort of weird to risk getting rounding errors like 8.00000001 bits. On the other hand, for all other units (kilobyte, etc) that are probably way more used, floating point is perhaps the expected value representation.

If we change all 3 quantities to double, we have the potential to clean up a LOT of QuantityValue complexity.

I agree. Floating point error is a fact of life anyway. Some number can't even be represented and we still use them for computation everywhere. I don't think it's worth the complexity just for one unit.