Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
computer adds .1 9 times and comes up with .8000001
#11
Quote:I had a problem with things acting oddly in my program. When I investigated I found something really strange.
example:
cls
do
print b;
b=b+.1
a=a+1
loop until a=70
this is the result I received:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8000001 .9000001 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.799999 2.899999 2.999999 3.099999 3.199999 3.299999 3.399999 3.499999 3.599999 3.699999 3.799999 3.899998 3.999999 4.099999 4.199999 4.299999 4.399999 4.499999 4.599999 4.699999 4.799999 4.899999 4.999999 5.099998 5.199997 5.299997 5.399997 5.499997 5.599997 5.699997 5.799997 5.899997 5.999997 6.099997 6.199996...............

I brought this issue up a while ago, but noone bothered to take any interest. They all thought i was asking a question.

http://forum.qbasicnews.com/viewtopic.php?t=4773 for more info


That link explains why this problem occours, if you havent already got it from the guys above.
Reply
#12
Thank you everyone. I tried the program above with the dim integer and it worked. I had allready tried using /10 and the problem had continued. the dim integer program fixed it. In the past I worked in binary knowing which number was in what register and what action the computer would take depending on which number it was viewing. I assisted my cousin in writting an assembler. I understand that it can be very difficult to figure out a way to do certain things. That was the more creative and fun part. I can't fathom that teams of pro's would just let this problem be. If there is a way to program around the problem then there is a way to program the program to program properly. DOes this problem exist in all basic progams or can I upgrade to one where they have solved this issue. I see there is a simple way around the problem ,but I find the existence of the problem disturbing.
thanks again,
Sean
Reply
#13
It has nothing to do with BASIC, it has to do with how the computer stores numbers internally. In other words...it doesn't matter what you use, the same error will always exist.
I'd knock on wood, but my desk is particle board.
Reply
#14
It does have to do with basic. If the basic program was writen using the proper algorithm the issue would not exist. when I open the calculator on my computer and use it to perform the same type of math it gives accurate results because the person/persons writing the calculator program spent the time to resolve the issue. Again has anyone fixed it in a later version. do I have to write my programs around it like programers of basic COULD have and or find a more accurate language.
thank you,
Sean
Reply
#15
The calculator does not work in the same way and use the same variable types as QB do.

For example:
2^100 is valid on the calculator, not in QB


If you use 32bit's to store decimal numbers (floating point) then you get the same error, because of how the computer works. read an explanation of it somewhere, but can't find it now.


In any case, using whole integers is faster.
I've never really needed to add 0.1, I've never needed to use decimals at all.

Like already said, it can be done by division later.


Code:
do
b!=b!+0.1
loop until b! = 1

Code:
do
b%=b%+1
loop until b% = 10
Reply
#16
Sean, there is no "fix" for the problem in later versions. In fact, most languages that use single or double floating point numbers will have the same problem. I've also been plagued by this problem on occassions.

NOTE: The best way to avoid the problem is not to use numbers with decimals. Convert the numbers to whole numbers (like LONG) and YOU keep track of where the implied decimal point is. This works like a charm. I've done many accounting systems, and using this method, have not had any accuracy problems.
*****
Reply
#17
Quote:cls
do
print b;
b=b+.1
a=a+1
loop until a=70
.....

In addition to what others said, this code has another problem if using floats instead of integers. Consider the line:
loop until a=70

this line may never be true. When using floats in a conditional test, always test using, eg greater than rather than equals to avoid this problem. Better yet, avoid floats altogether, except when you need them. when doing integer divition, use the mod operator to keep track of the remainder. Never use a float as a counter. Never index an array with a float.

QB is pretty good about hiding conversions from you...for example if you:
pset(123.456, 89.012)
QB will not complain and simply convert the decimals to ints...whether it rounds or truncates the numbers...well...I don't know which it does off the top of my head, although it'd be easy to determine using pairs of pset(x,y) and point(x,y) statements.

Anyway...once you get used to *not* using floats, you find that you don't miss them one bit...and your programs will run faster.

The following tests the speed of int vs float. I get ratio of ~8. Anyone care to tell the value if ffix is used??
Code:
DEFINT I  'an integer number
DEFSNG F  'a floating point number

CLS

'counts using 16-bit integers
'cumbersome nested loops used to avoid 16-bit overflow
t = TIMER + 1
DO
  FOR i1 = 1 TO 1000
    FOR i2 = 1 TO 1000
      FOR i3 = 1 TO 1000
      NEXT i3
      IF (TIMER > t) THEN EXIT DO
    NEXT i2
  NEXT i1
LOOP
countINT = (i1 * 1000000!) + (i2 * 1000!) + (i3 * 1!)

'counts using single precision floating point numbers
'cumbersome nested loops used to avoid introducing bias
t = TIMER + 1
DO
  FOR f1 = 1 TO 1000
    FOR f2 = 1 TO 1000
      FOR f3 = 1 TO 1000
      NEXT f3
      IF (TIMER > t) THEN EXIT DO
    NEXT f2
  NEXT f1
LOOP
countFLOAT = (f1 * 1000000!) + (f2 * 1000!) + (f3 * 1!)

PRINT "after one sec   ints were added"; countINT; "times"
PRINT "after one sec floats were added"; countFLOAT; "times"
PRINT "int to float speed ratio ="; countINT / countFLOAT
Reply
#18
So long and thanks for all the fish. I don't know why but I just had to say that(maybe the beer). After the last two days of this I finally started to remember. I started programming in basic(on an atari 400) in about 78-79 when I was ten or eleven. By the time I stopped programming about 85-86 I had allready resolved this problem ,and I'm sure others, to the point were I didn't even think about it anymore(hence me not remembering it). Originaly when I posted this I just wanted to know if there was an error in my computer or in the program(qbasic) that I had downloaded. The codes that have been sent to me have either reminded me of how I dealt with this problem in the past or some have pointed out some of the new features or ,maybe feature I had not known, of basic. there is still something wrong and this the best I could sum it up.

You are offered 100,000 pounds of gold to write one portion of the latest version of qbasic. All you have to do is make all equations such as I originaly posted work in any circumstance(to any value) until the computer had used it's full memory for the sum. Tell me which one of you could not do it?
Reply
#19
The problem lies in fitting huge numbers in only 32bits.

The floating point number can never be exact.

0.1 is infact: 0.10000000000000[...]

We humans ignore that, but the computer don't.

I'm not 100% sure, but the bit's wrap around, and the 1 is added to the end as well, so the number becomes something (roughly) like:
0.100000001000000010000000100000001[...]


after a certain operations, that rougue 1 has become so large, that it's no longer ignored by the CPU, and your floating point number becomes: 0.8000001

It's not an error, it's the way computers work.
It's how the floating point number is fitted into only 32bit's





(All this may be completely wrong... *waiting for Plasma to come and correct me*)
Reply
#20
I understand what your driving at. I understand the concept. with your programming skills you could not create a solution. Even if the computer is limited as to what it can view. 2bits, 4bits, 32 bits. You can not direct it through a program of your design to view and display predictable results. (2 bits would be rather difficult, one bit and you have me beat also).
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)