Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 19:05 28 Mar 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 : Micromite eXtreme Firmware V5.03

     Page 3 of 4    
Author Message
isochronic
Guru

Joined: 21/01/2012
Location: Australia
Posts: 689
Posted: 07:41pm 16 Apr 2017
Copy link to clipboard 
Print this post

The usual double precision variable will only keep 12 or so
significant figures accurately (?)Edited by chronic 2017-04-18
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 09:46pm 16 Apr 2017
Copy link to clipboard 
Print this post

The double precision variables keep roughly 16 digit accuracy throughout all mathematical operations. The issue is with a C routine written by Geoff called FloatToString which takes the binary representation and converts it to ASCII. This works perfectly in single precision and works perfectly in double when the digits are to the left of the decimal point e.g. 1234567890123456.0
There is some sort of problem that I haven't been able to track down when the digits are to the right of the decimal point. What should print as 0.1234567890123456 prints as 0.1234567890777777. This is just an artefact of the ascii conversion in this routine.

It is on my to-do list to fix this and Jim's idea seems very interesting. The problem is that the routine is quite complex as it makes intelligent decisions about things like using exponential notation (x.xxxExxx) and does clever stuff to create fixed length padded output when called from the STR$ function

I believe the only impact of the problem is currently when you want to print > 10 digits accuracy of numbers to the right of the decimal point whether in standard or exponential notation so it hasn't been high up on the "to-do" list but cdeagle has identified a specific application where it is important to him. For most use where doubles are used to avoid errors in calculation there is no issue.Edited by matherp 2017-04-18
 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 01:11am 17 Apr 2017
Copy link to clipboard 
Print this post

Jim,

Thanks for posting your uFormat$ function.

I tried it with the program that creates the DATA statements and got the following output for uFormat$(x, 10);

DATA -19509.1504904551 , -19101.5975629190 , -5379.2389600431
DATA 2674.5479140215 , -411076.3923386102 , 18039.1705252558
DATA -302385.5002937336 , -6927.7505690791 , -102534.8152911626
DATA 2372.8918290417 , 146514.2066164300 , -5205.2288478688
DATA 47026.2473037709 , -1324.9750680459 , 16002.3414701039
DATA -1296.8825492908 , -14753.2676623915 , 162.1208555740
DATA -4017.7777613461 , 544.7224956757 , -1386.4294032517
DATA 209.4456841553 , 1302.5618648993 , 18.1866552863
DATA 408.0068327223 , -61.6961381778 , 141.2789790387
DATA -16.8787954896 , -151.3402381788 , 0.2240511289
DATA -52.2066272425 , 3.6345097148 , -17.9205134669
DATA 0.8677964695 , 20.2834133534 , -.3232061603
DATA 7.1829675456 , -.1502183779 , 2.5567619612
DATA 0.-384471089 , -2.7613886969 , 0.0-17482134
DATA -.9255155106 , 0.0109838853 , -.3880391668
DATA 0.0-27603561 , 0.3227224342 , 0.0157758824
DATA 0.0825569366 , 0.0028333913 , 0.0536707147
DATA 0.0050759350 , 0.-177960174 , 0.0-34995422
DATA 0.0036598555 , 0.0-35998922 , 0.0-47281067
DATA 0.0-24012091 , 0.0-43875197 , 0.0001654927
DATA 0.0-48342663 , 0.0019899368 , 0.00-4804109

Most of the DATA statements are correct. However, several have a negative sign embedded within the number. This can be seen in the last four DATA statements.

Here's the program output using uFormat$(x, 12);

DATA -19509.150490455116 , -19101.597562919016 , -5379.238960043110
DATA 2674.547914021532 , -411076.392338610176 , 18039.170525255764
DATA -302385.500293733568 , -6927.750569079078 , -102534.815291162544
DATA 2372.891829041659 , 146514.206616430016 , -5205.228847868756
DATA 47026.247303770888 , -1324.975068045855 , 16002.341470103866
DATA -1296.882549290833 , -14753.267662391464 , 162.120855573956
DATA -4017.777761346128 , 544.722495675652 , -1386.429403251716
DATA 209.445684155272 , 1302.561864899325 , 18.186655286300
DATA 408.006832722261 , -61.696138177777 , 141.278979038727
DATA -16.878795489627 , -151.340238178770 , 0.224051128854
DATA -52.206627242525 , 3.634509714780 , -17.920513466857
DATA 0.867796469463 , 20.283413353429 , -.323206160327
DATA 7.182967545636 , -.150218377913 , 2.556761961220
DATA 0.-38447108915 , -2.761388696944 , 0.0-1748213429
DATA -.925515510583 , 0.010983885294 , -.388039166797
DATA 0.0-2760356101 , 0.322722434241 , 0.015775882394
DATA 0.082556936574 , 0.002833391276 , 0.053670714705
DATA 0.005075935010 , 0.-17796017408 , 0.0-3499542221
DATA 0.003659855542 , 0.0-3599892174 , 0.0-4728106716
DATA 0.0-2401209093 , 0.0-4387519705 , 0.000165492722
DATA 0.0-4834266271 , 0.001989936790 , 0.00-480410859
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 03:10am 17 Apr 2017
Copy link to clipboard 
Print this post

Well there is good news and bad news

The good news is that I've fixed the issue on the Pi-cromite by rewriting the formatting routine using the standard c-library call sprintf

The bad news is that version 1.42 of the Microchip compiler doesn't support sprintf for doubles

the new V1.43 of the compiler does support doubles but doesn't compile the rest of the Micromite code.

I'll post the update for the Pic-cromite on the relevant thread
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 04:46am 17 Apr 2017
Copy link to clipboard 
Print this post

Minor changes but possible issues - please let me know if you find anything strange

This release fixes the bug in outputting more than 10 significant digits after the decimal point in floating point numbers using the STR$ function

It also fixes a bug in the GPS(longitude) function

In order to fix the first issue it has been necessary to move to the latest version of the XC32 compiler (V1.43) and the latest version of Harmony (2.02b) so there may be bugs that have been introduced (by Microchip) even though the code hasn't changed.


Attached is the latest release 5.3.17 for the 100 and 144-pin parts

2017-04-17_144129_MMX5.3.17.zip

And for the 64-pin part with same bug fixes

2017-04-17_144218_MMX645.3.17.zip

 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 07:20am 17 Apr 2017
Copy link to clipboard 
Print this post

Here's a test with MMX5.3.17

The code



option default float

option base 1

' global constants

const seccon = 206264.8062470964

print seccon

print " "

print str$(seccon, 6, 10)

print " "

print pi

print " "

print str$(pi, 1, 16)

print " "

end


The results

RUN
206265

206264.8125

3.14159

3.1415927410125732

>
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 08:57am 17 Apr 2017
Copy link to clipboard 
Print this post

  Quote  Here's a test with MMX5.3.17


Can you try the Pi version - I think that should be correct now.

Everyone else - please don't use 5.3.17
Edited by matherp 2017-04-18
 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 10:49am 17 Apr 2017
Copy link to clipboard 
Print this post

Peter,

The PI version seems to work fine. It created proper DATA statement values and correct program results.

David
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5867
Posted: 12:36pm 17 Apr 2017
Copy link to clipboard 
Print this post

  cdeagle said   Jim,

Thanks for posting your uFormat$ function.


When the micromite first appeared as a successor to the Maximite, I missed the FORMAT function. STR$ didn't have any options at that stage.
That's where uformat$ came from. I am not sure how much is my work. I know there was a bit of discussion here ate the time.

To solve the problem with some numbers giving strange results, I suggest scaling the number first to a number between 1.0 and 9.999... and displaying in exponential form by adding the "e" to the end. While walking the dogs this morning, I came up with a simple plan to do that and will give it a try later today.

Peter might have beaten me to it by then but it's a good exercise anyway.

Jim


VK7JH
MMedit   MMBasic Help
 
BobD

Guru

Joined: 07/12/2011
Location: Australia
Posts: 935
Posted: 01:10pm 17 Apr 2017
Copy link to clipboard 
Print this post

[quote] While walking the dogs this morning, I came up with a simple plan to do that and will give it a try later today.
[/quote]
I get my best ideas while in the thinking room. Have a look here for further inspiration.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5867
Posted: 06:45pm 17 Apr 2017
Copy link to clipboard 
Print this post

David, try this version called eformat$
All numbers are returned in exponential form.
The number of significant figures seems to work well and it works with single precision but the expected inaccuracies are there when you try for too many sig figures

  Quote   DO
READ a

PRINT a, eformat$(a,12)
LOOP UNTIL a = 0

FUNCTION eformat$(x,p)
LOCAL s, sign, sg$, ev$, f$
IF x< 0 THEN ' save the sign to add later
sign = -1
sg$=
"-"
ELSE
sign =
1
sg$=
" "
ENDIF
x = x * sign
' convert to positive number
IF x < 1 AND x <>0 THEN ' convert the number to between 1 and 10
DO ' and save the exponent for later
x = x*10
s = s-
1
LOOP UNTIL x>=1
ev$ =
"e"+STR$(s)
ELSEIF x >=10 THEN
DO
x = x/
10
s = s+
1
LOOP UNTIL x< 10
ev$ =
"e"+STR$(s)
ENDIF

f$=
STR$(CINT(x*10^p),p,0,"0")
IF p>0 THEN
f$=
LEFT$(f$,1)+"."+MID$(f$,2)
ENDIF
eformat$ = sg$+f$+ev$
END FUNCTION

DATA -19503.5967962382, -19120.6463095138, -5386.83402043336
DATA 2697.05908554283, -411062.593704381, 18048.4396148379
DATA -302378.152698336, -6944.44935382575, -1025352.02824372
DATA -1.95035967962382e4, -1.91206463095138e4, -5.38683402043336e3
DATA 2.69705908554283e3, -4.11062593704381e5, 1.80484396148379e4
DATA -3.02378152698336e5, -6.94444935382575e3, -1.02535202824372e5
DATA -19509.150490455116 , -19101.597562919016 , -5379.238960043110
DATA 2674.547914021532 , -411076.392338610176 , 18039.170525255764
DATA -302385.500293733568 , -6927.750569079078 , -102534.815291162544
DATA 2372.891829041659 , 146514.206616430016 , -5205.228847868756
DATA 47026.247303770888 , -1324.975068045855 , 16002.341470103866
DATA -1296.882549290833 , -14753.267662391464 , 162.120855573956
DATA -4017.777761346128 , 544.722495675652 , -1386.429403251716
DATA 209.445684155272 , 1302.561864899325 , 18.186655286300
DATA 408.006832722261 , -61.696138177777 , 141.278979038727
DATA -16.878795489627 , -151.340238178770 , 0.224051128854
DATA -52.206627242525 , 3.634509714780 , -17.920513466857
DATA 0.867796469463 , 20.283413353429 , -.323206160327
DATA 7.182967545636 , -.150218377913 , 2.556761961220
DATA 1,-1,0


I have not made any attempt to speed up the process, staying with hopefully readable code instead.

[Edited to test for zero - not happy with zero!]
Jim
Edited by TassyJim 2017-04-19
VK7JH
MMedit   MMBasic Help
 
isochronic
Guru

Joined: 21/01/2012
Location: Australia
Posts: 689
Posted: 09:20pm 17 Apr 2017
Copy link to clipboard 
Print this post

Mea culpa - I was a bit pessimistic with 12 sig fig - Was in sleeping-brain easter mode I think !

Looking at Microchip lit, they do specify 16 sig fig for their double precision variables. (and 6 for single precision)

I have slogged through writing versions of printf/ sprintf to get output etc as part of porting to the MZ, and it is annoying to have to do that.

One aspect is that, for user-specified-precision output, rounding is necessary - which adds more complexity. More importantly, the math operations of scaling, division, etc needed for output (and more so with rounding) slowly impact the original sig figs so 16 is a bit of a stretch.

 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 09:21pm 17 Apr 2017
Copy link to clipboard 
Print this post

  Quote  I have slogged through writing versions of printf/ sprintf to get output etc as part of porting to the MZ, and it is annoying to have to do that.


Can you share them?
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 01:29am 18 Apr 2017
Copy link to clipboard 
Print this post

Hopefully right this time

Minor changes but possible issues - please let me know if you find anything strange

New feature:

You can use a negative number in the str$ function to force conversion into exponential format as in the picture






Bug Fixes:

This release fixes the bug in outputting more than 10 significant digits after the decimal point in floating point numbers using the STR$ function

It also fixes a bug in the GPS(longitude) function

In order to fix the first issue it has been necessary to move to the latest version of the XC32 compiler (V1.43) and the latest version of Harmony (2.02b) so there may be bugs that have been introduced (by Microchip) even though the code hasn't changed.


Attached is the latest release 5.3.17 for the 100 and 144-pin parts

2017-04-18_111823_MMX5.3.17.zip

And for the 64-pin part with same bug fixes

2017-04-18_111901_MMX645.3.17.zip
 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 02:18am 18 Apr 2017
Copy link to clipboard 
Print this post

The new DATA statements with Peter's new STR$ function (first line) and Jim's eformat function (second line). Note that several numbers using eformat$ do not include the exponential part.

Thanks Peter and Jim.

Now to confirm that the READ statement works with Peter's exponential format.


DATA -1.9509150490455762e+04 , -1.9101597562906206e+04 , -5.3792389600437023e+03
DATA -1.9509150490455764.e4 , -1.9101597562906204.e4 , -5.3792389600437024.e3

DATA 2.6745479139695885e+03 , -4.1107639233861732e+05 , 1.8039170525238259e+04
DATA 2.6745479139695884.e3 , -4.1107639233861720.e5 , 1.8039170525238260.e4

DATA -3.0238550029372377e+05 , -6.9277505690488060e+03 , -1.0253481529116041e+05
DATA -3.0238550029372380.e5 , -6.9277505690488056.e3 , -1.0253481529116042.e5

DATA 2.3728918290534584e+03 , 1.4651420661642793e+05 , -5.2052288478643040e+03
DATA 2.3728918290534588.e3 , 1.4651420661642792.e5 , -5.2052288478643032.e3

DATA 4.7026247303780471e+04 , -1.3249750680520442e+03 , 1.6002341470107360e+04
DATA 4.7026247303780464.e4 , -1.3249750680520440.e3 , 1.6002341470107360.e4

DATA -1.2968825492757745e+03 , -1.4753267662386909e+04 , 1.6212085558023923e+02
DATA -1.2968825492757746.e3 , -1.4753267662386908.e4 , 1.6212085558023924.e2

DATA -4.0177777613644884e+03 , 5.4472249566385002e+02 , -1.3864294032602171e+03
DATA -4.0177777613644888.e3 , 5.4472249566385000.e2 , -1.3864294032602172.e3

DATA 2.0944568417002891e+02 , 1.3025618648952362e+03 , 1.8186655290580043e+01
DATA 2.0944568417002892.e2 , 1.3025618648952360.e3 , 1.8186655290580044.e1

DATA 4.0800683272180116e+02 , -6.1696138184359625e+01 , 1.4127897903869770e+02
DATA 4.0800683272180104.e2 , -6.1696138184359624.e1 , 1.4127897903869770.e2

DATA -1.6878795485286642e+01 , -1.5134023816145989e+02 , 2.2405113034100004e-01
DATA -1.6878795485286642.e1 , -1.5134023816145990.e2 , 2.2405113034100004.e-1

DATA -5.2206627243118069e+01 , 3.6345097141761684e+00 , -1.7920513466880599e+01
DATA -5.2206627243118072.e1 , 3.6345097141761688. , -1.7920513466880598.e1

DATA 8.6779646031902207e-01 , 2.0283413346424432e+01 , -3.2320616223538909e-01
DATA 8.6779646031902208.e-1 , 2.0283413346424432.e1 , -3.2320616223538908.e-1

DATA 7.1829675324621513e+00 , -1.5021838189568371e-01 , 2.5567619549789620e+00
DATA 7.1829675324621512. , -1.5021838189568370.e-1 , 2.5567619549789620.

DATA -3.8447105541958342e-02 , -2.7613886906044733e+00 , -1.7482108419894107e-03
DATA -3.8447105541958344.e-2 , -2.7613886906044732. , -1.7482108419894110.e-3

DATA -9.2551550288252251e-01 , 1.0983875057371777e-02 , -3.8803916473850784e-01
DATA -9.2551550288252256.e-1 , 1.0983875057371776.e-2 , -3.8803916473850784.e-1

DATA -2.7603287474318803e-03 , 3.2272242650062597e-01 , 1.5775894057393691e-02
DATA -2.7603287474318804.e-3 , 3.2272242650062600.e-1 , 1.5775894057393692.e-2

DATA 8.2556945377118182e-02 , 2.8333855651518594e-03 , 5.3670717564749610e-02
DATA 8.2556945377118176.e-2 , 2.8333855651518592.e-3 , 5.3670717564749616.e-2

DATA 5.0759404395995213e-03 , -1.7796021268059985e-02 , -3.4995377309747879e-03
DATA 5.0759404395995224.e-3 , -1.7796021268059988.e-2 , -3.4995377309747884.e-3

DATA 3.6598594389423460e-03 , -3.5999052689432918e-03 , -4.7281039878726006e-03
DATA 3.6598594389423464.e-3 , -3.5999052689432924.e-3 , -4.7281039878726008.e-3

DATA -2.4012103261026949e-03 , -4.3875247543577895e-03 , 1.6549131673638753e-04
DATA -2.4012103261026948.e-3 , -4.3875247543577896.e-3 , 1.6549131673638752.e-4

DATA -4.8342686506137911e-03 , 1.9899465305137534e-03 , -4.8041223375808579e-04
DATA -4.8342686506137912.e-3 , 1.9899465305137532.e-3 , -4.8041223375808592.e-4
 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 03:20am 18 Apr 2017
Copy link to clipboard 
Print this post

The READ statement for DATA works for data formatted as STR$(x, 0, -14) but not for data formatted as STR$(x, 0, -15) or STR$(x, 0, -16).


Computer programming is a lot like the monkey making love to the skunk. He hasn't had all he wants, but he's had all he can stand!
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 06:23am 18 Apr 2017
Copy link to clipboard 
Print this post

  Quote  The READ statement for DATA works for data formatted as STR$(x, 0, -14) but not for data formatted as STR$(x, 0, -15) or STR$(x, 0, -16).


That one was deep in the guts of Geoff's code. There was a limit of 20 characters for a number literal that wasn't obvious. I've now upped that to 30 which should fix it


Attached is the latest re-release 5.3.17 for the 100 and 144-pin parts

2017-04-18_162131_MMX5.3.17.zip

And for the 64-pin part with same bug fixes

2017-04-18_162221_MMX645.3.17.zip

 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 06:27am 18 Apr 2017
Copy link to clipboard 
Print this post

Thanks Peter
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5867
Posted: 11:23am 18 Apr 2017
Copy link to clipboard 
Print this post

  cdeagle said   The new DATA statements with Peter's new STR$ function (first line) and Jim's eformat function (second line). Note that several numbers using eformat$ do not include the exponential part.

Thanks Peter and Jim.

Now to confirm that the READ statement works with Peter's exponential format.


DATA -1.9509150490455762e+04 , -1.9101597562906206e+04 , -5.3792389600437023e+03
DATA -1.9509150490455764.e4 , -1.9101597562906204.e4 , -5.3792389600437024.e3



I deliberately left the exponent off for an exponent of zero.
I am more concerned with the second decimal point - the one at the end of the mantissa.
I will try with a few different versions of MMBasic and see which ones it occurs with.

Jim
VK7JH
MMedit   MMBasic Help
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5867
Posted: 05:00pm 18 Apr 2017
Copy link to clipboard 
Print this post

Bug in MMX_5.3.17

f$=STR$(CINT(x*10^p),p,0,"0")

will produce a string with a trailing decimal

k= cint(x*10^p)
f$=STR$(k,p,0,"0")

will produce the correct string without the trailing decimal

The same problems occurs with INT in place of CINT
The RPi version works OK with either code

With the RPi, STR$() defaults to 5 trailing zeros for floating point whole numbers

x = 1
PRINT STR$(x)

gives "1.00000"

Jim
VK7JH
MMedit   MMBasic Help
 
     Page 3 of 4    
Print this page
© JAQ Software 2024