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.