How to check for equality against absolute 0?

[Caprico]

I'm writing a program in which I need to check if a certain "double" number is an exact integral square root or not. For example, if applied in the Pythagorean triplet problem, then for a=1, b=1, c is sqrt(2) which is not integral, hence will return false, whereas for a=3, b=4, c is exactly 5 and would return true..

So my current algorithm is I accept the sqrt of the number, type-cast into int in another variable, and then find the difference. Now I want to check whether the difference is exactly 0 or not, coz I've heard that using 0 as equality against a double is risky. Even 0.0000 or something won't do. So how exactly can I achieve this? Or can someone suggest a better algorithm for this task? (I desire speed efficiency, not memory..)

Here's my current function, for reference.. (Please don't mind, its in Java, but I guess its very basic, so people won't have any issues as such)

public static boolean isSquare(double a)
{
	boolean isSquare=false;

	if ((double)(a-(int)a)==0.0000000000)
		isSquare=true;

	return isSquare;
}

Thank you in advance.. :)

[Gaminic]

Rather than checking for a certain value, it's often best to check if it's outside a certain margin, e.g.:
if (a - floor(a)) > epsilon) isSquare = false;
Then, define an epsilon within the required precision. (e.g. 0.00001)

By the way, naming a variable the same way as a function seems like asking for trouble.

[edit] Any chance this is for one of the Euler problems?

[Caprico]

Yes, it is...

And if I use your method of the epsilon thing, won't it return true for even close values of the square root? I mean, it wants me to check squares upto the range of the order of 10^6. At those numbers, I'll need higher accuracy, won't I?Any other way I can do this particular function? Never mind the question.. I need this function even in other problems..

(I write slightly inefficient solutions.. I'm trying to improve on that, but for the time-being, please suggest.. Don't give away any idea you may have.. Please just hint it to me.. thanks.. :) )

[Gaminic]

I had the same issue with that Problem, hence why I asked. :)

My hint? The Euler problems never said your code should provide the final solution.

[Caprico]

Yea, I know, I solved half of the problem manually by logic, hence cutting out most of the run-time, but I definitely need code for the next half.. By my estimate, it'd take about 6hours to compute the answer.. :( Well, lets see.. I'll work on it a little more, and if I get an idea, I'll post it here so you 'll know I've made some progress... Thanks anyway! :) :) :)

[ne555]

Use the definition

int root = sqrt(number); //round could be safer
return root*root == number;

[LB]

Isn't that still subject to rounding errors?

[ne555]

number is an integer, the comparison is exact.
There could be issues with the computation of the sqrt (if it misses the number). Then you could use an integer root algorithm.

[roberts]

If you're going to do any serious FP work, I recommend a read through this:

http://docs.oracle.com/cd/E19957-01/806-3568/ncgTOC.html

This part:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#674

is of particular note.

[Caprico]

Wow... It is interesting, and undoubtedly important to know, but most of it is pretty much over my head.. I'm just a student, and some of the terms they've used are slightly high level.. But anyway, thanks! It did help.. :D

[mik2718]

This is easy reading and also very interesting

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.18

Basically, the FPU operates on 80 bit floating point numbers and has a few registers to store them. But if a number has to be written out to RAM it is rounded to 64 bits (for a double). So results can vary depending on whether the code can fit intermediate results into the registers or not.

Also, when comparing to absolute zero you have the issue of denormalised numbers. Normalised representation has a 1 in the most significant position but this means the smallest positive number is rather larger then you would like. The denormalised numbers fill this hole around zero by allowing very small non zero numbers to have a denormalised form. It might be possible to turn off denormalisation to get a more robust comparison to absolute zero.

http://en.wikipedia.org/wiki/Denormal_number

This is a great read too

http://www.eecs.berkeley.edu/~wkahan/ieee754status/754story.html