Ad
  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    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)

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    (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?

  • Custom User Avatar

    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?