Using some Math(tm), I figured out there was space for an exponent of up to 21, still fitting it all in 32 bits, allowing for silly small numbers and silly high numbers.Here's a quick implementation: (the exponent is offset by 7 to allow for negative exponents)

I am a little lost at how you are proposing to convert the input floating point to an integer represenation? I am trying to reverse engineer it from your decoding formula but with little avail..

I'll explain a bit:

there are N possible values, with 9 decimal positions, so there are N*9 combinations.there are M positive values in N, where M = (N-1)/2when we have a value N and we multiply it by 9, we have the result R

EDIT:having a look in the Float class JavaDoc you can easily pick the Sign, Mantissa and exponent

Quote

Bit 31 (the bit that is selected by the mask 0x80000000) represents the sign of the floating-point number. Bits 30-23 (the bits that are selected by the mask 0x7f800000) represent the exponent. Bits 22-0 (the bits that are selected by the mask 0x007fffff) represent the significand (sometimes called the mantissa) of the floating-point number. If the argument is positive infinity, the result is 0x7f800000. If the argument is negative infinity, the result is 0xff800000.

I have made a specialised version of the method i created which is purely for 8 digit (or less) numbers... numbers higher than 99999999 will be set to 99999999 and numbers below -99999999 will be set to -99999999.

I think you need to back up and explain why you think you can, or should, invent a more efficientway to store floats than the native float type. Some very smart people designed the IEEE floatingpoint representation.

One should always be thinking of better solutions to problems! be that as it may, i am not attempting to make a "better" float, rather i have specific requirements which storing as a native float is not a good fit.

1. the number has a fixed maximum number of digits. e.g. 62. the number needs to be represented with as few bits as possible.3. the encoded number should represent the actual number as close as possible.3. the number has a maximum number derived from the maximum number of digits... e.g. for 6 digits, the max number is 999999.3. likewise, the number has a minimum number derived from the maximum number of digits... e.g. for 8 digits, the minnumber is -999999.4. the precision of the number is determined by the number of digits used in the "integer" part of the number with the remaining digits are used to represent the "fractional" part of the number.. e.g. representing the floating point number 812.633445: it uses 3 digits for the integer part leaving 3 digits for the fractional part giving the number 812.633

There can be reasons - for example in financial programs, you can never use normal floating point torepresent money, because rounding errors would cause your numbers to not add up properly. In thiscase, it soulds like your specifications arise from a communications protocol - ie; a 6 digit field, wherethe contstraints are on the representation, not on the underlying numbers.

I think you would do best by using regular floating point to represent your numbers, and meet yourconstraints by controlling the conversion to and from floating point.

If this is a programming exercise "see how good a codec you can design" then of course go for it. But be awarethat real codecs are designed by very smart people with a lot of science and math at their disposal.. You are unlikelyto do better. There could be exceptions, if you have a particular video application in mind and you can apply domain specific knowledge in ways that a general codec couldn't.

If you haven't already done so, read the specs for existing codecs such as JPEG and MP3. It's really interesting reading.

On a similar note, if you read the IEEE floating point spec, it's fairly obvious how to use the designbut reduce the size of the exponent and matissa so they can only represent numbers in the rangesyou've specified. You'd end up with a few less bits - maybe 24 instead of 32 bits

i am not sure whether you are meaning to come across as a little insulting but one could read your replies that way.

Yes i do not think for a second that i will create a mpeg-4 or h264 killer codec i simply had an idea and want to implement it.

For my final year thesis I did develop a lossless codec which was specifically designed for animated video or similar which was able to out perform ( in terms of compression) the readily available codecs.

I wanted to try my hand at a lossless codec but trying a totally new approach. I do not think it will even get close to the compression from the current state of the art codecs but i have to start some where no?

I agree, the IEEE floating point spec can be readily converted to use less bits. I just thought that it would be a performance overhead to implement my on IEEE floating point class when another solution better suited to my problem could be deleveloped which would be faster.

Yes i do not think for a second that i will create a mpeg-4 or h264 killer codec i simply had an idea and want to implement it

you should! it is always good to beleave in yourself at least I do

@ddyer : you cant imagine all stuff that havn't been done yet , so doing computer research is always good, and is especially fun/interrisitng to do even when you fall with something useless. I love reinventing the whell as I think this is the only way to find real new stuff. My personal feeling about that is that reading paper and applying them dont bring to new stuff as papers "format" you. A good example is the DIVX format that have been created by someone that was playing to do a new codec lucky him

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org