Myrna Larson wrote in message . ..
It's not the adding and subtracting of 48 that slows things down. It's the use of a string to
store the number. When you write something like

A = ASC(MID$(TheText, i, 1)) - 48

the problem isn't the subtraction of 48. It's the MID$ function. When you use that, Basic
creates a new temporary string "behind the scenes", gets it's ASCII value, then deletes the
temporary string. Those string operations are what eat up the CPU cycles. In addition, garbage
collection could be triggered, too.


What I actually wrote is:


In particular, the problem with a high-
level language is that hidden things are
taking place. In the case of the string,
data is stored as ASCII - where every
digit has 48 added on in order to create
the ASCII of the SYMBOL.


"HIDDEN THINGS" covers all these small points.

One real burden is "interpretation". Compiled languages will produce
machine-code that just runs. Interpreted languages do all of the above
things - and also compute the SEQUENCE (syntax) again and again.

Qbasic seems to be a hybrid. On disk the programs are kept as text.
When loaded, however, a "thread" of machine-code addresses is put
between the text elements. Thus, Qbasic can be listed by reading the
non-thread parts and run by following the thread.

It is a violation of set theory, however, to expect a set of
instructions to check itself. So some checking is not in the "compile
time" section, but in the "run time" section of Qbasic.

So when you are programming and "break the thread", Qbasic says that
you will have to RUN the program if you want to make this change.

Self-checking is made easier by CLOSING THE SET. When the reserved
words cannot be extended, a protective shell of syntax-checking can be
built around them.

All of these points show that a high-level language uses a lot of CPU
power.

The machine-code factorial generator is actually just 392 bytes.
Custom-made assembler programs tend to beat all comers.
http://wehner.org/tools/factor.txt

Those with time on their hands might like to optimise my code - I
suspect many bytes and many clock-cycles are redundant. Maybe you can
reduce the size of my program by 391 bytes.....?

Charles Douglas Wehner