x86 Machine Code (with SSE2), 36 bytes
; bool CirclesOverlap(double x1, double y1, double r1,
; double x2, double y2, double r2);
F2 0F 5C C3 subsd xmm0, xmm3 ; x1 - x2
F2 0F 5C CC subsd xmm1, xmm4 ; y1 - y2
F2 0F 58 D5 addsd xmm2, xmm5 ; r1 + r2
F2 0F 59 C0 mulsd xmm0, xmm0 ; (x1 - x2)^2
F2 0F 59 C9 mulsd xmm1, xmm1 ; (y1 - y2)^2
F2 0F 59 D2 mulsd xmm2, xmm2 ; (r1 + r2)^2
F2 0F 58 C1 addsd xmm0, xmm1 ; (x1 - x2)^2 + (y1 - y2)^2
66 0F 2F D0 comisd xmm2, xmm0
0F 97 C0 seta al ; ((r1 + r2)^2) > ((x1 - x2)^2 + (y1 - y2)^2)
C3 ret
The above function accepts descriptions of two circles (x- and y-coordinates of center point and a radius), and returns a Boolean value indicating whether or not they intersect.
It uses a vector calling convention, where the parameters are passed in SIMD registers. On x86-32 and 64-bit Windows, this is the __vectorcall
calling convention. On 64-bit Unix/Linux/Gnu, this is the standard System V AMD64 calling convention.
The return value is left in the low byte of EAX
, as is standard with all x86 calling conventions.
This code works equally well on 32-bit and 64-bit x86 processors, as long as they support the SSE2 instruction set (which would be Intel Pentium 4 and later, or AMD Athlon 64 and later).
AVX version, still 36 bytes
If you were targeting AVX, you would probably want to add a VEX prefix to the instructions. This does not change the byte count; just the actual bytes used to encode the instructions:
; bool CirclesOverlap(double x1, double y1, double r1,
; double x2, double y2, double r2);
C5 FB 5C C3 vsubsd xmm0, xmm0, xmm3 ; x1 - x2
C5 F3 5C CC vsubsd xmm1, xmm1, xmm4 ; y1 - y2
C5 EB 58 D5 vaddsd xmm2, xmm2, xmm5 ; r1 + r2
C5 FB 59 C0 vmulsd xmm0, xmm0, xmm0 ; (x1 - x2)^2
C5 F3 59 C9 vmulsd xmm1, xmm1, xmm1 ; (y1 - y2)^2
C5 EB 59 D2 vmulsd xmm2, xmm2, xmm2 ; (r1 + r2)^2
C5 FB 58 C1 vaddsd xmm0, xmm0, xmm1 ; (x1 - x2)^2 + (y1 - y2)^2
C5 F9 2F D0 vcomisd xmm2, xmm0
0F 97 C0 seta al ; ((r1 + r2)^2) > ((x1 - x2)^2 + (y1 - y2)^2)
C3 ret
AVX instructions have the advantage of taking three operands, allowing you to do non-destructive operations, but that doesn't really help us to compact the code any here. However, mixing instructions with and without VEX prefixes can result in sub-optimal code, so you generally want to stick with all AVX instructions if you're targeting AVX, and in this case, it doesn't even hurt your byte count.
we usually are a bit more relaxed on the I/O...could I take
(x1,y1),(x2,y2),(r1,r2)
? – Giuseppe – 2017-07-26T20:48:52.753@Giuseppe sorry that was just how I presented them for the test cases. You can take them however you like. (You can take them as a single variable (list, string etc) or as multiple inputs / arguments.) – Tim – 2017-07-26T20:50:31.633
4What do we need to return if two circles are touching externally? – JungHwan Min – 2017-07-26T20:55:53.353
@JungHwanMin I've been thinking about that. The idea of circles touching but not overlapping gives me a headache - I'm not sure it's a real thing. I think that touching circles are technically overlapping, but that might invalidate some answers, so you can return either True or False, as long as it is consistent for your program. – Tim – 2017-07-26T20:59:38.433
6The technical term for "touching but not overlapping" is "tangent" and it is a thing in geometry if nowhere else. – dmckee --- ex-moderator kitten – 2017-07-27T04:32:20.617
2Taking floats seems like a pretty stringent requirement. Could you relax it to a more general representation? I would like to solve this in Brain-Flak, but I am unlikely to take the time to implement IEEE floats, and if I did it would be 90% of the byte count anyway so I would just be golfing a float implementation. – Post Rock Garf Hunter – 2017-07-27T04:34:08.890
4I would also like to point out that floats are not accurate up to "three decimal places" in a lot of cases. I'm not sure exactly what you want answers to handle, but its a little confusing right now. – Post Rock Garf Hunter – 2017-07-27T04:39:52.003
Related. – Martin Ender – 2017-07-27T09:34:01.340
Is it really necessary to have float inputs? If the inputs were restricted to integers, a lot more languages could participate, and there wouldn't be issues w.r.t. floating-point imprecision, which would greatly improve this challenge. – Mego – 2017-07-27T10:57:49.110
With hindsight the floats requirement was stringent (there was a reason for it - I had to solve this problem myself with floats and wasn’t thinking carefully enough). I’m not changing it now because I’ve got 19 answers, and some could be affected (maybe they could be shorter if they didn’t handle floats). I’m not sure how it’s confusing - they handle numbers which have any number of digits and optionally a decimal point followed by up to 3 digits. – Tim – 2017-07-27T11:03:20.667
2I think you might have a fundamental misunderstanding of how floats work. Because they are fixed-size, as the values get larger, the precision gets lower. There is a point beyond which a float cannot accurately represent all values within 3 decimal places. Also, editing a challenge to remove an unnecessary restriction is not discouraged. – Mego – 2017-07-27T13:58:25.577
@Mego you can assume the number is small enough that it is accurate to 3dp – Tim – 2017-07-27T15:29:14.543
1Specifying 'up to four decimal digits precision' would (a) encompass all the test cases shown and (b) ensure that IEEE 32-bit floats could convincingly represent such numbers over a wide range of magnitudes. – dmckee --- ex-moderator kitten – 2017-07-27T19:46:33.210
Is
[x1, x2, y1, y2, r1, r2]
acceptable input? – Alexander - Reinstate Monica – 2017-07-28T07:09:38.930@Alexander yes it is – Tim – 2017-07-28T10:57:14.820