>>>>> "OR" == Octavian Râşniţă <orasn...@gmail.com> writes:
OR> From: "Uri Guttman" <u...@stemsystems.com> OR> sorry to say but you still don't get it. automatically rounding numbers OR> is not higher level NOR correct. there is NO correct way to handle OR> floating numbers like that. none. nada. it is a very well known issue in OR> ALL programming languages that support floats. some choose convenience OR> solutions which may work some of the time but will screw up worse other OR> times. the correct solution for money has always been to use integers OR> for the smallest amount (e.g. cents). this will always be correct in all OR> languanges. OR> To be sincere, I doubt that those languages/programs that use OR> convenience methods fail sometimes. I made some tests with very OR> well known databases, and they seem to work and I don't think a OR> database management system is made so bad: wow. you really don't get it. a few test cases is not how you analyze floating point accuracy and rounding issues. this is something that has been studied for years and no one claims it is correct to use floats if you want true accuracy for money issues. OR> Oracle: SQL> select 0.079 - 0.085 from dual; OR> 0.079-0.085 OR> ----------- OR> -.006 2 lousy decimal points. so what? OR> Do you say that these databases make mistakes and I shouldn't use OR> decimal and float type columns? nope. i say you shouldn't do math with them and assume they will be correct. please study something about how floats work on a computer. and many databases may not even use machine floats but some bcd format (like bignum does) so that isn't a good test. you are really way out of your league in understanding this issue. OR> you can choose what you want but the key point is that you make a OR> rational choice based on the facts, not based on some emotional reaction OR> to which appears more correct. this is the lesson you should learn here OR> more than anything else. programming is a set of logical decisions and OR> your code is the record of the choices you made. OR> Well, I don't remember to have read a big warning to not make OR> float calculations in perl at all because the results are not OR> correct, or to not store floats in a database for the same OR> reason. I knew about the errors that might be encountered when OR> using floats, but I thought that this refers to the fact that the OR> computer can't calculate the "correct" value for operations like OR> 1/3, and I knew that in cases like this it is very normal to OR> expect losing some decimals. do you need a warning on every possible bad thing to do in coding? floats are fine for many things. they are just not correct for money in all cases. sure they may work for some values in some situations but not in ALL of them. OR> Please tell me if I am wrong and if there is a better method I OR> didn't think about. you are wrong in your understanding of the issue. i can't say it strongly enough. you don't understand how floats are implemented in these various systems, the possible errors that can occur and how to avoid them. you are just randomly trying things and they seem to work as you expect in some places and not in others. yet you still won't investigate why this happens so you can deal with it. i can't say anything more than this. i will not reply any more to this thread as you are not listening to me or others who say the same thing. uri -- Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Free Perl Training --- http://perlhunter.com/college.html --------- --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
