It might be a good idea to include the zero-length input in the sample test cases. Using C, this will likely crash before you have a chance to look much at input and be a pain to debug. If it's a sample test, then solvers can see what the issue is.

I am an engineer and still found the units painful. Keeping everything in meters, seconds, and kg would be preferable. Along these lines, computing the force on the bike (rather than direct accel) would probably make this easier to grok. Once one gets the force, converting to accel given the mass is easy.

And +1 to the comment about setting the absolute value of acceleration. Conversely, it isn't necessary to take the absolute value of v when computing the drag, because it gets squared anyway.

The kata description could stand to be more, well, descriptive. While part of this kata is understanding the puzzle of what the pattern is, it can at least state that clearly.

I believe I've implemented the radix-2 FFT as described, but I noticed the test case time-outs I was getting was all for odd-length inputs. As the kata description only mentions that these must be solved with some other FFT method, I found it odd that they were in the test cases. Is the intention to pad with zeros to the next power of two? If so, that should be stated. Although, I believe that introduces error (it may still be acceptable in certain applications).

Also, I believe the name is "Tukey", not "Turkey".

I was running into a similar problem and talked to donaldsebleung about it (easy enough to comment on one of his Fortran solutions). His method, however, was to first create a static-length string, and then build from that. It seems Fortran has some ability to autosize strings, but only if it's built of existing strings and you concatenate. Writing directly into such strings I haven't fully sorted out yet. Often, I'm frustrated by Kata that are challenging mainly because of arbitrary string formatting output rather than programming or mathematical difficulty.

I was having trouble making a dynamic string work with the write function. It's like if you have some string already created, Fortran can figure out how big to make your new string, but this feature isn't built into write. It makes me wonder if there's a way to do a trial write to get the necessary size, allocate, and then do the real write. Thanks!

Do you know of a more general way of allocating the string, tmp, here? I was trying different things but found myself circling back to essentially what you did.

Good kata, especially walking the learner through solving it the "slow" way to see the pure solution. But for the Fortran version, can the skeleton code start lowercased? Fortran90 can handle cases just fine, no need to have it be F77 style all uppercase.

Thanks for adding a Fortran version. It seems pretty good, but I have one suggestion. While making a function "pure" can be good practice, in this case, a learner will become frustrated when they can't write debugging information as with write (*,*) str, idx. I'd advise taking that out of the skeleton, even if doing so fills up the max buffer size with debugging print info.

Are you sure this still works if a=0? The test cases don't cover this situation.

Any suggestions for how to debug a memory corruption error? I get *** Error in `/home/codewarrior/solution': double free or corruption (!prev): 0x0000000001a23620 *** after passing the first test. On my local machine, everything tests fine. I'm not using free() at all (just to be paranoid), so I'm not sure what the issue is.

Please use just a single fictional currency. While the levity is appreciated, it creates confusion because it could be understood to be different units in the same currency (such as quarters, dimes, nickels, dollars, etc).