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

The Mantis item number is 2681.

Shalom 


Shalom Bresticker
Intel LAD DA
Jerusalem, Israel
+972  2 589 6582 (office)
+972 54 721 1033 (cell)

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Stuart Sutherland
Sent: Monday, April 27, 2009 11:45 PM
To: 'SV_BC List'; sv-ec@server.eda.org
Subject: 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.

---------------------------------------------------------------------
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.