[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal() |
Date: |
Wed, 05 Jul 2017 18:11:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Eric Blake <address@hidden> writes:
> On 07/05/2017 08:48 AM, Max Reitz wrote:
>>>> /**
>>>> + * qnum_is_equal(): Test whether the two QNums are equal
>>>> + */
>>>> +bool qnum_is_equal(const QObject *x, const QObject *y)
>>>> +{
>>>> + QNum *num_x = qobject_to_qnum(x);
>>>> + QNum *num_y = qobject_to_qnum(y);
>>>> +
>>>> + switch (num_x->kind) {
>>>> + case QNUM_I64:
>>>> + switch (num_y->kind) {
>>>> + case QNUM_I64:
>>>> + /* Comparison in native int64_t type */
>>>> + return num_x->u.i64 == num_y->u.i64;
>>>> + case QNUM_U64:
>>>> + /* Implicit conversion of x to uin64_t, so we have to
>>>> + * check its sign before */
>>>> + return num_x->u.i64 >= 0 && num_x->u.i64 == num_y->u.u64;
>>>> + case QNUM_DOUBLE:
>>>> + /* Implicit conversion of x to double; no overflow
>>>> + * possible */
>>>> + return num_x->u.i64 == num_y->u.dbl;
>>>
>>> Overflow is impossible, but loss of precision is possible:
>>>
>>> (double)9007199254740993ull == 9007199254740992.0
>>>
>>> yields true. Is this what we want?
>>
>> I'd argue that yes, because the floating point value represents
>> basically all of the values which are "equal" to it.
>
> But the problem is that we CAN represent the fully-precise number as an
> integer, so having multiple distinct integers that compare differently
> against each other, but equal to the same double, is awkward.
Yup.
>> But I don't have a string opinion. I guess the alternative would be to
>> convert the double to an integer instead and check for overflows before?
>
> That's the solution Markus gave, and I'm in favor of the tighter check:
>
[...]
>>> I think there's more than one sane interpretations of "is equal",
>>> including:
>>>
>>> * The mathematical numbers represented by @x and @y are equal.
>>>
>>> * @x and @y have the same contents, i.e. same kind and u.
>>>
>>> * @x and @y are the same object (listed for completeness; we don't need
>>> a function to compare pointers).
>>>
>>> Your patch implements yet another one. Which one do we want, and why?
>>
>> Mine is the first one, except that I think that a floating point value
>> does not represent a single number but just some number in a range.
>>
>>> The second is easier to implement than the first.
>>
>> It seems much less useful, though.
Depends on what for.
Common Lisp has
* eq: same object
* eql: eq, or both numbers with same type and value, or both characters
that represent the same character
* =: mathematically equal (arguments must be numbers)
* equal: like eql, but it recursively descends into lists (I'm
simplifying)
Decades of use back the assertion that eq, eql and = are all useful.
>>> If we really want the first, you need to fix the loss of precision bugs.
>>
>> I'm not sure, but I don't mind either, so...
For what it's worth, your v2 had QInt compare not equal to QFloat.
Makes me suspect that eql is good enough for the problem at hand.
>>> I guess the obvious fix is
>>>
>>> return (double)x == x && x == y;
>>
>> Yes, that would do, too; and spares me of having to think about how well
>> comparing an arbitrary double to UINT64_MAX actually works. :-)
>
> It basically says that we are unwilling to declare an integer equivalent
> to the double if the double loses precision when trying to store the
> integer.
>
>>> Note that this is what you do for mixed signedness: first check @x is
>>> exactly representable in @y's type, then compare in @y's type.
>>>
>>> Regardless of which one we pick, the function comment needs to explain.
- [Qemu-block] [PATCH v3 0/5] block: Don't compare strings in bdrv_reopen_prepare(), Max Reitz, 2017/07/03
- [Qemu-block] [PATCH v3 1/5] qapi/qnull: Add own header, Max Reitz, 2017/07/03
- [Qemu-block] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/03
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Eric Blake, 2017/07/03
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Markus Armbruster, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Eric Blake, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Eric Blake, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Eric Blake, 2017/07/05
- Re: [Qemu-block] [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal(), Max Reitz, 2017/07/05
[Qemu-block] [PATCH v3 3/5] block: qobject_is_equal() in bdrv_reopen_prepare(), Max Reitz, 2017/07/03