[ibis-macro] Re: About the Typos BIRD comments from Fangyi

  • From: Mike LaBonte <milabont@xxxxxxxxx>
  • To: Arpad Muranyi <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 06 Dec 2010 11:19:35 -0500

Arpad,

For reference, the complete BNF listing:

| <tree>:
| <branch>
|
| <branch>:
| ( <branch name> <leaf list> )
|
| <leaf list>:
| <branch>
| <leaf>
| <leaf list> <branch>
| <leaf list> <leaf>
|
| <leaf>:
| ( <parameter name> whitespace <value list> )
|
| <value list>:
| <value>
| <value list> whitespace <value>
| <value>:
| <string literals>
| <decimal number>
| <decimal number>e<exponent>
| <decimal number>E<exponent>
|

My proposal doesn¹t use the term ³leaf², but it uses ³sub-branch² which is
not in the BNF at all. Since all of the things I call sub-branches happen to
be leaves as defined by the BNF, I now see why you used the term ³leaves².
Yours is more consistent, but now I¹m not too keen on our BNF. I won¹t make
any argument about the BNF because it is functional and probably entrenched.

Usually leaves are just values, not branches without sub-branches, and that
threw me off. Your wording talks about the leaves that an AMI Parameter has,
then says it ³does not contain another branch². So you have to read the BNF
to understand that here, a leaf is a kind of branch. Could we use the term
³leaf branch²?

The only other question I had is about the handling of required, optional,
and ³one of these² categories. If you are trying to say that Description is
optional, Type and Usage are required, and one of Default, Format, or
<data_type> is required, then maybe ³any of the following leaves² might be
changed to ³one of the following leaves². Also the part about Description
might alternatively be worded ³An AMI Parameter branch may also contain a
Description leaf but no branches or leaves other than Type, Usage, Format,
<data_format>, or Description are permitted.²

Mike

On 12/6/10 10:14 AM, "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx> wrote:

> Mike,
>  
> Thanks for your comments.  The problem I see with the
> terminology you are suggesting is that it contradicts
> the BNF definition we have on pg. 187:
>  
> | <leaf>:
> | ( <parameter name> whitespace <value list> )
>  
> In order to use your terminology, we would have to change
> that too.
>  
> This suggestion makes me wonder what is the most widely
> used (or most familiar) meaning of ³leaf²?
>  
> Arpad
> ==========================================================
>  
>  
> 
> From: Mike LaBonte [mailto:milabont@xxxxxxxxx]
> Sent: Friday, December 03, 2010 1:59 PM
> To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
> Subject: Re: [ibis-macro] Re: About the Typos BIRD comments from Fangyi
>  
> Hmmm, re-reading these emails I think this is about what terminology to use
> for two different things:
> 
> 1) Terminology for the structure of generic LISP-like parenthetical trees.
> Often a branch is a sublist, and the first keyword inside the left paren is
> considered the name of the branch. Any other items after the branch name are
> leaves (aka branch values) unless they are inside their own parentheses. In
> this regard Description would be a branch name and the string following it
> would be a leaf/value.
> 
> 2) Special terminology to describe a 2-level bundle of branches and leafs as
> ³AMI parameters², where there is some datum surrounded by prescribed meta-data
> to help interpret it.
> 
> Therefore I think Arpad¹s latest wording is headed in the right direction to
> define #2 using the terminology of #1:
> 
> |*              A branch in the .ami file is an "AMI Parameter" if it
> |*              contains the leaves Type, Usage, and any of the following
> |*              leaves:
> |*
> |*                   Default
> |*                   <data_format> or Format <data_format>
> |*
> |*              and does not contain another branch.  A branch which
> |*              contains one or more sub-branches may only contain the
> |*              Description <string> leaf/value pair in addition to the
> |*              sub-branches.
> 
> But I would suggest changing it to:
> 
> |*              A branch in the .ami file is an "AMI Parameter" if it
> |*              contains the sub-branches Type, Usage, and any of the
> |*              following optional sub-branches:
> |*
> |*                   Default
> |*                   <data_format> or Format <data_format>
> |*                   Description
> |*
> |*              A branch with sub-branches arranged as an AMI Parameter may
> |*              not contain other sub-branches.
> 
> Mike
> 
> On 12/3/10 11:31 AM, "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx> wrote:
> Hello AMI Experts,
>  
> This thread stopped a day or so ago without reaching a conclusion.
> I am going to summarize the questions I would like to get answered.
>  
>  
> 1)  When does a branch become an ³AMI parameter²?  Does this have
> 
> to be spelled out in the IBIS-ATM specification, or does this belong
> to a Cookbook or HOWTO document?
>  
> Currently this is what I have in the Typos BIRD draft:
>  
> |*              A branch in the .ami file is an "AMI Parameter" if it
> |*              contains the leaves Type, Usage, and any of the following
> |*              leaves:
> |*
> |*                   Default
> |*                   <data_format> or Format <data_format>
> |*
> |*              and does not contain another branch.  A branch which
> |*              contains one or more sub-branches may only contain the
> |*              Description <string> leaf/value pair in addition to the
> |*              sub-branches.
>  
>  
> 2)  What is supposed to be passed into the AMI executable model in the
> 
> parameter string, and what is supposed to be omitted from this string?
> Does this have to be spelled out in the IBIS-ATM specification, or does
> this belong to a Cookbook or HOWTO document?
>  
> Currently this is what I have in the Typos BIRD draft:
>  
> ******************************************************************************
> **
> REMOVE THIS PARAGRAPH if the next few are agreed
> on:****************************
> |*              The tree data structure passed in and out of the DLL
> |*              described in section 3.1.2.6 of Section 10 of this document
> |*              is similar to the tree data structure in the .ami file except
> |*              the 'Reserved_Parameters' and 'Model_Specific' branch names
> are
> |*              not included, the "AMI Parameter" branches become leaves and
> |*              the ³AMI parameters² of Usage Info and Out are not included.
> END OF REMOVED 
> PARAGRAPH********************************************************
> ******************************************************************************
> **
> |*
> |*              The parameter string passed in and out of the DLL (described
> in
> |*              section 3.1.2.6 of Section 10 of this document) is formatted
> |*              the same way as the tree data structure in the .ami file with
> |*              the following exceptions:
> |*
> |*                1) The "Reserved_Parameters" and "Model_Specific" branch
> |*                   names are not included
> |*                2) None of the Description leaf/value pairs are included
> |*                3) AMI Parameter branches or sub branches with Usage Info
> |*                   or Usage Out are omitted, but all other branches or sub
> |*                   branches are included
> |*                4) AMI Parameter branches with Usage In or Usage InOut
> |*                   become leaves
> |*
>  
>  
> 3)      Define how/where the DLL returns Out or InOut parameters and
> 
> how/where the EDA tool is supposed to look for these values.  Does
> this have to be spelled out in the IBIS-ATM specification, or does
> this belong to a Cookbook or HOWTO document?
>  
> There is nothing on this topic in the Typos BIRD draft, nor can I
> find anything about this in the current IBIS specification.
>  
> Thanks,
>  
> Arpad
> ==============================================================================
> 
>

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2010