dimensionless units

[Jesus J. Salgado]

Dear Jonathan, dear all,

Pedro is on leave for three days due to personal reasons, but I have
been talking to him about the Jonathan's suggestion, and these are our
conclusions.

If we have, instead of our scaleq/dimeq convection, the following
parameters:

>---  Here we have the standardized units for simple software ---
>     SISCAL = 62.15 
>     SIUNIT ='m^-2 s^-1'
> 

our software can perfectly be adapted to parse them to our notation, and
for us would be enough. The fact that this notation is compatible with
the "units string parsers" could be a good reason for taking it.

About the discussion about if our algorithm is really units analysis or
dimensional analysis, we are trying to clarify it in the paper we are
preparing.

I would say (Solomonic approach) that the algorithm is dimensional
analysis (using the dimensional equation) during most of the conversion
process and, as a last step, we make a units analysis using the
scalings.


Best Regards,
Jesus Salgado



On Mon, 2005-02-21 at 23:56, Jonathan McDowell wrote:
> I think that Martin and Ed have made some very good points
> about the subtleties of unit and dimensional analyses, and I'm
> going to repeat an old suggestion of mine in the context of this
> discussion.
> 
> Part of the problem is that Pedro's approach makes total sense within
> the context of photon spectra of sources, where things can be
> interconverted using some combination of (1) unit analysis and (2) the
> dispersion relation nu * lambda = c. But it doesn't extend so easily
to
> general astronomical data where, as has been pointed out, the UCD and
> possibly other metadata may be needed to do a conversion or to
determine
> whether a conversion makes scientific sense.
> 
> I think in the DM context it's important to distinguish between
> conversions which are simple scaling  (pc to AU to km) and conversions
> which in principle require a UCD (even though you can get away without
> one if you are in the spectral context and using nu * lambda = c).
> The UCD based conversions are domain and context specific and 
> should be in software associated with particular contexts (e.g. a
spectral
> packag) while the basic units scaling conversion is general and should
be in
> general software.
> 
> So to me the question is: how can we support the very useful
functionality
> of Pedro's tool in the spectral domain without boxing ourselves into
> a corner that won't generalize well?
> 
> I've argued with Pedro in the past about this distinction between
> dimensional analysis as - I think it was Ed said this? - the answer to
> the question 'are these things compatible' with no numeric factor, and
> unit analysis where the numerical factors are included. 
> 
> I would restate
> some of the recent discussion as alleging that Pedro's scheme is
> really unit analysis dressed up in the clothes of dimensional
analysis,
> and I assert that if you restate that scheme as "reduce all units to
> their unprefixed SI base unit representation", so that
> 
>     mJy ->  10^-23 kg s^-2
>     10^-11 erg cm^-2 s^-1 keV^-1   -> 6.215 10^1 m-2 s-1 
> 
> and then rename  kg = "M", s = "T", m = "L" so that it's  1.E-23 MT-2
and 6.215E+01 L-2T-1
> you have exactly Pedro's scheme. Given that, why not skip the
> renaming. If we require (possibly as additional metadata) that
> an SI base representation of the units be provided
> 
>   ---  Here we have the units as they appear in the relevant ApJ paper
---
>     UNITSCAL  = 1.0E-11
>     UNIT      = 'erg cm^-2 s^-1 keV^-1'
>   ---  Here we have the standardized units for simple software ---
>     SISCAL = 62.15 
>     SIUNIT ='m^-2 s^-1'
> 
> that's really trivial for Pedro's software to parse into his L-2T-1
format, but
> it can also be used by unit analysis software. I'm just saying, even
if we
> have redundant metadata (unit and sifac/siunit) we don't need
redundant
> DIFFERENT string syntaxes. If we're going to have a string syntax for
> the "dimensional" analysis, why not use the SAME syntax that we use
> for general unit analysis, since then other people's clever unit
software can handle
> either UNITSCAL/UNIT or SISCAL/SIUNIT with the same parser.
> 
> If clever unit software becomes widespread and standardized we maybe
eventually
> can drop the SI.. version. 
> 
>  - Jonathan
-- 
Jesus J. Salgado


ESAC Archive Development Team
e-mail: Jesus.Juan.Salgado at esa.int
Tel + 34 91 8131271

European Space Agency/European Science Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN