Support for primitive types in instanceof and type patterns

[Brian Goetz]

Indeed.  During the early explorations for this feature we got fooled by 
values for which casting from T to U lost precision, but the 
corresponding cast back from U to T was also imprecise, and so the 
round-trip T -> U -> T preserved the input value.  We scratched our 
heads over this for a while.



On 11/16/2022 10:15 AM, Dan Heidinga wrote:
> It's good to hear that you and others are thinking through the details 
> on how float/doubles will work.
>
> I still have some concern with user-intuition when writing pattern 
> matching code over floating point values if users base their intuition 
> on their experience with widening casts to float.  There's a great 
> sample program (JLS Example 5.1.2-1) which shows the loss of precision 
> when casting a large int to a float which I would try to express with 
> pattern matching roughly as:
>
> record FloatBox(float f) {}
> int big = 1234567890;
> FloatBox box = new FloatBox(big);
> if (box instanceof FloatBox(int i)) {
>    // pattern won't match here
> }
>
> I think users would be surprised reading the code that the pattern 
> doesn't match because converting back to an int would lose precession.
>
> The equivalent non-pattern code would be pretty clear that it accepted 
> the loss of precession:
>
> if (box instanceof FLoatBox) {
>   int i = (int)box.f();
>   ....
> }
>
> Users will find it confusing when the pattern seems to match 
> "sometimes" though this is likely due to existing confusion related to 
> floating types.  Maybe expanding on the expected implementation will 
> make it easier to build a mental model for when the match will succeed?
>
> --Dan
>
>
> On Tue, Nov 15, 2022 at 6:13 PM Joseph D. Darcy <joe.darcy at oracle.com> 
> wrote:
>
>     On 11/15/2022 12:13 PM, Brian Goetz wrote:
>     >
>     >
>     > On 11/15/2022 2:55 PM, Dan Heidinga wrote:
>     >> Hi Angelos,
>     >>
>     >> The overall direction and writeup for this looks good to me.  I
>     think
>     >> we need to be more specific about how doubles & floats fit into
>     this
>     >> though as they are perpetual source of special cases.
>     >
>     > Indeed, floating point is the gift that keeps on giving.
>     >
>     > Joe recently did some nice work in the spec of Float and Double,
>     > outlining the various different ways in which floats can be
>     compared.
>     > This allows language features like pattern matching, casting, and
>     > switch to appeal to "compared by FooBar comparison", rather than
>     > spelling it out for each use.
>     >
>     >
>     FYI, the new text in question is:
>
>     https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq
>     <https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html*fpNumericalEq__;Iw!!ACWV5N9M2RV99hQ!NLeYfZTwyKuJa79r6BKK7vCpK18EfV6UFYQATED31R-rgD9GThj4b5Apwa-MjRhTkfthC6sXdBLheOEVZLA$>
>
>     For the cases in the draft JEP, there have been separate discussions
>     working through the details. Putting aside how it might be
>     implemented,
>     for the
>
>         floating-point type -> integral type
>
>     cases, conceptually if the same real number can be presented in the
>     floating-point type and the integral type, then the conversion is
>     exact.
>     (While floating-point values are often thought of as "fuzzy," each
>     finite floating-point value represents some particular real number.
>     Finite binary floating-point values are sums of the powers of 2 where
>     the exponent difference of the powers is bounded by the significand
>     width of the floating-point format in question.) The main special
>     case
>     is how conversion of -0.0 to an integral type is defined for
>     purposes of
>     instanceof. The desired double -> float behavior can be inferred from
>     IEEE 754 concepts.
>
>     HTH,
>
>     -Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221116/477081ea/attachment.htm>