Dimensionless units

[Martin @ ROE]

Ed Shaya wrote:

> Martin Hill wrote:
> 
>> Units and dimensions are not ontologies (thank goodness!)
>>
> I agree, but units analysis should be constrained by ontologies.

Well...  I think we're mixing unit analysis with value analysis.  Unit 
analysis, comparisons and convertions only works when we know what the 
value(s) are a measure of.  And we shouldn't be trying to work out what 
a value is a measure of from the units.

>> We don't expect the units to fully define what we're measuring, but 
>> they are an important part of that definition.  So, in this case, we 
>> don't expect um to tell us we have a wavelength, instead we know 'in 
>> some other way' that we have a wavelength value, and its units are in 
>> um. 
>>
> And, that 'some other way' is?

Ontologies, dictionaries, UCDs, or simply by definition (For example, 
the SSAP protocol formats define which 'measures' go into which part of 
the document without requiring an ontology). This is, as we know, a 
difficult subject and I don't think it should be mixed up into unit 
analysis.

>> The equivelence between wavelength and frequency and energy in light, 
>> say, requires knowing that we are dealing with photons (the 
>> equivelence is different for waves in beer), so we can make use of the 
>> units to simplify the ontology; if we know 'in some other way' that we 
>> have photons, then the units can be length, time-1 or energy.
>>
> The speed of light c is a function of the index of refraction so your 
> automated converter between frequency and wavelength needs to know the 
> index of refraction as well.  So, we get into problems of c in air or c 
> in space.  In the radio the electron density can make a difference but 
> let's assume a vacuum in space.
> 
>> Similarly the difference between surface flux and observed flux need 
>> to be described, but is a problem for ontologies not units or dimensions.
>>
> Yes.  So long as there is awareness of the ontological class by the 
> units converter.

Well... a *unit converter* should only deal with units.  Converting 
between different 'measures' (I can't think of a better term just now) 
requires different algorithms, which will vary depending on the measures 
and the particular task in hand.

So in those measurements where space is a vacuum enough to assume a 
constant conversion between wavelength/energy/frequency, then we can 
have a single term (eg 'photon') describing what the value is a measure 
of, and different units that we can freely convert between.  But these 
particular unit conversions should be part of a 'photon' library of 
algorithms (for example), not some massive unit conversion library that 
needs to know about all the various contexts that the unit conversions 
exist in.

> 
>> Units and dimensions allow us to convert and compare things that we 
>> know 'in some other way' are the same. These need not be simple 
>> comparisons; Pedro has demonstrated that you can build an SED from 
>> dimension analysis, because you already know which values go on the 
>> 'brightness' axis and which go on the 'wavelength' axis, even if the 
>> units are all different.
>>  
>>
> If I put an rate of change of energy spatial density vs wavelength in an 
> SED with units w/um^3.   Will it get mixed up with a Flux density of 
> w/um^2/um?
> On the other hand will nuFnu be allowed to convert to Fnu, as it well 
> can be, even though they are different UCDs.
> 
> Also, I now understand that we are talking about dimensional analysis in 
> terms of
> km/THz = 1e3 m * 1e12 s
> Not dimensional analysis in terms of
> km/THz = L*T.

I must admit I thought we were talking about dimensions L, T, etc with a 
scaling factor.  So our unit conversion library can convert between all 
the various units (kg, um, etc) and dimensions.  That way values in 
miles per hour can be compared with values in meters per second, or 
fathoms per fortnight, by using the dimensions as an intermediary.

I understood from the previous posts that we get problems with this 
approach when we have units that are dimensionless.  So this method 
doesn't work very well converting even between radians and degrees, but 
we could perhaps add some pseudodimensions ('count', 'ratio').

This doesn't help with some measures that we think of as the same thing 
(such as magnitudes and fluxes) because they're not actually the same 
measures. Again, this is a problem for a higher level library which will 
have to look at the metadata (such as finding the magnitude zero point), 
not a unit converter.

Similarly I think David's list:

 > deg  (plus rad, arcmin, arcsec, mas)
 > sr
 > mag
 > count (plus photon, ct, ph)
 > pixel (plus pix)
 > Sun
 > chan
 > bin
 > voxel
 > bit
 > byte
 > adu
 > beam

is mixing the concept of dimensions and units with types and ontology 
and metadata.  We often use terms for units even when they're not really 
units, because it's convenient.  We must avoid trying to make our unit 
definitions into a UCD-like dictionary.

Martin

-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66 (mobile)
0131 668 8326 (ROE)