[
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)
