-2

I was theorizing a new kind of 64-bit number for use in data storage, but then started wondering if it could become practical if created in hardware. (I believe it would be too slow if only software could interpret it).

Encoding

Bits 0-7: a (8-bit signed integer)

Bits 8-15: b (8-bit signed integer)

Bits 16-39: c (24-bit signed floating-point: 1b sign, 7b exponent, 16b mantissa)

Bits 40-64: d (24-bit unsigned floating-point: 8b exponent, 16b mantissa)

Formula: a^b+cd

Note that I've asked StackOverflow how the two 24-bit floating-point numbers should be encoded and the minimum value of these.

Justification

Using this, Wolfram|Alpha says the positive smallest non-zero number is about the ratio of 3 planck lengths to 1 kilometer and the largest positive number is insanely larger than the number of atoms in a ball of carbon the size of our known universe

Problem

Let's, for this question only, ignore the fact that there are likely huge gaps in the possible numbers.

To decode this is trivial. We can easily construct an ALU that can raise one 8-bit number to the power of another, and then add that to the product of one 24-bit floating-point number to another. The problem comes in encoding. I have no idea what algorithm might discover the best way to encode 12,345,678,901,234,567,890,123,456,789,012,345,678,901,234,567,890.98765432109876543210987654321, despite the fact that that's a perfectly reasonable number for this format to represent. Still, I know that whatever algorithm is best for this, it would be faster on hardware than software (duh). My question, here, is would such an algorithm be practically built onto a silicon wafer, or would it be too complex, require too much memory, etc.?

Also, I'm very new to this kind of question. If you can help me re-word it, I'd be very grateful

Ky -
  • 107
  • 5
  • 4
    The bigger question is... how would you perform math with such an encoding? For all its weaknesses, IEEE 754 (and 854, by extension) is very practical to use. – Ignacio Vazquez-Abrams Jul 19 '14 at 03:24
  • @IgnacioVazquez-Abrams that's a very big question. Like I started with, I designed this to store numbers, not to calculate them. Coming up with these algorithms, I think, it paramount to designing the first microchip that can do floating-point operations. – Ky - Jul 19 '14 at 03:33
  • 1
    Some things, like floating point math on the ARM architecture, are not that much faster in hardware. Vector operations are where hardware pulls ahead strongly. A practical bit of hardware for this depends on the usefulness and advantages. – C. Towne Springer Jul 19 '14 at 03:35
  • I don't see what the point of such a complex representation is. Standard [IEEE-754 double-precision representation](http://en.wikipedia.org/wiki/Double-precision_floating-point_format), with its 11-bit exponent field, already has more dynamic range than what you're proposing, using the same 64 bits. – Dave Tweed Jul 19 '14 at 03:42
  • @C.TowneSpringer Fascinating... so it would be the same speed to use a well-assembled C program as it would the same program built on a wafer in gates? – Ky - Jul 19 '14 at 03:45
  • 1
    Pretty close. And you don't need to rearrange the wiring in order to get it to do something different. – Ignacio Vazquez-Abrams Jul 19 '14 at 03:51
  • @DaveTweed IEEE-754 cannot accurately represent numbers as large or as small as mine. IEEE-754 goes as high as ~1.8×10^308, and as low as ~2.2×10^−308. As my math shows, this range is infinitesimally smaller than my format – Ky - Jul 19 '14 at 03:54
  • I think it would be a full blown research project to evaluate the pros and cons of using this encoding. I think it has potential, but would have to be looked at in quite a bit of detail. – kjgregory Jul 19 '14 at 04:39
  • You're wrong. Ignoring the \$cd\$ term for the moment, since its dynamic range is limited, your \$a^b\$ term has a dynamic range of \$127^{-128} = 5.165 \cdot 10^{-270}\$ to \$127^{127} = 1.524 \cdot 10^{267}\$. And the accuracy at those extremes is *very* limited, since the \$cd\$ term must be set to zero. – Dave Tweed Jul 19 '14 at 11:10
  • 1
    @DaveTweed - Why do the cd terns need to be set to zero? It only need to be set to zero for the large negative exponents. For large positive exponents it can take on a large value and increase the dynamic range (admittedly, not by much). – WhatRoughBeast Jul 19 '14 at 11:23
  • @WhatRoughBeast: Verbal shorthand. The *cd* term is effectively zero at the high end because its dynamic range is so much less than the \$a^b\$ term. \$2^{63} \cdot 2^{127} = 2^{190} = 1.569 \cdot 10^{57}\$ and \$2^{-64} \cdot 2^{-128} = 2^{-192} = 1.593 \cdot 10^{-58}\$ You would be better off using those 48 bits for a single floating-point number that has 1 sign bit, 9 exponent bits and 38 mantissa bits. – Dave Tweed Jul 19 '14 at 11:50
  • @DaveTweed - Oh, I quite agree about the representation, it's just that I thought you were claiming that, for some reason, the cd term MUST be set to zero (imperative form), rather than "it can be ignored". Obviously it MUST be set to zero when evaluating large negative exponents, and that's what had me confused. – WhatRoughBeast Jul 19 '14 at 12:54
  • 3
    This question appears to be off-topic because it is about some arbitrary number coding smashed into a question by asking if "building a chip is practical" when fundamentally practicality is entirely opinion based. Anything EE based on this question is secondary to the flawed primary aspect. – placeholder Jul 19 '14 at 15:40
  • 1
    @placeholder: Actually, this is probably the best place to discuss hardware representations of numbers, since it relates to the *implementation* of computer systems. The mathematicians are not interested in such questions, although it requires some serious math to analyze the properties of various representations. This topic is a bit of a "hot button" for me, because I was directly involved in the design of large-scale scientific computers back in the early 1980s, when the industry was starting to shift from proprietary number representations to IEEE-754/854. – Dave Tweed Jul 19 '14 at 19:16
  • @DaveTweed I understand where you are coming from and I'd agree if the OP was well formed. As it stands it's just a very odd implementation of a coding scheme with no justification for _why_ it exists. On top of that it is obviously very flawed -> even if it wasn't it could be easily closed as being overly broad. On top of that, the practicality of building a chip is very dependant upon circumstance. Maybe this morphs into a better question on number representation and trade offs? – placeholder Jul 19 '14 at 19:24
  • Also, the OP's "extreme" dynamic ranges are not really all that extreme. The ratio between the Planck length and 1 km, and the ratio between the diameter of the universe and the diameter of a carbon atom are both on the order of \$10^{38}\$, which is within the range of ordinary single-precision floating-point representations. Even the ratio between the *volume* of the universe and a "Planck volume" is only on the order of \$10^{185}\$. – Dave Tweed Jul 19 '14 at 19:25
  • I believe that OP idea is having a "wide enough" dynamic while keeping a very high precision where IEEE-754/854 fails. *How* he wants to achieve that is completaly obscure to me. – Vladimir Cravero Jul 19 '14 at 20:11
  • Yes, my idea is hopefully a way to keep a high dynamic range and still retain precision. To be honest, I'm not a mathematician, and there's likely plenty of tweaking to this concept of a^b+cd before it achieves the optimal solution. I just want to know if this format should ever even be put to silicon before I start research to perfect it. – Ky - Jul 20 '14 at 18:17

1 Answers1

1

Regarding whether it's practical to build a custom chip (ASIC):

Short answer is 'no', unless you manage to prototype your design in an FPGA first.

The encoding scheme you hint at, sounds like a search for a combination of the four fields that gives the least error for a given constant to be encoded. In principle this search can be done in parallel. You could implement this on software or hardware.

In software, you could use multi-threaded program coding techniques and run the software on a modern multi-core CPU or a GPU. A master thread would partition the search range among the worker threads, and coordinate the results.

In hardware, you could use an array of encoder modules (which you will have to design) with the search range partitioned among the encoders and some other hardware to coordinate the results.

I have no idea whether software or hardware would perform better in this particular case, since it's not really clear to me what your actual encoder hardware design needs to do. But whatever route you choose, I suspect scalability and parallelization will be key.

As a practical matter, try a proof-of-concept encoder on an FPGA board first. Then you can evaluate its performance with just the cost of an FPGA board. (Xilinx and Altera both have free versons of their design tools). Transferring a working Verilog/VHDL design from FPGA into to a silicon ASIC becomes a much more practical question.

If you're really set on building hardware, and you want to move beyond an FPGA prototype to an Application-Specific Integrated Circuit, this classic question explains in more detail what's actually involved in making an ASIC and why the development cost is so high. How are integrated circuits fabricated?

That said... you can't just throw a vague idea over the wall and expect it to magically be solved 'in silicon'. Until you get a better grip on the problem of how to actually encode values, you don't really have a practical design to implement in either software or hardware. So your best bet is to grab whichever tools you are most familiar with, whether that's C or Java or Verilog or VHDL, and start working on the encoding problem. Maybe start with a scaled-down version of your encoding, still with four fields but fewer bits -- that limits the search space, and improves the odds of finding an encoding method that will terminate (succeed) in a reasonable period of time.

P.S. Regarding the number encoding scheme itself:

To unseat an established, incumbent floating-point number format such as IEEE-754, the new format needs to demonstrate greatly improved performance -- not just extended dynamic range, but also reduced 'machine epsilon' (roundoff error) better than 10^-16 over the entire range.

There's also the question of whether it's possible to do any kind of arithmetic operations with this format directly, or if this format is only good for storing a precise number in 64-bits. I don't see the value of a format that only lets me store a number but not do any comparison testing or even simple arithmetic. If I have to use IEEE-754 to do anything with the number, I could lose the supposed benefits of the new format (precision or dynamic range) when the number is unpacked. So without native math library support I remain skeptical.

Community
  • 1
MarkU
  • 14,413
  • 1
  • 34
  • 53
  • Thank you! My next step is to head over to Math.SE to see if they can help find a formula or algorithm to encode these. Also, I like the idea of making a smaller version, like how classrooms might teach the idea of floating-point with an 8-bit version. I was considering doing this before, and I will give it more credence, now. – Ky - Jul 20 '14 at 18:24
  • I was thinking the arithmetic could be done using similar math as in Mathematica or with "Big" number libraries, instead of IEEE-754 math. – Ky - Jul 20 '14 at 18:27