[Gmat-developers] Start on object map document

[Steven Hughes]

Darrel,

I've read through the doc once, and probably need a second reading. So
far I prefer method 3.2. But, here's a few questions I have so far:

1) How does a function manage its LOS in the case that it calls itself, or if it calls a function that in turn calls it back?

In the case of recursion, what about having a list or tree (not sure of the best term here) of LOSs' for each nested/recursive call made to a function. So using your example, if CalculatePropTime was called recursively (not sure why this would happen, just need a simple example), then the LOS may look like this

* Call from MainSequence
o XYPlot: plot
o Variable: startEpoch, endEpoch, j
* Call from CalculatePropTime
o XYPlot: plot
o Variable: startEpoch, endEpoch, j
* Call from CalculatePropTime
o XYPlot: plot
o Variable: startEpoch, endEpoch, j
* Last Call to CalculatePropTime
o XYPlot: plot
o Variable: startEpoch, endEpoch, j

At the last recursive call to CalculatePropTime, you would begin
traversing the tree in reverse. It seems that if we support recursion
or some types of nested functions calls, then something like this is
unavoidable. Is this true, and is there a design issue or conflict with
this approach??

2) I can see eventually using something like an Include command to load
a library of useful GMAT functions. If we create a LOS for every
function,during the build process, this means that a lot of memory and
time could be consumed setting up the LOS for functions that may not be
used. Why can't the LOS for functions be created as the mission sequence
is run and a function is called?

Steve

The attached document shows the object map options I'm thinking
through for Functions. I only have one test case in it so far; I'll
add a second and maybe a third tomorrow, and fill out the table at the
end.
Just thought you might want to see the pieces I'm thinking about. The
current example favors the "semilocal" approach, but it's only one
data point, and other examples won't be as generous to that approach,
I think.
(Yeah, it's 10 pages, but mostly faked up scripting and definitions.)

[Steven Hughes]

Darrel,

I've read through the doc once, and probably need a second reading. So
far I prefer method 3.2. But, here's a few questions I have so far:

1) How does a function manage its LOS in the case that it calls itself,
or if it calls a function that in turn calls it back?

In the case of recursion, what about having a list or tree (not sure of
the best term here) of LOSs' for each nested/recursive call made to a
function. So using your example, if CalculatePropTime was called
recursively (not sure why this would happen, just need a simple
example), then the LOS may look like this

Call from MainSequence
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Last Call to CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j

At the last recursive call to CalculatePropTime, you would begin
traversing the tree in reverse. It seems that if we support recursion
or some types of nested functions calls, then something like this is
unavoidable. Is this true, and is there a design issue or conflict with
this approach??

2) I can see eventually using something like an Include command to load
a library of useful GMAT functions. If we create a LOS for every
function,during the build process, this means that a lot of memory and
time could be consumed setting up the LOS for functions that may not be
used. Why can't the LOS for functions be created as the mission sequence
is run and a function is called?

Steve

The attached document shows the object map options I'm thinking
through for Functions. I only have one test case in it so far; I'll
add a second and maybe a third tomorrow, and fill out the table at the
end.
Just thought you might want to see the pieces I'm thinking about. The
current example favors the "semilocal" approach, but it's only one
data point, and other examples won't be as generous to that approach,
I think.
(Yeah, it's 10 pages, but mostly faked up scripting and definitions.)

[Darrel J. Conway]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I think I mentioned (on the phone?&nbsp; Not sure exactly where at the
moment.) that I wanted to be sure I understood and we reached agreement
on the strategy for handling global and local references for functions
before tacking issues with recursion.&nbsp; But since you bring it up again,
I think we want to be slightly more elegant here.&nbsp; Or maybe I'm saying
the same thing you are here, using a language I understand better.<br>
<br>
Basically what we need is a "last-in, first-out" storage mechanism for
the LOS data.&nbsp; The STL provides a mechanism for this type of stack in
the deque template.&nbsp; I'm thinking that we'll basically have a deque of
Local Object Store (note to new readers of this thread -- that's what
LOS stands for) containers that we'll use when a function is called.&nbsp;
That way we don't need to know the depth of the recursion when the
script gets parsed and built.&nbsp; Crudely speaking, each call into the
function pushes a copy of the LOS onto the deque, and each return pops
it back off.&nbsp; There's a bit of design that I'll need to do to get this
written up to work more smoothly, of course.&nbsp; So far I've been putting
that off until I have the LOS a bit better defined, but we'll
definitely need something like that to handle recursion.<br>
<br>
- Darrel<br>
<br>
Steven Hughes wrote:
<blockquote cite="mid:***@nasa.gov" type="cite">Darrel,
<br>
<br>
I've read through the doc once, and probably need a second reading. So
<br>
far I prefer method 3.2. But, here's a few questions I have so far:
<br>
<br>
1) How does a function manage its LOS in the case that it calls itself,
or if it calls a function that in turn calls it back?
<br>
<br>
In the case of recursion, what about having a list or tree (not sure of
the best term here) of LOSs' for each nested/recursive call made to a
function.&nbsp; So using your example, if CalculatePropTime was called
recursively (not sure why this would happen, just need a simple
example), then the LOS may look like this
<br>
<br>
Call from MainSequence
<br>
&nbsp;&nbsp;&nbsp; XYPlot: plot
<br>
&nbsp;&nbsp;&nbsp; Variable:&nbsp; startEpoch, endEpoch, j
<br>
Call from CalculatePropTime
<br>
&nbsp;&nbsp;&nbsp; XYPlot: plot
<br>
&nbsp;&nbsp;&nbsp; Variable:&nbsp; startEpoch, endEpoch, j
<br>
Call from CalculatePropTime
<br>
&nbsp;&nbsp;&nbsp; XYPlot: plot
<br>
&nbsp;&nbsp;&nbsp; Variable:&nbsp; startEpoch, endEpoch, j
<br>
Last Call to CalculatePropTime
<br>
&nbsp;&nbsp;&nbsp; XYPlot: plot
<br>
&nbsp;&nbsp;&nbsp; Variable:&nbsp; startEpoch, endEpoch, j
<br>
<br>
At the last recursive call to CalculatePropTime, you would begin
<br>
traversing the tree in reverse.&nbsp; It seems that if we support recursion
<br>
or some types of nested functions calls, then something like this is
<br>
unavoidable.&nbsp; Is this true, and is there a design issue or conflict
with
<br>
this approach??
<br>
<br>
2) I can see eventually using something like an Include command to load
<br>
a library of useful GMAT functions. If we create a LOS for every
<br>
function,during the build process, this means that a lot of memory and
<br>
time could be consumed setting up the LOS for functions that may not be
<br>
used. Why can't the LOS for functions be created as the mission
sequence
<br>
is run and a function is called?
<br>
<br>
Steve
<br>
<br>
<br>
<br>
Darrel J. Conway wrote:
<br>
<blockquote type="cite">The attached document shows the object map
options I'm thinking through for Functions.&nbsp; I only have one test case
in it so far; I'll add a second and maybe a third tomorrow, and fill
out the table at the end.
<br>
<br>
Just thought you might want to see the pieces I'm thinking about.&nbsp; The
current example favors the "semilocal" approach, but it's only one data
point, and other examples won't be as generous to that approach, I
think.
<br>
<br>
(Yeah, it's 10 pages, but mostly faked up scripting and definitions.)
<br>
<br>
</blockquote>
<br>
<br>
<pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now &gt;&gt; <a class="moz-txt-link-freetext" href="http://get.splunk.com/">http://get.splunk.com/</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Gmat-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gmat-***@lists.sourceforge.net">Gmat-***@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gmat-developers">https://lists.sourceforge.net/lists/listinfo/gmat-developers</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-----------------------------------------------------------------------------------------------------
GMAT Architectural Design, Linux Development and Test Team

Darrel J. Conway, Ph.D. Thinking Systems, Inc.
Senior Scientist and CEO 6441 N Camino Libby
Phone: [phone] Tucson, AZ 85718
FAX: [phone] <a class="moz-txt-link-abbreviated" href="http://www.thinksysinc.com">www.thinksysinc.com</a>
djc_at_thinksysinc_dot_com
-----------------------------------------------------------------------------------------------------
</pre>
</body>
</html>

[Darrel J. Conway]

(Reposted in plain-text. Sorry about the HTML; I'll hide that version
on SourceForge)

I think I mentioned (on the phone? Not sure exactly where at the
moment.) that I wanted to be sure I understood and we reached agreement
on the strategy for handling global and local references for functions
before tacking issues with recursion. But since you bring it up again,
I think we want to be slightly more elegant here. Or maybe I'm saying
the same thing you are here, using a language I understand better.

Basically what we need is a "last-in, first-out" storage mechanism for
the LOS data. The STL provides a mechanism for this type of stack in
the deque template. I'm thinking that we'll basically have a deque of
Local Object Store (note to new readers of this thread -- that's what
LOS stands for) containers that we'll use when a function is called.
That way we don't need to know the depth of the recursion when the
script gets parsed and built. Crudely speaking, each call into the
function pushes a copy of the LOS onto the deque, and each return pops
it back off. There's a bit of design that I'll need to do to get this
written up to work more smoothly, of course. So far I've been putting
that off until I have the LOS a bit better defined, but we'll definitely
need something like that to handle recursion.

- Darrel

Post by Steven Hughes
Darrel,
I've read through the doc once, and probably need a second reading. So
1) How does a function manage its LOS in the case that it calls
itself, or if it calls a function that in turn calls it back?
In the case of recursion, what about having a list or tree (not sure
of the best term here) of LOSs' for each nested/recursive call made to
a function. So using your example, if CalculatePropTime was called
recursively (not sure why this would happen, just need a simple
example), then the LOS may look like this
Call from MainSequence
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Last Call to CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
At the last recursive call to CalculatePropTime, you would begin
traversing the tree in reverse. It seems that if we support recursion
or some types of nested functions calls, then something like this is
unavoidable. Is this true, and is there a design issue or conflict with
this approach??
2) I can see eventually using something like an Include command to load
a library of useful GMAT functions. If we create a LOS for every
function,during the build process, this means that a lot of memory and
time could be consumed setting up the LOS for functions that may not be
used. Why can't the LOS for functions be created as the mission sequence
is run and a function is called?
Steve

The attached document shows the object map options I'm thinking
through for Functions. I only have one test case in it so far; I'll
add a second and maybe a third tomorrow, and fill out the table at
the end.
Just thought you might want to see the pieces I'm thinking about.
The current example favors the "semilocal" approach, but it's only
one data point, and other examples won't be as generous to that
approach, I think.
(Yeah, it's 10 pages, but mostly faked up scripting and definitions.)

------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
------------------------------------------------------------------------
_______________________________________________
Gmat-developers mailing list
https://lists.sourceforge.net/lists/listinfo/gmat-developers

--
-----------------------------------------------------------------------------------------------------
GMAT Architectural Design, Linux Development and Test Team

Darrel J. Conway, Ph.D. Thinking Systems, Inc.
Senior Scientist and CEO 6441 N Camino Libby
Phone: [phone] Tucson, AZ 85718
FAX: [phone] www.thinksysinc.com
djc_at_thinksysinc_dot_com
-----------------------------------------------------------------------------------------------------

[Steven Hughes]

Post by Darrel J. Conway
(Reposted in plain-text. Sorry about the HTML; I'll hide that version
on SourceForge)
I think I mentioned (on the phone? Not sure exactly where at the
moment.) that I wanted to be sure I understood and we reached
agreement on the strategy for handling global and local references for
functions before tacking issues with recursion.

As far as I can tell, everyone who has an opinion has agreed 3.2 is the
best approach.

Post by Darrel J. Conway
But since you bring it up again, I think we want to be slightly more
elegant here. Or maybe I'm saying the same thing you are here, using
a language I understand better.
Basically what we need is a "last-in, first-out" storage mechanism for
the LOS data. The STL provides a mechanism for this type of stack in
the deque template. I'm thinking that we'll basically have a deque of
Local Object Store (note to new readers of this thread -- that's what
LOS stands for) containers that we'll use when a function is called.
That way we don't need to know the depth of the recursion when the
script gets parsed and built. Crudely speaking, each call into the
function pushes a copy of the LOS onto the deque, and each return pops
it back off. There's a bit of design that I'll need to do to get this
written up to work more smoothly, of course. So far I've been putting
that off until I have the LOS a bit better defined, but we'll
definitely need something like that to handle recursion.
- Darrel

Post by Steven Hughes
Darrel,
I've read through the doc once, and probably need a second reading. So
1) How does a function manage its LOS in the case that it calls
itself, or if it calls a function that in turn calls it back?
In the case of recursion, what about having a list or tree (not sure
of the best term here) of LOSs' for each nested/recursive call made
to a function. So using your example, if CalculatePropTime was
called recursively (not sure why this would happen, just need a
simple example), then the LOS may look like this
Call from MainSequence
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Call from CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
Last Call to CalculatePropTime
XYPlot: plot
Variable: startEpoch, endEpoch, j
At the last recursive call to CalculatePropTime, you would begin
traversing the tree in reverse. It seems that if we support recursion
or some types of nested functions calls, then something like this is
unavoidable. Is this true, and is there a design issue or conflict with
this approach??
2) I can see eventually using something like an Include command to load
a library of useful GMAT functions. If we create a LOS for every
function,during the build process, this means that a lot of memory and
time could be consumed setting up the LOS for functions that may not be
used. Why can't the LOS for functions be created as the mission sequence
is run and a function is called?
Steve

The attached document shows the object map options I'm thinking
through for Functions. I only have one test case in it so far; I'll
add a second and maybe a third tomorrow, and fill out the table at
the end.
Just thought you might want to see the pieces I'm thinking about.
The current example favors the "semilocal" approach, but it's only
one data point, and other examples won't be as generous to that
approach, I think.
(Yeah, it's 10 pages, but mostly faked up scripting and definitions.)

------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
------------------------------------------------------------------------
_______________________________________________
Gmat-developers mailing list
https://lists.sourceforge.net/lists/listinfo/gmat-developers

[Edwin Dove]

Great job on the examples in the "Function Call Samples and Discussion"
document Darrel. Things are much clearer now.

Since this discussion is in the public domain we should make those
brainstorm documents available somehow, otherwise a lot of our email
conversation is cryptic to others.

I prefer approach 3.2, Local Objects with Select Global Objects. Approach
3.3 is interesting and seems promising but it would get complicated for the
user to know the hierarchal relationship between functions once the number
of functions increases.

Edwin Dove
Aerospace Engineer
Flight Dynamics Analysis Branch (595)
NASA Goddard Space Flight Center
Phone: [phone]

[Darrel J. Conway]

Steve added the document as an attachment to one of the messages in this
thread. It would be nice if SourceForge could give a clue about which
one -- I just looked, and didn't see anything obvious. I'd also like
the requirements document to be public, but don't know if you guys have
internal issues with releasing it that way.

- Darrel

Post by Edwin Dove
Great job on the examples in the "Function Call Samples and Discussion"
document Darrel. Things are much clearer now.
Since this discussion is in the public domain we should make those
brainstorm documents available somehow, otherwise a lot of our email
conversation is cryptic to others.
I prefer approach 3.2, Local Objects with Select Global Objects. Approach
3.3 is interesting and seems promising but it would get complicated for the
user to know the hierarchal relationship between functions once the number
of functions increases.
Edwin Dove
Aerospace Engineer
Flight Dynamics Analysis Branch (595)
NASA Goddard Space Flight Center
Phone: [phone]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gmat-developers mailing list
https://lists.sourceforge.net/lists/listinfo/gmat-developers

--
-----------------------------------------------------------------------------------------------------
GMAT Architectural Design, Linux Development and Test Team

Darrel J. Conway, Ph.D. Thinking Systems, Inc.
Senior Scientist and CEO 6441 N Camino Libby
Phone: [phone] Tucson, AZ 85718
FAX: [phone] www.thinksysinc.com
djc_at_thinksysinc_dot_com
-----------------------------------------------------------------------------------------------------