[ibis-editorial] Re: Typ value confusion...
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <ibis-editorial@xxxxxxxxxxxxx>
- Date: Mon, 5 Mar 2012 15:04:09 -0800
Arpad:
Your cases below are the same with (Default 5).
Default is optional, and the we intentionally defined
the first List entry as the <typ> entry in the official V5.0.
Therefore the coverage is complete in your four
examples, but the defaults are 4, 1, 1, 2. without (Default 5)
One equivalent case you left out that must be supported is
the case that automatically sets the default to 5:
(List 5 4 2 1 3 6)
I agree that repeated values are meaningless and
probably represent a mistake. Furthermore, purposely
repeating an entry serves no purpose unless the committee
officially creates a reason - such as allowing this interpretation
(List 5 1 2 3 4 5 6 7 8 9)
| \----------------/
| this thing being
| the "list"
In case someone read the minimal V5.0 specification and
chose the above interpretation, as Michael questioned,
we could allow this with a future Warning or Caution message.
However, I would favor the interpretation and approach.
1. Distinct entries (recommendation)
2. The first remains the <typ> entry for consistency
3. Default is optional and can be used to select one of
the members of the set (including the <typ> value).
4. At least two entries are needed.
I would favor making distinct entries as a recommendation, not
a checkable requirement. Later it could be a Warning or
Caution check. This simplifies the parser rules and
test cases.
Otherwise, we require compares and pass and fail test cases
for all these cases and more:
Float (including Integers) (how close, compiler bit variations?)
Integers
UI (float)
Tap (float)
Boolean - do we flag a List of more than two/three entries?
String (quoted string includes white space which can be spaces, CR, CR/LF,
LF, Tabs, etc. and possible differences for Windows, Linux)
Maybe we would allow one match with the first <typ> entry.
So that is why I want it as a recommendation at this time so we do
not get bogged down now on pathological cases for situations
unlikely to occur.
Bob
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 05, 2012 11:47 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Bob,
Your "third" example, is really the same as my first example,
except that the values are in "random order". The point
in both your 3rd and my 1st examples is that the first value
in the list is part of the list, not a separate "typ" value
which repeats one of the entries from the list (just as
"Default" does).
You are making an interesting point about "typ" being required
and the rest not being required. But having a list of size
one makes no sense, because in that case the model maker should
use the "Value" or "Default" format types.
I would also challenge the idea of having repeated values in
the list, because there is no reason for that. What is the
difference between these examples:
(List 4 2 5 3 6 4 1)
(List 1 4 2 5 3 6 4)
(List 1 4 2 5 3 6)
(List 2 5 3 6 4 1)
if they all have a (Default 5), for example? The repeated values
in the first two examples are just there for no other reason but
to create confusion. I think they should not be allowed.
Thanks,
Arpad
====================================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Monday, March 05, 2012 1:33 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Arpad:
The statement
"As far as I understand, we never had the second example
on our mind."
may be partially true. We clearly had the first entry as the typ value, but
we never stated one way or the other whether it also had to be one of
the value entries. The third choice would have been my interpretation::
(List 5 1 2 3 4 6 7 8 9)
\----------------/
this entire thing
being the "list" with 5 as default and
5 not included in the 1 ... 9 sequence.
The official V5.0 rules are.
| Format: (default is range)
| Value <value> Single value data
| Range <typ value> <min value> <max value>
| List <typ value> <value> <value> <value> ... <value>
| Corner <typ value> <slow value> <fast value>
| Increment <typ> <min> <max> <delta>
| After expansion, the allowed values of the parameter are
| typ+N*delta where N is any positive or negative integer
| value such that: min <= typ + N*delta <= max
| Steps <typ> <min> <max> <# steps>
| Treat exactly like Increment with
| <delta> == (<max>-<min>)/<# steps>
Consistent throughout IBIS, a "typ" value is always specified.
Because we never stated any rules, my recommendation is to support all
cases and let the tool work out what to use and how to process the List.
There is no stated or implied processing order. There is no harm if
duplicates
are shown or removed, or if the list is re-ordered by the EDA interface.
We are supporting both batch processing or user selection.
However, we can suggest, but not require - typical value first, and 0 or
more
remaining values follow.
Bob
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 05, 2012 10:00 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Bob,
Mike was asking the question whether a list looks like this:
(List 1 2 3 4 5 6 7 8 9)
\----------------/
this entire thing
being the "list"
or:
(List 5 1 2 3 4 5 6 7 8 9)
| \----------------/
| this thing being
| the "list"
|
\ this being a value repeated from the list
to indicate which value in the list is to
be considered as the typical value
As far as I understand, we never had the second example
on our mind. It is just an unfortunate misnomer to call
the first value in the list "typical", because the word
can have a misleading interpretation as shown in the 2nd
example.
Thanks,
Arpad
=========================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Friday, March 02, 2012 9:12 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Arpad:
(I was mostly focused on the optional Default and not focused
too closely on the duplicate entries or giving the full list after <typ>
But Typ is part of the required syntax in case no selection is made.)
There are no rules to the contrary that exclude any of the
cases nor exclude repeated entries nor a requirement of
more than one entry (though at least two entries could be implied
if an element beyond <typ> is required, whether or not it is the
same as <typ>.
All the EDA tool has to do is use the <typ> if no choice is
made (or Default is not given) and make available at least once
all of the distinct choices. For List, the Default must be one
of the selections.
There is no problem if the choices are repeated or if duplicates
are screened out, if sorted or if ordered exactly as in the (List ..)
parameter, or if there is only one entry or choice.
-----
However, this is a good point. If we need rules, we
then should write a BIRD that at least states a style recommendation.
But we need to cover all Types (integers, float, string, UI(float),
Tap(float)
and Boolean cases etc. If we introduce specific requirements, then we
have several more rules and cases to check.
As long as all choices are available (whether provided once or with
duplicates) or in any order, there should not be any problem.
This is a tool processing issue. So that is why I consider all choices
below legal.
Bob
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 4:37 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Bob,
"All cases 4 below are correct for List. "
How could they be?
Arpad
===============================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Friday, March 02, 2012 6:09 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Michael:
Good questions and many more should follow.
So, I would hold off starting to write explanations until we
have the organization nailed down. Your general question also
applies to Corner, Range, Increment, Step and maybe something
else. There are different rules and limits for Default values for each
case as to what a member of the class may mean and the limits.
All cases 4 below are correct for List. For List repeats are required,
so a new "unlisted value" (Default E) would be flagged as an error.
Bob
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 4:01 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
We can discuss that in the next editorial meeting.
Thanks,
Arpad
====================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, March 02, 2012 5:48 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Arpad,
Thanks. If this is the consensus answer, we'll need to add some explanatory
text plus edit out the <typ value> mention in the List syntax definition.
The new text would state exactly what you did: if Default is not present for
a List, the first item in the list is assumed the Default value.
- MM
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 3:45 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...
Mike,
The list is just a list of A, B, C, D, where "A" is the first
item in the list.
If Default is not defined, the first item will be used from the
list. I don't know why the name "typ" was given to this first
item, but that is just a bad naming convention (probably coming
from the Range, or Increment types).
Does this answer your question?
Thanks,
Arpad
================================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, March 02, 2012 5:37 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Typ value confusion...
(this may require cross-posting to ibis-macro)
In reviewing Section 10A in the draft 5.1 document, I have a question about
the "typ value" of a Model Specific parameter: for List, etc., must one list
a *duplicate* value for the typ value? In other words, are repeats
required?
This should not be affected by the presence of "Default" (though "Default"
makes it confusing).
Here's an example in four variations. Which is correct? My own vote is for
(1) and (4) being correct. However, we only say that the Default value has
to be a member of the list, *not* that the typ value has to be a member of
the list! ("Also, if Default is specified, <value> must be a member of the
set of allowed values of the parameter. If Default is not specified, the
default value of the parameters will be the <typ> value.")
1)
(Informative_String (Usage In)(List B A B C D)(Type String)(Default B)
(Description "This is an example with a repeated item, because the
first in the list should be the Typ Value"))
2)
(Informative_String (Usage In)(List A B C D)(Type String)(Default B)
(Description "This is an example without a repeated item, because the
first in the list shouldn't have to be the Typ Value, as I have a Default
declared; but I risk declaring a typ that isn't actually in my list, if the
typ is A and the list consists only of B, C and D"))
3)
(Informative_String (Usage In)(List A B C D)(Type String)
(Description "This is an example without a repeated item, and without
a Default, I risk declaring a typ that isn't actually in my list, if the typ
is A and the list consists only of B, C and D"))
4)
(Informative_String (Usage In)(List B A B C D)(Type String)
(Description "This is an example with a repeated item, and without a
Default; this technically matches the spirit and letter of the 5.1 law"))
- MM
Other related posts:
