Units in catalogue files

[t00fri]

Ok postfix it is.

I actually preferred prefix, but I'll yield to the majority on this one.

I also prefer to see the units specified immediately after the property name, and before the value (as you originally specified Andrew). I just think it will be more readable and easier to understand (especially when mixed with numbers with many significant digits).
ie. It makes better sense (cognitively) when reading, to know the units before reading the value.

CC

I also prefer the prefix notation.

Fridger

[Guckytos]

I also think prefix is better.

[ajtribick]

Well this swings which side the majority lies on... in any case the coding change required to switch from prefix to postfix is minimal, so this is in no way set in stone at present. Reasons for preference of one form or the other would be helpful, I'd rather make a decision factoring these considerations in than simple majority.

[Guckytos]

Well this swings which side the majority lies on... in any case the coding change required to switch from prefix to postfix is minimal, so this is in no way set in stone at present. Reasons for preference of one form or the other would be helpful, I'd rather make a decision factoring these considerations in than simple majority.

Okay, some reasoning

If you have a parameter and directly behind it the information in what format the numbers are, it's easy to link that information.
If it was prefix it would look more "standardized". If there is a prefix, you see it and know it's there.
You don't have to go to the line end to find out if a "special" format is declared or not.

Okay, for only short numbers, you would see more or less easily.

But what if you have an array with long decimals? Then you would have to go to the end of the line to see it and then back, just to see it.

[duds26]

Well this swings which side the majority lies on... in any case the coding change required to switch from prefix to postfix is minimal, so this is in no way set in stone at present. Reasons for preference of one form or the other would be helpful, I'd rather make a decision factoring these considerations in than simple majority.

Please make your code in a way that somewhere on ONE place in the whole celestia code, there is a value.
That value says if it's post or prefix.
e.g. prefix = 1 // true for prefix, 0 for postfix, initialized on default value.
This could be handy for changing everything at once, just change a 1 <> 0.
Testing this will make your code more dynamic and robust.

[duds26]

Ok postfix it is.

I actually preferred prefix, but I'll yield to the majority on this one.

I also prefer to see the units specified immediately after the property name, and before the value (as you originally specified Andrew). I just think it will be more readable and easier to understand (especially when mixed with numbers with many significant digits).
ie. It makes better sense (cognitively) when reading, to know the units before reading the value.

CC

Very interesting.

Why not code both!?!

[t00fri]

I have NO reasons for my preference whatsoever Really?

Fridger

[ajtribick]

Definitely don't want to make it possible to do either - this makes the task of writing third-party parsers that much more difficult.

duds26 never fear I do know how conditional compilation works.

[Chuft-Captain]

duds,

Earlier, I too (for a moment) considered suggesting both options, but immediately decided not to suggest it !! (out of consideration for Andrew )

The issue is that for the parser to allow either style, then you'd either:
(a) need some sort of parser-directive at the beginning of each file or addon to inform the parser which style to expect in that file/addon;
or:
(b) the parser would need to be significantly more sophisticated to be able to expect the appropriate token at any point in a line.

If you also wanted to freely mix both prefix and postfix styles in a single file, then option (b) would be the only workable option.

This would add complexity to the parser, making Andrew's task that much more more difficult, and is IMO hard to justify for this feature.

Flexible syntax == complex parser
Structured syntax == simple parser

Let us invoke the KISS Priciple in this circumstance.

CC

[Chuft-Captain]

Reasons for preference of one form or the other would be helpful, I'd rather make a decision factoring these considerations in than simple majority.

Ok, so here's my thoughts....
The argument for prefix or postfix is actually a red-herring.
The real question that should be asked is: "what is the scope of the unit specification?"
As I see it, the possible options for scope are...
(in decreasing order of flexibility, complexity):

1. VALUE-scope
-- Applied to individual values
-- Units specified either before or after each individual value
2. PROPERTY-scope
-- Applied to all values of a given value-domain for a single property. (which may extend over 1 or more lines)
-- Units specified either before or after the Property Name
3. FILE-scope
-- Applied to all values of a given value-domain in a file.
-- Would require named-pairs comprising value-domain and unit specification at beginning of the file
4. CELESTIA-scope
-- Applied to alll values of a given value-domain in all files.
-- Would require named-pairs comprising value-domain and unit specification in celestia.cfg

Note: I also considered a 5th option "OBJECT-scope", but ruled this out because it would have most of the in-flexibility of FILE-scope (see below) without any of the benefits of the clarity and simplicity which the narrow scope of options 1 and 2 gives.
For reasons of practicality and cost/benefit which Andrew has already discussed above, I think options 3 and 4 can be immediately ruled out.
Option 3 would not fit well with the parser's generic mode of operation as Andrew mentions above, and would IMO be inflexible as the scope is too wide.
Option 4 amounts to a celestia-wide re-definition of units which would clearly have the potential to break a wide range of functionality! (But would be quite handy if you wanted to do a complete re-scaling of the entire solar-system. -- For example, I've always thought it would be fun to model "the galaxy" from Men In Black in Celestia (complete with cat). This would be a real tough test of Celestia's exponential scaling and floating point accuracy!! )

Anyway, back to serious matters...
For most simple cases like:

Code: Select all

        Period <days> 365.25
        SemiMajorAxis <km> 149597870.7


option 2. is obviously fine.

For compound cases like:

Code: Select all

LongLat <deg><m> [ 20 220 500 ]

where there are multiple value domains, while VALUE-scope (option 1) would give more flexibility, I think option 2 is still the best choice.

I believe the only justification for option (1) would be if there was a real need to specify different scales for different values in the same domain type.
eg. Note the use of both Km and m units in this example:

Code: Select all

LongLat  [ 20<deg> 220<deg> 500<m> ]

I don't personally think that there are many situations where this would be an important requirement, and I think the risk of making the parser too complicated would outweigh any such need. (although I am prepared to be proved wrong in the future, perhaps even by my own addons. )

In any case, it doesn't really matter whether prefix or postfix is used ... the real question is "what is the most useful and practicable scope?"
So as I hope you can see, the real issue is one of scope, whilst the question of prefix/postfix is a secondary (non-functional) style consideration.

Hope this makes sense...
Regards CC

PS. This post has been revised several times to try and make it clearer, so if you've read it prior to the date-time below, you might want to read it again.
Last edited Fri Dec 04, 2009 2:22 pm UTC

[Chuft-Captain]

Firstly, apologies for the length of these posts.

I realize that in order to adopt my way of thinking about this, a clarification/correction is required to the post above.

The Clarification:
If we are to think of unit specifications in terms of SCOPE as I suggest, then we need to be consistent in terms of what is meant by prefix/postfix.
If we're talking about VALUE-scope (option 1), then nothing changes: prefix units appear before the values, postfix units appear after the values,...
...however when talking about PROPERTY-scope (option 2), then to be consistent about the notion of prefix/postfix form, it's necessary to think of it as being "tied to" the Property Name, rather than to the the values: prefix units appear before the Property Name, postfix units appear after the Property Name.

So the 4 possibilities are:

VALUE-scope, postfix

Code: Select all

LongLat  [ 20<deg> 220<deg> 500<m> ]

VALUE-scope, prefix

Code: Select all

LongLat  [ <deg>20 <deg>220 <m>500 ]

PROPERTY-scope, postfix

Code: Select all

LongLat <deg><m> [ 20 220 500 ]

PROPERTY-scope, prefix

Code: Select all

<deg><m> LongLat [ 20 220 500 ]

So whereas (in the old sense) I said that I prefer Prefix,... in the new way of thinking, this should actually be referred to as: (PROPERTY-scope, postfix) ... the 3rd option above.

ie. in order to state a preference, you need to state both the SCOPE and the FORM.

Clear as mud??
If so then state your preference from the 4 choices above !
-----------------------------------------------------------
It's also worth noting that if unit-specifications are associated with a scope as I suggest, then there's no reason why multiple scopes couldn't be implemented just as easily as a single option (the scope would be determined by where the unit is specified) -- with narrower scopes overriding wider scopes. (in this sense, VALUE-scope is conceptually no different to PROPERTY-scope -- it would be simply a narrower scope which would override the PROPERTY-scope).
I'm sure that the parser already handles scope for it's usual duties, so in large-part this scheme would probably plug in quite nicely, allowing scenarios such as the following...

In the following example the Height and MieScaleHeight units are <km> -- determined by virtue of the fact they're within the Atmosphere scope, whereas the CloudHeight units are in <m>. (And take a look at the Sunset units )
This is probably not a very realistic example, but is merely used to demonstrate the idea of using multiple levels of scope to specify custom units at various levels of detail.

Code: Select all

"Earth" "Sol"
{
   Texture "earth.*"
   NightTexture "earthnight.*"
   
   # SpecularTexture "earth-spec.*"
   Color [ 0.85 0.85 1.0 ]
   SpecularColor [ 0.8 0.8 0.85 ]
   SpecularPower 25.0
   HazeColor [ 1 1 1 ]
   HazeDensity 0.3
   Radius 6378.140  # equatorial
   # Oblateness 0.0034

   Atmosphere <km> {
      Height 60
      Lower [ 0.43 0.52 0.65 ]
      Upper [ 0.26 0.47 0.84 ]
      Sky [ 0.40 0.6 1.0 ]
      Sunset <rgb> [ 255 153 51 ]

      CloudHeight <m> 7000
      CloudSpeed 65
      CloudMap "earth-clouds.*"
      CloudShadowDepth 1.0

      Mie 0.001
      MieAsymmetry -0.25
      Rayleigh [ 0.001 0.0025 0.006 ]
      MieScaleHeight 12
   }



The tricky part with this scheme is determining which sub-properties inherit which units of the parent. ie. Imagine the implications of the following:

Code: Select all

Atmosphere <rgb> <km> {
   ...
}

This may be a show-stopper for the idea of unit-inheritance, because it will require prior knowledge of the valid value-domains of each of the sub-properties. ie. Some are distances (km, m, etc), others are colors (rgb or ratio), yet others relate to degree of absorption/reflectance.
It's possibly getting all just a bit too complicated.

CC

PS. Whether the parser requires 'spaces" and/or "<>" to separate the units from the rest of the code is up to Andrew.

[t00fri]

Guys,

this is all getting totally obscure for me as a physicist. For example, you are discussing a list-valued property (LongLat) the name of which suggests a list of two values of dimension [angle], namely longitude and latitude. It would appear horrible if quantities of dimension [angle] would be allowed to be specified in terms of quantities of dimension [length]! Since a single [length] can never be converted into [angle].
Therefore, the explicitly discussed example,

Code: Select all

:
LongLat [ 24 <deg>, 0.1 <rad>, 100 <m> ]


really hurts my "soul" . At best LongLat could depend on two quantities of dimension length and one angle, like so

Code: Select all

:
LongLat [ 24 <deg>, 0.1 <km>, 100 <m> ]


since then [angle]-objects could result in terms of ratios of the last two [length]-valued quantities.
Yet such mixed dimensional input is definitely bad style in physics. Good physics style is rather to only accept such dimensionless ratios of lengths as input for an angular or dimensionless property.

More generally, one should distinguish TWO aspects of a property:

• it's basic dimension, of which it should only carry ONE, like e.g. [length], [angle], [time],...no matter whether the property is a scalar or a vector or a matrix.
  
• Then the main issue would be to allow different units for each basic dimension, such that they may be converted into each other. That's the useful part of this discussion! For instance:
  
  • [length]: <cm>,<m>,<km>,<parsec>...
    
  • [time}: <sec>,<min><h>,<h:min:sec>,....
    
  • [angle]: <radian>,<degrees>,...
• All properties with vectorial or list character should always involve componets of the same basic dimension, yet not necessarily the same units for that dimension!

EDIT: Sorry, when writing this post, I was in a hurry. Now I checked that LongLat in Celestia is actually a mixed dimension list, since besides angles it also contains altitude. So the above examples were at least dimensionally consistent. But a list property with a name suggesting 2 angular variables (LongLat) that also contains a quantity of dimension [length] (altitude) is certainly a bad habit. I would underlign that list properties should NOT involve entries of mixed dimension. But probably, it's to late for changes because of backward compatibility issues...

Fridger

[duds26]

VALUE-scope, postfix

LongLat [ 20<deg> 1.25<km> 500<m> ]

This please.

About the value domains, why not add the physical quantity too.

length<km>
rotation<rad>
time<sec>
...

[Chuft-Captain]

Guys,

this is all getting totally obscure for me as a physicist. For example, you are discussing a list-valued property (LongLat) the name of which refers to a list of two values of dimension [angle], namely longitude and latitude. It would appear horrible if quantities of dimension [angle] would be allowed to be specified in terms of quantities of dimension [length]! Since a single [length] can never be converted into [angle].
Therefore, the explicitly discussed example,

Code: Select all

LongLat [ 24 <deg>, 0.1 <rad>, 100 <m> ]


really hurts my "soul" . At best LongLat could depend on two quantities of dimension length and one angle, like so

Code: Select all

LongLat [ 24 <deg>, 0.1 <km>, 100 <m> ]


since then [angle]-objects could result in terms of ratios of the last two [length]-valued quantities.
Yet such mixed dimensional input is definitely bad style in physics. Good physics style is rather to only accept such dimensionless ratios of lengths as input for an angular or dimensionless property.

Firstly, my apologies. I inadvertently perpetuated an error from one of duds earlier posts by assigning distance units, rather than angular units to the latitude, which hasn't helped this discussion. Hope this hasn't confused the issue.
I've now corrected this typo where it occurred in my posts.
Should we pray for your soul Fridger?

More generally, one should distinguish TWO aspects of a property:

• it's basic dimension, of which it should only carry ONE, like e.g. [length], [angle], [time],...no matter whether the property is a scalar or a vector or a matrix.
  
• Then the main issue would be to allow different units for each basic dimension, such that they may be converted into each other. That's the useful part of this discussion! For instance:
  
  • [length]: <cm>,<m>,<km>,<parsec>...
  • [time}: <sec>,<min><h>,<h:min:sec>,....
  • [angle]: <radian>,<degrees>,...
• All properties with vectorial or list character should always involve componets of the same basic dimension, yet not necessarily the same units for that dimension!

Fridger

Agreed.
What you refer to as "basic dimension" is essentially what I'm referring to as the "value domain" in my earlier posts, except that you appear to be conceptually consolidating my 2 value domains in this example, into a single property domain (Vector: comprising 2 angle domains and a scalar domain).
Regardless of whether we conceptualize these as property domains, or value domains, I don't think that the "domain/basic dimension" needs to be explicitly specified (as duds26 is suggesting) as the parser should already know what's the appropriate domain (or domains) for a given property and only recognize appropriate units for the respective domains.

CC

[t00fri]

CC,

since I was in a hurry when writing my above post, have a look I did some editing later.

Fridger

[Chuft-Captain]

CC,

since I was in a hury when writing my above post, have a look I did some editing later.

Fridger

Ditto for me!! Have another read of my last post as well.

I hate cross-posting!!

EDIT: Sorry, when writing this post, I was in a hurry. Now I checked that LongLat in Celestia is actually a mixed dimension list, since besides angles it also contains altitude. So the above examples were at least dimensionally consistent. But a list property with a name suggesting 2 angular variables (LongLat) that also contains a quantity of dimension [length] (altitude) is certainly a bad habit. I would underlign that list properties should NOT involve entries of mixed dimension. But probably, it's to late for changes because of backward compatibility issues...

This is exactly why I chose to refer to "value" domains, rather than "property" domains.

[t00fri]

Addendum: I was never implying that the basic dimension needs to be specified explicitly. The point was rather not to use properties that involve a mix of basic dimensions if they are of list type. It always adds to transparency, if the property's name uniquely suggests the basic dimension:

Radius ======> [length] ; good
LongLat ======> [ angle angle length]; bad
Distance ======> [length] ; good
Color ======> [ dimensionless dimensionless dimensionless]; good
Rayleigh ======> [ dimensionless dimensionless dimensionless]; good

etc.

Fridger

[Chuft-Captain]

It's the wee small hours here now, so I must leave for now... but I will pray for your tortured soul (tomorrow)

[t00fri]

It's the wee small hours here now, so I must leave for now... but I will pray for your tortured soul (tomorrow)

You seem to be a NightOwl??

Sleep well...

Fridger

[Chuft-Captain]

Well, it is Friday night / Sat morning here...

vive de largo la revoluci?n !!!