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 for DOS. Ver 5.04 Beta
Page 1 of 6 | |||||
Author | Message | ||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I have finally got around to updating the DOS version of MMBasic to the current version of the language (V5.04). At the moment it is still a beta test version but it should be quite stable. Attached is the executable and the documentation: 2017-07-01_024307_DOS_MMBasic_V5.04.05_Beta_1.zip This version has integers, CASE statements, etc exactly the same as the Micromite version. The main difference between the DOS and Micromite versions is that the DOS version does not support any hardware related features of the Micromite (ie, there is no I/O, EDIT, graphics, interrupts, etc). The DOS version has four extra features: - A lot more memory for the program and arrays. - QUIT will close MMBasic and return to the operating system. - SYSTEM will issue a DOS command to the Windows operating system. - All floating point numbers are double precision (ie, accurate to about 16 significant digits). When printing a floating point number MMBasic will use up to 9 digits (the Str$() function can extend this). Please let me know if you find any bugs. If nothing serious eventuates I will post it to my website. Geoff Geoff Graham - http://geoffg.net |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
Thanks Geoff for updating the DOS version of MMBASIC. For strictly number-crunching purposes, I would find an eXtreme version of MMBASIC for DOS very useful. It seems most of the BASIC-like interpreters/compilers currently available are geared towards games, GUI applications, etc. Many are also lacking double precision capability. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I presume that you know that this version has double precision floating point? What other features of the eXtreme version would you like to see in the DOS version? Geoff Graham - http://geoffg.net |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
Thanks for this very welcome update of the DOS version. |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
I did not realize that the DOS version supported double precision. When all else fails, read the manual! I printed the manual but did not read it until now, especially page 4. I've run several of my large astronomy MMBASIC programs on the DOS version without any changes. I am seeing slightly different answers between the DOS version and the results computed with the MicroMite eXtreme. Might be minor differences between hardware number crunchers. I think the DOS implementation should provide all the programming constructs, command, etc. that I need. Thanks again Geoff. |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Interestingly, Running Rob's Speed Test in the new DOS version is considerably faster. Same i7 laptop; The old Version 0.062 Seconds. The new Version 0.047 Seconds. Phil |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Yes, interesting. A lot of optimising has gone into MMBasic over the past few years. Geoff Geoff Graham - http://geoffg.net |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Not a bug, But it is seeming to hammer my CPU pretty hard. Laptop seemed rather hot when I picked it up tonight. Up around the 80° mark. Closed all the IE sessions & also MMbasic for DOS & the temps fell right down. Tried 4.5 & temps went up again; Then 5.4 & same results. Screen capture shows the reaction. Not sure if this is an expected anomaly or it using the CPU while idle. Phil. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
All versions of MMBasic poll the console in a loop when sitting at the prompt looking for input. In the DOS box this is in part caused by the limitations of the OS but it is not a great issue because Windows will automatically limit the amount of CPU assigned to the DOS box. Your images show about 13% which is fine. Geoff Geoff Graham - http://geoffg.net |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
I've done some more testing between the MMX and DOS versions of MMBASIC. Interestingly, the MMX, DOS and Raspberry Pi versions of MMBASIC all seem to have the same machine epsilon which is 2.220446049e-16. A good program for testing number-crunching differences is demo_rkf78.bas which solves systems of differential equations. I have previously posted this software in this forum. The final - initial state vector differences reported by the demo_rkf78 software are a good indication of the "efficiency" of the software and hardware. I have run demo_rkf78 in the MMX, DOS and RPi versions of MMBASIC. Here are the differences reported by the MMX version; state vector differences (final - initial) ------------------------------------------ position vector x-component 0.004820 meters position vector y-component -0.011670 meters position vector z-component -0.005440 meters velocity vector x-component 0.0000017657 meters/second velocity vector y-component 0.0000069574 meters/second velocity vector z-component -0.0000058940 meters/second Here are the differences reported by the RPi version; state vector differences (final - initial) ------------------------------------------ position vector x-component 0.004846 meters position vector y-component -0.011733 meters position vector z-component -0.005469 meters velocity vector x-component 0.0000017752 meters/second velocity vector y-component 0.0000069951 meters/second velocity vector z-component -0.0000059258 meters/second Here are the differences reported by the DOS version; state vector differences (final - initial) ------------------------------------------ position vector x-component 23.586263 meters position vector y-component -57.315172 meters position vector z-component -26.550581 meters velocity vector x-component 0.0085601152 meters/second velocity vector y-component 0.0340918128 meters/second velocity vector z-component -0.0287001587 meters/second The comparison between the MMX and RPi versions is very good. The DOS comparison is off by orders of magnitude. Furthermore, I noticed that the conversion of the initial orbital elements to the corresponding state vector (position and velocity vectors) is incorrect. To illustrate this here is the program output for the MMX version position vector x-component 1515.374483 kilometers position vector y-component 6035.274923 kilometers position vector z-component -5080.745408 kilometers position vector magnitude 8033.360263 kilometers velocity vector x-component -3.2103497224 kilometers/second velocity vector y-component 7.8012017183 kilometers/second velocity vector z-component 3.6138337387 kilometers/second velocity vector magnitude 9.1774118291 kilometers/second and the output from the DOS version; position vector x-component 1515.375077 kilometers position vector y-component 6035.274383 kilometers position vector z-component -5080.745814 kilometers position vector magnitude 8033.360226 kilometers velocity vector x-component -3.2103493075 kilometers/second velocity vector y-component 7.8012022308 kilometers/second velocity vector z-component 3.6138330637 kilometers/second velocity vector magnitude 9.1774118538 kilometers/second This is especially problematic because the conversion of classical orbital elements to a corresponding state vector is non-iterative as illustrated by the following subroutine which performs these calculations. sub orb2eci(mu, oev(), r(), v()) ' convert classical orbital elements to state vector ' input ' mu = gravitational constant (km**3/sec**2) ' oev(1) = semimajor axis (kilometers) ' oev(2) = orbital eccentricity (non-dimensional) ' (0 <= eccentricity < 1) ' oev(3) = orbital inclination (radians) ' (0 <= inclination <= pi) ' oev(4) = argument of perigee (radians) ' (0 <= argument of perigee <= 2 pi) ' oev(5) = right ascension of ascending node (radians) ' (0 <= raan <= 2 pi) ' oev(6) = true anomaly (radians) ' (0 <= true anomaly <= 2 pi) ' output ' r() = position vector (kilometers) ' v() = velocity vector (kilometers/second) '''''''''''''''''''''''''''''''''''''''''''' local sma, ecc, inc, argper, raan, tanom local slr, rm, arglat, sarglat, carglat local c4, c5, c6, sinc, cinc, sraan, craan ' unload orbital elements array sma = oev(1) ecc = oev(2) inc = oev(3) argper = oev(4) raan = oev(5) tanom = oev(6) slr = sma * (1.0 - ecc * ecc) rm = slr / (1.0 + ecc * cos(tanom)) arglat = argper + tanom sarglat = sin(arglat) carglat = cos(arglat) c4 = sqr(mu / slr) c5 = ecc * cos(argper) + carglat c6 = ecc * sin(argper) + sarglat sinc = sin(inc) cinc = cos(inc) sraan = sin(raan) craan = cos(raan) ' position vector r(1) = rm * (craan * carglat - sraan * cinc * sarglat) r(2) = rm * (sraan * carglat + cinc * sarglat * craan) r(3) = rm * sinc * sarglat ' velocity vector v(1) = -c4 * (craan * c6 + sraan * cinc * c5) v(2) = -c4 * (sraan * c6 - craan * cinc * c5) v(3) = c4 * c5 * sinc end sub As I'm writing this, it occurred to me that perhaps pi is not double precision. To test this I typed the following at the MMBASIC-DOS prompt > print str$(pi, 0, 20) 3.14159260000000006840 The value of pi in the MMX version is 3.1415926535897931. Pi is used during the conversion of angular orbital elements from degrees to radians. When I changed all occurrences of pi in the demo_rkf78 source code to pie = 3.1415926535897931, the program reported the following comparison; state vector differences (final - initial) ------------------------------------------ position vector x-component 0.004818 meters position vector y-component -0.011665 meters position vector z-component -0.005438 meters velocity vector x-component 0.0000017650 meters/second velocity vector y-component 0.0000069545 meters/second velocity vector z-component -0.0000058916 meters/second There may be additional "fundamental" constants in the MMBASIC source code that should be updated to double precision. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Excellent detective work, thanks. I will fix it and get a new version out ASAP. Geoff Geoff Graham - http://geoffg.net |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
Geoff, The ability to display results in scientific notation, i.e., str$(x, 0, -15), would also be useful in the DOS version of MMBASIC. Thanks |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Geoff It took me ages to get double precision output accurate without rounding errors on the MMX and cdeagle found many errors in various special cases. This is the code I ended up with that supports the request for forced exponetial formatting. Needs a trivial change to calls in the rest of the code to specify if default formatting is required // convert a float to a string including scientific notation if necessary // p is the buffer to store the string // f is the number // m is the nbr of chars before the decimal point (if negative print the + sign) // n is the nbr chars after the point // ch is the leading pad char // def specifies to use default formatting void FloatToStr(char *p, long double f, int m, int n, unsigned char ch, int def) { int i, exp, trim = false; long double rounding; long double tens[] ={1.0L,10.0L,100.0L,1000.0L,10000.0L,100000.0L,1000000.0L,10000000.0L,100000000.0L,1000000000.0L,10000000000.0L,10000000 0000.0L,1000000000000.0L,10000000000000.0L,100000000000000.0L,1000000000000000.0L,10000000000000000.0L}; char *pp; long long int a; ch &= 0x7f; // make sure that ch is an ASCII char exp = floor(log10(fabs(f))); // get the exponent part if(((fabs(f) >= 1000000.0L || fabs(f) < 0.0001L) && f != 0.0L && def) || n<0) { // we must use scientific notation if(f==0.0L){ pp=p; *pp++='0'; *pp++='.'; for(i=0;i>n;i--)*pp++='0'; *pp++='e'; *pp++='+'; *pp++='0'; *pp++='0'; *pp++=0; } else { if(n<0)n=-n; f /= pow(10.0L, exp); // scale the number to 1.2345 FloatToStr(p, f, m, n, ch, 0); // recursively call ourself to convert that to a string p = p + strlen(p); *p++ = 'e'; // add the exponent if(exp >= 0) { *p++ = '+'; IntToStrPad(p, exp, '0', 2, 10); // add a positive exponent } else { *p++ = '-'; IntToStrPad(p, exp * -1, '0', 2, 10); // add a negative exponent } } } else { // we can treat it as a normal number // first figure out how many decimal places we want. // def == 1 means that we should automatically determine the precision if(def) { trim = true; n = 5 - exp; if(n < 0) n = 0; } // add rounding to hide the vagarities of floating point if(n > 0) rounding = 0.5L/pow(10.0L, n); else rounding = 0.5L; if(f > 0) f += rounding; // add rounding for positive numbers if(f < 0) f -= rounding; // add rounding for negative numbers // convert the digits before the decimal point if((long long int)f == 0 && f < 0) IntToStrPad(p, 0, -ch, m, 10); // convert -0 incl padding if necessary else IntToStrPad(p, (long long int)f, ch, m, 10); // convert the integer incl padding if necessary p += strlen(p); // point to the end of the integer pp = p; // convert the digits after the decimal point if(f < 0) f = -f; // make the number positive if(n > 0) { // if we need to have a decimal point and following digits *pp++ = '.'; // add the decimal point f -= (long long int)f; // get just the fractional part f*=tens[n]; a=(long long int)f; IntToStrPad(pp, a, '0', n, 10); pp+=n; // if we do not have a fixed number of decimal places step backwards removing trailing zeros and the decimal point if necessary while(trim && pp > p) { pp--; if(*pp == '.') break; if(*pp != '0') { pp++; break; } } } *pp = 0; } } |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
geoff, given the results for an MX170, is it worth updating the micromite II manual with a new 'lines per second' value - or better, switch to using statements per second? btw, the speed of MX170 versions seems to have varied a bit, just carried out some comparisons between the .hex files i have: version elapsed time statements/sec 4.5D 6.752 7127 5.0 4.942 9737 5.1 4.968 9686 5.2 5.021 9584 5.03.01 5.402 8908 5.03.02 5.402 8908 5.03.03 5.402 8908 5.03.04 5.402 8908 5.04.01 5.403 8906 5.04.04 5.403 8906 5.04.05 4.873 9875 5.04.05 is substantially faster than earlier 5.04.xx and all 5.03.xx releases. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
My "lines per minute" benchmark (which is very simple) is more I/O orientated where your benchmark is more maths orientated. I have found that, on average, MMBasic takes about 50uS per statement at 40MHz which equates to 20000 lines per second but this can vary widely depending on what statements you choose. I cannot understand why the 5.04.04 and 5.04.05 results differed by so much. There is very little difference between the two. Just a few bug fixes and some reorganisation of the code but no additional optimisations. Geoff Geoff Graham - http://geoffg.net |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Without digging through the eXtreme manual I assume that a negative third parameter means "always use scientific notation". Is that correct? Incidently, there is a bug in the DOS manual entry for STR$(). The third parameter can specify up to 20 digits (not 7). Geoff Geoff Graham - http://geoffg.net |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
geoff: good point about the types of instructions. just carried out the following quick test and got results very close to what you reckon: For I=2 To 6: SetPin I, DOUT: Next I Start = Timer For I=1 To 5000 Pin(2)=1 Pin(3)=1 Pin(4)=1 Pin(5)=1 Pin(6)=1 Pin(2)=0 Pin(3)=0 Pin(4)=0 Pin(5)=0 Pin(6)=0 Next I Elapsed = (Timer-Start)/1000 Print 55000/Elapsed " I/O lines per second" > > run 19434.6 I/O lines per second > cheers, rob :-) |
||||
cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
Yes, a negative argument in the STR$ function means print in scientific notation. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
OK, that is easy. I will get a new test version out. Geoff Graham - http://geoffg.net |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1133 |
@Geoff Thanks for this update! Good job! Please look at the value of Pi. Michael |
||||
Page 1 of 6 |
Print this page |