search

microsoft / calculator

Windows Calculator: A simple yet powerful calculator that ships with Windows
MIT License
29.58k stars 5.35k forks source link

Converter should integrate (or reuse) online unit conversions (Bing or similar services) to increase category/unit coverage #515

Open ferzkopp opened 5 years ago

ferzkopp commented 5 years ago

Problem Statement The proposed feature is to add more comprehensive coverage of categories and units for Converter through some form of integration with newly created or existing online systems.

Calculator provides unit conversions for 13 categories (Currency, Volume, Length, Weight/Mass, Temperature, Energy, Area, Speed, Time, Power, Data, Pressure, Angle) via the main Hamburger Menu. Length has for example selections for 11 units (Nanometer, Microns, Millimeters, Centimeters, Meters, Kilometers, Inches, Feed, Yards, Miles, Nautical Miles) and outputs additional "practical" units in the UI (Paperclips). While the current hard-coded list of conversions in calculator is reasonably extensive, the fixed set of units can quickly reach its limits, in particular when scientific or rare units are required (see evidence below).

Once a user hits a unit conversion limitation, they will likely turn to search engines which generally provide the requested conversions directly from the search box. This slows down the user trying to perform unit conversions (context switch to browser, copy-and-paste of converted results) overall diminishes the value of the unit conversion feature and Calculator in a cloud-connected world.

The goal for this feature is to make the Converter the one-stop-shop for unit conversions, in particular for scientific and educational settings.

Evidence or User Insights

Various gaps have been identified and documented in existing issues: https://github.com/microsoft/calculator/issues/275 - month and ns for time https://github.com/microsoft/calculator/issues/325 - light years for distance

A Bing query for a unit conversion (https://www.bing.com/search?q=20+F+in+C) shows a "Convert units" dialog with 17 categories (Length, Mass, Temperature, Speed, Volume, Area, Time, Frequency, Angle, Force, Pressure, Energy, Power, Electric Current, Voltage, Resistance, Digital storage, Fuel consumption) which is 4 more than calculator.

The Wikipedia page for Length https://en.wikipedia.org/wiki/Conversion_of_units#Length lists 77 distinct distance units, which is 66 more than calculator.

A Bing query can also support variable conversions such as currency conversions (https://www.bing.com/search?q=20+euro+in+dollar&FORM=AWRE) where the factor changes over time.

Proposal

The related work to modernize the unit conversion architecture: https://github.com/microsoft/calculator/issues/379 should consider making Converter fully data driven, and integrate with an online data-source or service so Converter can provide more comprehensive (and daily updatable) conversion tables without binary updates to Calculator itself.

Assuming the existence of an online service which would aggregate and serve existing conversions from online sources (i.e. via an exposed search engine API or code-sharing), add currency services, scrape Wikipedia or other public sources, and allow for curation (to avoid errors), Converter could download and cache a conversion table that is much more comprehensive than the current version.

Goals

User can convert anything that works in a search engine such as "20 dollars into euro" or "1 ly into mm" with Converter.

Non-Goals

Design and implementation of the web-service that aggregates and serves conversion data.

Low-Fidelity Concept

[Online Conversion Sources] + [Curators] ----web service ---> [Conversion Table Artifact] ---download/update---> [Calculator] ---cache/use---> [Converter UI]

Requested Assignment

I'm just suggesting this idea. I don't want to implement it.

MicrosoftIssueBot commented 5 years ago

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

MovGP0 commented 5 years ago

conversion tables will not work for non-linear conversions, ie. for dB.

MovGP0 commented 5 years ago

also note that some of the units on wikipedia aren't units, but prefixed units. Ie. mm is not a unit; just the second m is. The first m is a prefix.

ferzkopp commented 5 years ago

conversion tables will not work for non-linear conversions, ie. for dB.

That is true - but the the converter engine could support non-linear conversions, either as symbolic formula or a mapping table (Example: https://www.rapidtables.com/electric/decibel.html - dB to ratio conversion table) that is interpolated. In fact, even simple temperature conversion need formulas as well as allowed value ranges. A dB conversion would also need a 2nd reference input to form the ratio.

note that some of the units on wikipedia aren't units, but prefixed units

Conversions between prefixes (i.e. km into mm) are conversions nevertheless; the conversion factor would be generally a multiple of 10. I don't see the point in limiting a conversion table to pure "unit conversions" such as F to C. One has also common conversions of counts which have no (or arbitrary units) such as "1 gross == 144, 1 small gross == 10 dozen, etc."

The [Conversion Table Artifact] mentioned above would therefore need to support the following "features" to be specified:

  1. linear conversion without offset, i.e. 1 Thermochemical Calorie = 4.184 J)
  2. linear conversion with offset, i.e. Temperature in K = (Temperature in F - 32) / 1.8 + 273.15
  3. non-linear conversions using arbitrary formulas with reference input, i.e. Gain in dB @ Power P_reference = 10 * log_10 (Power P_input / P_reference)
  4. transparently handle common prefix units (i.e. prefix m = milli = 0.001, prefix k = kilo = 1000)
  5. allow association of prefix units to base units (i.e. a "milli" prefix is applicable to "1 meter", but not to "1 dozen")

As an example here is a similar implementation: https://github.com/angularsen/UnitsNet (90 quantities with 800+ units), which uses JSON for definitions (https://github.com/angularsen/UnitsNet/tree/master/Common/UnitDefinitions) but skipped implementing non-linear conversions (3) citing difficulty and lack of use-cases (https://github.com/angularsen/UnitsNet/issues/21).

Lo0oG commented 5 years ago

On Wikipedia, there is a nice table of unit data at https://en.wikipedia.org/wiki/Module:Convert/documentation/conversion_data which is used by the Convert template on there.

ghost commented 5 years ago

We reviewed the pitch and would love to explore this idea further! The pitch is a great start, but there are still some open questions. I am moving this issue into planning to iron out some of those details and I created calculator-specs/converterUnits to track progress. A human will follow up with some feedback on your pitch shortly. Keep in mind that not all ideas that make it into the planning phase are guaranteed to make it to release. For more information on next steps, check out our spec workflow.

grochocki commented 5 years ago

There have been a few issues discussing which units we should include (as well as what the source of truth should be for conversion values), so we think it would be good to define an overall strategy for making decisions for converters.

We could certainly leverage Bing to help decide which units should be included, but we are generally not in favor of taking a dependency on an online service at this time. We do not feel the complexity this introduces is warranted given how infrequently units change. I think we should consider other sources as well. For example, should we consider customary/regional units (e.g., Korean Pyeong via #382)?

To prevent scope creep, we’ll limit this feature to defining which converters and units to include, what we will use as the source of truth for conversion values, and a light framework for making future decisions regarding supported converters/units. I’ll open two new issues to address (a) improving unit selection UX to ensure that it is easy to select common units while also supporting, in some cases, large sets of units, and (b) exploring improvements to general unit converter navigation (e.g., perhaps converters would be more discoverable if we collapsed all converters into one mode).

ghost commented 4 years ago

/cc @ferzkopp @grochocki But we cannot expect our users to go online for a simple conversion, say a man's height from centimetres to inches. This would make the Calculator pretty useless if somehow the user is unable to connect to the internet.

ferzkopp commented 4 years ago

But we cannot expect our users to go online for a simple conversion...

Agreed. Unit conversions need to work on a freshly-installed air-gapped device.

The proposal states that a "Converter could download and cache a conversion table..." the key being the mention of a "cache" (i.e. a local copy) of the conversion table. The base installation can ship with the built-in converter table (pre-cache) so conversions will always work. However, when the device is actually online, an improved conversion table could be automatically retrieved from the online source. This would mean, the Client side unit conversion system needs to have the following features around this topic: