Find the number of unique Fibonacci numbers (don't count repeats) in a vector of positive integers.
Example:
x = [1 2 3 4 5 6 7 8 8] y = 5
Solution Stats
Problem Comments
8 Comments
Solution Comments
Show comments
Loading...
Problem Recent Solvers993
Suggested Problems
-
4495 Solvers
-
1914 Solvers
-
519 Solvers
-
Compute a dot product of two vectors x and y
1051 Solvers
-
6448 Solvers
Problem Tags
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Hello,
As soon as I do test 3, the 499th fibonacci term with 104 digits is converted to a double - should the test be char or strings for the inputs?
if I use int2str() it loses some of the accuracy...
Hello, Bob Tivnan. I agree with Ahmos Sansom that there is a flaw in the current Test Suite. The problem is demonstrated in "Solution 1418487". Please address this, either by changing the input data type (not my preference) or by using numbers with precision compatible with double or uint64 data type (my preference). . . . If you are concerned about hard-coded 'solutions' (e.g. "Solution 1418491"), then you should add more tests to your Test Suite, and can also implement random permuting of the order of elements within each of your specified input vectors.
—DIV
By the way, this might be avoided if you develop your own reliable Reference Solution beforehand.
David Verrelli, my reference test suite passes without the problem you mention.
what happens if you change the last digit - does it still pass?
i.e:
x = [2 2 3 3 3 3 3 3 5 5 6 6 6 7 86168291600238450732788312165664788095941068326060883324529903470149056115823592713458328176574447204501];
to
x = [2 2 3 3 3 3 3 3 5 5 6 6 6 7 86168291600238450732788312165664788095941068326060883324529903470149056115823592713458328176574447204500];
Hi Bob, in the last testsuite problem the last element in your x vector cannot be properly represented using double precision (t will be indistinguishable from similar numbers differing by anything within the last 88 digits). Please either switch to using other suitable representations (e.g. java big integers) or modify the testsuite to keep the values there a bit smaller (double precision can reasonably work with integers below ~1e15 and int64 could go up to ~1e20)
I went ahead and changed the test suite so the last number can be safely represented as an integer in double precision floating point.
having issue with that large number e^15 even using format long g...precision is reduced.. method of perfect square identfying doesnt work here