[ibis-macro] Re: Comment on Labels BIRD, and need to ammend the Definitions BIRD re "

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 6 Sep 2010 21:10:20 -0700

Walter,

As far as I can tell, the people at the ATM teleconference
voted to have double quotes around strings.  There were no
unanswered questions about the intent of the author(s) about
this.  The decision was made, and I would not resurrect any
BIRD-s on the string discussion.  We simply didn't think that
some of the examples may need to be corrected according to
this definition of the string.  So if we do any amendments,
we should correct the string examples to be in agreement with
the definitions BIRD.

Regarding Bob's comment, I wouldn't write it off so fast.  I
agree that we should strive for consistency and simplicity.
I am not sure that I fully understand everything Bob wrote
yet, but I just looked at Table and List, and they are indeed
inconsistent.  Why couldn't we treat List as a one row Table,
and use the same syntax for both?

Arpad
==============================================================

-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Saturday, September 04, 2010 8:12 AM
To: bob@xxxxxxxxxxxxx; Muranyi, Arpad
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Comment on Labels BIRD, and need to ammend
the Definitions BIRD re "

Bob,

Thanks for making me look at how Table (and Labels) where defined in
IBIS
5.0)

|                   (Format Table
|                     (Labels Row_No Time_UI Density)
|                     (-50 -0.1 1e-35)
|                     (-49 -0.98 2e-35)
|                     ...
|                     (0 0 1e-2)
|                     ...
|                     (49 0.98 2e-35)
|                     (50 0.1 1e-35)
|                   ) | End Table

And it is clear to me that the values of Lables are strings that are not
surrounded by ".

This is clearly an example of the intentions of the developers of this
language in the original spec of how string tokens without impeded
blanks
should be treated in the parser - that " would be optional in this case.
Since we are not deprecating Table then we must support it and how
strings
are handled in general. So I will be resurrecting my Sring Quating BIRD
as
an amendment to Arpad's definitions BIRD.

As far as Bob's other comment, Bob continues to make something that is
quite
simple quite complicated. I think the use of Labels in the context of
Table
parameters is quite clear - and I think that Lables in the context of
List
parameters is quite clear.

Walter

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Saturday, September 04, 2010 2:08 AM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: Comment on Labels BIRD

Arpad:

We need to address the Labels rules for both List and Table at
the same time.

The rules look almost identical and yet there appear to be
some significant differences.

List:

One of the leaves of the of branch containing this List can be named
"Labels" and, if provided, is to be assigned a string value
containing a list of List entry names.

Table:

The parameter name "Table" names a branch of the parameter tree
rather than a single leaf.
One of the leaves of the of the parameter containing this branch
can be named "Labels" and, if provided, is to be assigned a string value
containing a list of column names.

-----------------

Several problems:

   "Format Table" is a special name for a branch as shown in the
   examples on pages 141, 146, 147?

   Labels is always a special case leaf of a branch with a special
   syntax (plus some possible number of argument rules):

       (Label <string> <string> ... <string>)

   "Format List" is permitted for Model_Specific parameters.
   Since List is not listed as valid for any Reserved Parameter,
   Labels for List would never appear in the Reserved_Parameters
   block.

   The Model_Specific format needs to be extended to allow a Labels
   with just the string entries only when List is used.  A leaf
   syntax is not given in for Model_Specific cases.

     (parameter_name (Usage <usage>) (Type <data_type>)
     (Format <data format>) (Default <values>)
     (Description <string>))

      add?

     (parameter_name (Usage <usage>) (Type <data_type>)
     (Format <list format>) (Default <values>) (Labels <sring> ...)
     (Description <string>))


   We have not even mentioned tree or branch or leaf yet, and this
   is critical to the rules (to be fixed by re-organization).

   For consistency, Labels could follow the same rules for Table
   and be a leaf of List.  For example.

    (Process (Usage In) (Type Integer) (Usage In)
    (Format List (Labels "a" "b" "c") 1 2 3)
    (Description "your description"))

   or

    (Process (Usage In) (Type Integer) (Usage In)
    (Format List 1 2 3 (Labels "a" "b" "c"))  | any order??
    (Description "your description"))

   or be in any other position within the list.

   For Table, the corresponding example is:

    (Multi-process (Usage In) (Type Integer) (Usage In)
    (Format Table
    (Labels  "a" "b" "c") | It is not stated that Labels
                          | must be first
                          | Also the <string> arguments do not
                          | have quotes in Section 6c.
    (1 2 3) (2 3 4) (3 4 5))
    (Description "your description"))

---------------------

The whole point is that we are introducing an inconsistency.
We need to document all of this fully and clearly. This means
dealing with Table at the same time.

Bob


Muranyi, Arpad wrote:
> Walter,
> 
> I have one request for the Labels BIRD.  Please
> use the example you show in the Statement of the
> Issue section as an example that is added to the
> specification itself.  I searched the current spec
> for any examples with List and I couldn't find a
> single one.  It would be nice to illustrate this
> concept in the spec with an example...
> 
> Also, please add the title:
> 
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
> 
> to the section that begins with
> 
> "Replace this text:"
> 
> Thanks,
> 
> Arpad
> ===================================================
> ---------------------------------------------------------------------
> IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
> IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
> To unsubscribe send an email:
>   To: ibis-macro-request@xxxxxxxxxxxxx
>   Subject: unsubscribe
> 
> 


-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
401-284-1827                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@xxxxxxxxxxxxx

Teraspeed is a registered service mark of Teraspeed Consulting Group LLC

---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe


---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts: