wait, i think there exists a thingy like "assert similar", right?

I think he meant parallel lines.

Change the description to say that false should be returned for parralel lines.

Why should that be mentioned? That's their definition:

Parallel lines

Two or more lines that lie in the same plane and never intersect each other are known as parallel lines.

Also, what if segments don't intersect, but their extensions do?

Aren't we talking here about intersection of segments? If they don't intersect, then they don't. So your previous suggestion isn't valid either and the current description is fine.

Change the description to say that false should be returned for parralel lines.

Also, what if segments don't intersect, but their extensions do?

Floating point error:

Expected: '[\'8938.57393995\', \'2759412.26715096\']', instead got: '[\'8938.57393995\', \'2759412.26715097\']'

This kata is a close duplicate of https://www.codewars.com/kata/63a5b74a9803f2105fa838f1, which has become approvable.

Considering this kata has too many issues and written poorly, probably that kata should be approved instead.

No sample and random tests.

Would be nice if in the description it mentioned if there is no intersection between segments to return false.

Otherwise great kata!

Awesome. Thanks for your help!

I fixed it according to your suggestion using n.toFixed(8). Should be safer now in case of faulty rounded floats :)

Yeah, that's totally fine. It's just that if someone does the same mathematical operations in a different order, the float could come out being a tiny bit different. Floats tend to have a degree of error when dealing with floats or very large numbers. One way of fixing this would be to test n.toFixed(8) instead of the actual numbers themselves.

good point, sorry :)

As @wthit56 has not yet solved the kata if you mark your reply as "spoiler" he (@wthit) can't read it.
:)

Could you please be more clear? I'm not that good in English nor programming. Do you mean that I should set kata requirement, i.e. Float(0,2) and then check it with same tollerance in tests? Or just in tests?

For now I was assuming, that points like [1.5517241379310345,0.9655172413793105] are valid answers.

I think you need some float tolerances added to your tests. I seem to be getting the right numbers within 8 decimal places...