Upper limits for fibonnacci - java

I was reading about the DP version of fibonnaci.
In Sedgewick I saw:
int[] T = new int[47]; for storage of the previous calculations. Elsewhere I saw that the max input for fibonacci should be less than 92.
It is not clear to me how does these numbers come up? I understand that it has to do with overflow and size of int but I am not clear how we end up with these limits.
Any help?

There is a closed-form expression for the n-th Fibonacci number, Binet's formula,
F(n) = (φ^n - ψ^n) / (φ - ψ)
where
φ = (1 + √5)/2; ψ = 1 - φ = -1/φ
Now |ψ| < 1, so the ψ^n term converges to 0 pretty fast, hence in estimating the size of F(n) it can be ignored except for the first few numbers.
So if you have an integer type with b bits used for the representation of positive integers, you can represent the Fibonacci numbers with
F(n) < 2^b
(since the maximal number that can be represented is 2^b - 1). Ignoring the ψ^n term and using φ - ψ = √5, we find the condition
φ^n < 2^b * √5
<=> n*log φ < b*log 2 + 1/2*log 5
<=> n < b*(log 2 / log φ) + 1/2*(log 5 / log φ)
log 2 / log φ ≈ 1.44042009 and 1/2*(log 5 / log φ) ≈ 1.672275938, so with a signed 32-bit integer type (which has 31 bits to represent positive numbers, since one bit is used for the sign), you can represent the Fibonacci numbers for
n < 31*(log 2 / log φ) + 1/2*(log 5 / log φ) ≈ 44.65 + 1.67 ≈ 46.32
i.e. the 47 Fibonacci numbers with index between 0 and 46 (inclusive). With an unsigned 32-bit integer type you could also represent F(47).
With a signed 64-bit integer type, you can represent the Fibonacci numbers for
n < 63*(log 2 / log φ) + 1/2*(log 5 / log φ) ≈ 90.75 + 1.67 ≈ 92.42
and with an unsigned 64-bit integer type You can also represent F(93).

Well, the fibonacci series grows (approximately) exponentially with a ratio of 1.618 (the golden ratio).
If you take the log base 1.618 of Integer.MAX_VALUE it will therefore tell you approximately how many iterations you can go before overflowing....
Alternatively, you can determine empirically when it overflows just by doing the calculations....

(signed) int has a value range of −2.147.483.648 ... 2.147.483.647, so storing a fibonanacci number larger than 2.147.483.647 does not work.
The question now is: What is the first fibonnacci number larger than that value?
Spreadsheet says:
n fib(n)
1 0
2 1
3 1
4 2
5 3
6 5
7 8
8 13
9 21
10 34
11 55
12 89
13 144
14 233
15 377
16 610
17 987
18 1597
19 2584
20 4181
21 6765
22 10946
23 17711
24 28657
25 46368
26 75025
27 121393
28 196418
29 317811
30 514229
31 832040
32 1346269
33 2178309
34 3524578
35 5702887
36 9227465
37 14930352
38 24157817
39 39088169
40 63245986
41 102334155
42 165580141
43 267914296
44 433494437
45 701408733
46 1134903170
47 1836311903
48 2971215073
49 4807526976
So you can see: fibonnacci numbers after #47 won't fit in a (signed) int.
To clarify: Unlike C Java does not have unsigned types. So the emphasis on signed int is kind of obsolete.

You may use following formula:
F(2n) = F(n)* (2*F(n-1) + F(n))
n=46
F(92) = F(46) * (2*F(45) +F(46))
This is a Matrix Form of Fibonacci.
Full list of number (ulong not overflowed)
1 1
2 1
3 2
4 3
5 5
6 8
7 13
8 21
9 34
10 55
11 89
12 144
13 233
14 377
15 610
16 987
17 1597
18 2584
19 4181
20 6765
21 10946
22 17711
23 28657
24 46368
25 75025
26 121393
27 196418
28 317811
29 514229
30 832040
31 1346269
32 2178309
33 3524578
34 5702887
35 9227465
36 14930352
37 24157817
38 39088169
39 63245986
40 102334155
41 165580141
42 267914296
43 433494437
44 701408733
45 1134903170
46 1836311903
47 2971215073
48 4807526976
49 7778742049
50 12586269025
51 20365011074
52 32951280099
53 53316291173
54 86267571272
55 139583862445
56 225851433717
57 365435296162
58 591286729879
59 956722026041
60 1548008755920
61 2504730781961
62 4052739537881
63 6557470319842
64 10610209857723
65 17167680177565
66 27777890035288
67 44945570212853
68 72723460248141
69 117669030460994
70 190392490709135
71 308061521170129
72 498454011879264
73 806515533049393
74 1304969544928657
75 2111485077978050
76 3416454622906707
77 5527939700884757
78 8944394323791464
79 14472334024676221
80 23416728348467685
81 37889062373143906
82 61305790721611591
83 99194853094755497
84 160500643816367088
85 259695496911122585
86 420196140727489673
87 679891637638612258
88 1100087778366101931
89 1779979416004714189
90 2880067194370816120
91 4660046610375530309
92 7540113804746346429
As we see
45 1134903170
46 1836311903
92 7540113804746346429
7540113804746346429 = 1836311903*(2*1134903170 + 1836311903)

First, is already done some classes for representing large numbers beyond the limits for some primitive type, like with some C modifier of the type long long. To see the largest term look on largest known Fibonacci number.

Related

Output 12 Times Tables Java

I am trying to output 12 times tables. Where it will go through all the times tables from 1 to 12. And each times table will go up to *12. For examples, the output should look something like this:
1 2 3 4 5 6 7 8 9 10 11 12
2 4 6 8 10 12 14 16 18 20 22 24
3 6 9 12 15 18 21 24 27 30 33 36
...
12 24 36 48 60 72 84 96 108 120 132 144
Here is the code I have so far, I seem to be very close. But I am struggling with perfecting it.
public class Tables {
public void generateTable()
{
//Put the code for your times-table here
int i;
int j;
for(i=1; i<=12; i++)
{
for(j=i; j<=i*12; j = j+1)
{
System.out.print(j*i + " ");
}
System.out.println();
}
}
public static void main(String args[])
{
Tables t = new Tables();
t.generateTable();
}
}
I am receiving the following output for this code:
1 2 3 4 5 6 7 8 9 10 11 12
4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48
9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99 102 105 108
...
In the inner loop, you only want to go from 1 to 12 instead of from i to i*12.
You could also declare i and j more local in the respective loop where the initialization is done.

Why does array[idx++]+="a" increase idx once in Java 8 but twice in Java 9 and 10?

For a challenge, a fellow code golfer wrote the following code:
import java.util.*;
public class Main {
public static void main(String[] args) {
int size = 3;
String[] array = new String[size];
Arrays.fill(array, "");
for (int i = 0; i <= 100;) {
array[i++ % size] += i + " ";
}
for (String element: array) {
System.out.println(element);
}
}
}
When running this code in Java 8, we get the following result:
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100
2 5 8 11 14 17 20 23 26 29 32 35 38 41 44 47 50 53 56 59 62 65 68 71 74 77 80 83 86 89 92 95 98 101
3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99
When running this code in Java 10, we get the following result:
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100
The numbering is entirely off using Java 10. So what is happening here? Is it a bug in Java 10?
Follow ups from the comments:
The issue appears when compiled with Java 9 or later (we found it in Java 10). Compiling this code on Java 8, then running in Java 9 or any later version, including Java 11 early access, gives the expected result.
This kind of code is non-standard, but is valid according to the spec. It was found by Kevin Cruijssen in a discussion in a golfing challenge, hence the weird use case encountered.
Didier L simplified the issue with this much smaller and more understandable code:
class Main {
public static void main(String[] args) {
String[] array = { "" };
array[test()] += "a";
}
static int test() {
System.out.println("evaluated");
return 0;
}
}
Result when compiled in Java 8:
evaluated
Result when compiled in Java 9 and 10:
evaluated
evaluated
The issue seems to be limited to the string concatenation and assignment operator (+=) with an expression with side effect(s) as the left operand, like in array[test()]+="a", array[ix++]+="a", test()[index]+="a", or test().field+="a". To enable string concatenation, at least one of the sides must have type String. Trying to reproduce this on other types or constructs failed.
This is a bug in javac starting from JDK 9 (which made some changes with regard to string concatenation, which I suspect is part of the problem), as confirmed by the javac team under the bug id JDK-8204322. If you look at the corresponding bytecode for the line:
array[i++%size] += i + " ";
It is:
21: aload_2
22: iload_3
23: iinc 3, 1
26: iload_1
27: irem
28: aload_2
29: iload_3
30: iinc 3, 1
33: iload_1
34: irem
35: aaload
36: iload_3
37: invokedynamic #5, 0 // makeConcatWithConstants:(Ljava/lang/String;I)Ljava/lang/String;
42: aastore
Where the last aaload is the actual load from the array. However, the part
21: aload_2 // load the array reference
22: iload_3 // load 'i'
23: iinc 3, 1 // increment 'i' (doesn't affect the loaded value)
26: iload_1 // load 'size'
27: irem // compute the remainder
Which roughly corresponds to the expression array[i++%size] (minus the actual load and store), is in there twice. This is incorrect, as the spec says in jls-15.26.2:
A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T) ((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.
So, for the expression array[i++%size] += i + " ";, the part array[i++%size] should only be evaluated once. But it is evaluated twice (once for the load, and once for the store).
So yes, this is a bug.
Some updates:
The bug is fixed in JDK 11 and was back-ported to JDK 10 (here and here), but not to JDK 9, since it no longer receives public updates.
Aleksey Shipilev mentions on the JBS page (and #DidierL in the comments here):
Workaround: compile with -XDstringConcat=inline
That will revert to using StringBuilder to do the concatenation, and doesn't have the bug.

Regarding printf use in nested for loop (multiplication table)

Have a problem with my output when creating a multiplication table 1-12 inclusive. below is my code and output
public class Multiplication
{
public static void main(String[]args)
{
int row,column;
System.out.println("Below is a multiplication table from 1-12 inclusive");
for (row=1;row<=12;row++)
{
System.out.printf("%4d\n",row);
for (column=1;column<=12;column++)
System.out.printf("%6d",row*column);
}
}
}
and my output is
Below is a multiplication table from 1-12 inclusive
1
1 2 3 4 5 6 7 8 9 10 11 12 2
2 4 6 8 10 12 14 16 18 20 22 24 3
3 6 9 12 15 18 21 24 27 30 33 36 4
4 8 12 16 20 24 28 32 36 40 44 48 5
5 10 15 20 25 30 35 40 45 50 55 60 6
6 12 18 24 30 36 42 48 54 60 66 72 7
7 14 21 28 35 42 49 56 63 70 77 84 8
8 16 24 32 40 48 56 64 72 80 88 96 9
9 18 27 36 45 54 63 72 81 90 99 108 10
10 20 30 40 50 60 70 80 90 100 110 120 11
11 22 33 44 55 66 77 88 99 110 121 132 12
12 24 36 48 60 72 84 96 108 120 132 144
My problem is in getting the far right column to be on the far left. I've tried researching why only the number '1' appears and then it jumps but cant find anything
Your problem is the first of your two printf statements. You should just be able to replace it with System.out.printf("\n");.
(The "jump" to which you refer is a newline, which is represented by the \n character.)
Try this:
public class Multiplication
{
public static void main(String[]args)
{
int row,column;
System.out.println("Below is a multiplication table from 1-12 inclusive");
for (row=1;row<=12;row++)
{
System.out.printf("%4d",row);
for (column=1;column<=12;column++)
System.out.printf("%6d",row*column);
System.out.printf("\n");
}
}
}
for (row=1;row<=12;row++)
{
System.out.printf("%4d",row);
for (column=1;column<=12;column++)
System.out.printf("%6d",row*column);
if(column==12) System.out.printf("\n");
}

Problem with Project Euler problem 18 [closed]

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I'm currently trying to solve problem 18 of project Euler. The goal is:
By starting at the top of the triangle below and moving to adjacent numbers on the row below, the maximum total from top to bottom is 23.
3
7 4
2 4 6
8 5 9 3
That is, 3 + 7 + 4 + 9 = 23.
Find the maximum total from top to bottom of the triangle below:
75
95 64
17 47 82
18 35 87 10
20 04 82 47 65
19 01 23 75 03 34
88 02 77 73 07 63 67
99 65 04 28 06 16 70 92
41 41 26 56 83 40 80 70 33
41 48 72 33 47 32 37 16 94 29
53 71 44 65 25 43 91 52 97 51 14
70 11 33 28 77 73 17 78 39 68 17 57
91 71 52 38 17 14 91 43 58 50 27 29 48
63 66 04 68 89 53 67 30 73 16 69 87 40 31
04 62 98 27 23 09 70 98 73 93 38 53 60 04 23
I tried to solve it with the following algorithm:
public static void main(String[] args) throws NumberFormatException, IOException {
int[][] values = readFile();
int depth = values.length - 2;
while ( depth >= 0) {
for (int j = 0; j < depth; j++) {
values[depth][j] += Math.max( values[depth+1][j], values[depth+1][j+1]);
}
depth += -1;
}
values[0][0] += Math.max(values[1][0], values[1][1]);
System.out.println("The maximum path sum is: " + values[0][0]);
}
The array values contains all the numbers from the triangle where values[0][0] is the element in the top row and values[n][n] is the last element in the last row.
The algorithm uses the approach that if for example I start in the last row and have the choice between 04 + 63 and 62 + 63, the sum of the field in which 63 was will be set to 125 because this is the highest amount. This algorithm works for the small triangle, but for the big triangle it seems to fail. I'm not sure why and would appreciate every hint.
I believe that the line:
for (int j = 0; j < depth; j++) {
should be
for (int j = 0; j <= depth; j++) {
because right now you aren't visiting the last element on each row. Of course, then you don't need the line
values[0][0] += Math.max(values[1][0], values[1][1]);
because it is already done in the loop.
I don't know the correct algorithm, but there's an easy proof of #Johns comment on the question, that the best local choice doesn't necessarily lead to the best global solution.
Consider this (extreme) example:
1
1 0
1 0 1000
1 0 0 0
1 0 0 0 0
Given your algorithm, you'd obviously go down the very left of the path and never read the 1000 that must be on the best path.
This may not be the best solution, but what if for each iteration you kept track of the sum to that point. Then when you go to the last row the max value would be your answer.

Java: Simple Combination of a set of element of k order

I have a set of numbers {'1','13','25','32','49',...}, i want to calculate all possible combinations of this numbers of order k.
Esample1:
set = {'1','5','23','41,'54','63'};
k = 4;
Output1:
1 5 23 41
1 5 23 54
1 5 23 63
1 5 41 54
1 5 41 63
1 5 54 63
1 23 41 54
1 23 41 63
1 23 54 63
1 41 54 63
5 23 41 54
5 23 41 63
5 23 54 63
5 41 54 63
23 41 54 63
Example2:
set = {'a','v','f','z'};
k=3;
Output2:
a v f
a v z
a f z
v f z
in Java plaese.
Thank you!
You should be able to find an appropriate algorithm in D.Knuth's The Art of Computer Programming, Volume 4, fascicle 3 - Generating All Combinations, which can be downloaded from his website.

Categories