Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[VL] Incorrect result type of nested decimal arithmetic expressions #7082

Open
jiangjiangtian opened this issue Sep 2, 2024 · 6 comments
Open
Labels
bug Something isn't working triage

Comments

@jiangjiangtian
Copy link
Contributor

jiangjiangtian commented Sep 2, 2024

Backend

VL (Velox)

Bug description

The SQL as follows will produce wrong result:

select col0 / (col1 + 0.00001) from table;

where col0 and col1 is decimal(20, 0).
The values of col0 and col1 are 25 and 72. Gluten returns 3.4722217399692027821 and spark returns 0.3472221739969202782.
The result type needs to be decimal(38, 19). But during calculation, the actual result type is decimal(38, 20):
image
The reason is that the type of the subexpression col1 + 0.00001 will be rescaled to decimal(27, 5):
截屏2024-09-02 17 15 29
But we don't notice it when we rescale the topmost expression:
截屏2024-09-02 17 16 06

Spark version

None

Spark configurations

No response

System information

No response

Relevant logs

No response

@jiangjiangtian jiangjiangtian added bug Something isn't working triage labels Sep 2, 2024
@jiangjiangtian
Copy link
Contributor Author

@kecookier

@jiangjiangtian
Copy link
Contributor Author

Maybe we should not remove the PromotePrecision(Cast(...)). Otherwise, we will always have the bug.
Besides, maybe we can also override DecimalPrecision in gluten and make it consistent with high version Spark.

@jiangjiangtian
Copy link
Contributor Author

jiangjiangtian commented Sep 2, 2024

After some investigations, I find that if we have some literals in the decimal arithmetic expressions , we may have wrong result type. The reason is that the existence of constant folding makes we can't get the original type of the literal.

@rui-mo
Copy link
Contributor

rui-mo commented Sep 3, 2024

Hi @jiangjiangtian, would you also post the expected result and incorrect result in this issue? Thanks.

@jiangjiangtian
Copy link
Contributor Author

Hi @jiangjiangtian, would you also post the expected result and incorrect result in this issue? Thanks.

Thanks for reminding me. I add the result in the issue.

@jiangjiangtian
Copy link
Contributor Author

For now, we pass the result type when we create the decimal function, but it is not an elegant solution, and we will come up with a better solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage
Projects
None yet
Development

No branches or pull requests

2 participants