44
6
Challenge
So, um, it seems that, while we have plenty of challenges that work with square numbers or numbers of other shapes, we don't have one that simply asks:
Given an integer n
(where n>=0
) as input return a truthy value if n
is a perfect square or a falsey value if not.
Rules
- You may take input by any reasonable, convenient means as long as it's permitted by standard I/O rules.
- You need not handle inputs greater than what your chosen language can natively handle nor which would lead to floating point inaccuracies.
- Output should be one of two consistent truthy/falsey values (e.g.,
true
orfalse
,1
or0
) - truthy if the input is a perfect square, falsey if it's not. - This is code-golf so lowest byte count wins.
Test Cases
Input: 0
Output: true
Input: 1
Output: true
Input: 64
Output: true
Input: 88
Output: false
Input: 2147483647
Output: false
@Neil I realized my mistake. I retract that suggestion, and instead offer
18014398509481982
(2**54-2
), which is representable with a double, and causes answers that usesqrt
to fail. – Mego – 2017-06-08T12:24:56.033@Mego I'm probably wrong or just misunderstanding what you're saying, but I'm sure
2**54-2
is still larger than a double can safely handle, at least in JavaScript18014398509481982 > 9007199254740991
– Tom – 2017-06-08T12:32:02.703@Mego I think the limiting value is 9007199515875288. It's not the square of 94906267, because that's not representable in a double, but if you take its square root, then you get that integer as the result. – Neil – 2017-06-08T12:33:29.257
@Tom Type
2**54-2
into a JS console, and compare what you get with18014398509481982
(the exact value). JS outputs the exact value, therefore2**54-2
is representable with a double. If that still doesn't convince you, take the binary data0100001101001111111111111111111111111111111111111111111111111111
, interpret it as a IEEE-754 double-precision float, and see what value you get. – Mego – 2017-06-08T12:41:02.743Extremely relevant SO post. – Stewie Griffin – 2017-06-08T12:42:22.773
@Mego Numbers larger than 2^53 can be stored accurately as IEEE-754 double precision floats, "...but we all know they are tiny islands of exactitude in an ocean of near misses" – Stewie Griffin – 2017-06-08T12:48:48.780
@StewieGriffin Exactly.
2**54-2
is the smallest integer I found that is representable with a double, but is large enough that(n**.5)**2 != n
due to inaccuracies in the calculations. – Mego – 2017-06-08T12:51:35.983In my opinion, it's over-complicating things if we should start including numbers that high. If it's impossible to count to a number then it should be acceptable that we can't take the square root or do any other mathematical operation on it.
– Stewie Griffin – 2017-06-08T13:07:58.3373Sorry, guys, stepped away for lunch and ... well, that escalated! And there I thought this would be a nice, simple challenge! Would adding a rule that you need not handle inputs that lead to floating point inaccuracies in your chosen language cover it? – Shaggy – 2017-06-08T13:17:14.097
@StewieGriffin That's not the current consensus. – Mego – 2017-06-08T13:27:44.180