This content has been marked as final. Show 23 replies
Seeing as how you are continuing to ignore what you're told, and insist that this must be possible, then I will tell you it is, but not in any way you want. Make an Object and store Doubles and Longs. There. That doesn't use any less (and possibly more) space than both a long and double, but hey, there's only one reference to it. Also, all of the auto(un)boxing, or explicit value and new calls (both needing casts to work) will actually hurt your performance, but hey, it's all under the same reference. Everything in the previous sentence also leads to more code than using two arrays would as well, but hey, it's all under the same reference. And, using the same reference for both seems to be what your after, so have fun.
wayne wrote:Why can you not do this immediately?
... I will later want to change to the more convenient array of double.
If you have a large set of existing long values stored on disk
converting them to double will have little impact compared to reading them from disk.
If you have a large array of long values returned to you from a method in some class you do not have control over:
If the long values are all in the range [0;0x7fffffffffffffff] (all positive) you can use the top bit to mark an entry as something other than a plain long.
If the long values are all in the range [0xc000000000000000;0x3fffffffffff] or even [0xc000000000000000-0x7fffffffffffffff]
you can use the value of top two bits; 11 and 00 (or even 01) for long and 10 for something other than plain long
[after Double.doubleBitsToLong() right shift the long 2 bits and set the two top bits to 10; you loose two bits of precision].
If the entire range of long is already used you have no option but to
change to the more convenient array of double.
wayne wrote:Oh yeah! And that minimal space savings (80 Mb max which isn't much, these days) is definately worth that performance hit. Yeah!
Thanks for knowing how to answer the question, and then doing it.
Have a lot of fun instituting the same mathematics and readings to get at the values. And, oh, BTW, don't make a mistake in it, as it won't be noticed, but the results will definately not be what you expect.
What is so important about that 80 mb that you insist on doing something like this? On taking all this futzing around and easily error-prone "solution" to simply avoid one more reference? Besides, if you want one type then later another and don't need the first type again, then the "extra" memory is only used for a second or so, as as soon as you create and start using the second array you could null the first reference and, lo and behold, that memory space is reclaimed.
I reply here to the last post because I did not know exactly to whom to reply.
My reading of the OP (and hence the answer) was this
(and no, he did not express it clearly and he did not play nice to people who wanted to help):
The data is just a collection of bits (multiple of 64) arriving from a file or from the network or from God knows where.
Some of them should be interpreted as longs and some as doubles. How do we decide which is which?
I don't know or care. Maybe there is a formula, maybe there is a list of what is double and what is long somewhere.
The approach I proposed is to take the whole (potentially huge) amount of bits and treat them as doubles or longs, as necessary.
Something along those lines is common in network protocols, where byte n tells us what bytes n+1, n+2 etc represent.
And the reason for the ByteBuffer views to exist.