How many operations can we do with an 8-digit (plus decimal) calculator? - decimal

I have this model: a simple 8-digit display calculator (no memory buttons, no square root etc etc) has buttons (the decimal point does not count as a 'digit'):
10 buttons for integers 0 to 9,
1 button for dot (decimal point, so it can hold decimals, like from 0.0000001 to 9999999.9),
4 buttons for operations (+, -, /, *), and
1 button for equality (=). (the on/off button doesn't count for this question)
The question is two-fold: how many numbers can they be represented on the calculator's screen? (a math-explained solution would be appreciated)
*AND
if we have to make all 4 basic operations between any pair of 2 numbers, of the above calculated, how many operations would that be?
Thank you for your insight and help!

For part one of this answer, we want to know how many numbers can be represented on the calculator's screen.
Start with a simplified example and work up from there. Let's start with a 1-digit display. With this calculator, you can display the numbers from 0 to 9, and you can display each of those numbers with a decimal point either before the digit (making it a decimal), or after the digit (making it an integer). How many unique numbers can be made?
.0, .1, .2, .3, .4, .5, .6, .7, .8, .9, 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.
That's 20 possibilities with 1 repeat number makes 19 unique numbers. Let's find this result again, but using a mathematical approach that we can scale up to a larger number of digits.
Start by finding all the numbers 0 <= n < 1 that can be made. For the numbers to fit in that range, the decimal point must be before the first digit. We're still dealing with 1 digit, so there are 101 different ways to fill the calculator with numbers that are greater than or equal to 0, but less than 1.
Next, find all the numbers 1 <= n < 10 that can be made. To do this, you move the decimal point one place to the right, so now it's after the first digit, and you also can't allow the first digit to be zero (or the number will be less than 1). That leaves you 9 unique numbers.
[0<=n<1] + [1<=n<10] = 10 + 9 = 19
Now we have a scaleable system. Let's do it with 2 digits so you see how it works with multiple digits before we go to 8 digits. With 2 digits, we can represent 0-99, and the decimal point can go in three different places, which means we have three ranges to check: 0<=n<1, 1<=n<10, 10<=n<100. The first set can have zero in its first place, since zero is in the set, but every other set can't have zero in the first place or else the number would be in the set below it. So the first set has 102 possibilities, but each of the other sets has 9 * 101 possibilities. We can generalize this by saying that for any number d of digits that our calculator can hold, the set 0<=n<1 will have 10d possibilities, and each other set will have 9 * 10d-1 possibilities
So for 2 digits:
[0<=n<1] + [1<=n<10] + [10<=n<100] = 100 + 90 + 90 = 280
Now you can see a pattern emerging, which can be generalize to give us the total amount of unique numbers that can be displayed on a calculator with d digits:
Unique displayable numbers = 10d + d * 9 * 10d-1
You can confirm this math with a simple Python script that manually finds all the unique numbers that can be displayed, prints the quantity it found, then also prints the result of the formula above. It gets bogged down when it gets to higher numbers of digits, but digits 1 through 5 should be enough to show the formula works.
for digits in range(1, 6):
print('---%d Digits----' % digits)
numbers = set()
for d in range(digits + 1):
numbers.update(i / 10**d for i in range(10**digits))
print(len(set(numbers)))
print(10**digits + digits * 9 * 10**(digits - 1))
And the result:
---1 Digits----
19
19
---2 Digits----
280
280
---3 Digits----
3700
3700
---4 Digits----
46000
46000
---5 Digits----
550000
550000
Which means that a calculator with an 8 digit display can show 820,000,000 unique numbers.
For part two of this answer, we want to know if we have to make all 4 basic operations between any pair of 2 numbers, of the above calculated, how many operations would that be?
How many pairs of numbers can we make between 820 million unique numbers? 820 million squared. That's 672,400,000,000,000,000 = 672.4 quadrillion. Four different operations can be used on these number pairs, so multiply that by 4 and you get 2,689,600,000,000,000,000 = 2.6896 quintillion different possible operations on a simple 8 digit calculator.
EDIT:
If the intention of the original question was for a decimal point to not be allowed to come before the first digit (a decimal 0<=n<1 would have to start with 0.) then the formula for displayable numbers changes to 10d + (d - 1) * 9 * 10d-1, which means the amount of unique displayable numbers is 730 million and the total number of operations is 2.1316 quintillion.

Related

How to compress an integer to a smaller string of text?

Given a random integer, for example, 19357982357627685397198. How can I compress these numbers into a string of text that has fewer characters?
The string of text must only contain numbers or alphabetical characters, both uppercase and lowercase.
I've tried Base64 and Huffman-coding that claim to compress, but none of them makes the string shorter when writing on a keyboard.
I also tried to make some kind of algorithm that tries to divide the integer by the numbers "2,3,...,10" and check if the last number in the result is the number it was divided by (looks for 0 in case of division by 10). So, when decrypting, you would just multiply the number by the last number in the integer. But that does not work because in some cases you can't divide by anything and the number would stay the same, and when it would be decrypted, it would just multiply it into a larger number than you started with.
I also tried to divide the integer into blocks of 2 numbers starting from left and giving a letter to them (a=1, b=2, o=15), and when it would get to z it would just roll back to a. This did not work because when it was decrypted, it would not know how many times the number rolled over z and therefore be a much smaller number than in the start.
I also tried some other common encryption strategies. For example Base32, Ascii85, Bifid Cipher, Baudot Code, and some others I can not remember.
It seems like an unsolvable problem. But because it starts with an integer, each number can contain 10 different combinations. While in the alphabet, letters can contain 26 different combinations. This makes it so that you can store more data in 5 alphabetical letters, than in a 5 digit integer. So it is possible to store more data in a string of characters than in an integer in mathematical means, but I just can't find anyone who has ever done it.
You switch from base 10 to eg. base 62 by repeatedly dividing by 62 and record the remainders from each step like this:
Converting 6846532136 to base62:
Operation Result Remainder
6846532136 / 62 110427937 42
110427937 / 62 1781095 47
1781095 / 62 28727 21
28727 / 62 463 21
463 / 62 7 29
7 / 62 0 7
Then you use the remainder as index in to a base62 alphabet of your choice eg:
0 1 2 3 4 5 6
01234567890123456789012345678901234567890123456789012345678901
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
Giving: H (7) d (29) V (21) V (21) v (47) q (42) = HdVVvq
------
It's called base10 to base62, there bunch of solutions and code on the internet.
Here is my favorite version: Base 62 conversion

Counting binary digits in a list of excel cells

I'm trying to make a formula that transforms a list decimal numbers to binary, then counts the number of appearances of ones at a certain position. I was trying to build an array formula that went something like this:
{=SUM(MID(DEC2BIN(A1:A10;10);9;1)}
This will return #VALUE. Is there a way to do this?
EDIT: examples added
Input (Binary Equivalent)
2 0000000010
3 0000000101
7 0000000111
7 0000000111
5 0000000101
9 0000001001
Outputs Result
(digit to sum
from the right)
1 5
2 3
3 3
4 1
This was another way e.g. for the second digit from the right
=SUMPRODUCT(--ISODD(A1:A10/2))
Divide by 2^(n-1) where n is digit numbered from the right: the ISODD function ignores any fraction that results from the division.
=SUM(0+MID(DEC2BIN(--A1:A10,10),9,1))
array-entered.
Regards
If you are trying to count have many of the second digits are set in a range of numbers you can do this:
={SUM((MOD(A1:A10,4)>=2)+0)}
To understand this, let's look at some example data
Here I have some decimal numbers with their binary equivalents. In column C I have just extracted the 2nd digit (i.e. your MID(A1,9,1)). Then in column D I just take the modulo by 4. You can see that when the remainder is greater than 2, the second digit is set.
MOD(A1,4) basically divides the number by 4 and gives us the remainder (the numerator of the remainder if it was represented as a fraction over 4). With binary numbers, division by a power of two is just a right shift. Division by 4 is a right shift by 2 and the numbers that 'fall off' are the remainder. In this case it's the first two digits. They can be
00 | 0
01 | 1
10 | 2
11 | 3
so we see that the second digit is set only when the remainder is greater than 2.
Note the +0 in the original formula is to cast the boolean result of = to an integer so we can use SUM i.e. SUM({TRUE,FALSE}) doesn't work but SUM({TRUE,FALSE}+0) computes to SUM({1,0}) which does work.
To make this generic, let's assume you want to do it for the $E$1th digit:
=SUM((MOD(A1:A12,2^$E$1)>=2^($E$1-1))+0)
With bit operations it's not necessary to treat the number as a string.
{=SUM(BITAND(A1:A10;2^(C1-1))/2^(C1-1))}
Assuming the position you are looking for is stored in C1.

How to distribute n identical balls into k identical boxes having different capacities

Suppose there are 4 boxes having capacities 10, 5, 2, 1.Please help me in finding number of ways to distribute 16 identical balls into these four boxes. Each box can have 0 to the capacity number of the balls.
We can simplify the question to
"Find number of ways to distribute 2 identical balls into 4 boxes, having capacities 2,2,2 and 1.",
because we can count empty spaces in the original.
1) If we put a ball in 4th box, then we have 3 box for another one - 3 combination.
2) Now we don't put a ball in 4th box at all, so we have 3 box with 2 places.
n^k=2^3=8
In total, we have 8+1=9 combinations.
Let the parts be a_1,...,a_k and sum of them n, there are a total of n! combinations and then so each of the a_i parts are equal so we divide it by all a_i! and then divide it by k!, so the final answer will be:
n!/(a_1! * a_2! * ... * a_k! * k!).
this can be calculate in O(k) with O(n) preprocess using the Fermats theorem.

Normalized values, when summed are more than 1

I have two files:
File 1:
TOPIC:topic_0 1294
aa 234
bb 123
TOPIC:topic_1 2348
aa 833
cc 239
bb 233
File 2:
0.1 0.2 0.3 0.4
This is just the format of my files. Basically, when the second column (omitting the first "TOPIC" line) is summed for each topic, it constitutes to 1 as they are the normalized values. Similarly, in file 2, the values are normalized and hence they also constitute to 1.
I perform multiplication of the values from file 1 and 2. The resulting output file looks like:
aa 231
bb 379
cc 773
The second column when summed of the output file should give 1. But few files have values little over 1 like 1.1, 1.00038. How can I precisely get 1 for the output file? Is it some rounding off that I should do or something?
PS: The formats are just examples, the values and words are different. This is just for understanding purposes. Please help me sort this.
Python stores floating point decimals in base-2.
https://docs.python.org/2/tutorial/floatingpoint.html
This means that some decimals could be terminating in base-10, but are repeating in base-2, hence the floating-point error when you add them up.
This gets into some math, but imagine in base-10 trying to express the value 2/6. When you eliminate the common factors from the numerator and denominator it's 1/3.
It's 0.333333333..... repeating forever. I'll explain why in a moment, but for now, understand that if only store the first 16 digits in the decimal, for example, when you multiply the number by 3, you won't get 1, you'll get .9999999999999999, which is a little off.
This rounding error occurs whenever there's a repeating decimal.
Here's why your numbers don't repeat in base-10, but they do repeat in base-2.
Decimals are in base-10, which prime factors out to 2^1 * 5^1. Therefore for any ratio to terminate in base-10, its denominator must prime factor to a combination of 2's and 5's, and nothing else.
Now let's get back to Python. Every decimal is stored as binary. This means that in order for a ratio's "decimal" to terminate, the denominator must prime factor to only 2's and nothing else.
Your numbers repeat in base-2.
1/10 has (2*5) in the denominator.
2/10 reduces to 1/5 which still has five in the denominator.
3/10... well you get the idea.

Dynamic Programming : Why the 1?

The following pseudocode finds the smallest number of coins needed to sum upto S using DP. Vj is the value of coin and min represents m as described in the following line.
For each coin j, Vj≤i, look at the minimum number of coins found for the i-Vjsum (we have already found it previously). Let this number be m. If m+1 is less than the minimum number of coins already found for current sum i, then we write the new result for it.
1 Set Min[i] equal to Infinity for all of i
2 Min[0]=0
3
4 For i = 1 to S
5 For j = 0 to N - 1
6 If (Vj<=i AND Min[i-Vj]+1<Min[i])
7 Then Min[i]=Min[i-Vj]+1
8
9 Output Min[S]
Can someone explain the significance of the "+1 " in line 6? Thanks
The +1 is because you need one extra coin. So for example, if you have:
Vj = 5
Min[17] = 4
And you want to know the number of coins it will take to get 22, then the answer isn't 4, but 5. It takes 4 coins to get to 17 (according to the previously calculated result Min[17]=4), and an additional one coin (of value Vj = 5) to get to 22.
EDIT
As requested, an overview explanation of the algorithm.
To start, imagine that somebody told you you had access to coins of value 5, 7 and 17, and needed to find the size of the smallest combination of coins which added to 1000. You could probably work out an approach to doing this, but it's certainly not trivial.
So now let's say in addition to the above, you're also given a list of all the values below 1000, and the smallest number of coins it takes to get those values. What would your approach be now?
Well, you only have coins of value 5, 7, and 23. So go back one step- the only options you have are a combination which adds to 995 + an extra 5-value coin, a combination which adds to 993 + an extra 7-value, or a combination up to 977 + an extra 23-value.
So let's say the list has this:
...
977: 53 coins
...
993: 50 coins
...
995: 54 coins
(Those examples were off the top of my head, I'm sure they're not right, and probably don't make sense, but assume they're correct for now).
So from there, you can see pretty easily that the lowest number of coins it will take to get 1000 is 51 coins, which you do by taking the same combination as the one in the list which got 993, then adding a single extra 7-coin.
This is, more or less, what your algorithm does- except instead of aiming just to calculate the number for 1000, it's aim would be to calculate every number up to 1000. And instead of being passed the list for lower numbers in from somewhere external, it would keep track of the values it had already calculated.

Resources