From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 73B8F6EC55; Tue, 7 Sep 2021 14:52:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 73B8F6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1631015533; bh=24GxcP/gV4yjd12fD3ZdJWnj8JA88BVLXvPwbZrJ6O0=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nkIRS1XUjxC3qXVJcl6WxkLXg0R5qeDKqUAEIAGBVEC1hvtfImEeRWFJg5+8YHZmK eBObmJHQA2mDfGZoCHnU7haOyBT2w0gkFOmV9gL5HNdoqBzAwPZH0TdSYDm7UakokM xUawwZVFzToe0z0pKmEyS19Q44I2ISd29Cbfb3LE= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 430986EC55 for ; Tue, 7 Sep 2021 14:52:12 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 430986EC55 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mNZe7-0005Gx-0E; Tue, 07 Sep 2021 14:52:11 +0300 Date: Tue, 7 Sep 2021 14:26:56 +0300 To: Safin Timur , Mergen Imeev Cc: tarantool-patches@dev.tarantool.org Message-ID: <20210907112656.GW5743@tarantool.org> References: <6229320676324201d74e78ac1f2832b79fd159cb.1630303937.git.imeevma@gmail.com> <017301d79ea0$eba3de60$c2eb9b20$@tarantool.org> <20210901085235.GA112149@tarantool.org> <7b0d7a1f-b307-dacd-1f35-200c043e6181@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7b0d7a1f-b307-dacd-1f35-200c043e6181@tarantool.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9D96C1EA41D18F4D5409838B14BB7DC4567FB6F44CFDC9DC8182A05F538085040444C6B95D966C1C84631816B05ECB0905C8FC096BDBCB8C5CB63D923A63E5987 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE791E547C23789F646EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063781C5E355D70FD85B8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D850EC0A48D7B6403F77180D29E7AEB2C5117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352026055571C92BF10FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8B779389CF6F126FEC75ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A511E960B1E54C5BD9F1E29100F470B9664FF02B3123AA5671D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA752546FE575EB473F1410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D344EF254DC71474AA3EA1A3348880A2A34E7E4AA370BC8524E7DB2CD202B27B47DEA6CAE88D7C6A0E61D7E09C32AA3244C564ED83D5ED472A3BF39620316A8173EF522A1CF68F4BE05FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojSvkey75OmIoSSl0I9qTE3A== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5DDA5A55646C7BD5BB3842C508C336322EA7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v1 1/1] sql: fix comparison between DECIMAL and big DOUBLE X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi there, On 07.09.21, Safin Timur via Tarantool-patches wrote: > > > On 01.09.2021 11:52, Mergen Imeev wrote: > > Thank you for the review! My answer below. > > > > On Tue, Aug 31, 2021 at 10:46:40PM +0300, Timur Safin wrote: > >>> From: imeevma@tarantool.org > >>> Subject: [PATCH v1 1/1] sql: fix comparison between DECIMAL and big > >>> DOUBLE > >>> > >>> This patch fixes comparison between DECIMAL value and DOUBLE values > >>> greater or equal to 1e38 or less or equal to -1e38. Now any DOUBLE > >>> value > >>> greater or equal to 1e38 is more than any DECIMAL value and DOUBLE > >>> value less or equal to -1e38 is less than any DECIMAL value. > >>> > >>> Closes #6376 > >> ... > >>> diff --git a/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf- > >>> cmp.md b/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf-cmp.md > >>> new file mode 100644 > >>> index 000000000..70de655f1 > >>> --- /dev/null > >>> +++ b/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf-cmp.md > >>> @@ -0,0 +1,3 @@ > >>> +## bugfix/sql > >>> + > >>> +* Fixed wrong comparison between DECIMAL and large DOUBLE values > >>> (gh-6376). > >>> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c > >>> index 4c40f15dc..a3ab31af5 100644 > >>> --- a/src/box/sql/mem.c > >>> +++ b/src/box/sql/mem.c > >>> @@ -2451,9 +2451,9 @@ mem_cmp_num(const struct Mem *a, const struct > >>> Mem *b) > >>> } > >>> case MEM_TYPE_DOUBLE: { > >>> if (b->u.r >= 1e38) > >>> - return 1; > >>> - if (b->u.r <= -1e38) > >>> return -1; > >>> + if (b->u.r <= -1e38) > >>> + return 1; > >> > >> Well, while we are here. I do understand that these kind of constants > >> already spreading all corners of mem.c when you deal with decimals, > >> but it's not entirely clear that this all about DECIMAL_MAX_DIGITS > >> limitation in our decimal implementation. > >> And beyond all of that - hardcoded constant are evil. Could you please > >> introduce any symbolic constant defines for such DECIMAL_MAX_DIGITS- > >> derivative values? And use them wherever possible. > >> > >> (I'm not insisting on fixing whole mem.c, that might be done separately, > >> but at least this tricky case worth it) > >> > > I agree that this is not good, but I think that addition of double constant for > > decimal in SQL is not good idea. I think it is better to move all these > > operations to decimal.c/.h. Could you fill an issue? If you cannot, I will do > > it myself a bit later. Сомневаюсь, что проблема в языке, на котором мы тут общаемся. > > Ну вот давай посмотрим на этот код чужими глазами. Ты ведь понимаешь, > что пишешь его не для себя, а "для того парня" и тут из контекста не > всякому понятно, почему 1e38 при операциях с даблом. Ситуацию можно было > бы улучшить несколькими способами: > - если волшебная константа используется один раз - то просто написать > комментарий > - если использования магических констант несколько - то просто вынести в > именованную константуЮ из названия которой за километр будет понятно, > что это про лимиты нашей decimal реализации. Например, MAX_DECIMAL_FLOAT > или что-то вроде того. > - (ну или сделать и второе и третье - по желанию). Как это улучшение относится к 2-строчному патчу по конкретному багосу? > > Тут же нет ничего такого не сделано в прошлом и продолжается в > настоящем, и простое чтение этого кода требует приложить дополнительные > когнитивные усилия для того, чтобы понять что за захардкоженная > константа из окружающего контекста. Причем, для того, чтобы понять это > место в mem.c надо случайно уже побывать в decimal.c. Я не был ни в mem.c, ни в decimal.c, но все равно понял в чем патч (есть же описание в commit message). Единственное, о чем бы стоило упомянуть дополнительно -- порядок операндов (обратный случай работал и до этого, как писал Влад в своем ревью). > > > > I also agree that I was wrong when I didn't introduce new functions for decimal, > > but at that time I feared that I will spend too much time on tests for these > > functions, and decided to leave this for later. > > Да, тогда была спешка и на такое закрывали глаза, но давай всё же > завяжем с такими практиками? (Понятно, что спешка будет всегда, но таки > когда-то надо начинать. Благо у нас таки есть карт-бланш на > кратковременные рефакторинги) Причем тут спешка и рефакторинг? Патч просто переставляет return-ы местами (то, что затронуты строки с константами -- побочный эффект diff-а). Зачем еще что-то менять в рамках этого патча, который решает свою проблему? > > В данной ситуации можно приступить за нексоклько шагов: > - для данного патча (и только для него) вводим внутри mem.c > макрос/именованную константу и использовать только её Какую проблему это решит, без общего рефакторинга? Имхо, это не тот билет, в рамках которого стоит разводить такую активность. > - создаёшь тикет на короткий рефакторинг таких decimal-related граничных > проверок - перелопачиваешь весь mem.c Что Мерген и предложил, AFAIU. > > > > > In general, I have quite a few questions about functions in decimal.c/.h and > > I plan to ask them in the mentioned issue. > > > >>> decimal_t dec; > >>> decimal_t *d = decimal_from_double(&dec, b->u.r); > >>> assert(d != NULL && d == &dec); > > Эта проблема была очевидной еще на предыдущих шагах да, и я, и Серёжа > Петренко просили перенести этот код в decimal.c. Мне не кажется, что > этот рефакторинг надо делать в одном шаге с граничными условиями, но > можно поместить в ту же серию. В тему разговоров "для того парня" -- я лично не понял, что и где обсуждали на предыдущих шагах. Можешь, пожалуйста, подсказать где стоит искать обсуждение по теме переноса какой-то функциональности в decimal.c? > > >> > >> Thanks, > >> Timur > >> > > Если ты считаешь, что что-то можно сделать потом и коммитишься под это, > то важно чтобы такой фоллоуап тикет был создан тобой, а не кем-то > другим. Но в рамках обсуждаемых текущих правок, мне кажется что > отдельный тикет - излишен, так как правки тривиальные (надо поправить > всего 8 строчек кода в mem.c - come on!) и могут идти фоллоуапом > релевантному патчу, когда пришли в какое-то место кода и огляделись. Опять же, текущие правки переставляют 2 return-а. Ты предлагаешь в этот патч или даже в эту серию засунуть какой-то рефакторинг, связанный c decimal в сиквеле. Почему объем рефакторинга (8 строчек кода) такой? Имхо, если уж и разводить рефакторинг, то не на уровне константы vs magiс numbers, а инкапсулировать эти проверки в decimal-specific модуле. Мерген, нарисуй билет на эту активность, пожалуйста. > > Тимур -- Best regards, IM