Closed kwatch closed 2 months ago
NAN's aren't intuitive per definition. That's why Float::NAN != Float::NAN
I'm uncertain that this is a useful change for two reasons:
IMHO using val.equal?(Float::NAN)
is relying on an implementation detail and so is no good recommendation.
Maybe val&.nan?
is good enough (assuming that the column is float)?
As you say, this pull request may not be very useful for many people. However, if it does not give any negative values to the pg
library, please consider accepting it.
I think that eval "0.0/0.0"
or eval "1.0/0.0"
is not the proper way to get NaN or Infinity, and referring to Float::NAN
or Float::INFINITY
is the proper way in Ruby.
(Ruby doesn't provide Float::NEGATIVE_INFINITY
, so this pull request doesn't change eval "-1.0/0.0"
.)
In programming, eval
should be used only in case when the problem can be solved only by eval
, I think.
Again: this pull request may not be very useful for many people, but if it does not give any negative values to the pg
library, please consider accepting it.
This PR introduces inconsistencies. This is the negative value. I tried to write a proper test for this behaviour change and noticed the additional complexity to differentiate the cases.
There's nothing wrong to use rb_eval in a C extension to express things that are not complicated in C.
This PR introduces inconsistencies.
Please tell me the details. I'm trying this PR on my project and it seems fine until now.
CI on GitHub reports some errors but they seems to be related to Ractor, so this PR doesn't seem to be the cause of that errors.
I do not accept this pull request. Sorry! My concerns are written in my first comment and you didn't show better reasons other than a very little performance benefit.
Why do you avoid describing the detail of inconsistencies'? Please explain about
inconsistencies'.
If you can't, it means that you are lying, and closed this issue with unfair reason.
You have the right to close issues, but you also have responsibility for what you said.
Currently, ruby-pg returns evaluated value of
0.0/0.0
when a query search result contains NaN, instead ofFloat:: NAN
. This behavior is strange and not intuitive, especially when user checks values in query byval.equal?(Float::NAN)
(faster) instead ofval.is_a?(Float) && val.nan?
(slower).This commit fixes it to return
Float::NAN
. Similarly, fix to useFloat::INFINITY
instead of1.0/0.0
.