is x a perfect number?

Started by
12 comments, last by Nibbles 22 years, 5 months ago
What is a perfect number?
Advertisement
quote:Original post by Anonymous Poster
What is a perfect number?


A number is perfect if the sum of all of its divisors, excluding itself, is itself. ie:

6 has divisors of 1, 2, and 3.
6 = 1 + 2 + 3
6 is a perfect number

4 has divisors of 1 and 2
4 != 1 + 2
4 is not a perfect number
quote:Original post by Spinal Confusion
Wouldn't using the mod function be slightly easier? Perhaps more efficient?


Yes, you're right. On Java, that would be a good way to go. On C++, the long doesn't have enough range to check 8589869056. That's why I had to use doubles (oddly, it didn't work with singles, either). So, I had to use floor, since in truncating to a long I would have lost data, and the result would be wrong.

No, I think that the second floor isn't needed in C/C++, since sqrt(8589869056) will definately fit in a long. Although the sum variable would still need to be a double (but that doesn't effect the floor). And, of course, if you know that your compiler has a 64-bit integer, you can use that. (long long in gcc, __int64 in VC++, I think)

Ahem. Neither floor is needed in C/C++, since sqrt(8589869056) will definately fit in a long, so we can safely truncate in both cases. Doh

Java's long is much bigger (in fact, a whole 32-bits bigger) than C++'s long, so it'd work just fine with that. Indeed, you can get rid of the Math.floor that's still left in, by defining everything as a long.

Edit: Brainfart the First.
Edited by - Mayrel on October 30, 2001 7:18:11 AM

Edit: Brainfart the Second.

Edited by - Mayrel on October 30, 2001 7:20:25 AM
CoV
quote:Original post by Null and Void
You should try to avoid floor in C/C++. You can easily duplicate it by truncating to an integer, which takes much less time. On x86 CPU''s floor can take over 100 clockcycles due to alterations of the FPU''s rounding mode.


Surely the FPU is used to truncate the float when it''s cast to long or int or whatever? Indeed, since the FPU has to construct a integer when truncating, it seems to me that casting should take longer, because it''s a floor followed by a conversion.

Not that I don''t believe you; I''m quite familiar with the x86''s idiosynchronies, so it wouldn''t surprise me.

As an side, on gcc, integer shift is slower than integer division unless you have optimisation turned on. Whether that''s an x86 thing, a gcc thing or just a thing with my copy of gcc, I don''t know.

''Nuff said. I''ll enjoy watching you live, demon.
CoV

This topic is closed to new replies.

Advertisement