Hello guys. I still don't understand why the result case is like that. Let me explain my view. The probability a number except 1 (because 1 and n have GFD 1 and it's prohibited for the problem) toward n where that number is a factor of n is 3 / n. For example, 21 (comes from 3 * 7) only have 4 factor. They are 1, 3, 7, and 21. And 1 is prohibited. So the total is 3. So the probability 3/n. Let me know my mistake, so I know why test case is different of my view. Lo siento, bad English.

What I meant was, you should mention that the answer are returned as a percentage, not a decimal (which is how probability are dealt with almost all the time). After that, rounding to the nearest percent is okay, no need for 2 decimal places and being a percent at the same time.

Well, but it's far from clear what is actually being returned (there's no mention of it being a percentage). Besides, rounding to 2 decimal places or something isn't really that much of a problem for people anyway, lots of katas do it all the time and we're pretty much used to it :P.

@Voile Ah, good point on the Number.safeInteger. I missed that. I wanted to include some large prime test cases though so people couldn't just throw together a couple loops and call it good. But perhaps I can't do that.

With regards to your first point, I don't entirely understand what you mean by "Either returning the probability as an integer or...", is that not what I am asking to be done right now? I thought it would be simplest for people just to throw their answer into a Math.round() rather than have to deal with decimals that may differ slightly based on rigor of the solution method.

Important note: express probability in a rounded integer form (i.e. 0.301 is equivalent to 30 and 0.247 is equivalent to 25).

This is mysterious, why should probability be represented and rounded in the nearest percent? Either returning the probability as a integer or as a fraction over the original p*q would make much more sense.

Test cases: 1.355877461004671e+22 4.125636888562549e+33

These numbers are already way beyond Number.safeInteger so they aren't even integers. It's impossible to know what the number actually is!

Hello guys. I still don't understand why the result case is like that. Let me explain my view. The probability a number except 1 (because 1 and n have GFD 1 and it's prohibited for the problem) toward n where that number is a factor of n is 3 / n. For example, 21 (comes from 3 * 7) only have 4 factor. They are 1, 3, 7, and 21. And 1 is prohibited. So the total is 3. So the probability 3/n. Let me know my mistake, so I know why test case is different of my view. Lo siento, bad English.

nice!

Hi,

Would be nice if you explained exactly how the history is formated in the description!

Happy Coding

`^_^`

180 point was paid by the Code Adventurer Guild ;-)

great kata. harder (more time-consuming) than a 5 kyu, though. deserves a 4 imo.

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

I have marked up the description a little. Hope you don't mind.

Needs random tests.

Got it

Wait :P

What I meant was, you should mention that the answer are returned as a percentage, not a decimal (which is how probability are dealt with almost all the time). After that, rounding to the nearest percent is okay, no need for 2 decimal places

andbeing a percent at the same time.Okay I changed it to rounded to 2 decimal places :)

Should hopefully be more clear now

Well, but it's far from clear what is actually being returned (there's no mention of it being a percentage). Besides,

`rounding to 2 decimal places`

or something isn't really that much of a problem for people anyway, lots of katas do it all the time and we're pretty much used to it :P.@Voile Ah, good point on the Number.safeInteger. I missed that. I wanted to include some large prime test cases though so people couldn't just throw together a couple loops and call it good. But perhaps I can't do that.

With regards to your first point, I don't entirely understand what you mean by "Either returning the probability as an integer or...", is that not what I am asking to be done right now? I thought it would be simplest for people just to throw their answer into a Math.round() rather than have to deal with decimals that may differ slightly based on rigor of the solution method.

`Important note: express probability in a rounded integer form (i.e. 0.301 is equivalent to 30 and 0.247 is equivalent to 25).`

This is mysterious, why should probability be represented and rounded in the nearest percent? Either returning the probability as a integer or as a fraction over the original

`p*q`

would make much more sense.Test cases:

`1.355877461004671e+22 4.125636888562549e+33`

These numbers are already way beyond

`Number.safeInteger`

so they aren't even integers. It's impossible to know what the number actually is!Need random tests## Loading more items...