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