I see your point in general, but it is not a problem in this case for two reasons:
1. the calculation is exactly the same so you are assured that you will reach the exact same IEEE752 float 2. the termination of the while rely on an inequality "<" not on the an equality "==" so even in a world with unstable IEEE752 operations the loop stops with enough precision to pass the Online Judge. I also just posted my solution and analysis for Equal Sums: http://codejamdaemon.blogspot.it/2012/05/equal-sums-google-codejam-2012-round-1b.html Which is almost identical to yours (and to what I actually used in the round). A. On Monday, 7 May 2012 23:25:35 UTC+2, Chris Knott wrote: > > No, I don't think so because it relies on the <= operator working properly > - which it does. Basically, you are at some point going to get the same set > of numbers again in 'small', so this calculation will produce exactly the > same bits, as it is the same calculation, not just "the same number" in a > logical sense. > > You get problems with floats when you are trying to argue that two things > are "the same number", like sqrt(16) and 4 - this sort of thing might have > float problems. > -- You received this message because you are subscribed to the Google Groups "Google Code Jam" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-code/-/7N9pFNaOUFwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-code?hl=en.
