has anyone been able to execute python programs in less than 12 seconds?) I have tried various algorithms, including recursion, interation for, reduce, but the factorial 1000 exceeds the time

You don't need to prevent "scientific notation". Scientific notation is just... notation. Why would it matter what kind notation is used? Notation has no impact on calculations (not in this kata, at least).

What you have to avoid though is overflow. The "scientific notation" you observed is a symptom of the fact that your numbers overflow MAX_INT at some point and turn into imprecise floatign point numbers. Large FP numbers are represented with scientific notation, so what you observe is just a visible symptom of the fact that your calculations overflow and your numbers lose precision. Find a way to get the answer without overflowing, keep calculations precise, and you will be good. *e+20 is not your problem, but 30! is.

Any hint how to prevent scientific notation over e+20?
Test on 30! returns an *e+32 number but I am unable to convert back a number that is over *e+20. Under *e+20 everything is fine.

If, for example, n=1_000_000_000, your loop performs 1_000_000_000 iterations, your array grows to 1_000_000_000 elements, and you divide n by 5^1_000_000_000. Is that really necessary?

use BigInteger to store your resultant

Yes, read the hint.

has anyone been able to execute python programs in less than 12 seconds?) I have tried various algorithms, including recursion, interation for, reduce, but the factorial 1000 exceeds the time

oooh i forgot "return" was a boolean!!!

You don't need to prevent "scientific notation". Scientific notation is just... notation. Why would it matter what kind notation is used? Notation has no impact on calculations (not in this kata, at least).

What you have to avoid though is overflow. The "scientific notation" you observed is a symptom of the fact that your numbers overflow MAX_INT at some point and turn into imprecise floatign point numbers. Large FP numbers are represented with scientific notation, so what you observe is just a visible symptom of the fact that your calculations overflow and your numbers lose precision. Find a way to get the answer without overflowing, keep calculations precise, and you will be good.

`*e+20`

is not your problem, but`30!`

is.Any hint how to prevent scientific notation over e+20?

Test on 30! returns an *e+32 number but I am unable to convert back a number that is over *e+20. Under *e+20 everything is fine.

That's too bad! You need to think of some better, more efficint approach, because trivial approach will definitely not pass!!!!!

@collinsmarra thank you for your efforts. Execution timeout means you should build a better algorithm in terms of Big O notation

I get execution timeout when executing!!!!

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

woow nice use of recursion over there

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

thanks a lot! figured it out with your help

:)

If, for example, n=1_000_000_000, your loop performs 1_000_000_000 iterations, your array grows to 1_000_000_000 elements, and you divide n by 5^1_000_000_000. Is that really necessary?

## Loading more items...