Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 01:39 03 May 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 : MMBasic for DOS. Ver 5.04 Beta

     Page 1 of 6    
Author Message
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 05:02pm 30 Jun 2017
Copy link to clipboard 
Print this post

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 States
Posts: 261
Posted: 04:46am 01 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 11:12am 01 Jul 2017
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 1985
Posted: 11:29am 01 Jul 2017
Copy link to clipboard 
Print this post

Thanks for this very welcome update of the DOS version.
 
cdeagle
Senior Member

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

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: Australia
Posts: 1664
Posted: 01:18pm 01 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 06:52pm 01 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 1664
Posted: 01:41am 02 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 01:56am 02 Jul 2017
Copy link to clipboard 
Print this post

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 States
Posts: 261
Posted: 02:01am 02 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 02:06am 02 Jul 2017
Copy link to clipboard 
Print this post

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 States
Posts: 261
Posted: 02:21am 02 Jul 2017
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8592
Posted: 02:32am 02 Jul 2017
Copy link to clipboard 
Print this post

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 Zealand
Posts: 2290
Posted: 02:33am 02 Jul 2017
Copy link to clipboard 
Print this post

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 :-)Edited by robert.rozee 2017-07-03
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 03:25am 02 Jul 2017
Copy link to clipboard 
Print this post

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: Australia
Posts: 3165
Posted: 03:42am 02 Jul 2017
Copy link to clipboard 
Print this post

  cdeagle said  The ability to display results in scientific notation, i.e., str$(x, 0, -15), would also be useful in the DOS version of MMBASIC.

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 Zealand
Posts: 2290
Posted: 04:17am 02 Jul 2017
Copy link to clipboard 
Print this post

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 :-)Edited by robert.rozee 2017-07-03
 
cdeagle
Senior Member

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

Yes, a negative argument in the STR$ function means print in scientific notation.

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 06:20am 02 Jul 2017
Copy link to clipboard 
Print this post

OK, that is easy. I will get a new test version out.
Geoff Graham - http://geoffg.net
 
twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133
Posted: 08:58am 02 Jul 2017
Copy link to clipboard 
Print this post

@Geoff
Thanks for this update! Good job!

  Geoffg said   OK, that is easy. I will get a new test version out.

Please look at the value of Pi.

Michael

 
     Page 1 of 6    
Print this page
© JAQ Software 2024