Mailing-List: contact dev-help@tajo.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tajo.incubator.apache.org
Date: Sun, 8 Dec 2013 07:46:35 +0000 (UTC)
From: "Hyunsik Choi (JIRA)" <jira@apache.org>
To: dev@tajo.incubator.apache.org
Message-ID: <JIRA.12681952.1385790455241.93416.1386488795156@arcas>
In-Reply-To: <JIRA.12681952.1385790455241@arcas>
References: <JIRA.12681952.1385790455241@arcas>
Subject: [jira] [Comment Edited] (TAJO-344) Tajo cannot recognize negative
 numeric expressions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/TAJO-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842440#comment-13842440 ] 

Hyunsik Choi edited comment on TAJO-344 at 12/8/13 7:46 AM:
------------------------------------------------------------

Thank you for your detailed review. 

The result of Math.round may be different from other programming languages. This is because there are various round half-down/up manners \[1\] and Math.round uses some different round manner. So, we can get a mismatch as follows:

{code:title=Math.round}
Math.round(-5.5) -> -5
{code}

{code:title=PostgreSQL}
hyunsik=> select round(-5.5);
 round 
-------
    -6
(1 row)
{code}

{code:title=MySQL}
MariaDB [(none)]> select round(-5.5);
+-------------+
| round(-5.5) |
+-------------+
|          -6 |
+-------------+
1 row in set (0.00 sec)
{code}

Especially, we could face the result mismatch problem when we use a vectorized engine based on C++. This patch also contains the workaround code. I missed the detail comment for this reason. Since this workaround code may make other guys confuse, I'll add some notes on Round class.

In addition, in my opinion, succeeded hunks are not problem because it just means somewhat difference of diff lines but success. If we have to rebase all patches that cause even success hunk, contributors will be exhausted due to too frequent rebase.

 \[1\] https://en.wikipedia.org/wiki/Rounding#Round_half_up


was (Author: hyunsik):
Thank you for your detailed review. 

The result of Math.round may be different from other programming languages. This is because there are various rounding half-down/up manners \[1\] and Math.round uses some different rounding half-down manner. So, we can get a mismatch as follows:

{code:title=Math.round}
Math.round(-5.5) -> -5
{code}

{code:title=PostgreSQL}
hyunsik=> select round(-5.5);
 round 
-------
    -6
(1 row)
{code}

{code:title=MySQL}
MariaDB [(none)]> select round(-5.5);
+-------------+
| round(-5.5) |
+-------------+
|          -6 |
+-------------+
1 row in set (0.00 sec)
{code}

Especially, we could face the result mismatch problem when we use a vectorized engine based on C++. This patch also contains the workaround code. I missed the detail comment for this reason. Since this workaround code may make other guys confuse, I'll add some notes on Round class.

In my opinion, succeeded hunks are not problem because it just means somewhat difference of diff lines but success. If we have to rebase all patches that cause even success hunk, contributors will be exhausted due to too frequent rebase.

 \[1\] https://en.wikipedia.org/wiki/Rounding#Round_half_up

> Tajo cannot recognize negative numeric expressions
> --------------------------------------------------
>
>                 Key: TAJO-344
>                 URL: https://issues.apache.org/jira/browse/TAJO-344
>             Project: Tajo
>          Issue Type: Bug
>          Components: operator/function/udf, parser, planner/optimizer
>            Reporter: Hyunsik Choi
>            Assignee: Hyunsik Choi
>             Fix For: 0.8-incubating
>
>         Attachments: TAJO-344.patch
>
>
> The parser cannot deal with negative numeric values. You can reproduce the problem as follows:
> {code}
> select -1;
> {code}
> We have to fix it.


--
This message was sent by Atlassian JIRA
(v6.1#6144)