> On Sept. 16, 2015, 6:01 p.m., Ben Mahler wrote:
> > Have you surveyed how other libraires handle this? For example, the scala 
> > play framework seems to use BigDecimal (128 bit floating point) for all 
> > numbers, which can represent all 64 bit signed / unsigned integral values 
> > without loss. Have you considered this as well?
> > 
> > It would be great to outline the options we have here in the ticket so we 
> > can decide on the tradeoffs. If you've already done this, can you point me 
> > to it? :)

Hi Ben! THanks for bringing this up.

When you say "handle this", what do you mean exactly? The issue that Joseph is 
dealing with is the round-trip loss when we transit through pico-json. The 
modification to Number are just to maintain type information when possible.

I believe we would have to choose another parsing library if we wanted to use 
128 bit floats, or am I missing something? I'm definitely open to discussing 
alternative libraries; but I would like to patch this up in the mean time so 
that we don't need to rush the larger discussion. What are your thoughts?


- Joris


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38031/#review99254
-----------------------------------------------------------


On Sept. 15, 2015, 5:24 p.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38031/
> -----------------------------------------------------------
> 
> (Updated Sept. 15, 2015, 5:24 p.m.)
> 
> 
> Review request for mesos, Ben Mahler, Artem Harutyunyan, Joris Van 
> Remoortere, Michael Park, and Vinod Kone.
> 
> 
> Bugs: MESOS-3345
>     https://issues.apache.org/jira/browse/MESOS-3345
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> * Changes JSON::Number to keep track of whether it is floating, signed 
> integral, or unsigned integral.
> * Changes how JSON::Number is stringified, to ensure that stringified doubles 
> are parsed as JSON doubles.
> * Added one test for integer precision between String <-> JSON <-> Protobuf 
> conversions.
> * Added one test for JSON::Number comparisons.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> f28138c4682c41e94ab6c7641a78d66b2f9daa5f 
>   3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
> 57d5fdf45273c620655b44b5f5572290cffa4bf6 
>   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
> 850650c269e9be24c0f1ae81b8aa8725f8a0c151 
>   3rdparty/libprocess/3rdparty/stout/tests/protobuf_tests.cpp 
> c56d6a3098293eb3659b3066f10e875927ec3ac3 
> 
> Diff: https://reviews.apache.org/r/38031/diff/
> 
> 
> Testing
> -------
> 
> No testing done until the last patch in the chain.
> 
> However, this patch does breaks some libprocess and mesos tests (because 
> JSON::Number is stored differently), which are fixed in the following two 
> reviews.
> 
> 
> Thanks,
> 
> Joseph Wu
> 
>

Reply via email to