About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
Completed (24 days)
Completed (57 days)
Completed (26 days)
Completed (47 days)
Completed (19 days)
Completed (14 days)

Introduction >

UnitParser Code (.NET/C#) >

Unit conversions

DateParser Code (.NET/C#) >

FlexibleParser
UnitParser code (.NET/C#) >
Unit Conversions
Parsing means recognising and adapting raw inputs to the target format; consequently, a library only recognising the string "m/s" as a valid (velocity) unit might be rightfully called parser. On the other hand, virtually any piece of software dealing with units supports conversions. That's why the unit conversion functionalities can be considered part of the most essential features of UnitParser.

It has to be noted that the unit prefixes are treated like numeric values associated with the given unit. For example, the operation new UnitP("1 kg") + new UnitP("1 g") doesn't involve a unit conversion, but just an operation between different values. Same ideas apply to situations accounting for different types of prefixes (e.g., new UnitP("1 kbit") + new UnitP("1 Kibit")).

Performing auto-conversions is other distinctive feature of UnitParser; also another side-effect of its permissive input policy. A situation like new UnitP("kg*ft/s2") (i.e., a force where SI and imperial constituent parts are being mixed up) is wrong and that's why an automatic conversion has to be performed. These auto-conversions certainly represent an additional layer of complexity despite relying on the standard conversion algorithm described below.

All the unit conversions go through the following steps (code stored in Operations_Private_Conversions.cs):
  • After confirming the validity of the input variables, PerformConversion normalises (as explained in the next section) their values according to the rules applicable under the given conditions. Then, a call to UnitsCanBeConvertedDirectly determines the method, out of the ones described below, to go next.
  • ConvertUnitValue deals with situations where a direct conversion (e.g., named units whose conversion factors share the same reference) is possible. If the given unit type (bear in mind that different-type units cannot be converted into each other) is included in the SpecialConversionTypes array, the specific method for that type would be called (via ConvertUnitValueSpecial); otherwise, both conversion factors would be brought into picture.
  • PerformUnitPartConversion manages cases where the corresponding unit constituent parts need to be analysed. Equivalently to what happens when dealing with other functionalities, this code is much more complex than the aforementioned one dealing with the simplest scenario.
    Note that, additionally to the typical problems associated with multi-part units (e.g., simplifications, prefix compensations, dividable vs. non-dividable peculiarities, etc.), this method has also to account for the eventuality of converting units without a direct equivalence. For example, new UnitP("BTU/s") is a power unit which can be converted into new UnitP("W"), but none of the supported conversion factors (or specific conversion methods) is applicable to this situation. The way to deal with these cases is by aggregating the partial results output by converting the common subparts (i.e., just new UnitP("BTU") into new UnitP("J"), because new UnitP("s") doesn't need to be converted).