json_dumps real value 7.6 as 7.59....96

[mrryanjohnston]

Behavior:

$ gcc main.c -Iinclude -Llib -ljansson -Wl,-rpath,lib
$ ./a.out 
7.5999999999999996
$ ls lib
libjansson.a  libjansson.la  libjansson.so  libjansson.so.4  libjansson.so.4.14.0  pkgconfig
$ ls include/
jansson_config.h  jansson.h
$ cat main.c 
#include <jansson.h>

int main()
{
  json_t *j = json_real(7.6);
  printf("%s\n", json_dumps(j, JSON_ENCODE_ANY));
  return 0;
}
$ ldd ./a.out 
        linux-vdso.so.1 (0x00007ffd2ff7d000)
        libjansson.so.4 => lib/libjansson.so.4 (0x00007f2f8b45b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f8b220000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2f8b472000)

Steps to reproduce:

1. download latest release from github: https://github.com/akheron/jansson/releases/tag/v2.14
2. configure with --prefix="/my/current/path"
3. make && make install

I first noticed this with the jansson lib installed in ubuntu via apt, so this should exist in 2.13, as well.

[wqboth]

This is probably due to the fact to 7.6 not being presentable as a float in binary.

https://en.wikipedia.org/wiki/Floating-point_arithmetic

You can use the call JSON_REAL_PRECISION().

Thereby you force the internal use of the printf() family to round the number and that will "hide" this effect.

I have the same issue. Doesn't everybody when placing prices in json with c-code?

(Normaly you could also consider sending a price multiplied with a 100 so you send the prices as cents.
But when using this in a API then the other party has to agree to conform to that method which is not always likely.)

Using JSON_REAL_PRECISION() had the disadvantage that it is for all "reals"; so they are all rounded the same way and that is not always desirable.

I've tried to make a change/extension for this in the code. To the real object I added a precision. So with each real stored in json_t you can use a function that also allows you to set the precision for that specific real number.

I've still to test it. But maybe I can get it accepted here as a change

[mrryanjohnston]

@wqboth you're right :) I hope you'll forgive my ignorance on this one. I had heard about this issue, but had never understood it. I can close this now.

Edit: Oops, saw you added a change. Re-opening.

[wqboth]

I only did some spelling checks. I'm not a native speaker of English. So sometimes some corrections need to be made.

[wqboth]

But I have the same issue as you. It already frustrates me for quite some time.
Couple of years now. But i never got around to try to extend the possibilties of this otherwise great library.

[akheron]

Do you need to be able to format floats with a specific precision, or do you just want to get rid of the non-optimal formatting of floats?

My guess is that the former is very rarely useful. However, Jansson supports it because it has made it possible to fix the latter in some situations.

For the latter use case, it would make more sense to incorporate something like https://github.com/ulfjack/ryu in Jansson to always format floats correctly.

[wqboth]

I will read the information in the url you just gave.
But indeed I do need a very specific formatting for floats. For example the numbers for prices may demand a different precision(variable number of decimals) than weights or other numbers.
This also has the advantage that you have control over binary non presentable numbers like 0.15. Because of the implicit rounding it will nicely be presented as 0.15 and not 0.1499999999....
That is why I created a branche of jansson with a proposition to a solution as you might have seen?

My suggestion:
https://github.com/wqboth/jansson/tree/real_precision_option

[wqboth]

https://github.com/ulfjack/ryu does have somenthing in common.
I can see that this could be a used in printf()?
Or a replacement of printf() in jansson?
But even than I would like to have control over the precision per individual float value.

To put it accurately there are two issues. One is the fact of numbers not being presentable and wanting to have more control over the precision. The fun thing is that when you have control over the precision you "hide"/"solve" the other issue implicitly.

[akheron]

I've opened #680 that changes encoding of reals to output optimal values, i.e. no 7.599999... anymore. There's still a bit of work to do with the tests, but you can already check if it fixes your use case.

[mrryanjohnston]

This does indeed work for my use case:

$ ./a.out 
7.6

Thank you.