Thanks for the explanation. Turns out I was completely wrong. I'm glad someone finally explained it to me.

Found a Wikipedia article that almost mirrors the wolfram article, but it left out the 1 which is probably another subtle detail lost...

https://en.wikipedia.org/wiki/Table_of_prime_factors#1_to_100

Not sure you can call this readable or clever. It is definitely good code golf though.

So is there something wrong with the tests or the description? Your reply does not seem to address the actual issue.

It seems like you are just trying to defend your previous comment?

In that case, you should explain your problem explicitly, and not say "I think the tests are wrong".

I actually said:

What numbers have 107 as a factor? It feels like the test case might be suggesting 107 is its own factor since the sum is exactly 107?

I might have just misunderstood the description?

I even included "I might have just misunderstood the description?" because of how many people had completed the kata already. I thought this statement conveyed an earnest and polite tone, but for some reason, it was only met with condescension.

Just to be explicit and explain the same thing again. I assumed the terms factor and prime factor are very well understood concepts on here. I am still under the impression that these are fundamental concepts that all but true novices would struggle with. This is a 4 kyu kata, so I believe it is safe to assume it is not meant for true novices. Also, you literally need to understand how to implement integer factorization to even complete this kata.

Read my original comment with the assumption that the audience actually understands all of this. If that is the case, the reasoning should be self evident.

Issue should be raised when something is definitely wrong with the kata. If you assume that your answer is correct but you still can't pass the tests, post a question...

Again. Is there something definitely wrong with the kata? It seems apparent to me, but for some reason, you and another high ranking user stated otherwise. I would like to know the "some reason" if I am wrong, or at least have my suspicions confirmed.

in this case, asking why 107 is included in the output, despite not following the exact mathematical rules on integer factorization.

From my second comment:

Based on the condescending replies, I guess I need to explicitly define some terms that I had assumed were well understood on a site such as this.

Seriously though, was my assumption that these terms should be well understood by people who have completed this kata unreasonable? Feel free to point out where my thought process is wrong. I would honestly welcome it at this point because this entire interaction has confused me.

Yep. Missed something obvious. Thanks.

Yes, 107 is a primary factor of 107, what a surprise!

It feels like you're suggesting that 1165 people completed this kata in JS, and nobody noticed an issue. Your solution is wrong.

Based on the condescending replies, I guess I need to explicitly define some terms that I had assumed were well understood on a site such as this.

*Note the bolded terms below

From the description:

[ [p, sum of all ij of I for which p is a prime factor (p positive) of ij] ...]

In number theory, integer factorization is the decomposition of a composite number into a product of smaller integers. If these integers are further restricted to prime numbers, the process is called prime factorization.

A prime number (or a prime) is a natural number greater than 1 that cannot be formed by multiplying two smaller natural numbers.

I am assuming we can agree that prime factorization is the process for finding prime factors?

Note that there are two issues with calling 107 a prime factor of 107.

1. 107 is not smaller than 107
2. The other smaller integer would be 1 which is not a prime number

To be explicit, 107 is already invalid as a factor based on the fact that it is not less than 107. This means it cannot be an integer factor, much less a prime factor. The fact that the other smaller integer of 1 is not prime is unnecessary.

Maybe I am still wrong, but I am just not able to see it on my own. Instead of another condescending response, maybe provide some helpful information this time around? Also, I have no idea how my original comment warranted such condescension, but that is separate issue.

PS: On second thought, to avoid further condescension, I am just going to include a link that explicitly states the relationship between prime factor and prime factorization.

Writing a number as a product of prime numbers is called a prime factorization of the number... The terms in the product are called prime factors.

For JavaScript

#
[ 107, 158, 204, 100, 118, 123, 126, 110, 116, 100 ]
Actual:  [ [ 2, 1032 ],
  [ 3, 453 ],
  [ 5, 310 ],
  [ 7, 126 ],
  [ 11, 110 ],
  [ 17, 204 ],
  [ 29, 116 ],
  [ 41, 123 ],
  [ 59, 118 ],
  [ 79, 158 ] ]
Expect:  [ [ 2, 1032 ],
  [ 3, 453 ],
  [ 5, 310 ],
  [ 7, 126 ],
  [ 11, 110 ],
  [ 17, 204 ],
  [ 29, 116 ],
  [ 41, 123 ],
  [ 59, 118 ],
  [ 79, 158 ],
  [ 107, 107 ] ]

What numbers have 107 as a factor? It feels like the test case might be suggesting 107 is its own factor since the sum is exactly 107?

I might have just misunderstood the description?

It is not O(n^2). He's using the same counter to grab the range. It is just O(n).

Also, why did everyone remove the steps they used to solve each Bomb? Wouldn't it be more interesting to see those as well as the actual solution?

How did you figure out it was using indexOf?

Technically, the accuracy of the popular solutions falters before x reaches 170, but factorial 171 exceeds the max value of double which is when those solutions completely fail.

Could make this slightly harder by checking with higher inputs (something that exceeds factorial(170)). Right now, this is a bit too straight forward for a 5 kyu.

prob_simpson(8, 12, '>') == 0.888075998981    # or P(12>c)
prob_simpson(8, 12, '>=') ==  0.936202803263  # or P(12≥c)
prob_simpson(8, 12, '<') == 0.063797196737    # or P(12<c)
prob_simpson(8, 12, '<=') == 0.111924001019   # or P(12≤c)

P(c<12) = 0.00033546262790251196 + ... + 0.072190206422935 = 0.888075998981

P(c≤12) = P(c=0) + ... + P(c=12) = 0.936202803263

Not sure why you switch between c < x and x > c randomly through the description. It makes it confusing even though the two statements are equivalent. It could definitely confuse someone on what direction the comparison operation should be.

Actually, a lot of computations are done with lookup tables. You might want to learn more about computers before making generalizations about them.

For all the people saying this is not best practice, lookup tables are actually the best practice in the majority of cases where memory is not limited. So unless if you are implementing something without a hardware multiplier, you should not rule out an implementation that uses lookup tables. They don't have to be a one to one table like this one.

Not just vintage games like Doom. Most modern calculators/[cg]pus will use some form of lookup tables for transcendentals. There are performant alternatives when lookup is not available (in memory limited applications like old microcontrollers), but if you have the option, it would make no sense to go for the slower more complicated algorithm. Lookup tables aren't just limited to calculating transcendentals, they are ubiquitous across software and hardware.