Changes between Version 4 and Version 5 of ProcedureDefinedUnits


Ignore:
Timestamp:
03/19/10 11:32:39 (9 years ago)
Author:
gschadow
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProcedureDefinedUnits

    v4 v5  
    5454And thus our simple 7 component dimension vector stops being a vector of any finite length.
    5555
    56 What do we do?
     56== What do we do? ==
    5757
    5858The present approach was to add a new property "arbitrary unit" into the unit definition.
     
    6464But we need a final solution that deals with this challenge.
    6565
    66 == One Solution ==
     66=== One Solution ===
    6767
    68 One possible solution is to assume a hardline scientific position and put any and all UCUM units on a black-list that are used to merely decorate dimensionless number, indexes, or ratios. A very good argument for this position can be found in #27.
     68One possible solution is to assume a hard-line scientific position and put any and all UCUM units on a black-list that are used to merely decorate dimensionless number, indexes, or ratios. A very good argument for this position can be found in #27 (the strike-through only indicates this issue is closed, not that it is invalid).
     69
     70=== A Way Forward ===
     71
     72Arbitrary units [IU] and [iU] are equal, they are, in fact, the same (just literal difference). The same issue you have with the case-insensitive and case-sensitive lexical variants. So, if we use the isArbitrary property to force checking the unit, we must not fail equal because of those differences.
     73
     74Therefore, we probably need to extend our dimension and base-unit vector with additional fields, and when checking dimensionality, we need to take those into account. This makes the dimension and base-unit vector sparse at the end. There are 10^3^ arbitrary units to reckon with.