From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 30A3946970E for ; Tue, 28 Jan 2020 00:56:27 +0300 (MSK) References: <2dec35136a47362584f27ea3293bef0b1ad09af2.1580057028.git.v.shpilevoy@tarantool.org> <20200126184554.GD1144@tarantool.org> From: Vladislav Shpilevoy Message-ID: <9f4910e3-d37d-4daf-df2c-a4b889282da3@tarantool.org> Date: Mon, 27 Jan 2020 22:56:23 +0100 MIME-Version: 1.0 In-Reply-To: <20200126184554.GD1144@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 1/1] tuple: don't truncate float in :update() List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org Ok, then discard this patch. On 26/01/2020 19:45, Nikita Pettik wrote: > On 26 Jan 17:44, Vladislav Shpilevoy wrote: >> Before the patch there were the rules: >> * float +/- double = double >> * double +/- double = double >> * float +/- float = float >> >> The rules were applied regardless of values. That led to a problem >> when float + float exceeding maximal float value could fit into >> double, but was stored as an infinity. >> >> The patch makes so that if a floating point arithmetic operation >> result fits into float, it is stored as float. Otherwise as >> double. Regardless of initial types. >> >> This alongside saves some memory for cases when doubles can be >> stored as floats, and therefore takes 4 less bytes. Although >> these cases are rare, because any not integer value stored in a >> double may have a long garbage tail in its fraction. >> >> Closes #4701 >> --- >> Branch: https://github.com/tarantool/tarantool/tree/gerold103/gh-4701-update-float-truncate >> Issue: https://github.com/tarantool/tarantool/issues/4701 >> >> I am not sure about the patch correctness. Perhaps we should not >> save double + double as float even when it fits. It would break >> DOUBLE data type, which we are going to introduce, because from >> what I understood, it is going to store MP_DOUBLE only. >> >> On the other hand, DOUBLE is not implemented yet > > I guess double is already on board. See d8193eb1c > >> and when it will >> be implemented, we may decide to allow to store MP_FLOAT there. >> >> src/box/xrow_update_field.c | 18 ++++++++-- >> test/box/update.result | 66 +++++++++++++++++++++++++++++++++++++ >> test/box/update.test.lua | 46 ++++++++++++++++++++++++++ >> 3 files changed, 127 insertions(+), 3 deletions(-) >> >> diff --git a/src/box/xrow_update_field.c b/src/box/xrow_update_field.c >> index 7c0f5fb5e..31429ee37 100644 >> --- a/src/box/xrow_update_field.c >> +++ b/src/box/xrow_update_field.c >> @@ -400,13 +400,25 @@ xrow_update_arith_make(struct xrow_update_op *op, >> unreachable(); >> break; >> } >> - if (lowest_type == XUPDATE_TYPE_DOUBLE) { >> + float fc = (float) c; >> + /* >> + * A value may be saved as double even if it looks >> + * like fitting a float. For example, 0.01 + 0.01 >> + * may be stored as double. This is because >> + * 0.01 may be stored as 0.009999999999999, what >> + * looks like double precision. And there is no >> + * way how to check if this is actually 0.01. >> + * By the same reason FLT_MAX can't be used to >> + * detect whether a value fits float, because it >> + * may be <= FLT_MAX, but may have a double >> + * precision in its fraction part. >> + */ >> + if (c != (double) fc) { >> ret->type = XUPDATE_TYPE_DOUBLE; >> ret->dbl = c; >> } else { >> - assert(lowest_type == XUPDATE_TYPE_FLOAT); >> ret->type = XUPDATE_TYPE_FLOAT; >> - ret->flt = (float)c; >> + ret->flt = fc; >> } >> } else { >> decimal_t a, b, c;