Mon, 26 Jul 2010 10:23:15 +0100 Andrew Haley <a...@redhat.com>: > On 07/24/2010 09:47 AM, Ivan Maidanski wrote: > > Hello, Andrew! > > Hi, > > > 1. As for .diff extensions - what should be tunable in a browser > > which app to use for opening the file. > > All I was saying is: please don't mark text attachments as binary.
This is out of my control - I just attach that file and nothing more. How could I mark it? > Most mail readers will not display such attachments. This means that > fewer people will see the patch. I apologies. Sorry. > > > 2. As for testing for zero sign - I can't agree with you because: > > > - Sun writes "Floating-point positive zero and floating-point > > negative zero compare as equal, but there are other operations that > > can distinguish them; for example, dividing 1.0 by 0.0 produces > > positive infinity, but dividing 1.0 by -0.0 produces negative > > infinity." > > (http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html); > > > - your consideration about the asm code produced for > > doubleToRawLongBits are valid for machines which use the same FP > > formats as JVM; > > Which is all of them! :-) Not all. E.g., some ARM chips have swapped words order for FP doubles. But I definitely agree IEEE FP is 100% dominated. > > > - yes it's always better to say what you mean and let the optimizer > > worry about optimization if the latter is capable of doing such > > things but doubleToBits(x)<0 and 1/x<0 are equally far from what I > > mean (x==-0) in that comment. > > Well, your claim was that 1/x<0 was cheaper than doubleToBits(x)<0, > and I showed why that probably isn't true in many cases. If you still > want to keep that form, even though it isn't cheaper, that's OK. But > it's important not to base decisions on false data. Ok. I was wrong saying that. Let me not change that code (just to not resend the patch) - it's not a big deal really to use any code there. Thanks for the explanations. > > Andrew.
