Dimensionless units

[Martin Hill]

As you sort of say, there is more than one analysis, but here one is 
unit analysis and the other is dimension analysis.

Unit analysis for kg, miles, Jys, etc is not, I really don't think, 
straightforward or easily automated or much fun either.

Dimension analysis for time, length, energy, etc does not solve all our 
problems, but it is very easy and works well in many situations; much 
easier than the many<->many convertions required for unit analysis.

But as soon as you start dealing with conversions such as redshift to 
distance, or flux to magnitude, you need metadata, and this becomes what 
might be called a 'domain conversion', ie the algorithms belong to a 
particular domain of physics or maths, not to unit or dimension analysis.


Ed Shaya wrote:
> David and Martin
> 
> Again, we are getting the two types of dimensional analyses confused.
> Unit Analysis specifies the conversion fully:
> 
> Jy/sr *  sr/[(pi/4)deg]^2  * [deg/(60 arcmin)]^2 = [4*60/pi]^2 
> Jy/arcmin2 or something like that.
> 
> This type of analysis should almost always work and be valid and easily 
> automated.  I can think of some oddball occassions, like using redshift 
> for distances to planets etc, that would be a mistake.   For conversion 
> purposes, we should add radian to the basic SI units: meter, kilogram, 
> second, candela, ampere, kelvin, mole.  Since mole is not terribly 
> useful in astronomy, we could switch number count for mole.  Then one 
> can convert anything to these base units and do comparisons on a common 
> basis.  I think this is part of  Pedro's system and it is also the basis 
> of what Brian and I wrote a schema for many years ago.
> 
> The base units are not the dimensions.   Don't get them confused.  A 
> mole is dimensionless, but one can still do unit analysis with moles!
> 
> The dimensional analysis where one uses just the dimensions doesn't tell 
> you anything about how to
> go from Jy/sr to Jy/arcmin**2 other than to tell you that it is not 
> dimensionally wrong.  Pedro's system does use real dimensional analysis 
> for spectra by taking the ratio of the dimensions of two quantities and 
> if the ratio is L/T then it assumes that a velocity can be used to do 
> the conversion and since spectra are EM waves, the velocity is probably 
> the speed of light. 
> I wonder, is a SED only allowed to be spectra?  If I have Fnu/pc (flux 
> along a disk) and Fnu/sec (rate of change of the flux), are these 
> allowed in a SED?  If so then we will need to rely on UCD or ontology to 
> stop Pedro's system from doing a dimensional analysis and converting one 
> to the other.  I am sure he is aware of this.
> EdDavid Berry wrote:
> 
>> Martin,
>>
>>  
>>
>>>>        It would seem reasonable that a unit conversion scheme should be
>>>> able to determine the conversion from Jy/sr to Jy/arcmin**2 without 
>>>> needing
>>>> UCDs. The conversion is obviously just a simple scaling factor - no 
>>>> need
>>>> for any extra physics or UCDs or anything. But since these two units 
>>>> have
>>>> the same MLT dimensions, how can the conversion be determined on the 
>>>> basis
>>>> of a dimensional analysis alone? Introducing Angle as a dimension along
>>>> with Mass, Length and Time could do it.
>>>>     
>>>
>>> Hi David
>>>
>>> I understood that a scaling factor was part of the dimension-based unit
>>> converters (we can't do any unit conversions otherwise?)  So converting
>>> from Jy/sr to a dimension equation will give the same result as 
>>> converting
>>> Jy/arcmin^2 to a dimension equation, as the scaling values used for 
>>> radians
>>> and arcmins will be different.
>>>   
>>
>>
>> But the scaling factor as I understand it is just the ratio of the units
>> you want, to the SI units implied by the dimensional analysis. That is,
>> The DIMEQ for "Jy" is "MT-2", implying SI units of kg/s/s, and the
>> corresponding SCALEQ value of 1.0E-26 means that 1 Jy is 1.0E-26 kg/s/s/.
>> But since angle does not enter into the dimensional analysis, neither 
>> will
>> it enter into the scaling factor. So I would expect Jy/sr and 
>> Jy/arcmin**2
>> to have the same scale factor.
>>
>>  
>>
>>> However you can, in principal, ask a dimension-based unit converter to
>>> convert from Jy/sr to Jy, and it will not be able to tell you that 
>>> this is,
>>> at first glance, just silly.
>>>   
>>
>>
>> Is this progress, given that a straightforward string parsing system 
>> could
>> tell you this?
>>
>> David
>>
>>
>>  
>>
> 
> 


-- 
Martin Hill
AstroGrid Software Engineer @ ROE
07901 55 24 66