Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Data functions (like ElementData) and physical units

  • To: mathgroup at smc.vnet.net
  • Subject: [mg83048] Re: Data functions (like ElementData) and physical units
  • From: Chris Chiasson <chris.chiasson at gmail.com>
  • Date: Thu, 8 Nov 2007 06:16:30 -0500 (EST)
  • References: <fgs95u$56i$1@smc.vnet.net>

On Nov 7, 5:56 am, John Jowett <John.M.Jow... at gmail.com> wrote:
> The new data functions (like ElementData, ParticleData, ...) in
> Mathematica Version 6 are tremendously useful.
>
> However one aspect of their design seems unfortunate to me.  That is
> the way the units of physical quantities are given.  For example,
>
> ParticleData["Muon", "Mass", "Units"]    evaluates to
>
> "MegaelectronVoltsPerSpeedOfLightSquared"
>
> and
>
> ElementData["Iron", "ThermalExpansion", "Units"]
>
> returns
>
> "ReciprocalKelvins".
>
> In my opinion, it's a great pity that this was not integrated with the
> Units and PhysicalConstants packages which provides symbols (rather
> than strings) for units.  The two evaluations given above could have
> returned
>
> Mega ElectronVolt SpeedOfLight^-2
>
> Kelvin^-1
>
> and one would immediately be able to simplify expressions without
> worrying about units, convert to other systems etc.
>
> A solution to this would be to recursively parse the unit strings and
> convert them to expressions of this kind.  I think this could be done,
> roughly as follows:
>
> Strings of the form  "aPerB" would have to be converted to fractions
> (as far as I have seen, "Per" or "Reciprocal" occur at most
> once ...),
>
> The strings would then be split at uppercase letters (except where
> substrings like SpeedOfLight coincide with names of constants...).
>
> Then one has to to capitalize the "p" and remove the plural "s" when
> splitting  "Megapascals"  into (Mega Pascal) ...
>
> This would open up the possibility of having a function that returned
> physical quantities with their units attached:
>
> myElementData["Iron", "ThermalExpansion"]
> 0.0000118 Kelvin^-1
>
> rather than the present
>
> ElementData["Iron"]
> 0.0000118
>
> and would greatly reduce the chances making wrong calculations like
>
> AstronomicalData["Sun", "Mass"]/ParticleData["Muon", "Mass"]
>
> 1.881947*10^28
>
> which most people would expect to be a dimensionless ratio.
>
> Has anyone already written the code required to do this ?   Does
> anyone from Wolfram want to comment on this design decision ?
>
> John Jowett

I am self-censoring my comments about the overall utility of the data
functions (and the physical constants package) for real work.

On to your question. The main goal in the design decision to use
strings seems to have been to prevent an increase in the number of
symbols "crowding" default namespaces. Of course, this does not apply
to your case, because the units could have been returned as 1/
Units`Kelvin, for example. The Units package would not even need to be
loaded to do that. Therefore, I don't see a good reason to use string
units.



  • Prev by Date: Re: Re: ListPointPlot3D
  • Next by Date: Re: Reproducing a hash code
  • Previous by thread: Data functions (like ElementData) and physical units
  • Next by thread: Re: Data functions (like ElementData) and physical units