-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Added jv_is_integer_large() to the library. #1862
base: master
Are you sure you want to change the base?
Conversation
Do we need a jq function for this? It can be coded using the builtin |
Probably not for this change, although I'd imagine there could be some uses for it in scripts. Jq mostly leaves numbers as they came in on the way out, so there's no need for scripts to make corrections unless they're trying do explicitly convert ints to floats. I haven't looked at the sources for any of the other language bindings, but I assumed that |
Not every As to jq throwing away zero-valued fractional parts... well, it's just about how it formats numbers. On input jq immediately parses JSON numeric values into IEEE754 There is a pending contribution to add a big number facility to jq. And we could delay parsing of numeric values (but not validation) so that on output we could print unmodified numbers exactly as they were on input. Even so there would be edge cases. Should |
Just my two cents, the decimal number branch #1752 has the feature of keeping number precision intact.
1 == 1.00 == 1.0
but
[1, 1.00, 1.0] => jq map(. + 1) => [2, 2.00, 2.0]
Sent from mobile device, typos and false corrections are possible
Regards,
Leonid S. Usov
… On Mar 15, 2019, at 1:10 AM, Nico Williams ***@***.***> wrote:
Not every jv function has a jq function binding. Some might only be used internally, some might be used by "internal libjq applications" (src/main.c and src/jq_test.c), some might be used by external libjq applications. Who would use this one?
As to jq throwing away zero-valued fractional parts... well, it's just about how it formats numbers. On input jq immediately parses JSON numeric values into IEEE754 doubles. On output it formats doubles back into JSON numeric values. As a result the original form of a numeric value is lost. Now, if in C you have double r = 1.0; that's the same as double n = 1; in that the two values will be bit-by-bit equal (i.e., memcmp((void*)&r, (void*)n, sizeof(double)) == 0)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@leonid-s-usov Oh, I see, that is nice. @wtlangford is rebasing your PR and undoing the big file split. |
yeah, I have received his message. I loved that split BTW, I think it brings some order.
… On 15 Mar 2019, at 10:04, Nico Williams ***@***.***> wrote:
@leonid-s-usov <https://github.com/leonid-s-usov> Oh, I see, that is nice. @wtlangford <https://github.com/wtlangford> is rebasing your PR and undoing the big file split.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1862 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC_85ykYENS-Gg09g2XV7y7ObMb9C7d0ks5vW1QGgaJpZM4b1Ddw>.
|
I understand. The idea is not to not have that split, but to first merge the contribution, and then do the split in a commit that only does the split. |
Side discussions about bindings and how integers will be handled in the future, does this look like something that will be in the next release? |
@mfeit-internet2 sure, a few questions:
|
1752: If the plan is to merge that change into the next release and there's still going to be a Code needing it: I have a patched version of jq with the new function and a patched PyJQ that uses it. Both are privately built and privately distributed, so that code is totally contained and under my control. I'm not the only PyJQ user with this problem, and my plan is to submit a patch to PyJQ patch once jq either pulls this, fixes Exposure as a function: No need. Scripts shouldn't care since jq takes care of all of this internally and seems to work fine. (See the perfSONAR ticket I referred to in the first comment.) Nothing internal uses |
@mfeit-internet2 thanks. OK, so, I think this should be folded into If you can force push a version that fixes |
Thanks! I'll squash and rebase as soon as I get a chance. |
This change adds a new function to the library called
jv_is_integer_large()
, which returns true for anyJV_KIND_NUMBER
that fits into adouble
and has a fractional part smaller than the system's epsilon.It was written to let PyJQ make decisions about using the arbitrarily-large integer types available in Python. (A companion pull request for that project is forthcoming.)
Gory details about why: perfsonar/pscheduler#717