Catching up on email...
On 1/8/2019 10:55 AM, Hans Boehm wrote:
The IEEE standard does say that for quiet NaNs, the value (or one of them)
"should" be preserved by most operations on the quiet NaN. I have not heard
of implementations violating this for anything other than the "quiet" bit.
Thus I
Le 08/01/2019 à 19:55, Hans Boehm a écrit :
> The IEEE standard does say that for quiet NaNs, the value (or one of them)
> "should" be preserved by most operations on the quiet NaN. I have not heard
> of implementations violating this for anything other than the "quiet" bit.
> Thus I don't immediat
Technically, another option would be to have Java standardize a meaning,
and I take it you're not mentioning that because of the performance
implications?
On Tue, Jan 8, 2019 at 2:37 AM John Rose wrote:
> As I think you expect, isSubstitutible(x,y) will mean that x and y are
> equivalent
> for a
As I think you expect, isSubstitutible(x,y) will mean that x and y are
equivalent
for all practical purposes. One hard question is nailing down what are
"all practical purposes". Certainly it's unfair to flip a coin while evaluating
x and y separately, and claim that a distinct outcome proves a
See
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Objects.html#compare(T,T,java.util.Comparator)
-Joe
On 1/6/2019 2:56 AM, Zheka Kozlov wrote:
Why don't we just add a generic method which compares any instances of
Comparable?
public interface Comparator {
...
Hello 99206970363698485155,h
On 1/4/2019 3:11 PM, some-java-user-99206970363698485...@vodafonemail.de
wrote:
To test whether primitive float or double values are equal according to
`Float.equals` and `Double.equals` you either have to create wrapper instances
for them (possible performance de
Objects.equals is not type-safe:
Objects.equals(1, "your mom"); // returns false
Comparator.equal(1, "your mom"); // error
However, I agree that they are both slower than Float.equal(float, float)
and Double.equal(double, double).
пн, 7 янв. 2019 г. в 01:41, <
some-java-user-99206970363698485..
Followers of Project Valhalla will see that this issue comes up when
defining equality on value types. The relation you are looking for is
being called "substitutible"; it asks whether there is any way to
distinguish between two values. For primitives other than float/double,
this coincides w
My main goal was to provide a way where NaN is equal to NaN and I went with the
behavior of the
respective wrapper classes, Float and Double, which consider -0.0 and +0.0 as
not equal.
The static method could be called "exactlyEquals" if that is better.
It might also depend on the usecase wheth
If the developer implemented the Comparable interface correctly, the method you
proposed would be
equivalent to java.util.Objects.equals(Object, Object).
Additionally both variants would require boxing for primitive types which I
initially wanted to prevent.
> Zheka Kozlov hat am 6. Januar 20
Why don't we just add a generic method which compares any instances of
Comparable?
public interface Comparator {
...
public static > boolean equal(T x, T y) {
return x.compareTo(y) == 0;
}
}
Usage:
Comparator.equal(1, 1); // true
Comparator.equal(1.0, 1.0); // true
Comparator.equal(2.0f
Hello Remi,
You are right, the proposed method names would prevent backwards compatibility,
I forgot to think
about that. Sorry for the trouble.
Maybe a different, currently not used name, such as `areEqual`,
`primitiveEquals` or similar would
be better.
What do You think about the addition of
Hi,
it's not obvious to me that this is a source backward compatible change.
if you have something like:
interface Fun { boolean eq(Double a, double b); }
...
Fun fun = Double::equals;
it's not clear to me which variant will be selected ?
regards,
Rémi
- Mail original -
> De: som
13 matches
Mail list logo
