TheBackShed.com

Forum Index : Microcontroller and PC projects : Limits of variable names

Page 1 of 2

Author

Message

karjo238
Regular Member

Joined: 12/10/2018
Location: New Zealand
Posts: 54

Posted: 04:13am 13 Jul 2019

Copy link to clipboard

Print this post

Hey there! I've recently purchased a Micromite Extreme 144 to give all my MMBasic projects a bit more pep, but I'm running up against problems with variable names, and can't find a clear answer in the manual.

I am running MMBasic version 5.0502, and am trying to run a program with variable names of X and X1, J and J2 and so on. These worked on my old Colour Maximite, but now don't seem to be any more.

So, what I need to ask is: What are the rules for creating variables in this version of MMBasic? Can you only have a total of 26 variables, i.e. one per letter, or can you have more and I'm just programming it wrong?

Any help that can be provided would be most appreciated.

Cheers,

Joseph.

seco61
Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 205

Posted: 04:49am 13 Jul 2019

Copy link to clipboard

Print this post

Hi Joseph.

As per the Micromite manual, variables can be up to 32 characters in length:

Quote Naming Conventions

Command names, function names, labels, variable names, etc are not case sensitive, so that "Run" and "RUN" are equivalent and "dOO" and "Doo" refer to the same variable.
The type of a variable can be specified in the DIM command or by adding a suffix to the end of the variable's name. For example the suffix for an integer is '%' so if a variable called nbr% is automatically created it will be an integer. There are three types of variables:

1. Floating point. These can store a number with a decimal point and fraction (eg, 45.386) and also very large numbers. However, they will lose accuracy when more than seven significant digits are stored or manipulated. The suffix is '!' and floating point is the default when a variable is created without a suffix

2. 64-bit integer. These can store numbers with up to 19 decimal digits without losing accuracy but they cannot store fractions (ie, the part following the decimal point). The suffix for an integer is '%'

3. Strings. These will store a string of characters (eg, "Tom"). The suffix for a string is the '$' symbol (eg, name$, s$, etc) Strings can be up to 255 characters long.

Variable names and labels can start with an alphabetic character or underscore and can contain any alphabetic or numeric character, the period (.) and the underscore (_). They may be up to 32 characters long. A variable name or a label must not be the same as a command or a function or one of the following keywords: THEN, ELSE, TO, STEP, FOR, WHILE, UNTIL, MOD, NOT, AND, OR, XOR, AS. Eg, step = 5 is illegal.

Regards

Gerard (vk3cg/vk3grs)

disco4now

Guru

Joined: 18/12/2014
Location: Australia
Posts: 903

Posted: 04:50am 13 Jul 2019

Copy link to clipboard

Print this post

Not sure where I copied it from but see below. Your X,X1,J and J2 should be OK, but you can use variable names up to 32 characters. As many as you need until you run out of memory for them. Type the MEMORY command to see how much you have used.
I think what may be different in Micromite is you can't use j$,j%,j together once j is used for a string or integer it cant be used again, so if you have X$,X1$ etc as well then you would have a problem.

Maximum length of a variable name or a label is 32 characters.
Maximum number of dimensions to an array is 8.

Regards
Gerry

Latest F4 Latest H7

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 2080

Posted: 05:11am 13 Jul 2019

Copy link to clipboard

Print this post

karjo238 said
So, what I need to ask is: What are the rules for creating variables in this version of MMBasic? Can you only have a total of 26 variables, i.e. one per letter, or can you have more and I'm just programming it wrong?

Morning Joseph.

Doesn't sound like you are doing anything wrong and single character/26 variables is definitely not the case.

can you post a bit of your code for us to see?

h

karjo238
Regular Member

Joined: 12/10/2018
Location: New Zealand
Posts: 54

Posted: 05:13am 13 Jul 2019

Copy link to clipboard

Print this post

I probably need to clarify what's happening here. This line:

X1=C(C1,1)+(C(C1+1,1)-C(C1,1))*(C1-Int(C1)):X=S1:Y=S2

Throws an error "X already declared". X has been declared earlier in the program, and X1 is the new declaration. They are both integers, so *in theory* they should both work.

I think.

Can anyone shed a light on this?

karjo238
Regular Member

Joined: 12/10/2018
Location: New Zealand
Posts: 54

Posted: 05:59am 13 Jul 2019

Copy link to clipboard

Print this post

CaptainBoing said

Morning Joseph.

Doesn't sound like you are doing anything wrong and single character/26 variables is definitely not the case.

can you post a bit of your code for us to see?

h

The problem is I can't really. All I did in the first case was take this code:

http://vintage-basic.net/bcg/superstartrek.bas

and make a few modifications to make it work on MMBasic 4.5.

Now that there is more specific type-checking, I'm going to have to go down the route of rewriting the code from scratch, which won't be too much of a drama as I have already done a version in Python 3 which has SUBs, FUNCTIONs, etc, and all I really need to do is change the program structures from Python to BASIC.

Many thanks for your guidance anyhow,

Joseph.

Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1619

Posted: 07:49am 13 Jul 2019

Copy link to clipboard

Print this post

Hi karjo238,

Line 440 of the original program says:

440 P=10:P0=P:S9=200:S=0:B9=2:K9=0:X$="":X0$=" IS "

So X is already declared as X$. As disco4now said if you use X$ you cannot use X%. Using X without declaring the type of variable will default to a floating point anyway (X!).

All you need to do is change all occurrences of X$ to XA$ (for example) and do the same for other variable names that cause the same problem.

You may want to change all X variables to X% and similar to make them integers rather than floating point variables (after you have the program working). The program should then run faster.

Bill

Keep safe. Live long and prosper.

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 10:38am 13 Jul 2019

Copy link to clipboard

Print this post

Turbo46 said ... to make them integers rather than floating point variables ...
The program should then run faster.

Bill

Yes, it should. But it does not!

A short test on a ARMmite MMBasic Version 5.04.33:

Dim i,a As integer
Dim j,b As float

Timer=0
For i = 1 To 50000:a = i + i:Next i
For i = 1 To 50000:a = i * i:Next i
Print Timer
Timer=0
For j = 1 To 50000:b = j + j:Next j
For j = 1 To 50000:b = j * j:Next j
Print Timer

End

Result:

Quote 891
854

On a MM2 the same relation - float is faster than integer -, but slower.

In general, I do not think it's a good idea to use integers to get faster.
Maybe Geoff has an idea why ...?

Michael

causality ≠ correlation ≠ coincidence

lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3157

Posted: 12:02pm 13 Jul 2019

Copy link to clipboard

Print this post

twofingers said

Turbo46 said ... to make them integers rather than floating point variables ...
The program should then run faster.

Bill

Yes, it should. But it does not!

A short test on a ARMmite MMBasic Version 5.04.33:

Hmmm ... Interesting indeed. Integers are a third slower than floats with MMBasic DOS: 62 & 47

PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed

Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1619

Posted: 12:28pm 13 Jul 2019

Copy link to clipboard

Print this post

Thanks Michael and Lizby,

That's what happens when you assume. I am surprised and disappointed. Integers was one reason that I was waiting for MMBasic for the Maximite!

Can somebody please explain?

Bill

Keep safe. Live long and prosper.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 9172

Posted: 01:00pm 13 Jul 2019

Copy link to clipboard

Print this post

Quote Yes, it should. But it does not!

It does if you get your test code correct

Dim i,a As integer

sets i as a float and a as an integer

try

dim integer i,a

Dim i as integer,a As integer

OPTION DEFAULT INTEGER
DIM i,a
DIM FLOAT j,b

etc.

Edited by matherp 2019-07-14

Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1619

Posted: 01:32pm 13 Jul 2019

Copy link to clipboard

Print this post

Thank you Peter,

So each time around in the loop the integer is converted to a float to add the two numbers. That's what causes the longer time for the 'integer' part of the test to execute.

Timings on my DOS MMBasic with the corrected program.were:

78
94

My faith is restored.

Bill

Keep safe. Live long and prosper.

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 02:37pm 13 Jul 2019

Copy link to clipboard

Print this post

oops! SORRY!

Thanks Peter!

New results for

Dim integer i,a
Dim float j,b
... and the code above

Quote 829
854

But the difference seems very small.

Dim integer i,a
Dim float j,b

Timer=0
For i = 1 To 50000:a = i - i:Next i
For i = 1 To 50000:a = i / i:Next i
Print "Integer ="Timer"ms"
Timer=0
For j = 1 To 50000:b = j - j:Next j
For j = 1 To 50000:b = j / j:Next j
Print "Float ="Timer"ms"

End

gives
[code]Integer = 884ms
Float = 855ms[/code]

causality ≠ correlation ≠ coincidence

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 02:56pm 13 Jul 2019

Copy link to clipboard

Print this post

I think it's time to see at the details:

Dim integer i,a
Dim float j,b

Timer=0
For i = 1 To 50000:a = i + i:Next i
Print "+ Integer ="Timer"ms"
Timer=0
For i = 1 To 50000:a = i * i:Next i
Print "* Integer ="Timer"ms"
Timer=0
For i = 1 To 50000:a = i - i:Next i
Print "- Integer ="Timer"ms"
Timer=0
For i = 1 To 50000:a = i / i:Next i
Print "/ Integer ="Timer"ms"
Print
Timer=0
For j = 1 To 50000:b = j + j:Next j
Print "+ Float ="Timer"ms"
Timer=0
For j = 1 To 50000:b = j * j:Next j
Print "* Float ="Timer"ms"
Timer=0
For j = 1 To 50000:b = j - j:Next j
Print "- Float ="Timer"ms"
Timer=0
For j = 1 To 50000:b = j / j:Next j
Print "/ Float ="Timer"ms"

End

Result:

+ Integer = 418ms
* Integer = 411ms
- Integer = 416ms
/ Integer = 468ms

+ Float = 429ms
* Float = 426ms
- Float = 424ms
/ Float = 431ms

causality ≠ correlation ≠ coincidence

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 9172

Posted: 02:57pm 13 Jul 2019

Copy link to clipboard

Print this post

Quote But the difference seems very small.

That is because most of the time is taken in parsing the commands. Just the reality of a Basic Interpreter I'm afraid.

Note the comparatively slow integer divide. This is because the FPU supports double floating division but there is no H/W support for 64-bit integer divideEdited by matherp 2019-07-15

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 03:25pm 13 Jul 2019

Copy link to clipboard

Print this post

But there is something else weird:
If I exchange positions of the Dim's

Dim integer i,a
Dim float j,b

Dim float j,b
Dim integer i,a

then the integers are slower than floats again:

+ Integer = 429ms
* Integer = 422ms
- Integer = 426ms
/ Integer = 480ms

+ Float = 418ms
* Float = 416ms
- Float = 414ms
/ Float = 420ms

causality ≠ correlation ≠ coincidence

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 9172

Posted: 03:51pm 13 Jul 2019

Copy link to clipboard

Print this post

Quote then the integers are slower than floats again:

Yes, but this is again due to parsing. The integer variables are now after the float ones in the variable table so the parser takes longer to find them.

The variable table is just a sequential list in the order created and the parser searches from the top until it finds a match to the variable name.

To accurately see the difference between float and integers you need to do it both ways and average the results.

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 04:24pm 13 Jul 2019

Copy link to clipboard

Print this post

matherp said ... To accurately see the difference between float and integers you need to do it both ways and average the results.

Okay!

Dim integer i,a
Dim float j,b

Timer=0
For i = 1 To 50000:a = i + i:Next i
For i = 1 To 50000:a = i * i:Next i
For i = 1 To 50000:a = i - i:Next i
For i = 1 To 50000:a = i / i:Next i
Print "Integer ="Timer"ms"
Timer=0
For j = 1 To 50000:b = j + j:Next j
For j = 1 To 50000:b = j * j:Next j
For j = 1 To 50000:b = j - j:Next j
For j = 1 To 50000:b = j / j:Next j
Print "Float ="Timer"ms"

End

Result:

Integer = 1712ms
Float = 1709ms
vs
Integer = 1756ms
Float = 1664ms

ie
sum for integers = 1712+1756=3465ms
sum for floats = 1709+1664=3372ms

On an ArmMite H7!

causality ≠ correlation ≠ coincidence

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 9172

Posted: 06:00pm 13 Jul 2019

Copy link to clipboard

Print this post

Remove the divide and you will see integer slightly faster. Floating point divide is supported by hardware. 64 bit integer divide isn't.

However, speed isn't really the issue. The key point is that integer arithmetic is exact whereas, even with double precision you will see rounding errors with FP

Dim float i,a
For i=1 To 10000*7
a=a+1/7
Next i
Print Str$(a,5,15)
End

=9999.999999991743607

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1258

Posted: 06:42pm 13 Jul 2019

Copy link to clipboard

Print this post

Hi Peter!

Quote Remove the divide and you will see integer slightly faster. Floating point divide is supported by hardware. 64 bit integer divide isn't.

I totally agree!
I was just trying to say - and prove - something against the myth that (MMBasic) integers are in any case significant faster. I think that is important for us users.

causality ≠ correlation ≠ coincidence

Page 1 of 2

Print this page