last day (18 days later) » 

16:39
0
A: One OEIS after another

Mr. Xcoder259. Swift 4, 159 bytes, A000329 import Foundation func b(n: Int) -> Double { return n > 0 ? tan(Double(b(n: n-1))) : 1 } func sequence(_ n: Int) -> Int { return Int(round(b(n: n))) } Try it here! Next Sequence. This implements a recursive function which computes our floating-poin...

@Giuseppe Yes but it would theoretically work for any given input, so I guess it is valid.
The theory of IEEE 754 floating point is quite accurately implemented. Whether 128-bit doubles would theoretically be good enough, I'm not sure, although I'm currently working on an interval arithmetic implementation to bound the true values.
@PeterTaylor Fixed...
Also, would the downvoters care to explain their reasoning? I don’t think that a small inaccuracy that has been changed trivially is a problem which requires a downvote...
That's not fixed: it's even more broken. Now it gets input 8 wrong.
Broken - It is due to the type limitations of the language I used... The algorithm theoretically works for any given input, so I am not sure why this would be considered invalid?...
16:39
The allowance which the question makes for numerical analysis issues is that you are only required to give correct output for input up to 1000. And even if that weren't the case, your language supports 80-bit floating point, so claiming that the problem is due to the type limitations of your language when you're using 64-bit floating point is silly.
@PeterTaylor My language does not have overloads of tan for Float80s... I did, however understand that the challenge requires the first 1000 test cases (at least) to be computed correctly. I will delete this for now.
Well I obviously thought this would be valid, but I now see your point (since I have deleted my answer).
"I don't have built-ins which do it all for me" is not the same as "the types are too narrow to support it".

  last day (18 days later) »