Units in catalogue files

Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.
Avatar
Chuft-Captain
Posts: 1771
Joined: 18.12.2005
With us: 13 years 9 months

Re: Units in catalogue files

Post #61by Chuft-Captain » 09.12.2009, 18:31

duds26 wrote:[Now who's making the parser's life difficult!?!
Not at all. :wink: My suggestions were based on an assumption (without looking at the code) about how the catalog parser worked.
My assumption :
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,
was that this parser was based on a similar design pattern to a typical programming language compiler, which keeps track of the current language scope by means of a context stack.
If indeed this was the case, then the catalog parser would already be aware of the current context/scope as part of it's normal function. (In Celestia catalogs, the current scope would most likely be determined by pushing or popping context elements on/off a context stack (or similar programming construct) on encountering "{" and "}" tokens.
As Andrew explains in the post above, my assumption is clearly incorrect. The Celestia catalog parser is not keeping track of {} block scope. To do so now would require a major rewrite of the parser to implement some sort of context stack, or to quote Andrew: "redesigning the system by which Celestia reads in files".

Now serious, that property scope isn't going to help.

Please don't add such a PROPERTY-scope thing.
If it, and it will someday, mess up stuff. Debugging will be very difficult, hard due to how addons are made.
When addon-writers are writing, they are writing files.
Don't forget their workflow.

In this respect, what if there are two conflicting PROPERTY-scope in different files?
....
I think you have maybe misunderstood what I meant by these "scopes".
I am not suggesting these various scopes as any sort of keywords to be added to catalog files. They are merely conceptual elements of a programming paradigm, which I had assumed the parser already implemented.
My comments above have hopefully clarified this, although if you're not familiar with how programming language compilers are designed, then perhaps not.
Scope is referring to "current syntactic scope/context" and would be internally consistent within the parser (if it implemented a context stack, which it doesn't), so there would be no possibility of conflicting scope in different files.

Anyway, this is all moot now, since Andrew's last post:
ajtribick wrote:Bear in mind that the tokenizer operates on files and converts them to hashes, the parser operates on these hashes. The code to create an elliptical orbit does not see the outer context, all it gets is a hash containing the following key-value pairs
Given this fact, then I tend to agree with your decision Andrew.
It's a pity the parser isn't already keeping track of language scope -- it's clearly more of a "property collector' than a language parser, however I don't think the effort and risk of making it more sophisticated is warranted for this single feature. There would have to be numerous other benefits to justify the extra work and risk.
Perhaps Chris will think of some. :lol:.

Regards
CC
"Is a planetary surface the right place for an expanding technological civilization?"
-- Gerard K. O'Neill (1969)

CATALOG SYNTAX HIGHLIGHTING TOOLS LAGRANGE POINTS

Topic author
ajtribick
Posts: 1780
Joined: 11.08.2003
With us: 16 years 2 months
Location: Switzerland

Re: Units in catalogue files

Post #62by ajtribick » 13.12.2009, 14:58

Having read through this thread, I'm thinking the argument for prefix notation is somewhat better, especially regarding the points about long numbers, and also of the two notations

Code: Select all

SemiAxes<km> [ 2340 2100 2680 ]
SemiAxes [ 2340 2100 2680 ] <km>

The former seems neater to me. So will be going with that. Haven't heard anything back from anyone who's tried the latest version of the code yet...

Avatar
Cham M
Posts: 4325
Joined: 14.01.2004
Age: 55
With us: 15 years 9 months
Location: Montreal

Re: Units in catalogue files

Post #63by Cham » 13.12.2009, 15:05

Andrew,

I much prefer the second example. Looks clearer and more natural to me.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 6 months
Location: Hamburg, Germany

Re: Units in catalogue files

Post #64by t00fri » 13.12.2009, 16:49

ajtribick wrote:Having read through this thread, I'm thinking the argument for prefix notation is somewhat better, especially regarding the points about long numbers, and also of the two notations

Code: Select all

SemiAxes<km> [ 2340 2100 2680 ]
SemiAxes [ 2340 2100 2680 ] <km>

The former seems neater to me. So will be going with that. Haven't heard anything back from anyone who's tried the latest version of the code yet...

I state it once more: I favor

Code: Select all

SemiAxes <km> [ 2340 2100 2680 ]


since physicswise, that's the proper hierarchy ordering!

The units of a dimensionful variable in physics are clearly more basic than it's numerical value. Often one calculates with dimensionful variables without EVER inserting actual numbers. This is only possible if the dimensions are known and properly taken care of. But one cannot use numbers for that variable without knowing it's units!

Hence my preference:

<name> <unit> <value>

Fridger
Image

Avatar
Chuft-Captain
Posts: 1771
Joined: 18.12.2005
With us: 13 years 9 months

Re: Units in catalogue files

Post #65by Chuft-Captain » 13.12.2009, 18:56

ajtribick wrote:Having read through this thread, I'm thinking the argument for prefix notation is somewhat better, especially regarding the points about long numbers, and also of the two notations

Code: Select all

SemiAxes<km> [ 2340 2100 2680 ]
SemiAxes [ 2340 2100 2680 ] <km>

The former seems neater to me. So will be going with that. Haven't heard anything back from anyone who's tried the latest version of the code yet...
Sorry, not in a position to compile at the moment. (I can barely even run Celestia at present!)
However, I'm completely in agreement with you with regards to the "per-property definition" (the former).

I do think it would be more consistent to call this a "per-property, postfix" notation. :)
ie. the units are actually appearing after the property name, rather than before the values (even though they're applied to the values).

Remember my previous post with the 4 permutations? :wink:

Just being really pedantic here! :lol:

CC
"Is a planetary surface the right place for an expanding technological civilization?"
-- Gerard K. O'Neill (1969)

CATALOG SYNTAX HIGHLIGHTING TOOLS LAGRANGE POINTS

Topic author
ajtribick
Posts: 1780
Joined: 11.08.2003
With us: 16 years 2 months
Location: Switzerland

Re: Units in catalogue files

Post #66by ajtribick » 16.12.2009, 19:30

I've now committed this to the Subversion repository: no need to use the patch any longer.

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 6 months
Location: Hamburg, Germany

Re: Units in catalogue files

Post #67by t00fri » 16.12.2009, 20:15

ajtribick wrote:I've now committed this to the Subversion repository: no need to use the patch any longer.

Good!

Andrew, I understand that the old (unit-less) syntax of solarsys.ssc is compatible with your changes. Yet wouldn't it have been nice to reformat solarsys.ssc with the new default <units> ? This would e.g. be highly informative for newcomers, teaching them right away what those numbers mean with proper dimensions attached...

Fridger
Image

duds26
Posts: 328
Joined: 05.02.2007
Age: 29
With us: 12 years 8 months
Location: Europe

Re: Units in catalogue files

Post #68by duds26 » 18.12.2009, 15:45

Chuft-Captain wrote:
ajtribick wrote:Having read through this thread, I'm thinking the argument for prefix notation is somewhat better, especially regarding the points about long numbers, and also of the two notations

Code: Select all

SemiAxes<km> [ 2340 2100 2680 ]
SemiAxes [ 2340 2100 2680 ] <km>

The former seems neater to me. So will be going with that. Haven't heard anything back from anyone who's tried the latest version of the code yet...
Sorry, not in a position to compile at the moment. (I can barely even run Celestia at present!)
However, I'm completely in agreement with you with regards to the "per-property definition" (the former).

I do think it would be more consistent to call this a "per-property, postfix" notation. :)
ie. the units are actually appearing after the property name, rather than before the values (even though they're applied to the values).

Remember my previous post with the 4 permutations? :wink:

Just being really pedantic here! :lol:

CC


I would like to see the units positioned as close as possible to where the values are.
It's the most robust method, better readable when there are a lot of columns.
(It doesn't really matter for me if the unit is before or after the values, as long as it's positioned around the same place as the values.)

Here are four different examples of how I would want to see the positioning done, they are all equal for me:

Code: Select all


SemiAxes [ 2340<km> 2100<km> 2680<km> ]

SemiAxes [ <km>2340 <km>2100 <km>2680 ]

SemiAxes [ <km> ]

SemiAxes [ <km> <km> <km> ]
SemiAxes [ 2340 2100 2680 ]


Topic author
ajtribick
Posts: 1780
Joined: 11.08.2003
With us: 16 years 2 months
Location: Switzerland

Re: Units in catalogue files

Post #69by ajtribick » 18.12.2009, 19:54

duds26 wrote:

Code: Select all

SemiAxes [ 2340<km> 2100<km> 2680<km> ]
Why would you want this? It has unnecessary duplication of the units across the components of the vector. The most common case would be the same unit repeated across all components, which could not be concisely specified using this method. I still have not seen a compelling use case for being able to specify each length with different units.

For example, all of the following seem to me to be reasonable (to somewhat varying degrees) interpretations...

Code: Select all

SemiAxes [ 2340 2100<km> 2680 ]
= SemiAxes [ 2340<default> 2100<km> 2680<default> ] ?
= SemiAxes [ 2340<default> 2100<km> 2680<km> ] ?
= SemiAxes [ 2340<km> 2100<km> 2680<km> ] ?

And then what about

Code: Select all

LongLat [ 23 17 12<hRA> ]
= LongLat [ 23<default angle> 17<default length> 12<hRA> ] ?
= LongLat [ 23<default length> 17<default angle> 12<hRA> ] ?
= LongLat [ 23<hRA> 17<default length> 12<hRA> ] ?
= LongLat [ 23<default length> 17<hRA> 12<hRA> ] ?

As you see this is rapidly leading to increasing complexity!

The options where the SemiAxes property is specified twice strikes me as a bad option too: you've got a situation where an entry in the ssc file could represent a units declaration or a set of values, leads to unnecessary duplication of the property name, requires handling different syntax for units associated with tuples and scalar quantities.

In short, all these suggestions suffer from bloating the syntax for the most common use case and increasing the parser complexity in order to allow flexibility that would only be useful in a small minority of cases.

duds26
Posts: 328
Joined: 05.02.2007
Age: 29
With us: 12 years 8 months
Location: Europe

Re: Units in catalogue files

Post #70by duds26 » 20.12.2009, 17:51

For example, all of the following seem to me to be reasonable (to somewhat varying degrees) interpretations...

Code: Select all
SemiAxes [ 2340 2100<km> 2680 ]
= SemiAxes [ 2340<default> 2100<km> 2680<default> ] ?
= SemiAxes [ 2340<default> 2100<km> 2680<km> ] ?
= SemiAxes [ 2340<km> 2100<km> 2680<km> ] ?


And then what about

Code: Select all
LongLat [ 23 17 12<hRA> ]
= LongLat [ 23<default angle> 17<default length> 12<hRA> ] ?
= LongLat [ 23<default length> 17<default angle> 12<hRA> ] ?
= LongLat [ 23<hRA> 17<default length> 12<hRA> ] ?
= LongLat [ 23<default length> 17<hRA> 12<hRA> ] ?


As you see this is rapidly leading to increasing complexity!

Ho stop there, no varying interpretations.

Code: Select all

LongLat [ 23 17 12<hRA> ]
    = LongLat [ 23<default angle> 17<default length> 12<hRA> ]

SemiAxes [ 2340 2100<km> 2680 ]
    = SemiAxes [ 2340<default> 2100<km> 2680<default> ]


However, since there wouldn't be much point in using separate units per value, units could be placed like in one of these options:

Code: Select all

SemiAxes [ <km> 2340 2100 2680 ] Notice the space! between km and the first value

SemiAxes [ 2340 2100 2680 <km> ] << :)  notice the space between km and the last value

SemiAxes [ 2340 2100 2680 ] <km>

SemiAxes<km> [ 2340 2100 2680 ]


The options where the SemiAxes property is specified twice strikes me as a bad option too: you've got a situation where an entry in the ssc file could represent a units declaration or a set of values, leads to unnecessary duplication of the property name, requires handling different syntax for units associated with tuples and scalar quantities.

In short, all these suggestions suffer from bloating the syntax for the most common use case and increasing the parser complexity in order to allow flexibility that would only be useful in a small minority of cases.

I'm aware of that last one, it really is too much.
I was just trying to be somewhat complete.

duds26
Posts: 328
Joined: 05.02.2007
Age: 29
With us: 12 years 8 months
Location: Europe

Re: Units in catalogue files

Post #71by duds26 » 29.12.2009, 18:14

:idea:
Maybe the added flexibility can be achieved another way, with using the per-value properties and a default unit parameter.
Something like:

Code: Select all

SemiAxes<km><default><km> [ 2340 2100 2680 ]
// the first value is in km the second in whatever Celestia's default unit is and the third in km again.


Using the per property thing in this situation would be handy and doesn't suffer (that much) from the problems with my earlier attempts.

Maybe having a celestia default: <cel(estia)default> and a normal default: <default> would be handy.
The former would use the Celestia default values even if there are other units specified, the latter would take everything in account.

It's a pity the parser isn't already keeping track of language scope -- it's clearly more of a "property collector' than a language parser, however I don't think the effort and risk of making it more sophisticated is warranted for this single feature. There would have to be numerous other benefits to justify the extra work and risk.
Perhaps Chris will think of some. :lol:.
(Celestia 2) Something that is on the roadmap would be an addon redesign which is breaking backwards-compatibility.
Adding an addon organizer and doing an addon redesign would be something that could need this.


Return to “Ideas & News”

Who is online

Users browsing this forum: 15 guests