Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : MMBasic V4.5C Error in Arithmetic?
Author | Message | ||||
DrifterNL Regular Member Joined: 27/09/2018 Location: NetherlandsPosts: 56 |
Using Colour Maximite MMBasic V4.5C Using the following program: start: Input a a = a - Fix(a) Print a GoTo start entering 0.1 will print the answer 0.1 which is correct entering 1.1 will print the answer 0,1 which is correct entering 2.1 will print the answer 0.0999999 which in incorrect the incorrect answer 0.0999999 will be given for any number from 2.1 to 7.1 at 8.1 the answer goes back to 0.1 this error also occurs with higher numbers: 22.2 should print 0.2 but prints 0.200001 33.3 should print 0.3 but prints 0.299999 11.11 will print 0.11 which is correct 22.22 should print 0.22 but prints 0.219999 Is this a thinking error on my side? Edit: At first I thought this was an error in function "Fix" but after some experimenting it looks like something else is going on: print 1.1 - 1 will print 0.1 print 2.1 - 2 will print 0.0999999 print 2.1 - 2.0 will print 0.0999999 print 8.1 - 8 will print 0.1 Floating Point Keeps Sinking Me! Back To Integer So I Don't Get Injured. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
Hello DrifterNL - welcome to the forum. Humans work really well with this stuff but floating point doesn't. 0.0999999 is tantamount to 0.1 - i.e. the numerical value error is so tiny that it doesn't matter for all but scientific/financial tasks - doesn't help here but that is the reason you get these "errors". As a human, you are using your excellent pattern matching abilities and you can easily visualize precisely a tenth part - the maths pack is dealing with raw numbers and it is bound by what it can get into the format of a floating point number held in bytes. This is a problem with just about any computing system that uses floating point expressed as a mantissa and exponent. Google "Excel rounding error" You can see this in human terms when you think of 1/3 expressed as a decimal. same thing; the maths pack can't give you the precise value so you get one that is so close as not to matter but if you are expecting something that makes perfectly good sense in your head you might be forgetting that when you enter 7.1 it has to be converted to FP format and that will result in some minor loss of fidelity. Probably not want you wanted to hear but it isn't a bug. What you can do is work out what limits are applied to your numbers and then multiply them up to preserve the possible decimals then use integer maths (e.g. don't work in Euros, work in cents); dividing down before you output the result. This is an old trick to get machine code to work with decimals in integer maths. If you can't define limits, you are then confined to using what you have, with the very common result above - shocking isn't it? hth h |
||||
DrifterNL Regular Member Joined: 27/09/2018 Location: NetherlandsPosts: 56 |
Thanks for the quick response! Being used to an older micro controller (C-Control V2.0 from Conrad) that uses Bit, Byte and Signed integer variables, this floating point mathematics with it's quirks / rounding errors is new to me and something I will have to take in to account. just glad to hear it's not a bug. Floating Point Keeps Sinking Me! Back To Integer So I Don't Get Injured. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
LOL, I have been at it for 40+ years and it still catches me out. Most things in electronics and maths are only ever "close enough that it doesn't matter" e.g. Logic 0 is rarely (never) precisely GND potential. and Logic 1 will only ever be "close enough" to VCC... that's why we have all these dull tables of signal names and values in the datasheets. Have fun though, always. h |
||||
Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@DrifterNL ... Every number system has irrational or insoluble quirks. We are used to base 10 because most of us have 10 fingers. In base 10 you can't divide exactly by 3 or 7 or any multiple of 3 or 7, and everybody understands that. In base 2, which is what most computers use, you can't divide by 3, 5, or 7 or any multiple of 3, 5, or 7, and almost nobody understands that. Business oriented languages like COBOL, dBase and FoxPro use very slow and elaborate math functions with encode BCD (Binary Coded Decimal) numbers into binary form and then divide using the same rules we learned with pencil and paper. Those BCD math functions produce exactly the same errors we are used to, which seems to satisfy accountants and lawyers immensely. Accountants and lawyers are easy to satisfy. Paul in NY |
||||
DrifterNL Regular Member Joined: 27/09/2018 Location: NetherlandsPosts: 56 |
Sorry for raising an old thread. After watching "PicoMite: Running BASIC on a Rasberry Pi Pico" from Explaining Computers I thought I would give the PicoMite a try. Running the program in the initial post I am now getting the correct values. This should make things much easier! Floating Point Keeps Sinking Me! Back To Integer So I Don't Get Injured. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5899 |
Don't worry, floating point is still floating point so the same 'limitations' apply. With 64 bits, it just appears for higher resolution numbers. VK7JH MMedit MMBasic Help |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3654 |
You always were getting the correct values within the limits of arithmetic, as has been explained in previous posts. Every (non-formulaic) finite representation of infinite numbers (such as 1/3, in decimal being 0.3333...) inevitably suffers the issue which has been explained - and the PicoMite will too (though it may appear not to for the kind of numbers you've mentioned). If you think it doesn't have the issue, sooner or later it will bite you (because it does, as does every computer or indeed calculator). It's inherent. Program around it. By way of example, you're dealing with the equivalent on a calculator of 1/3 result 0.3333333333 *3 result 0.9999999999 Note: the result isn't 1. John Edited 2022-05-04 19:22 by JohnS |
||||
Print this page |