Strange Arithmetic?

PicoCalc
1

If you type in

? 84^42

you’ll get a strange answer: 0.
However, if you type in

? 84.0^42

you’ll get the correct answer of 6.602828461e+80
No, your PicoCalc isn’t broken. What’s happening? In the first example, both numbers are signed integers and MMBasic isn’t smart enough to convert them to floating point numbers. The calculation exceeds the limit for integers so 0 is printed. In the second example, 84.0 is a floating point number so the calculation is done in floating point and the range is much greater so the number can be computed. I don’t know if anyone ever complained about it but seeing as how the author of MMBasic has said only bugs will be fixed and no new features will be included in release 6.00.02, don’t look for a solution to this problem any time soon.

3 Likes
2

This is by design. MMBasic is a clone of the original Microsoft Basic.

If you look on page 1-4 of the original manual it states:

  1. Integer constants: Whole numbers between -32768 and +32767. Integer constants do not have decimal points.
  2. Fixed Point constants: Positive or negative real numbers, i.e., numbers that contain decimal points.

The reason being that back in the day when Z-80 CPUs ran at 2 ~ 4 MHz (with an average of 4 cycles per instructions), the difference in speed between integer and real numbers was big.

So: A=34*5, was quite a bit faster than A=34.0*5.0. This also affected storage size when memory was very expensive. Real numbers used 4 bytes, integers only used 2.

You would not want the interpreter to auto-convert between the two. (If it did it would break old basic programs that depend upon this.)

FWIW: I’m old. My first computer was a TRS-80 running Microsoft Basic. :slight_smile:

The link to the original manual (available on the internet archive) is:

3

Microsoft BASIC does automatically convert integers to reals when it does division and exponentiation. I’m running BASIC-80 right now on an Altair 8800 under CP/M and TRS-80 BASIC on a Model 1. It also gives a floating point number when the range exceeds integers. Of course my example won’t work on an Altair since MBASIC has a range limited to e+38 and not the e+80 required. Old BASIC programs relied on automatic conversion. Here’s a pic of a TRS-80 screen. Note that even though 7 and 4 are integers, the floating point division is done. Even though 45 and 20 are integers, the answer is outside the integer range.

image
image916×819 9.38 KB

The PicoCalc gets 45^20=6545036034076902481 which is totally wrong. PicoCalc uses 64-bit integers, BTW.

2 Likes
4

As I recall, in the versions of Microsoft BASIC on systems like the Commodores, TRS-80s, etc. the default numeric type was floating point. If you wanted to speed up your programs, you could denote some of your variables as integer (I think it was the “#”) or a DEFINT statement.

But

A=10

actually stored

A=10.0

And magic happened when you needed to use it in an integer context. ex:

FOR B= 1 TO A

1 Like
5

MMBasic uses 64-bit IEEE as the default for numerical variables unless you use OPTION DEFAULT INTEGER to tell it otherwise.

I believe MMB4L should work the same as the PicoMite/PicoCalc, and it produces:

> ? 45^20
 6545036034076902481
> ? 45.0^20
 1.15944533e+33
> ? 45^20.0
 1.15944533e+33
> ? 45.0^20.0
 1.15944533e+33
> a=45:b=20:?a^b
 1.15944533e+33
> c%=45:d%=20:?c%^d%
 6545036034076902481

Best wishes,

Tom

1 Like
6

But it looks like they missed constant conversion.

I have the Kaypro 4/84 fired up this morning, so I loaded up MBASIC-80 5.21 CP/M version.

image
image1233×925 63.3 KB

1 Like
7

I guess it is a bit ambiguous. Does the use of ‘^’ indicate a floating point constant?

But how cool is using an example from an original Kaypro to make a point? :slight_smile:

If you’re trying to emulate Microsoft’s BASIC-80 (Rev 5.21), then there’s no better test of what it should do than by running Microsoft’s BASIC-80 and seeing what it does!

If the idea behind MMBasic is to be able to run old MBasic code without modification, then:

? 84^42

Should be 6.602828461e+80, not 0.

8

At the time, it was common to do automatic type conversions. So if I used integers in a floating point call, the interpreter would convert my integers to floats for the call.

And BASIC wasn’t the only language to do that.

Correct. MMBasic isn’t doing the automatic type conversion correctly - if it’s goal is to emulate MBASIC.