RE: [sv-ec] RE: [sv-bc] Issue 41 - real in associative array

I'm not sure which committee now owns Mantis 2861 (ballot comment 41), but I
have uploaded a proposal to correct the example in 7.9.5, per the request of
the balloter and per Arturo's comment, below.  I have also searched Clause 7
to make sure the example was not referenced elsewhere in the clause, and it
is not.

Mantis 2681 should be ready for an e-mail vote.

Stu
~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
(503) 692-0898


> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo
> Salz
> Sent: Friday, April 24, 2009 11:04 AM
> To: Gordon Vreugdenhil; jonathan.bromley@doulos.com
> Cc: SV_BC List; sv-ec@eda.org
> Subject: [sv-ec] 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.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.