Sorry, I should have been more clear; I was speaking to the question of how to avoid modifying the thrift interface.
- Jason On Jun 27, 2011, at 7:58 PM, Joseph Stein <crypt...@gmail.com> wrote: > hmmm, well Jason it is not as accurate as I would have thought at first and > the increments on the long are whacked (which now that I think about it more > makes sense since a +1 of the bits as long for the double would not > necessarly represent the +1 on the double). > > So I am setting the increment to be > > 1.23 > > which comes back as 1.3213044541238036E308 > > and then another increment of 1.23 comes back as 10.359999999999987 > > so for the increment (which is just +value to the long which would not > provide the right shift) > > even if under the hood I keep the thrift interface as long somehow the 1.23 > vs 1.321 is a big difference when you have billions of them > > so I think it goes back to my original idea/proposition. Any one have > issue? any +1 ? should I create a JIRA and get to it? > > On Mon, Jun 27, 2011 at 7:39 PM, Joseph Stein <crypt...@gmail.com> wrote: > >> I will give that a shot, seems that it will work fantastically, thanks! >> >> I will keep trolling JIRA then for something I feel I can get my feet wet >> with and contribute then. >> >> On Mon, Jun 27, 2011 at 7:33 PM, Jason Fager <jfa...@gmail.com> wrote: >> >>> Longs and Doubles are both 64-bit values and are pretty easily >>> convertible. Check out Double.doubleToLongBits and >>> Double.longBitsToDouble in the JDK; you can also read more about the >>> details of the conversion and get some pointers to some code in a post >>> I wrote last year: >>> http://jasonfager.com/770-lexi-sortable-number-strings/ (the emphasis >>> is on using doubles in key strings, but it should cover what you >>> need). >>> >>> >>> >>> >>> >>> On Mon, Jun 27, 2011 at 7:13 PM, Joseph Stein <crypt...@gmail.com> wrote: >>>> So has anyone considered using the CounterColumn for summing? >>>> >>>> I wanted to-do this over the weekend until I realized it was only a long >>> :( >>>> so using it for things like duration (as an example for me this would >>> have >>>> been great to keep track of aggregate durations of ad impressions) are >>> not >>>> possible (or total costs when processing business workflows, etc,etc). >>>> >>>> I thought this might be a little more the speed of a first contribution >>> too >>>> :) and also helps out with more functionality since a lot of real time >>>> analytics will need double. >>>> >>>> Let me know, I think it is a good feature. >>>> >>>> Implementing it not sure we would want to break the thrift interface I >>> would >>>> suggest that I would create another interface for the double value? >>>> >>>> Under the hood of the thrift interface I was thinking of creating a >>>> CounterValue class and then setting the lValue or the dValue depending >>> on >>>> which thrift function was called. I can update the thrift, add a sister >>>> function and re-work the entire code path of long CounterColumn.value >>> into >>>> CounterValue CounterColumn.value. >>>> >>>> /* >>>> Joe Stein >>>> http://www.linkedin.com/in/charmalloc >>>> Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> >>>> */ >>>> >>> >> >> >> >> -- >> >> /* >> Joe Stein >> http://www.linkedin.com/in/charmalloc >> Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> >> */ >> > > > > -- > > /* > Joe Stein > http://www.linkedin.com/in/charmalloc > Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> > */
