Omega359 commented on issue #13780: URL: https://github.com/apache/datafusion/issues/13780#issuecomment-2573323646
I've spent a few hours trying to determine where DataFusion was going wrong with the math and finally came up with a condensed test case. The math is fine ... as far as Rust is concerned. You can see a boiled down test case I wrote up on the [rust playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=835b3d7bc195114a70d490f0d8973354). The core issue is that the result *cannot* be represented as a f32 which is what the `REAL` type maps to. So technically the result that DataFusion is returning is correct. Sqlite maps real to 8 bytes. Postgresql maps real to 4 bytes ... but for the query in query it uses an int type (proper handling of nullif types as opposed to DataFusion's incorrect type selection). Even if you force part of the query to be a real type it still uses int: `SELECT - 15.0000::float4 * 16860600 + 31 AS col0;` => -252908969 `SELECT - 15.0001::float4 * 16860600 + 31 AS col0;` => -252910657.34972382 Duckdb maps real to 4 bytes. If you force the type to be float4 it returns the same result as DataFusion: ```sql D SELECT - 15.0000::float4 * 16860600 + 31 AS col0; ┌──────────────┐ │ col0 │ │ float │ ├──────────────┤ │ -252908960.0 │ └──────────────┘ ``` So I think for these queries the resolution here should be that DataFusion should fix the typing of nullif .. and then update the results in the slt test if the type maps to f32. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For additional commands, e-mail: github-h...@datafusion.apache.org
