Changes between Version 4 and Version 5 of ProcedureDefinedUnits

Timestamp:

03/19/10 11:32:39 (15 years ago)

Author:

gschadow

Comment:

--

ProcedureDefinedUnits

@@ -54 +54 @@
 And thus our simple 7 component dimension vector stops being a vector of any finite length.
 
-What do we do?
+== What do we do? ==
 
 The present approach was to add a new property "arbitrary unit" into the unit definition.
@@ -64 +64 @@
 But we need a final solution that deals with this challenge.
 
-== One Solution ==
+=== One Solution ===
 
-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.
+One 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).
+
+=== A Way Forward ===
+
+Arbitrary 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.
+
+Therefore, 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.