Re: [sv-bc] RE: Mantis 1523

That is fine with me. If you'd like to fold that into your proposal,
I'd have no objection.

Gord.

On 8/24/2011 10:45 PM, Bresticker, Shalom wrote:
> 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.
>

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