The exponent computation in the function prec in Preloaded relies on a non-standard compiler extension:

"It's undefined behavior to read from the member of the union that wasn't most recently written. Many compilers implement, as a non-standard language extension, the ability to read inactive members of a union." (https://en.cppreference.com/w/cpp/language/union).

I recommend to compute the exponent with the frexp function.

This happens because of floating-point underflow. Specifically, the derivative of (18*57.2^x-x^x+81.9*x^5.2*x^62)^x is a very small number which is computed as 0 + 0i by the reference solution and as -6.09095e-315 + 8.56785e-314i by my solution. In general, both results are unreliable. Overflow and underflow should be avoided in all randomly generated subexpressions.

I've increased the number of iterations in the tests. Do you know some way to prevent such solutions from passing? I think it's impossible to restrict this since there will always be some upper bound of how many values can be consumed/tested before hitting the time limit.

@Schulzkafer: it is up to you to decide whether to use the approximate equality or not. My position is that it should not be used. On the other hand, I am almost certain that you get more positive votes if you do use the approximate equality.

There are no precision problems in this kata. All inputs and the output are integers (I assume that the kata models the real Codewars satisfaction rating which is displayed as an integer number). The specification is given in terms of real numbers. The floor function is well-defined for real numbers. An incorrect usage of floating-point arithmetic to approximate real-valued computations is not a kata issue. That's why the result should be compared without any error tolerance.

Inputs are integer numbers. Output is another integer. No floating-point operations are required so the output should not be compared with an error margin.

I wonder if you're aware of the issue that Blind4Basics has raised for this kata?

rank suggestions need to be cleaned up before approval.

I'm not sure what it's about -- perhaps not everyone has given a suggested rank for this kata. Anyway, I thought that you might like to look into it if you want to get the kata out of beta.

Added a test like you suggested.

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

I think it is possible to test if a solution is lazy enough.

The exponent computation in the function

`prec`

in Preloaded relies on a non-standard compiler extension:"It's undefined behavior to read from the member of the union that wasn't most recently written. Many compilers implement, as a non-standard language extension, the ability to read inactive members of a union." (https://en.cppreference.com/w/cpp/language/union).

I recommend to compute the exponent with the

`frexp`

function.This happens because of floating-point underflow. Specifically, the derivative of

`(18*57.2^x-x^x+81.9*x^5.2*x^62)^x`

is a very small number which is computed as`0 + 0i`

by the reference solution and as`-6.09095e-315 + 8.56785e-314i`

by my solution. In general, both results are unreliable. Overflow and underflow should be avoided in all randomly generated subexpressions.I've increased the number of iterations in the tests. Do you know some way to prevent such solutions from passing? I think it's impossible to restrict this since there will always be some upper bound of how many values can be consumed/tested before hitting the time limit.

@Schulzkafer: it is up to you to decide whether to use the approximate equality or not. My position is that it should not be used. On the other hand, I am almost certain that you get more positive votes if you do use the approximate equality.

It is possible to make tests stronger. But it is not a big issue if some solutions are not perfect for low level kata.

There are no precision problems in this kata. All inputs and the output are integers (I assume that the kata models the real Codewars satisfaction rating which is displayed as an integer number). The specification is given in terms of real numbers. The floor function is well-defined for real numbers. An incorrect usage of floating-point arithmetic to approximate real-valued computations is not a kata issue. That's why the result should be compared without any error tolerance.

Inputs are integer numbers. Output is another integer. No floating-point operations are required so the output should not be compared with an error margin.

Added.

You'll get a compiler warning when comparing the "int i" to "size_t arr_size".

Default int is signed, while size_t is unsigned. In practice it won't matter until the arrays get very large (not tried in this kata)

I wonder if you're aware of the issue that Blind4Basics has raised for this kata?

I'm not sure what it's about -- perhaps not everyone has given a suggested rank for this kata. Anyway, I thought that you might like to look into it if you want to get the kata out of beta.

why are we using "size_t i" in for loop? can't we use "int i"?

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

## Loading more items...