RE: [sv-bc] 'inside' on real operands

>From: "Jonathan Bromley" <jonathan.bromley@doulos.com>

>Whilst this makes sense from a language design point of view,
>I think it's very dangerous.  The obvious intuitive interpretation
>of "inside" for reals is "somewhere within this real range". 

But there is already a defined syntax for "somewhere within this
real range" with 'inside'.  If someone thinks that a different
syntax means this, then they just aren't paying attention.


>When combined with the fact that wildcard comparison makes no
>sense for reals,

This is already explicitly covered in the LRM.  For non-integeral
types, == is used instead of ==?.  Reals just become another case
of this.


>and the fragility of == on reals, I think the
>balance should be in favour of prohibiting reals as operands
>of 'inside' if the right-hand operand is considered to be 
>a countable set of values.

That fragility already exists in the use of == on reals.  The
ability to use ranges for reals with 'inside' actually provides
a way to do a less fragile "approximate equality" operation.  If
you want to test a value for equality to 1.0, with an error margin
of epsilon, you can use

	realvar inside {[1.0-epsilon, 1.0+epsilon]}

This isn't any shorter than the equivalent in this case, but could
be if 'realvar' were a more complex expression.


>  Furthermore, if we preserve the
>present meaning of 'inside' whereby its RHS specifies a set
>of values, then a real range such as [1.0:2.0] makes no sense.
>
>I completely agree with Steven Sharp that the following
>would be both reasonable and (very) useful...
>
>  R inside {[1.0:2.0], [3.0:4.5]}
>
>and I think that's what users would expect to be able to
>do - but that makes a specification of a set with an 
>uncountable number of members; and it suggests that 
>putting anything *except* such ranges on the RHS of 
>an 'inside' with real LHS would need to be specified to
>be erroneous.

If the language had an actual set datatype that was the
right-hand operand of 'inside', then I would agree that the
uncountable number of members was an issue.  But that stuff
to the right of the 'inside' is not actually a set in that
sense.  From the language viewpoint, it is just a syntax for
specifying a lot of operands to be used in a complex multi-way
compare operation.

And if you want to view it as a set in a conceptual sense,
there is nothing wrong with the concept of a set with an
uncountable number of members.  The 'inside' operation will
correctly tell you whether the left operand is in that set.

Unless someone foresees the addition of a set datatype to
Verilog, with a full range of set operators, I don't see a
problem with this.  Verilog allows wide bit-vectors and bitwise
logical operators, which covers most needs for sets.  Associative
arrays should cover the rest.

Steven Sharp
sharp@cadence.com


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