Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: krovit on August 08, 2020, 05:31:52 am

Title: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 05:31:52 am
Hello everyone, it is always a pleasure to read you and know that we are still here

My question:

The result is always 1.5
It is I who get confused and do something wrong or there is something wrong??

How can i handle decimals? 0.4999999 is not equal to 0.5.

After so many years of QB45 and QB64 it's a question I shouldn't even ask...
I know... it is one of the first and simplest problems faced when writing some code, but today I have doubts...

Thank you



Code: QB64: [Select]
  1.  
  3. ns=1.4999999999999999
  4. ? ns
  5. ? str$(ns)
  6.  
  8. nd=1.4999999999999999
  9. ? nd
  10. ? str$(nd)
  11.  
  13. nf=1.4999999999999999
  14. ? nf
  15. ? str$(nf)
  16.  
  17.  




Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: RhoSigma on August 08, 2020, 05:57:29 am
I usually avoid floating point math wherever and whenever possible. Eg. when calculating currency, then I do the calculations always in Cents, not in Dollars or Euros or whatever. I simply expand all INPUT values from the user with factor 100 and make internal calulations, only for display I convert it back using:

Code: QB64: [Select]
  1. PRINT LEFT$(STR$(cents&), LEN(STR$(cents&)) - 2); "."; RIGHT$(STR$(cents&), 2)

Same principle works for any other "all day" uses, you just need the right factor. Of course, if you calulate atronomic values, then you'll probably overflow even the biggest integer variable type using this method.

Another positive side effect, integer math is much faster than floating point math on every computer.
Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 06:10:59 am
Sorry... scrolling through the posts I saw of jack asking a question about _FLOAT accuracy on July 28th (I thought I was the only one still dealing with these little problems).
I saw that it used var## variables (which I did not know ... they had escaped me ... but how long have they existed?? a long time, I think, but I hadn't considered it)

However, excuse me, I still don't quite understand...
why if I declare the variable _FLOAT it doesn't work and if I use it directly with ## does it work? why is there a limit of 14 digits after the decimal point?


Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 06:17:28 am
1.4999999999999 = 1.4999999999999
1.49999999999999 = 1.5

with 14 digits after the comma everything works. with 15 and more rounds alone anyway

Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 06:21:41 am
Quote from: RhoSigma on August 08, 2020, 05:57:29 am
I usually avoid floating point math wherever and whenever possible. Eg. when calculating currency, then I do the calculations always in Cents, not in Dollars or Euros or whatever. I simply expand all INPUT values from the user with factor 100 and make internal calulations, only for display I convert it back using:

Code: QB64: [Select]
  1. PRINT LEFT$(STR$(cents&), 1); "."; RIGHT$(STR$(cents&), 2)

Same principle works for any other "all day" uses, you just need the right factor. Of course, if you calulate atronomic values, then you'll probably overflow even the biggest integer variable type using this method.

Another positive side effect, integer math is much faster than floating point math on every computer.

Thank you for your contribution, well, you... I, too, usually... maybe that's why I hadn't noticed this "problem"." But now I put it on because at some point the multiplication and division products in any case have numbers after the viorg that need to be evaluated

Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 07:04:44 am
Sorry I still don't understand...

Another example width _FLOAT variable:

1234567.49999999 = 1234567.49999999
1234567.499999999 = 1234567.5

9 digits after the comma (not 15)


Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: Richard Frost on August 08, 2020, 01:08:49 pm
http://www.qb64.org/wiki/Variable_Types

It says ## is the same as _FLOAT.

I look forward to the _BITCOIN type, which will make us all billionaires.   Likely this variable type
will only accept the results of divisions by zero. 
Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 08, 2020, 04:13:06 pm
Quote from: Richard Frost on August 08, 2020, 01:08:49 pm
http://www.qb64.org/wiki/Variable_Types

It says ## is the same as _FLOAT.

I look forward to the _BITCOIN type, which will make us all billionaires.   Likely this variable type
will only accept the results of divisions by zero. 


The first out of tune note in many years...

Yes ... I always consult the manual (for decades, I was not born yesterday) and I also search among the answers of other users. I know that certain issues are necessarily trivial but I had never noticed this behavior of the variables. I mainly dedicated myself to data management and interfaces for their entry, and little to calculation. Now, coincidentally, I need some calculations and this thing comes up.

I insist: 1.49999... is different from 1.5 and I would like to decide when to round and how (I know how to do it)
In single precision I could understand. I don't understand becauset rounds itself into _FLOAT and _DOUBLE

I'm certainly missing something extremely simple because I won't be the first to notice this.
Can someone please tell me where am I wrong?

Code: QB64: [Select]
  1. a#=1234567.49999999
  2. ? a#
  3.  
  4. a#=1234567.499999999
  5. ? a#
  6.  
  7. a##=1234567.49999999
  8. ? a##
  9.  
  10. a##=1234567.499999999
  11. ? a##
  12.  
  13. ? STR$(a##)
  14.  
  15.  

If the system rounds by itself I can't do it and it creates some problems with the results



I am asking the question in another way: I need to treat the number 1.4999999999999999999
not like 1.5 but just for what it is 1.4 and a long series of "9"
I thought I had to do it with double precision numbers but obviously I was wrong.

Any suggestions?






Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: FellippeHeitor on August 08, 2020, 04:48:52 pm
https://floating-point-gui.de/

Mandatory read, has this been posted in this thread yet?
Title: Re: a banality (sometimes sometimes doubts come back...)
Post by: SMcNeill on August 08, 2020, 08:20:05 pm
Sounds like you need to write your own string math routines so you can calculate values to whatever precision you desire.  Floating-point values terminate after a set point, depending on OS, math processors, and other factors, and if you’re not getting the level of precision you need, you’ll need to work around the issue with string math, or double-sided integer math (one integer for the left side of the decimal point, another decimal for the right side of the decimal point).
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 09, 2020, 11:04:38 am
Quote from: FellippeHeitor on August 08, 2020, 04:48:52 pm
https://floating-point-gui.de/

Mandatory read, has this been posted in this thread yet?

thanks, I did not know this site. it is a wealth of information
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 09, 2020, 11:09:53 am
Quote from: SMcNeill on August 08, 2020, 08:20:05 pm
Sounds like you need to write your own string math routines so you can calculate values to whatever precision you desire.  Floating-point values terminate after a set point, depending on OS, math processors, and other factors, and if you’re not getting the level of precision you need, you’ll need to work around the issue with string math, or double-sided integer math (one integer for the left side of the decimal point, another decimal for the right side of the decimal point).

Thank you, SMcNeill, If I understood your suggestion, yes, in fact I thought I would get around the problem by using strings. I wanted to deal with the whole part and the part after the comma, it wouldn't have been difficult, but the str$(x) function provides the string of the number already rounded without it being able to do anything to prevent it!

It all seems strange to me! it is not possible that I woke up this morning with a problem that I thought I had solved decades ago and that many have faced and overcome before me ...
my question also seems so stupid to me that I apologize first ...

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: SMcNeill on August 09, 2020, 11:30:12 am
You’re not looking for STR$(x).  You need to work with X$ directly.

X$ = “12345678901234567890123456789012345678901234567890”
Y$ = “98765432109876543210987654321098765432109876543210”
Z$ = X$ + Y$

What you want is a math routine to basically do the above, which since our strings are the same size, is fairly simple.  In this case, you just need a DO..LOOP to go from right to left, and add the current positions and any carry-over.

0 + 0 = 0
9 + 1 = 10, so second digit is 0, carry the 1 From the ten’s position.
8 + 2 + 1(the carry over) = 11.  Third digit is 1, carry the 1 From the ten’s position.
....continue until you go through the whole string.

When dealing with decimals, it’s the same process; you just convert both string values to the same number of decimal places.   0.0100000 + 0.987654

You’ll need to write routines for string addition, multiplication, subtraction, division, ect as needed, and then you can set your own precision limits to whatever you desire.  Just be warned: it’ll be much slower than binary math.
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 09, 2020, 12:21:55 pm
Quote from: krovit on August 09, 2020, 11:09:53 am
Thank you, SMcNeill, If I understood your suggestion, yes, in fact I thought I would get around the problem by using strings. I wanted to deal with the whole part and the part after the comma, it wouldn't have been difficult, but the str$(x) function provides the string of the number already rounded without it being able to do anything to prevent it!

It all seems strange to me! it is not possible that I woke up this morning with a problem that I thought I had solved decades ago and that many have faced and overcome before me ...
my question also seems so stupid to me that I apologize first ...




Sometimes I am speechless in front of the answers provided by the functions and the software... then I understand because I do not have a graduated in mathematics or in computer science (and sMcNeill turns the knife into the wound) ;) ... then I review the problems very well illustrated in the site suggested by Fellippe... and then I give up :(

I'm just looking for a simple way to round up as I would like
a# = 1 + .49999999999999
? a#  -->  1.49999999999999

a# = 1 + .499999999999999
? a#  -->  1.5


But it seems that a simple solution does not exist

Anyway thanks for your patience and for the answers (I've always said that this is a forum with tough and prepared people but kind and polite people)

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 09, 2020, 01:42:31 pm
Strange! For some odd reason this doesn't work for x1# = .55555555555555
Code: QB64: [Select]
  1. x1# = 10051.555555555555555555555555555 'Great!
  2. x1# = .3333333333333 'Great!
  3. x1# = .888888888888 'Great
  4. x1# = 5.55555555555 ' Fabulous!
  5. x1# = .444444444444 ' Marvelous!
  6. x1# = 73.737373737373 'Perfecto!
  7. x1# = .666666666666666 'good again!
  8. x1# = .54545454545 'Fine
  9. x1# = .49999999999 'OK was expecting 0's but alright
  10. x1# = .4555555 ' just lovely
  11. x1# = .5 'fine too though expecting 0's
  12. x1# = .55 'OK
  13. x1# = .655 'OK
  14. x1# = .6555 'OK
  15. x1# = .65555 'ok
  16. x1# = .655555 'ok
  17.  
  18. 'x1# = .555 'here it starts! 5 places good 2 places and more decimals sneek in
  19. 'x1# = .5555 'craps again
  20.  
  21. 'x1# = .5555555 'WTH where are the decimals coming from?
  22. 'comment the above line and try others
  23.  
  24. PRINT "Rounded to 5 places: "; RoundDblX2DP$(x1#, 5)
  25. PRINT "Rounded to 2 places: "; RoundDblX2DP$(x1#, 2)
  26. PRINT "Rounded to 0 places: "; RoundDblX2DP$(x1#, 0)
  27. PRINT "Rounded to Tens: "; RoundDblX2DP$(x1#, -1) 'just out of curiousity is this 0  in the 1's place ? yes!
  28. PRINT "Rounded to 100's: "; RoundDblX2DP$(x1#, -2)
  29.  
  30. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS INTEGER)
  31.     ' OK x <> .555...   .55 OK
  32.     'for DP = number of decimal places
  33.     DIM test$, p AS INTEGER, r AS DOUBLE
  34.     r = 5 * 10 ^ (-1 * (DP + 1))
  35.     'PRINT r      'that's it!
  36.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  37.     p = INSTR(test$, ".")
  38.     IF p = 0 AND DP <> 0 THEN test$ = test$ + "." + STRING$(DP, "0")
  39.     IF p AND DP = 0 THEN test$ = LEFT$(test$, LEN(test$) - 1)
  40.     RoundDblX2DP$ = test$
  42.  
  43.  
  44.  

EDIT: update after more investigation with .55...

One might begin to suspect there was a bug with .5 because this does not behave as expected.
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 09, 2020, 03:53:16 pm
Quote from: krovit on August 08, 2020, 04:13:06 pm
The first out of tune note in many years...

Yes ... I always consult the manual (for decades, I was not born yesterday) and I also search among the answers of other users. I know that certain issues are necessarily trivial but I had never noticed this behavior of the variables. I mainly dedicated myself to data management and interfaces for their entry, and little to calculation. Now, coincidentally, I need some calculations and this thing comes up.

I insist: 1.49999... is different from 1.5 and I would like to decide when to round and how (I know how to do it)
In single precision I could understand. I don't understand becauset rounds itself into _FLOAT and _DOUBLE

I'm certainly missing something extremely simple because I won't be the first to notice this.
Can someone please tell me where am I wrong?

Code: QB64: [Select]
  1. a#=1234567.49999999
  2. ? a#
  3.  
  4. a#=1234567.499999999
  5. ? a#
  6.  
  7. a##=1234567.49999999
  8. ? a##
  9.  
  10. a##=1234567.499999999
  11. ? a##
  12.  
  13. ? STR$(a##)
  14.  
  15.  

If the system rounds by itself I can't do it and it creates some problems with the results



I am asking the question in another way: I need to treat the number 1.4999999999999999999
not like 1.5 but just for what it is 1.4 and a long series of "9"
I thought I had to do it with double precision numbers but obviously I was wrong.

Any suggestions?








15 digits is the maximum number you get to see no matter where decimal goes:
Code: QB64: [Select]
  2. a# = 1
  3. FOR i = 1 TO 17
  4.     bs$ = "." + STRING$(i, "9")
  5.     b# = VAL(bs$)
  6.     PRINT "bs string, b Double, a Double + b Double: "; bs$, b#, a# + b#
  7.     FOR j = 1 TO i
  8.         PRINT "Round a + b to "; j; "places: "; RoundDblX2DP$(a# + b#, j)
  9.     NEXT
  10.     PRINT: PRINT "Press any for next..."
  11.     SLEEP
  12.     CLS
  14.  
  15. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS INTEGER)
  16.     ' OK x <> .555...   .55 OK
  17.     'for DP = number of decimal places
  18.     DIM test$, p AS INTEGER, r AS DOUBLE
  19.     r = 5 * 10 ^ (-1 * (DP + 1))
  20.     'PRINT r      'that's it!
  21.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  22.     p = INSTR(test$, ".")
  23.     IF p = 0 AND DP <> 0 THEN test$ = test$ + "." + STRING$(DP, "0")
  24.     IF p AND DP = 0 THEN test$ = LEFT$(test$, LEN(test$) - 1)
  25.     RoundDblX2DP$ = test$
  27.  
  28.  
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 09, 2020, 04:08:16 pm
Dang the freaking extra decimals popup again at 7 or 8 and then disappear:
Code: QB64: [Select]
  2. a# = 1
  3. FOR i = 1 TO 17
  4.     bs$ = "." + STRING$(i, "9")
  5.     b# = VAL(bs$)
  6.     PRINT "bs string, b Double, a Double + b Double: "; bs$, b#, b#
  7.     FOR j = 1 TO i
  8.         PRINT "Round a + b to "; j; "places: "; RoundDblX2DP$(b#, j)
  9.     NEXT
  10.     PRINT: PRINT "Press any for next..."
  11.     SLEEP
  12.     CLS
  14.  
  15. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS INTEGER)
  16.     ' OK x <> .555...   .55 OK
  17.     'for DP = number of decimal places
  18.     DIM test$, p AS INTEGER, r AS DOUBLE
  19.     r = 5 * 10 ^ (-1 * (DP + 1))
  20.     'PRINT r      'that's it!
  21.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  22.     p = INSTR(test$, ".")
  23.     IF p = 0 AND DP <> 0 THEN test$ = test$ + "." + STRING$(DP, "0")
  24.     IF p AND DP = 0 THEN test$ = LEFT$(test$, LEN(test$) - 1)
  25.     RoundDblX2DP$ = test$
  27.  


It's at 7 decimal places here. Must be a letter E or D popping into the STR$(Double).

Update: no it's not the E or D thing, guess I need to trim the tail
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 10, 2020, 06:02:00 am
Code: QB64: [Select]
  1. x1# = 10051.49999999999999999999999999999 ' :(
  2.  
  3. PRINT "Rounded to 5 places: "; RoundDblX2DP$(x1#, 5)
  4. PRINT "Rounded to 2 places: "; RoundDblX2DP$(x1#, 2)
  5. PRINT "Rounded to 0 places: "; RoundDblX2DP$(x1#, 0)
  6. ?
  7. PRINT "Rounded to Tens: "; RoundDblX2DP$(x1#, -1) 'just out of curiousity is this 0  in the 1's place ? yes!
  8. PRINT "Rounded to 100's: "; RoundDblX2DP$(x1#, -2)
  9.  
  10. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS INTEGER)
  11.     ' OK x <> .555...   .55 OK
  12.     'for DP = number of decimal places
  13.     DIM test$, p AS INTEGER, r AS DOUBLE
  14.     r = 5 * 10 ^ (-1 * (DP + 1))
  15.     'PRINT r      'that's it!
  16.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  17.     p = INSTR(test$, ".")
  18.     IF p = 0 AND DP <> 0 THEN test$ = test$ + "." + STRING$(DP, "0")
  19.     IF p AND DP = 0 THEN test$ = LEFT$(test$, LEN(test$) - 1)
  20.     RoundDblX2DP$ = test$
  22.  
  23.  

The site reported by Fellippe probably tells us that the problem is without solution.
In some cases this is a big problem! For example if the discriminant is 1.49 (or 1.4999999) rather than 1.5 or 1.51.
See how the first three cases give an erroneous laughter.

In the end, a conversion into a string as it is would be enough, without automatic rounding (even sMcNeill has provided a starting point to operate in this sense, however impractical).
If the number could be turned into a literal string, then everything would be possible.
But maybe that's too much to ask, I don't know... I think only Fillippe could do something about it at the source code level.

but it's a shame ... I don't know the extent of this problem on some of my applications, but I think the impact is strong

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 10, 2020, 12:47:26 pm
Quote from: krovit on August 10, 2020, 06:02:00 am
Code: QB64: [Select]
  1. x1# = 10051.49999999999999999999999999999 ' :(
  2.  
  3. PRINT "Rounded to 5 places: "; RoundDblX2DP$(x1#, 5)
  4. PRINT "Rounded to 2 places: "; RoundDblX2DP$(x1#, 2)
  5. PRINT "Rounded to 0 places: "; RoundDblX2DP$(x1#, 0)
  6. ?
  7. PRINT "Rounded to Tens: "; RoundDblX2DP$(x1#, -1) 'just out of curiousity is this 0  in the 1's place ? yes!
  8. PRINT "Rounded to 100's: "; RoundDblX2DP$(x1#, -2)
  9.  
  10. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS INTEGER)
  11.     ' OK x <> .555...   .55 OK
  12.     'for DP = number of decimal places
  13.     DIM test$, p AS INTEGER, r AS DOUBLE
  14.     r = 5 * 10 ^ (-1 * (DP + 1))
  15.     'PRINT r      'that's it!
  16.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  17.     p = INSTR(test$, ".")
  18.     IF p = 0 AND DP <> 0 THEN test$ = test$ + "." + STRING$(DP, "0")
  19.     IF p AND DP = 0 THEN test$ = LEFT$(test$, LEN(test$) - 1)
  20.     RoundDblX2DP$ = test$
  22.  
  23.  

The site reported by Fellippe probably tells us that the problem is without solution.
In some cases this is a big problem! For example if the discriminant is 1.49 (or 1.4999999) rather than 1.5 or 1.51.
See how the first three cases give an erroneous laughter.

In the end, a conversion into a string as it is would be enough, without automatic rounding (even sMcNeill has provided a starting point to operate in this sense, however impractical).
If the number could be turned into a literal string, then everything would be possible.
But maybe that's too much to ask, I don't know... I think only Fillippe could do something about it at the source code level.

but it's a shame ... I don't know the extent of this problem on some of my applications, but I think the impact is strong

You misunderstand how to use this function which only controls the display of numbers not the floating point math behind the scenes.

Only the first 14 to 16 digits are accurate in floating point math, the rest is always garbage.
So when you list more digits than a floating math memory address can hold of course it is going to chop off what it can't hold, it is generous that it does round at chop off point.

As applied to function, you asked for Rounded and for rounding to take place you need a cutoff of decimal places that is what DP parameter is for. Not any DP will work because of the 14-16 digit limit with Floating math.

If you test 15 digits or less the function rounds properly.

If you test more than 14-16 digits the floating point math will cut the number off at 14-16 digits (in base 10) because that is all the memory slot can hold.

Repeat: you only get 14-16 digits that will be treated in Floating point math.

As Steve said if you need higher precision than 14-16 digits then you have to write your own floating point math subs.

BTW I fixed the function to remove the extra decimal garbage creeping in, but again it will only work for 14-16 digits max, so the DP is limited to 14-16 minus the number of digits in the integer part of number.
Code: QB64: [Select]
  1. '_title "RoundDblX2DP$ test sub" b+ 2020-08-09
  2. ' 2020-08-09 revise function name as _TITLE
  3. ' trim excess tail if any and don't add decimal and 0's if not any
  4.  
  5. x1# = 10051.555555555555555555555555555 'Great!
  6. x1# = .3333333333333 'Great!
  7. x1# = .888888888888 'Great
  8. x1# = 5.55555555555 ' Fabulous!
  9. x1# = .444444444444 ' Marvelous!
  10. x1# = 73.737373737373 'Perfecto!
  11. x1# = .666666666666666 'good again!
  12. x1# = .54545454545 'Fine
  13. x1# = .4999999999 ' 10 places OK kept all the 9's
  14. x1# = .4555555 ' just lovely
  15. x1# = .5 'fine too though expecting 0's
  16. x1# = .55 'OK
  17. x1# = .655 'OK
  18. x1# = .6555 'OK
  19. x1# = .65555 'ok
  20. x1# = .655555 'ok
  21. x1# = 1.4999999999999990 'copied from forum
  22.  
  23. x1# = .555 'here it starts! 5 places good 2 places and more decimals sneek in  FIXED!
  24. x1# = .5555 'craps again  FIXED!
  25. x1# = .5555555 'WTH where are the decimals coming from? FIXED
  26.  
  27. 'try some lower and higher numbers
  28. x1# = 100000.000005 'no round?
  29. x1# = 100000.0000051 ' that should round
  30. x1# = 100000.00500001
  31. x1# = .005005005005
  32. x1# = .0505050505
  33.  
  34.  
  35. x1# = 10051.4999999999 ' 10 decimal place 15 digits total
  36.  
  37. 'comment the above line and try others
  38.  
  39.  
  40. PRINT "Rounded to 10 places: "; RoundDblX2DP$(x1#, 10)
  41. PRINT "Rounded to 5 places: "; RoundDblX2DP$(x1#, 5)
  42. PRINT "Rounded to 2 places: "; RoundDblX2DP$(x1#, 2)
  43. PRINT "Rounded to 0 places: "; RoundDblX2DP$(x1#, 0)
  44. PRINT "Rounded to Tens: "; RoundDblX2DP$(x1#, -1) 'just out of curiousity is this 0  in the 1's place ? yes!
  45. PRINT "Rounded to 100's: "; RoundDblX2DP$(x1#, -2)
  46.  
  47. FUNCTION RoundDblX2DP$ (x AS DOUBLE, DP AS LONG)
  48.     ' OK x <> .555...   .55 OK
  49.     'for DP = number of decimal places
  50.     DIM test$, p AS INTEGER, r AS DOUBLE
  51.     r = 5 * 10 ^ (-1 * (DP + 1))
  52.     'PRINT r      'that's it!
  53.     test$ = _TRIM$(STR$(INT((x + r) * 10 ^ DP) / 10 ^ DP))
  54.     p = INSTR(test$, ".")
  55.     IF p <> 0 THEN
  56.         IF DP = 0 THEN
  57.             test$ = LEFT$(test$, LEN(test$) - 1)
  58.         ELSE
  59.             IF DP > 0 THEN test$ = MID$(test$, 1, p) + MID$(test$, p + 1, DP)
  60.         END IF
  61.     END IF
  62.     RoundDblX2DP$ = test$
  64.  
  65.  

BTW the function is for displaying numbers, it doesn't work miracles with floating point math.





Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 12, 2020, 04:17:06 pm
Unfortunately I don't speak English... so some communication problem is inevitable...

Meanwhile I noticed that the phrase of my previous post was translated as follows:
"See how the first three cases give an erroneous laughter."
Of course I meant "answer" and not "laughter".

I precise this to avoid thinking that I make good laughs by observing the behavior of QB64 (it would have been an unforgivable disrespect)... :)

Apart from that for the patience and examples you've provided :)

These kinds of problems that you highlighted to me were more or less known to me and I understand that it is a formal rounding because over 15 digits (15 digits before and after the comma) the system is not able to go (and all you see is garbage without numerical importance).

But the problem is strange - and it's not just our lovable and dear QB64 (lovely and dear... I'm serious!). Just the windows calculator to make calculations with numbers of more than 15 digits without any problem.

If the number comes from a calculation, the problem does not exist. Or rather, it exists but it is not relevant because I can certainly do without the accuracy over 15 digit. At worst, it can be 999 billion and three decimal places... you can stay there (for financial calculations and also for others in many cases).

The problem, however, is without a solution if the data is entered. In this case, if they are read from a file, they must already be strings to treat them. If they are numbers when you "touch" they are already out of our reach because they are automatically rounded by the system.

The same goes for a traditional INPUT: in addition to the 15 digit the result is automatically rounded.

You need a controlled and treated input to the end as a sequence of individual strings to handle the digits beyond the 15th place properly

All right... I take note of that... Though.... why does the windows calculator seem to do better?


Sorry... not if in English there is a way of saying similar to that Italian "drown in a glass of water"... to say that maybe I see a problem that doesn't exist and I struggle to come out of it.



If you don't want to answer again... understand! :)




Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: TempodiBasic on August 12, 2020, 07:02:19 pm
Hi Krovit
thanks to show me another way to say "Perdersi in un bicchiere d'acqua" !
I have no ever listen "Affogare in un bicchiere d'acqua". 
https://it.wikipedia.org/wiki/Affogare_in_un_bicchier_d%27acqua (https://it.wikipedia.org/wiki/Affogare_in_un_bicchier_d%27acqua)
There is always something to know or to understand! Good so the life is not boring.

About the issue of the fifteenth number after the point of decimal digit,
Do you think that Windows' Calculator is able to avoid the rounding of the number done by the OS (system)? And how can it do this task? Maybe it is repiclable.

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 12, 2020, 08:20:03 pm
For the record, it's 14-16 digits total = digits left + digits right of the decimal.
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 13, 2020, 04:25:40 am
Quote from: TempodiBasic on August 12, 2020, 07:02:19 pm
Hi Krovit
thanks to show me another way to say "Perdersi in un bicchiere d'acqua" !
I have no ever listen "Affogare in un bicchiere d'acqua". 
https://it.wikipedia.org/wiki/Affogare_in_un_bicchier_d%27acqua (https://it.wikipedia.org/wiki/Affogare_in_un_bicchier_d%27acqua)
There is always something to know or to understand! Good so the life is not boring.

I'm not a kid anymore. but I still almost get emotional thinking about the diversity and wealth that can be grasped between peoples and different cultures.  And then to find out that, at the end of the day, we're all the same by staying different.


Quote from: TempodiBasic on August 12, 2020, 07:02:19 pm

About the issue of the fifteenth number after the point of decimal digit,
Do you think that Windows' Calculator is able to avoid the rounding of the number done by the OS (system)? And how can it do this task? Maybe it is repiclable.


Code: QB64: [Select]
  1. x#=1.499999999999999999  '19 places (for example)
  2. ? x#  '--> 1.5
  3.  
  4. x#=1.499999999999999999  + .05
  5. ? x#  '--> 1.55
  6.  
  7.  

...and compares with the windows calculator: why doesn't it all seem so simple?

  [ This attachment cannot be displayed inline in 'Print Page' view ]    [ This attachment cannot be displayed inline in 'Print Page' view ]  




Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 13, 2020, 04:31:30 am
Quote from: bplus on August 12, 2020, 08:20:03 pm
For the record, it's 14-16 digits total = digits left + digits right of the decimal.

Ah! Ok
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 13, 2020, 11:52:25 am
Yeah Windows Calculator has impressive math routines supporting it. We found that out comparing N! with _INTEGER64. As I recall we could do a deck of cards, 52!, but not 100!

Remember with calculators you need 1 calculation in a second or 2 but that would hardly do in a graphics animation.

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 14, 2020, 10:23:08 am
A contribution to the matter could come from ThinBasic (not for advertising but only to explore other possibilities).

Code: QB64: [Select]
  1. uses "Console"
  2.  
  4. CZ = 1.49999999999999  'limit: 15 places
  5. cz=cz+0.05
  6.  
  7. printl cz
  8.  
  9.  
  10. dim Cx AS ext
  11. Cx = 1.49999999999999  '15 places
  12. cx=cx+0.05
  13.  
  14. Cx = 1.49999999999999999  '18 places
  15. cx=cx+0.05
  16.  
  17. printl cx
  18.  
  19. WaitKey
  20.  

https://www.thinbasic.com/public/products/thinBasic/help/html/index.html

In ThinBasic it is possible to declare a variable type EXTENDED (EXT) width 18 digits of precision.
Okay, nothing sensational: 15 or 18, almost always wouldn't make a difference in the calculations.

However, I would like to point out a difference in behavior that appears useful for our purposes.

Then digits beyond the eighteenth are ignored (which one would expect) BUT it's interesting that the number is not automatically rounded! Only digits beyond the 18th are ignored.

The result is therefore similar to this:

1.49999999999999999999999999999999999999999999999999999 + 0.05 = 1.54999999999999999 (18 digits)

and not

1.49999999999999999999999999999999999999999999999999999 + 0.05 = 1.55


It seems to me a good compromise between precision, rounding and display!




Obviously... I have no idea how this effect can be reproduced in QB64...

Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 14, 2020, 12:23:39 pm
Quote
Obviously... I have no idea how this effect can be reproduced in QB64...

Make your own math subs working with strings. Lot's of work, slow running but you can have all the precision you want. 100 decimals? piece of cake*! once the math routines are worked out. ;-) 

This was already suggested by Steve, not sure you are understanding, could be lost in translation. :(

* ("Piece of cake" = expression of "easy to do"  ie, It's not hard to eat a piece of cake.)
Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: krovit on August 14, 2020, 03:49:00 pm
"Nothing is easy, especially when it appears simple".

Who said it? I say it! It is my motto when it comes to IT (and not only).

I understand well that ThinBasic's result is not reproducible quickly in QB64, but it doesn't seem like a bad idea to think about it.

Ultimately it seems that "simply" the garbage beyond the 15-18th digit is ignored and deleted and the system limits itself to operating with what remains WITHOUT rounding.

In my systems I never use direct numbers but strings introduced character by character and appropriately treated, as Steve approximately says.
This way, as you say, I get total control of the input. At some point, however, these strings have to be transformed into numbers and processed. At that point - in some cases - the question I raised arises.

For example: if the result is 1.49 periodic and an IF-THEN were to deal with it, the answer would ALWAYS be incorrect because for the periodic 1.49 system (1.499999999999999999999999999999999999999...) it is ALWAYS 1.5

But that's okay ... it's my problem. excess of zeal...


...But ThinBasic seems to me to solve the problem brilliantly. And with that I don't mean to take anything away from QB64 and its programmers


Anyway thanks for your patience and for listening


_____
For the record: several other basic dialects, which I have tested, have the same behavior as QB64. Thinbasic seems like an commendable exception (I haven't tried VB and not even the C)


Title: Re: Floating point math - a banality (sometimes sometimes doubts come back...)
Post by: bplus on August 18, 2020, 04:52:38 pm
@krovit Here it is in QB64, 1.49999.... 24 nines no rounding
Code: QB64: [Select]
  1. _TITLE "Math regulator demo for krovit" ' b+ start 2020-08-18
  2. RANDOMIZE TIMER 'now that it's seems to be running silent
  3. SCREEN _NEWIMAGE(1200, 700, 32)
  4. _DELAY .25
  6. x$ = mr$("3", "/", "2") '1.5
  7. y$ = mr$(x$, "-", ".0000000000000000000000001") '1.49999... 24 nines no rounding
  9. PRINT "Differnce to 1.5 is "; mr$(y$, "-", "1.5")
  10.  
  11.  
  12. FUNCTION mr$ (a$, op$, b$) ' catchy? mr$ for math regulator
  13.     DIM ca$, cb$, aSgn$, bSgn$, postOp$, SGN$
  14.     DIM adp AS INTEGER, bdp AS INTEGER, dp AS INTEGER, lpop AS INTEGER
  15.  
  16.     op$ = _TRIM$(op$) 'save fixing each time
  17.     ca$ = _TRIM$(a$): cb$ = _TRIM$(b$) 'make copies in case we change
  18.     'strip signs and decimals
  19.     IF LEFT$(ca$, 1) = "-" THEN
  20.         aSgn$ = "-": ca$ = MID$(ca$, 2)
  21.     ELSE
  22.         aSgn$ = "": ca$ = ca$
  23.     END IF
  24.     dp = INSTR(ca$, ".")
  25.     IF dp > 0 THEN
  26.         adp = LEN(ca$) - dp
  27.         ca$ = MID$(ca$, 1, dp - 1) + MID$(ca$, dp + 1)
  28.     ELSE
  29.         adp = 0
  30.     END IF
  31.     IF LEFT$(cb$, 1) = "-" THEN
  32.         bSgn$ = "-": cb$ = MID$(cb$, 2)
  33.     ELSE
  34.         bSgn$ = "": cb$ = cb$
  35.     END IF
  36.     dp = INSTR(cb$, ".")
  37.     IF dp > 0 THEN
  38.         bdp = LEN(cb$) - dp
  39.         cb$ = MID$(cb$, 1, dp - 1) + MID$(cb$, dp + 1)
  40.     ELSE
  41.         bdp = 0
  42.     END IF
  43.  
  44.     IF op$ = "+" OR op$ = "-" OR op$ = "/" THEN 'add or subtr  even up strings on right of decimal
  45.         'even up the right sides of decimals if any
  46.         IF adp > bdp THEN dp = adp ELSE dp = bdp
  47.         IF adp < dp THEN ca$ = ca$ + STRING$(dp - adp, "0")
  48.         IF bdp < dp THEN cb$ = cb$ + STRING$(dp - bdp, "0")
  49.     ELSEIF op$ = "*" THEN
  50.         dp = adp + bdp
  51.     END IF
  52.     IF op$ = "*" OR op$ = "/" THEN
  53.         IF aSgn$ = bSgn$ THEN SGN$ = "" ELSE SGN$ = "-"
  54.     END IF
  55.     'now according to signs and op$ call add$ or subtr$
  56.     IF op$ = "+" THEN
  57.         IF aSgn$ = bSgn$ THEN 'really add
  58.             postOp$ = aSgn$ + add$(ca$, cb$)
  59.         ELSE 'have a case of subtraction
  60.             IF aSgn$ = "-" THEN postOp$ = subtr$(cb$, ca$) ELSE postOp$ = subtr$(ca$, cb$)
  61.         END IF
  62.     ELSEIF op$ = "-" THEN
  63.         IF bSgn$ = "-" THEN 'really add but switch b sign
  64.             bSgn$ = ""
  65.             IF aSgn$ = "-" THEN
  66.                 postOp$ = subtr$(cb$, ca$)
  67.             ELSE 'aSgn = ""
  68.                 postOp$ = add$(ca$, cb$)
  69.             END IF
  70.         ELSE 'bSgn$ =""
  71.             IF aSgn$ = "-" THEN
  72.                 bSgn$ = "-"
  73.                 postOp$ = aSgn$ + add$(ca$, cb$)
  74.             ELSE
  75.                 postOp$ = subtr$(ca$, cb$)
  76.             END IF
  77.         END IF
  78.     ELSEIF op$ = "*" THEN
  79.         postOp$ = SGN$ + mult$(ca$, cb$)
  80.     ELSEIF op$ = "/" THEN
  81.         postOp$ = SGN$ + divide$(ca$, cb$)
  82.     END IF ' which op
  83.     'put dp back
  84.     IF op$ <> "/" THEN
  85.         lpop = LEN(postOp$) ' put decimal back
  86.         postOp$ = MID$(postOp$, 1, lpop - dp) + "." + MID$(postOp$, lpop - dp + 1)
  87.     END IF
  88.     mr$ = trim0$(postOp$)
  90.  
  91. FUNCTION divide$ (n$, d$)
  92.     DIM di$, ndi$, nD AS INTEGER
  93.     IF trim0$(n$) = "0" THEN divide$ = "0": EXIT FUNCTION
  94.     IF trim0$(d$) = "0" THEN divide$ = "div 0": EXIT FUNCTION
  95.     IF trim0$(d$) = "1" THEN divide$ = trim0$(n$): EXIT FUNCTION '8/17 add trim0$
  96.     di$ = MID$(nInverse$(d$, 100), 2) 'chop off decimal point after
  97.     nD = LEN(di$)
  98.     ndi$ = mult$(n$, di$)
  99.     ndi$ = MID$(ndi$, 1, LEN(ndi$) - nD) + "." + RIGHT$(STRING$(nD, "0") + RIGHT$(ndi$, nD), nD)
  100.     divide$ = trim0$(ndi$)
  102.  
  103. FUNCTION nInverse$ (n$, DP AS INTEGER) 'assume decimal at very start of the string of digits returned, no rounding
  104.     DIM m$(1 TO 9), si$, r$, outstr$, d$
  105.     DIM i AS INTEGER
  106.     FOR i = 1 TO 9
  107.         si$ = _TRIM$(STR$(i))
  108.         m$(i) = mult$(si$, n$)
  109.     NEXT
  110.     outstr$ = ""
  111.     IF n$ = "0" THEN nInverse$ = "Div 0": EXIT FUNCTION
  112.     IF n$ = "1" THEN nInverse$ = "1": EXIT FUNCTION
  113.     outstr$ = "." 'everything else n > 1 is decimal 8/17
  114.     r$ = "10"
  115.     DO
  116.         WHILE LEFT$(subtr$(r$, n$), 1) = "-" '   r - n < 0
  117.             outstr$ = outstr$ + "0" '            add 0 to the  output string
  118.             IF LEN(outstr$) = DP THEN nInverse$ = outstr$: EXIT FUNCTION 'check if we've reached DP length
  119.             r$ = r$ + "0"
  120.         WEND
  121.         FOR i = 9 TO 1 STEP -1
  122.             IF LTE(m$(i), r$) THEN d$ = _TRIM$(STR$(i)): EXIT FOR
  123.         NEXT
  124.         outstr$ = outstr$ + d$
  125.         IF LEN(outstr$) = DP THEN nInverse$ = outstr$: EXIT FUNCTION
  126.         r$ = subtr$(r$, mult$(d$, n$)) 'r = r -d*n
  127.         IF r$ = "0" THEN nInverse$ = outstr$: EXIT FUNCTION 'found a perfect divisor
  128.         r$ = r$ + "0" 'add another place
  129.     LOOP
  131.  
  132. FUNCTION mult$ (a$, b$) 'assume both positive integers prechecked as all digits strings
  133.     DIM la AS INTEGER, lb AS INTEGER, m AS INTEGER, g AS INTEGER, dp AS INTEGER
  135.     DIM f18$, f1$, t$, build$, accum$
  136.  
  137.     IF trim0$(a$) = "0" THEN mult$ = "0": EXIT FUNCTION
  138.     IF trim0$(b$) = "0" THEN mult$ = "0": EXIT FUNCTION
  139.     IF trim0$(a$) = "1" THEN mult$ = trim0$(b$): EXIT FUNCTION
  140.     IF trim0$(b$) = "1" THEN mult$ = trim0$(a$): EXIT FUNCTION
  141.     'find the longer number and make it a mult of 18 to take 18 digits at a time from it
  142.     la = LEN(a$): lb = LEN(b$)
  143.     IF la > lb THEN
  144.         m = INT(la / 18) + 1
  145.         f18$ = RIGHT$(STRING$(m * 18, "0") + a$, m * 18)
  146.         f1$ = b$
  147.     ELSE
  148.         m = INT(lb / 18) + 1
  149.         f18$ = RIGHT$(STRING$(m * 18, "0") + b$, m * 18)
  150.         f1$ = a$
  151.     END IF
  152.     FOR dp = LEN(f1$) TO 1 STEP -1 'dp = digit position of the f1$
  153.         build$ = "" 'line builder
  154.         co = 0
  155.         'now taking 18 digits at a time Thanks Steve McNeill
  156.         FOR g = 1 TO m
  157.             v18 = VAL(MID$(f18$, m * 18 - g * 18 + 1, 18))
  158.             sd = VAL(MID$(f1$, dp, 1))
  159.             t$ = RIGHT$(STRING$(19, "0") + _TRIM$(STR$(v18 * sd + co)), 19)
  160.             co = VAL(MID$(t$, 1, 1))
  161.             build$ = MID$(t$, 2) + build$
  162.         NEXT g
  163.         IF co THEN build$ = _TRIM$(STR$(co)) + build$
  164.         IF dp = LEN(f1$) THEN
  165.             accum$ = build$
  166.         ELSE
  167.             accum$ = add$(accum$, build$ + STRING$(LEN(f1$) - dp, "0"))
  168.         END IF
  169.     NEXT dp
  170.     mult$ = accum$
  172.  
  173. FUNCTION subtr$ (sum$, minus$) ' assume both numbers are positive all digits
  174.     DIM m AS INTEGER, g AS INTEGER, p AS INTEGER
  176.     DIM ts$, tm$, sign$, LG$, sm$, t$, result$
  177.  
  178.     ts$ = TrimLead0$(sum$): tm$ = TrimLead0$(minus$)
  179.     IF trim0(ts$) = trim0$(tm$) THEN subtr$ = "0": EXIT FUNCTION 'OK proceed with function knowing they are not equal
  180.     tenE18 = 1000000000000000000 'yes!!! no dang E's
  181.     IF LTE(ts$, tm$) THEN ' which is bigger? minus is bigger
  182.         sign$ = "-"
  183.         m = INT(LEN(tm$) / 18) + 1
  184.         LG$ = RIGHT$(STRING$(m * 18, "0") + tm$, m * 18)
  185.         sm$ = RIGHT$(STRING$(m * 18, "0") + ts$, m * 18)
  186.     ELSE 'sum is bigger
  187.         sign$ = ""
  188.         m = INT(LEN(ts$) / 18) + 1
  189.         LG$ = RIGHT$(STRING$(m * 18, "0") + ts$, m * 18)
  190.         sm$ = RIGHT$(STRING$(m * 18, "0") + tm$, m * 18)
  191.     END IF
  192.     'now taking 18 digits at a time From Steve I learned we can do more than 1 digit at a time
  193.     FOR g = 1 TO m
  194.         VB = VAL(MID$(LG$, m * 18 - g * 18 + 1, 18))
  195.         vs = VAL(MID$(sm$, m * 18 - g * 18 + 1, 18))
  196.         IF vs > VB THEN
  197.             t$ = RIGHT$(STRING$(18, "0") + _TRIM$(STR$(tenE18 - vs + VB)), 18)
  198.             p = (m - g) * 18
  199.             WHILE p > 0 AND MID$(LG$, p, 1) = "0"
  200.                 MID$(LG$, p, 1) = "9"
  201.                 p = p - 1
  202.             WEND
  203.             IF p > 0 THEN MID$(LG$, p, 1) = _TRIM$(STR$(VAL(MID$(LG$, p, 1)) - 1))
  204.         ELSE
  205.             t$ = RIGHT$(STRING$(18, "0") + _TRIM$(STR$(VB - vs)), 18)
  206.         END IF
  207.         result$ = t$ + result$
  208.     NEXT
  209.     subtr$ = sign$ + result$
  211.  
  212. FUNCTION add$ (a$, b$) 'add 2 positive integers assume a and b are just numbers no spaces or - signs
  213.     'first thing is to set a and b numbers to same length and multiple of 18 so can take 18 digits at a time
  214.     DIM la AS INTEGER, lb AS INTEGER, m AS INTEGER, g AS INTEGER
  216.     DIM fa$, fb$, t$, new$, result$
  217.     la = LEN(a$): lb = LEN(b$)
  218.     IF la > lb THEN m = INT(la / 18) + 1 ELSE m = INT(lb / 18) + 1
  219.     fa$ = RIGHT$(STRING$(m * 18, "0") + a$, m * 18)
  220.     fb$ = RIGHT$(STRING$(m * 18, "0") + b$, m * 18)
  221.  
  222.     'now taking 18 digits at a time Thanks Steve McNeill
  223.     FOR g = 1 TO m
  224.         sa = VAL(MID$(fa$, m * 18 - g * 18 + 1, 18))
  225.         sb = VAL(MID$(fb$, m * 18 - g * 18 + 1, 18))
  226.         t$ = RIGHT$(STRING$(36, "0") + _TRIM$(STR$(sa + sb + co)), 36)
  227.         co = VAL(MID$(t$, 1, 18))
  228.         new$ = MID$(t$, 19)
  229.         result$ = new$ + result$
  230.     NEXT
  231.     IF co THEN result$ = STR$(co) + result$
  232.     add$ = result$
  234.  
  235. ' String Math Helpers -----------------------------------------------
  236.  
  237. 'this function needs TrimLead0$(s$)
  238. FUNCTION LTE (a$, b$) ' a$ Less Than or Equal b$  comparison of 2 strings
  239.     DIM ca$, cb$, la AS INTEGER, lb AS INTEGER, i AS INTEGER
  240.     ca$ = TrimLead0$(a$): cb$ = TrimLead0(b$)
  241.     la = LEN(ca$): lb = LEN(cb$)
  242.     IF ca$ = cb$ THEN
  243.         LTE = -1
  244.     ELSEIF la < lb THEN ' a is smaller
  245.         LTE = -1
  246.     ELSEIF la > lb THEN ' a is bigger
  247.         LTE = 0
  248.     ELSEIF la = lb THEN ' equal lengths
  249.         FOR i = 1 TO LEN(ca$)
  250.             IF VAL(MID$(ca$, i, 1)) > VAL(MID$(cb$, i, 1)) THEN
  251.                 LTE = 0: EXIT FUNCTION
  252.             ELSEIF VAL(MID$(ca$, i, 1)) < VAL(MID$(cb$, i, 1)) THEN
  253.                 LTE = -1: EXIT FUNCTION
  254.             END IF
  255.         NEXT
  256.     END IF
  258.  
  259. ' ------------------------------------- use these for final display
  260.  
  261. FUNCTION TrimLead0$ (s$) 'for treating strings as number (pos integers)
  262.     DIM copys$, i AS INTEGER, find AS INTEGER
  263.     copys$ = _TRIM$(s$) 'might as well remove spaces too
  264.     i = 1: find = 0
  265.     WHILE i < LEN(copys$) AND MID$(copys$, i, 1) = "0"
  266.         i = i + 1: find = 1
  267.     WEND
  268.     IF find = 1 THEN copys$ = MID$(copys$, i)
  269.     IF copys$ = "" THEN TrimLead0$ = "0" ELSE TrimLead0$ = copys$
  271.  
  272. FUNCTION TrimTail0$ (s$)
  273.     DIM copys$, dp AS INTEGER, i AS INTEGER, find AS INTEGER
  274.     copys$ = _TRIM$(s$) 'might as well remove spaces too
  275.     TrimTail0$ = copys$
  276.     dp = INSTR(copys$, ".")
  277.     IF dp > 0 THEN
  278.         i = LEN(copys$): find = 0
  279.         WHILE i > dp AND MID$(copys$, i, 1) = "0"
  280.             i = i - 1: find = 1
  281.         WEND
  282.         IF find = 1 THEN
  283.             IF i = dp THEN
  284.                 TrimTail0$ = MID$(copys$, 1, dp - 1)
  285.             ELSE
  286.                 TrimTail0$ = MID$(copys$, 1, i)
  287.             END IF
  288.         END IF
  289.     END IF
  291.  
  292. FUNCTION trim0$ (s$)
  293.     DIM cs$, si$
  294.     cs$ = s$
  295.     si$ = LEFT$(cs$, 1)
  296.     IF si$ = "-" THEN cs$ = MID$(cs$, 2)
  297.     cs$ = TrimLead0$(cs$)
  298.     cs$ = TrimTail0$(cs$)
  299.     IF RIGHT$(cs$, 1) = "." THEN cs$ = MID$(cs$, 1, LEN(cs$) - 1)
  300.     IF si$ = "-" THEN trim0$ = si$ + cs$ ELSE trim0$ = cs$
  302.  
Text Only | Text with Attachments