New Floating point number handling concept that can improve processing speed...

[Laff70]

I am new to these forums. I hope this is the right place to put this. I felt someone had to know.

I had this new idea of how to store the data of floating point numbers. Currently the data from "1/3" is stored as "3333333333333/10000000000000". This takes up more bits that it should. It also doesn't store all the data and causes the info to be inaccurate. This is why I propose storing the data as "1/3". It takes up a lot less space. Also the computer doesn't have to process as much by not having to make all those 3s. It saves space and time. I feel it could be extremely useful.
Examples:
Equation: (1/3)+(1/5)
Standard: 5333333333/10000000000
Fraction: 8/15

Equation: (1/3)-(1/5)
Standard: 1333333333/10000000000
Fraction: 2/15

Equation: (1/3)x(1/5)
Standard: 6666666667/10000000000
Fraction: 1/15

Equation: (1/3)/(1/5)
Standard: 1666666667/1000000000
Fraction: 5/3

Tell me what you guys think.

 

[carnageX]

How will fractions be stored though? Remember, computers don't see any numbers besides 0's and 1's.

This is why IEEE-754 standard was made for floating point numbers. IEEE floating point - Wikipedia, the free encyclopedia

I'd look into it if you haven't already.

 

[Laff70]

How will fractions be stored though? Remember, computers don't see any numbers besides 0's and 1's.

This is why IEEE-754 standard was made for floating point numbers. IEEE floating point - Wikipedia, the free encyclopedia

I'd look into it if you haven't already.

I just saw it. The fractions are stored as two integers( the numerator and the denominator). Very simple.

 

[Warmonger]

I am new to these forums. I hope this is the right place to put this. I felt someone had to know.

I had this new idea of how to store the data of floating point numbers. Currently the data from "1/3" is stored as "3333333333333/10000000000000". This takes up more bits that it should. It also doesn't store all the data and causes the info to be inaccurate. This is why I propose storing the data as "1/3". It takes up a lot less space. Also the computer doesn't have to process as much by not having to make all those 3s. It saves space and time. I feel it could be extremely useful.
Examples:
Equation: (1/3)+(1/5)
Standard: 5333333333/10000000000
Fraction: 8/15

Equation: (1/3)-(1/5)
Standard: 1333333333/10000000000
Fraction: 2/15

Equation: (1/3)x(1/5)
Standard: 6666666667/10000000000
Fraction: 1/15

Equation: (1/3)/(1/5)
Standard: 1666666667/1000000000
Fraction: 5/3

Tell me what you guys think.

Where do you get fractions from a floating point number? A float is a number with decimal places. There is no way to optimize a floating point number as it will consume 4 bytes regardless to what you do with it. The FPU itself is a slow unit, and floating point performance has been an issue for several years. You want a new concept for accelerating floating point performance? AMD has already done it, it's called HSA (e.g. GPGPU). Let the GPU cores crunch floating point numbers, that's what they are good at. The only other concept that makes any logical sense is to round your floating point numbers and convert them to an integer using FISTP. Then you can crunch them as a integer which will be much faster than a float on the CPU. After calculated convert them back to a float. Tho this defeats the whole purpose of a float to begin with. So in short, no to be honest your post makes no sense. And secondly, if you want to improve performance of floating point calculations in your application try using GPGPU and letting the GPU in your computer do what it does best. Otherwise there is no real way to optimize a float. I wrote some code to test the performance of both the integer cores and the floating point unit in a computer. I even patched out x87 instruction to use SSE so not to get skewed results on Bulldozer based architectures. The FPU is at least 50% slower than the integer cores in every processor. This is why AMD made the HSA push and why GPGPU is the future of computing. hQ will be the most interesting aspect of Kaveri's launch. As you can queue tasks to the GPU directly without the CPU queuing the task. Meaning you can send tasks directly to the GPU and cut out all CPU overhead. Something I would check into when Kaveri hits shelves in January (rumored launch).