I've found my source of error and passed all the tests.

However, as floating point numbers are not exactly for most decimal fractional numbers, the tests should allow some error margins. Comparing with a reasonable error margin is also good practice in real program when floats are compared. Rust has assert_approx_eq for this. (use assert_approx_eq::assert_approx::eq)

While this may indeed be an issue (although I have the suspicion you're the first to run into this problem), I would also take a look at how you're working with fractional floats. In particular, your match arms b'0'..=b'9' => {} and b'.' => {}, together with your implementation of Ele::val(). That is a very weird way to handle such numbers, and possibly the source of your rounding errors.

genius

I guess you don't need to calculate the cube of each digit since an odd number will always have an odd cube and an even number will always have an even cube. The modulo 2 of the sum will always be the same.

3 lines!? Hawt

Hi Raihan,

Why are you calculating ^3 of each digit as (int(c) - int('0'))?
That's some bytes/runes claculation mechanics implies?

Can you please give some details?

I can't understand the logic behind this solution. Can you please clarify it.

Someone mind explaining?

fixed.

found the issue, will fix shortly; the starting velocity should just never be 0 as shown in the description but the range of the random number generator is (incorrectly) inclusive of 0.

everything is meant to be rounded to 3 decimal places, except integers as is said in the description.

(Scala) Some random test give me a feedback say that the expected result for heightEq() would be -16.0t^2 + 0.000t + ????.

While the description explicitly says: "NOTE: Some solutions were invalidated because I added tests for situations where the starting height is 0, in which case the equation for height would be in the form h(t) = -16.0t^2 + vt where v represents the initial vertical velocity.", shouldn't the 0 second term be omitted?

Also, why the second term has three decimal points?

How would a number (1) or a symbole (.) or a blank sort with letters, or with each other, considering sorting between lettes are case insensitive?