I have found the source of this inconsistency. In contrast to what is written below, it is not true that it "has always been the LRM intent" to disallow reals as associative array index types. 1800-2005 did not disallow them and the example in question is there, where it was not illegal. In fact, not everyone agreed that reals should be made illegal. See http://www.eda-stds.org/sv-ec/hm/2718.html, for example. Mantis 976 changed the LRM to make real index types illegal, but forgot to change the example. Since a conscious decision was made to disallow them and the ballot comment did not ask to change this, but just to make the example consistent with the text, the example should be changed. Regards, Shalom Shalom Bresticker Intel LAD DA Jerusalem, Israel +972 2 589 6582 (office) +972 54 721 1033 (cell) -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Arturo Salz Sent: Friday, April 24, 2009 9:04 PM To: Gordon Vreugdenhil; jonathan.bromley@doulos.com Cc: SV_BC List; sv-ec@eda.org Subject: RE: [sv-bc] Issue 41 - real in associative array You should include SV-EC in this discussion. For the record, I am in complete agreement with Jonathan. The actual ballot issue is trivially resolved by changing the example, which is evidently incorrect as it contradicts LRM verbiage that explicitly disallows real types as indices of associative arrays. That has always been the LRM intent and I see no reason to change it since IMHO it adds no value to users and does create the potential for surprises and confusion. At this point I would consider adding indices of type real to associative arrays as an enhancement that lies outside the ballot issue. Arturo -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil Sent: Friday, April 24, 2009 10:44 AM To: jonathan.bromley@doulos.com Cc: owner-sv-bc@eda.org; SV_BC List Subject: Re: [sv-bc] Issue 41 - real in associative array Jonathan, I completely agree with your point but not necessarily the conclusion. Anyone desiring to do what you are doing below would recode the example using something valid (a list of reals for example) and then use "==" and get into the same fundamental problem. Alternatively, they might just do $realtobits and use an associative array on the bit vectors (with the same issue again). Users can hurt themselves with reals -- if they care, I'd expect a user to create a "tolerance function" to normalize reals into representative values within some tolerance range and operate on those values. I don't see much point in arbitrarily restricting associative arrays of real in order to try to protect the user. Gord. jonathan.bromley@doulos.com wrote: >> I took a closer look at issue 41. The LRM certainly does >> intentionally restrict the existence of "real" in any >> component of an associative array index type. This is a >> bit odd since the general statement is simply that equality >> (and some internal ordering relation) is defined and certainly >> equality is defined for real. Personally I think that it makes >> more sense to drop the restriction than to modify the example >> but if there is any concern about dropping the restriction, >> then we should modify the example to be consistent with the >> normative text. > > Gord is clearly right to say that equality is defined for > reals, in the sense that there is an equality comparison > operator and it does something vaguely useful. However, > I am (as a matter of principle) uncomfortable about > any attempt to use reals to model or represent discrete > values; indeed, I would always regard testing reals for > equality as being fragile and untrustworthy. You just > KNOW that someone will complain when this doesn't do > what they expect: > > real thirty_degrees = $atan(1.0) * 2.0 / 3.0; > bit visited[real]; > visited[thirty_degrees] = 1; > assert (visited[$asin(0.5)]); > > So I would prefer to see the ballot feedback implemented > as-is by modifying the example to avoid the use of real. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Apr 27 01:04:17 2009
This archive was generated by hypermail 2.1.8 : Mon Apr 27 2009 - 01:05:12 PDT