Unary representation of floating-point numbers

Question

When the Find the inverse of a number 1/x challenge has been posted, the author posted a bounty for the shortest Retina submission. After that, there was a bounty for sed, another text/string-based language. Since the challenge requires I/O with floating-point numbers, this brings forth a question: how will floating-point numbers be represented in unary?

In unary an integer, say 5, would be represented with that many zeroes, in this case, 00000. What about decimal places? One suggestion was to do the same thing for decimal places as well, for example 4.3 would be 0000.000... BUT what about 4.03? It will share its representation with 4.3, so clearly this way of using unary to show decimal numbers (as in decimal places and not base-10 numbers) would not be valid.

How do we represent floating-point numbers in unary?

Answer 1

We shouldn't

The question as written puts the cart before the horse. Before asking how to do something, it's always worth asking whether there's any point to doing it. In this case, there is none.

The reason for allowing unary as a number format for natural numbers is that it is the natural way of representing them in some languages. There is no language which has a unary format which is the natural way of representing floating point numbers (or, come to that, fixed point numbers or rational numbers). As the other answers to this question show, it's fitting a round peg into a square hole and it isn't going to help anyone.

Answer 2

Use two numbers, a and b, to represent a/2^b or a/2^(b-1), whichever is more convenient. This is like how floating point numbers stored internally in most languages and architectures.

For example, 11111111111 111 means 11/2^3 = 1.375.

I doubt this would be the most natural way to to represent (approximated) real numbers. But you are asking about floating-point numbers, not rationals or fixed-point numbers.

Answer 3

I propose the following solution:

4.3   --> 1111.111
4.03  --> 1111.111111111111111111111111111111 (30 '1's)
4.003 --> 1111.111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 (300 '1's)

3.14  --> 111.11111111111111111111111111111111111111111 (41 '1's)
3.41  --> 111.11111111111111    (14 '1's)
1.0   --> 1.
1.10  --> 1.1

Basically, take the decimal number after the decimal point, reverse it, and convert that to unary.

Advantages:

• Simple.

• Doesn't require complex base conversion.

• A unique representation for every number.

Disdvantages:

• Gets really long as precision increases (but this is always a problem with unary)

• Leading zeros are lost (so 4.2 and 4.20 and 4.200000000... all have the same representation)

• Numbers with a periodic representation in base 10 (e.g. 1/3) cannot be represented very precisely.

Overall, the whole problem is weird, so I think this is as good a solution as your going to get.

Answer 4

Unary as a Bijection between the Naturals to the Rationals

My suggestion is simple. You choose your favorite bijection between the natural numbers and the rational numbers and you use it.

There are many such bijections to choose from. Here are two of my favorites:

• The Stern-Brocot Tree

• The Calkin-Wilf Tree

---

Why is this a good idea?

In my opinion including a decimal is not Unary. The reason we allow unary is to allow programming languages that cannot reasonably take input in other ways to compete. Including the decimal altogether defeats the purpose of allowing unary in the first place.

This circumvents the problem by having every natural number correspond to one rational number so that every number can be represented as a sequence of one character (most of the time 1).

It is also pretty flexible, there are many bijections between the natural numbers and the rationals so if one doesn't work for some reason you can always switch to a new one. We don't prescribe a specific bijection that everyone has to follow.

Drawbacks

While I do believe that this is the best option here it is worth mentioning that mathematical calculations with such numbers may be extremely difficult, especially with languages that have restricted operations.

Example calculations

Here are some examples using the Stern-Brocot Tree as a bijection.

Decimal | Fraction | Natural number | Unary 
  1.0  ->   1/1   ->       1       -> 1
  .5   ->   1/2   ->       2       -> 11  
  .75  ->   3/4   ->       11      -> 11111111111 
  4.0  ->   4/1   ->       15      -> 111111111111111

Answer 5

There are issues with repeating decimals, and I'm not sure if this is a good idea or not, but here we go...

We can introduce a second decimal point, which will tell us how many digits (from the end) are repeated infinitely. This can fit both proposals.

For example, in ETHProductions' proposal, this is how you can represent 1/3:

.11.11

Since 0.01 gets turned into .11, and the 01 bit is repeated infinitely, the second decimal point has two 1s.

This is 1/3 in DJMcMayhem's proposal:

.111.1

Since 0.3 gets turned into .111, and the 3 bit is repeated infinitely, the second decimal point has only one 1.

This should work for all repeating decimals.

More examples in both formats:

1/6:
Decimal:    0.16...               (6 recurs)
Binary:     0.001...              (01 recurs)
ETH format: 0.1111.11
DJ format:  0.{61 1's}.11

1/7:
Decimal:    0.142857...           (142857 recurs)
Binary:     0.001...              (001 recurs)
ETH format: 0.1111.111
DJ format:  0.{758241 1's}.111111

1/11:
Decimal:    0.09...               (09 recurs)
Binary:     0.0001011101...       (0001011101 recurs)
ETH format: 0.{744 1's}.{10 1's}
DJ format:  0.{90 1's}.11

In decimals which aren't repeating, you can just leave the second decimal place out. For example:

1/2:
Decimal:    0.5
Binary:     0.1
ETH format: 0.1
DJ format:  0.11111

Answer 6

I propose the following solution:

Binary -> Unary
.0    -> .
.1    -> .1
.01   -> .11
.11   -> .111
.001  -> .1111
.101  -> .11111
.011  -> .111111
.111  -> .1111111
.0001 -> .11111111
etc.

That is, to convert the fractional bits of a binary number to unary, reverse the bits, convert to unary, and append the result after the decimal point. As a basic example:

.011 -> 110. -> 6. -> 111111. -> .111111

So 4.375 in decimal would be 1111.111111 in unary (4 -> 1111, .375 -> .111111, as above)

This has the disadvantage of not being able to exactly represent decimal numbers such as 0.7, but of course, binary has the same disadvantage. The difference with this system is that there's no periodic pattern of digits either, but it would be impossible to create a periodic pattern in any unary system; any periodic decimal would just be represented by infinite 1s in unary.

I know this system isn't perfect, but it's a start...

Answer 7

5.3204 => 00000.000 00 0000

Every digit after the decimal point is displayed separately, with a space between every digit. Zero, as you can see, is not displayed and can be noticed by the spaces.