mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Mahler" <benjamin.mah...@gmail.com>
Subject Re: Review Request 38031: [3/5] Integer Precision for JSON <-> Protobuf conversions.
Date Wed, 16 Sep 2015 18:37:03 GMT


> 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? :)
> 
> Joris Van Remoortere wrote:
>     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?

Improving over the current state sounds good, just trying to gauge if this is how we want
this to look long term: Looking at the diff, it seems like we still are not able to represent
every unsigned 64 bit integer? I'm a bit worried about that, we can get away with it for now,
but given we may use uint64s for representing identifiers, this needs to be non-lossy longer
term, no?


- Ben


-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message