Arpad, I did notice a few other 'cosmetic' changes which could be attributed to the editorial committee. But a change like this should not have gone through without the ATM approval. It materially changes the meaning of the parameter. Thanks, Ambrish. ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, September 21, 2012 12:18 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: A question about "Value" Ambrish, I don't remember a BIRD for this text change, but the v5.1 specification has the text on pg. 177 I am asking about. I really don't know how this text was invented. Thanks, Arpad ============================================================ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma Sent: Friday, September 21, 2012 11:11 AM To: 'IBIS-ATM' Subject: [ibis-macro] Re: A question about "Value" Hi Arpad, I cannot locate when the text "The user may assign any value without any restrictions within the constraints of the Type of the variable" was introduced in the spec? The changes were invoked In BIRD 127.4 as reproduced below: On pg. 140 replace the following lines: | Format: (default is range) | Value <value> Single value data | Range <typ value> <min value> <max value> | List <typ value> <value> <value> <value> ... <value> with these lines: |* Format <data_format> <data>: |* |* Where Format is optional and <data_format> and <data> are required. |* <data_format> and <data> must be substituted with one of the following: |* Value <value> Single value data. Note that Value and Default |* (defined below) are mutually exclusive, and must not be used |* together for the same parameter. | Range <typ value> <min value> <max value> | List <typ value> <value> <value> <value> ... <value> So there must have been another BIRD to change the text. Can you or anyone else point me to that please? Thanks, Ambrish. ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d> On Behalf Of Muranyi, Arpad Sent: Friday, September 21, 2012 11:56 AM To: 'IBIS-ATM' Subject: [ibis-macro] A question about "Value" Hello, It was just brought to my attention that the IBIS v5.1 specification says the following on pg. 177: "Value <value> Single value data. The user may assign any value without any restrictions within the constraints of the Type of the variable." I remember asking a question in the ATM group a while ago about Value and Default. Parameters using these format types contain a single value in the .ami file, and the question I asked was whether the EDA tool should display these types of parameters in a GUI dialog and allow the user to change them or not. If I remember correctly, the answer was that for these types of parameters the model maker knew what the value should be and the reason they picked Value or Default as opposed to Range or List is because they only had one possible value in mind for the model. Therefore the EDA tool should not allow these parameter values to be changed by the tool user. However, reading the above sentence in IBIS v5.1 gives me the impression that the tool user should be allowed to make changes for these types of parameters, and consequently the EDA tool should provide an editable field for these parameters for the user. Was this written this way intentionally? Or is this sentence worded incorrectly? If the latter, I think we need to write a BIRD to correct it... But here comes a complication. If we intend to allow the user to edit these types of parameters, then what should we do with AMI_Version? AMI_Version is a Usage Info, Format Value parameter which should really not be edited by anyone, but according to the definition of "Value", the user of the model is allowed to change it to any legal value. I know AMI_Version currently can only have one value "5.1", but later we will have other possible IBIS version values, and this rule might cause problems. There might be other parameters which fall into a similar situation regarding this rule. Thanks, Arpad =========================================================================