Dennis Cote wrote: > 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 > I was not interested in being pedantic, just in offering some practical rule of thumb advice. > _____________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
