John Stanton wrote: > > But for practical arithmetic probability or possibility is not close > enough. It must be certainty.
There is a possibility that your code could be asked to compare two equal floating point numbers. To be correct, it must handle that case. If it does not, it is certainly broken. While you must be careful with floating point numbers, statements such as yours: "The point about using floating point is that there is no equal, only less or greater, because it is an approximation." just add confusion to the issue. There is very definitely an "equal" when dealing with floating point numbers, and it has nothing to do with floating point format sometimes being an approximation. > I make the point because it has been my > observation over the years that some of the silliest and most > embarrassing simple IT errors have been caused by the inappropriate > usage of floating point numbers. That is true, but neither this or your first post was applicable to the correction that Steve suggested (and Richard accepted). In fact the equal case, when xmin and xmax are set to the same value is required to allow points (rectangles with zero area and zero length) to be handled by the RTree module. It would be incorrect to say that xmin must be less than xmax when they can be equal. Dennis Cote _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
