RE: [sv-bc] RE: Mantis 1523

I prefer "If the elements have the same value" to the current "If the elements match".

Shalom

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Thursday, August 25, 2011 2:09 AM
> To: Arturo Salz
> Cc: Steven Sharp; Bresticker, Shalom; SV-BC
> Subject: Re: [sv-bc] RE: Mantis 1523
>
>
> But the element types might need case equality to get
> the right behavior -- a struct containing logics needs to
> do case equality on the logic elements. There really
> is no well defined term for "the element wise values
> are all exactly the same" but that is definitely the intent.
>
> Gord
>
> On 8/24/2011 3:22 PM, Arturo Salz wrote:
> > Good point. I don't believe case equality is warranted since that sentence
> defines the semantics precisely for the types that cannot be resolved - and
> do not support case equality.
> >
> > Arturo
> >
> > -----Original Message-----
> > From: Steven Sharp [mailto:sharp@cadence.com]
> > Sent: Wednesday, August 24, 2011 3:17 PM
> > To: Arturo Salz; Bresticker, Shalom; SV-BC
> > Subject: RE: Mantis 1523
> >
> > Agreed.
> >
> > One possible problem with talking about the elements being equal is that
> there are multiple equality operators in SV. Does "equal" mean logical
> equality or case equality? This may not be a real problem if case equality
> doesn't apply to any of the operand types being described here.
> >
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Arturo
> Salz
> > Sent: Wednesday, August 24, 2011 5:50 PM
> > To: Bresticker, Shalom; SV-BC
> > Subject: [sv-bc] RE: Mantis 1523
> >
> > Shalom,
> >
> > That particular sentence defined the semantics of the ternary operator
> when it needs to merge two objects of non-integral data-type, such as real
> or string. Since in those cases performing a bit-wise resolution is not
> possible (or well defined), the LRM calls for comparing the two elements
> (using equality) and return the default-uninitialized value if they do not
> "match". Possibly a better language would be "if the elements are not
> equal".
> >
> > Arturo
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> > Sent: Wednesday, August 24, 2011 1:58 PM
> > To: SV-BC
> > Subject: [sv-bc] Mantis 1523
> >
> > Hi,
> >
> > Does anyone have an answer to my question below?
> >
> > Thanks,
> > Shalom
> >
> >> -----Original Message-----
> >> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> >> Bresticker, Shalom
> >> Sent: Sunday, August 21, 2011 11:59 AM
> >> To: Maidment, Matthew R; SV-BC
> >> Subject: [sv-bc] RE: email vote: respond by Monday Aug 29
> >>
> >> Re 1523,
> >>
> >> the last paragraph, which is not being changed by this proposal, says,
> >>
> >> "For nonintegral and aggregate expressions, if cond_predicate evaluates
> to
> >> an ambiguous value, then:
> >> ..
> >> - Otherwise, both the first expression and second expression shall be
> >> evaluated, and their results shall be combined element by element. If the
> >> elements match, the element is returned. If they do not match, then the
> >> default-uninitialized value for that element's type shall be returned."
> >>
> >> The meaning of this is not clear to me.
> >> Can someone clarify it?
> >> In particular, what does "match" mean here?

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