I suggest that both the sv-ec and the sv-bc vote on the proposal. Neil On 04/27/09 13:44, Stuart Sutherland wrote: > 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.Received on Mon Apr 27 15:31:20 2009
This archive was generated by hypermail 2.1.8 : Mon Apr 27 2009 - 15:32:02 PDT