Hi. On Fri, Mar 01, 2002 at 07:10:10PM +0100, [EMAIL PROTECTED] wrote: [...] > ...but as long as 0.55-0.5 != 0.05 I will call it a bug. It may be well > known and hard to fix, but that does not make the expression right. :)
Well, IMHO no, a bug is an unexpected flaw. The imperfection of the float and real types of the according standard were by design and are well-known. It is also well documented in the manual. A kind of deficiency from the end user's view (i.e. not providing a "perfect" floating type). Okay, but that's just a matter of wording. > > Since there is another way to get consistent behaviour across > > platforms (FLOOR((2.55*10)+0.5)/10), but I know of none to get it > > consistent with the platform, I prefer the current behaviour. > > This formula is pretty straight forward... why is it so difficult to > implement it in the round() function? I know, read on... ;) Hm. Don't know. Did not care until now. The explanation of the ROUND() function explains to take the work-around if consistent behaviour is wished. And I did not asked further until now. Maybe there are other problems which we don't see at the moment. [...] > With this inconsistency in mind, is floating point really usefull for > anything? I can't think of a project where I would use it... when you have > very big and very small values in the same column, and accuracy is not > important...? This is not a flame, I really wonder what people use it for! > :) Well, float is called an "approximate" storage type, and therefore I would think that it is usable in all cases, where an approximated value (up to a certain precision) is good enough. > More important: this is a trap for novice users, maybe mysql would have been > better of without floating point numbers? Keep the decimal/numeric type, but > not using floating point as an internal representation, and also not using > floating point for decimal constants... just a thought. Think the other way around: If the other option is to have no floating point type at all, a "not perfect" one may be good enough for many cases. I would think that novices aren't aware of the different issues involved when rounding numbers (you don't want to round 0.5 always only up [or down] in statistical data because that will introduce an systematical error with large data sets) and therefore the slight errors they will get using float are not bigger than those they introduce by ignorance. Also, this problem is explained in detail in the manual: http://www.mysql.com/doc/N/u/Numeric_types.html http://www.mysql.com/doc/P/r/Problems_with_float.html So if someone cares (to read), she will know to rather avoid float if she didn't really understood it. > I suppose a replication setup with master/slave on different platforms could > also suffer from this... a statement involving floating point operations may > give a different result on the slave... I guess this could mean trouble in > some applications. Interesting question. Until now I did not think of that (well, neither I am currently using float types), but yes, that could become a problem (replication data is currently transferred as string representation, AFAIK). Bye, Benjamin. -- [EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
