Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 10:40 25 Apr 2024 Privacy Policy
Jump to

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: Netherlands
Posts: 56
Posted: 08:41am 24 Oct 2018
Copy link to clipboard 
Print this post

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

Edited by DrifterNL 2018-10-25
Floating Point Keeps Sinking Me!
Back To Integer So I Don't Get Injured.
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 08:54am 24 Oct 2018
Copy link to clipboard 
Print this post

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

hEdited by CaptainBoing 2018-10-25
 
DrifterNL

Regular Member

Joined: 27/09/2018
Location: Netherlands
Posts: 56
Posted: 09:36am 24 Oct 2018
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 1985
Posted: 11:39am 24 Oct 2018
Copy link to clipboard 
Print this post

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.

hEdited by CaptainBoing 2018-10-25
 
Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769
Posted: 04:25am 25 Oct 2018
Copy link to clipboard 
Print this post

@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: Netherlands
Posts: 56
Posted: 10:01pm 03 May 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 5898
Posted: 10:23pm 03 May 2022
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 3654
Posted: 07:50am 04 May 2022
Copy link to clipboard 
Print this post

  DrifterNL said  Running the program in the initial post I am now getting the correct values.

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


To reply to this topic, you need to log in.

© JAQ Software 2024