I don't think you can avoid that. I'd suggest making it CQL-only if we do doubles -- no backwards incompatibility required there.
On Mon, Jun 27, 2011 at 7:07 PM, Jason <jfa...@gmail.com> wrote: > 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> >> */ > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
