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: AustraliaPosts: 689 |
The usual double precision variable will only keep 12 or so significant figures accurately (?) |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
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. |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
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 KingdomPosts: 8516 |
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 KingdomPosts: 8516 |
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 StatesPosts: 261 |
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 KingdomPosts: 8516 |
Can you try the Pi version - I think that should be correct now. Everyone else - please don't use 5.3.17 |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
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: AustraliaPosts: 5867 |
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: AustraliaPosts: 935 |
[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: AustraliaPosts: 5867 |
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 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 VK7JH MMedit MMBasic Help |
||||
isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
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 KingdomPosts: 8516 |
Can you share them? |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
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 StatesPosts: 261 |
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 StatesPosts: 261 |
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 KingdomPosts: 8516 |
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 StatesPosts: 261 |
Thanks Peter |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5867 |
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: AustraliaPosts: 5867 |
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 |