misc, 8 digits possible using QBASIC?

Wrote a short routine to figure out a puzzle about lights on and off.
I note that when the answer goes over 9,999,999 the resulting answer
is always to a power of E. This is not a problem but I would like to be
able to read than light number 10,200,400, for example is on. As a
power
of E this might be rounded off or not as accurate or just hard to read
straight off.

I read that QBASIC cannot handle more than 8 letters or digits.

Is there anyway to print number with 8 digits and not using the E
representation?

Also, I forgot how to write numbers on a line in WRITE to a file.
If I PRINT to the screen with a ; the numbers appear in a row.
Else without a ";" they appear one to a line in a single column.

How do I write to file and indicate the numbers are fill up the row?
Did I specify columns before? It's been a while since I programmed in
BASIC
and before I used the Professional Development System [PSD] BASIC which
was
the last version of MSDOS BASIC, 7.1, I believe.

Then came Visual BASIC which was a continuation of the PDS.

At this point, I wiped out my PDS files and who knows where the
original floppy disks are and if they are any good, after 12 years in
storage. I can't find the original files nor even MASM 5.1 or 6.0 which
I was using and now costs around $160 in its vintage form. I used
assembler routines to do math that slowed down BASIC considerally, like
DFT's and so on. And my hard disks that contained the full development
system crashed and burned a long, long time ago. The backups also
crashed by now or on floppies that might not be good any more, assuming
I can find them among the few hundred floppies here and there.

Any advice would be awfully nice.

Thanks,
Treeline

You read wrong. QBasic (the correct spelling) handles 8 digits in single
precision format. If you use double precision variable, it can keep 16
digits. To do that you can

1) DIM variablename AS DOUBLE
2) DEFDBL varletter
3) Append a # to the end of the variable name everywhere it appears.

the statements in 1) and 2) should be at the beginning of your program.

In # 2 above, all variable starting with the letter (or letters) you choose
will be double precision. Example:

DEFDBL A-D, M

will define any variable starting with the letters A,B,C,D or M as double
precision.



WRITE #n, a,b,c,d

will put the values of the variable a,b,c and d in one row


Almost. There was Visual Basic for DOS after PDS 7.1.

Tom Lake

Thanks, this worked like a charm, and so quick a reply.



I'm getting error, "expecting an expression." with:

WRITE #1, X#

WRITE X1, X#, Y#
will put 2 items on a row, as you suggested, but will not fill out the
row as it does when I use a PRINT to the screen in a Loop.

I gather the problem is that this is inside a Loop. So each time it
does a WRITE it creates a new line. Any way to tell it to fill the
existing line as it does with a PRINT? Or is that not possible? Could
it be that the screen handling with a PRINT just does this
automatically whereas a WRITE cannot have built-in parameters as a
screen handler would with margins set?

I would like the X's to appear in a row filling it as they do when I
just put:

PRINT X#;



Okay, now I remember. I thought it seemed identical to PDS 7.1 but I
never used that under MSDOS as I recall, just with Windows 3.1. I
cannot recall offhand any additional capabilities under MSDOS that
justified even switching to using it. Now that you mention this, I
probably have both versions in storage on floppies, somewhere.

>> WRITE #n, a,b,c,d

PRINT #1, X#;

should print one after another but they might be hard to read back.
Why do you care how they're stored in the file? You can print them
however you want when you read them back.

Tom L

You're amazing. I was just trying to get the File to have the same
capabilities as the PRINT to the screen even if not terribly neat and
orderly. Your abilties with BASIC are impressive, thanks.

With QBasic up, hit ALT-H, try the Index and look under PRINT USING and WRITE.

You might want to look at DOUBLE while you're there.

ALT-H and Contents has background material you might find handy to get back in
the swing of things.

And for a bit of code,
a = 10200400
PRINT USING "##,###,###"; a
Produces this:
10,200,400

- Bill

I did before I posted here. The WRITE was helpful but Tom Lake's
suggestions answered my original queries and used methods not
mentioned, like PRINT #1 instead of WRITE #1 and tricks like that.



I did look at DOUBLE. Maybe if I had my 10 books on BASIC handy but I
could not even tell what character denotes DOUBLE from the Help. I am
not using my QBASIC 4.5 or PDS 7.1 or VB whatever. I am using the
QBASIC that comes with the operating sytem which is 1.1.


I did look at that. Some of the info is not quite right so doubly
confusing. Using Tom's suggestion I could get up to
1,000,000,000,000,000 or 16 digits. The info in Contents did not
suggest this directly. But I am getting back into the swing of things,
which seems to be documented and undocumented features or bugs.


I get errors with this but I remember using this in the distant past
which is quite helpful for certain types of formatting. My main problem
was precision and avoiding 7 digits with E engineering or exponent
method. Thanks.

WRITE.

Ah, I didn't notice a "I didn't find this in help..." comment, and didn't pick
up that you'd tried it.


ALT-H, Index, PRINT statement

PRINT [#filenumber%,] USING formatstring$; expressionlist [{; | ,}]

filenumber% The number of an open sequential file.


ALT-H, Contents, Basic Character Set, Data-Type Suffixes
% Integer
& Long-integer
! Single-precision
# Double-precision
$ String


I have both QBasic 1.1 and QuickBASIC 4.5. I was using the QBasic 1.1 help.

I can usually find what I need in it's help system. The problem is (as shown
above, and you've apparently (re)discovered) that it's not always in the
obvious place. I'd have expected the bit about # to be where DOUBLE was
explained, for example.

in

I've not yet run across a case where anything wasn't right. Can you give an
example?


Your example showed the 10M range (which the default single precision does),
and commas in the output (which is why I suggested PRINT USING). I see that
you didn't mean 10M literally. My mistake.


No, it doesn't. If the 10M example meant you needed eight digits, you could
also use a LONG giving a nine digits.


There are some nuggets of handy information to be found here:

http://support.microsoft.com/search/default.aspx?qu=qbasic

but you have to sort of dig for them.


Right. I mistook your 10M example for wanting numbers up to 10M, not for eight
(or more) digits of precision. The PRINT USING will get rid of the scientific
notation, though.

As to errors, what are you getting?

The example I gave above works here both in a Windows ME in a DOS session and
on a DOS 5.0 system.

- Bill

illiam J. Leary Jr. wrote:

After I posted my reply, I was able to find PDS71, QB45, and MASM 510.
Not bad, not bad at all. Feels nice to have all my linkers and
compilers back.
I even have uncorrupted [my mistake] ADVANCED HELP files now.



If I were very careful, I could eventually find it. Since the suffix
"#" was not in the usual place, when I did find it and went back to
find it again, I could not find it. Now I looked at the HELP in PDS71,
and it has more detail, of course, but it's not too different at the
basic 1.1 level. The PDS71 has three levels of HELP files. I had
corrupted the most ADVANCED level. Generally this does not matter. It
may have when I started to get into breaking the 640K DOS barrier for
program size. Can't remember now. That was a mess for me.


I would have to find my original notes when I was programming in PDS71.
Generally, things work as they should for most math functions. I recall
some anomalies with SLEEP or other such commands. I do recall some
anomalies when breaking the 640K DOS barrier or having to break up the
code because it was way too big for the compiler as a single module.
Then there were lots of problems but some may have been due to my
ignorance. I did not understand BYVAL and other basic programming
methods. It was a mess with Local and Global variables and what to put
where. But in the end, it worked although I am not quite sure what I
did. Fortunately I have my original source code and notes and someday
if when I can afford it, hire a programmer, a real programmer, who can
explain what I did and why it worked! What a mess. Even Assembly
routines and third party speedup routines, OBJ modules, to make BASIC
faster.

One thing was puzzling with QBASIC when I went to multiply big numbers.
I could add up to a trillion or 16 digits but not multiply to 16
digits. Finally I found that I needed either a decimal place which made
it okay. Or using "#" worked. The decimal point brought up the "#" and
this was something that eventually I would have stumbled upon but I
found it on the internet as a solution.

As I recall, 1000 * 10000 would give me an error. Overflow. But "." and
certainly "#" took care of things.


Nope, this is party my mistake. I realized for clarity I should have
indicated how many digits I wanted to use. 100,000,000 was okay but I
wanted the maximum just in case. In my puzzle, 10,000 iterations gets
me to 100,000,000. I can tell you which lights in 100,000,000 lights in
a row would be ON or OFF if the first person turned on all the lights.
The second person turned on every second light. The third person turned
on every third light and so on until the 100,000,000th person. I heard
this on CARTALK.com last week and put it into BASIC to work out an
answer after Xcel showed me the basic algorithm after using brute force
but was tedious after 100 bulbs in a row. Interpreted BASIC gets me to
100,000,000 in a few seconds if I use the entire row for numbers.
Longer if one number per line in a long column.


Yes, thanks, and I remember using this a LOT years ago to make things
neat and where I wanted them. Nothing worse than columns of numbers
jumping around, better to lose screen real estate and have them nice
and neat like a what, calculator?

When I said I get an error I did not mean your whole code gave me an
error. Just used the end of your code but obviously my numeric variable
needed to be re-specified to fit into P

an

OK. I thought you meant QBasic or QuickBASIC. I never used the PDS version,
so I can't say anything about that.


Yes. I see that as an implementation detail. If you don't force the
calculation to the precision you want, it may default to something you didn't
want. For small numbers, well within range, this rarely matters. When you get
outside that, then it can be a bear to keep eveyrthing straight, short of
DEFDBL everything, which wasn't really an option on most of the code I did back
then, because it would have taken far too long to execute. There's also, as I
recall, a problem with using DOUBLE for array indices.


I get those when I go from C at work to NS Basic or Oberon at home. Well, in
addition to the usual programming errors.

- Bill

Just easier to scroll through a file that is 20% shorter.

I guess I can rearrange them with the text processor using a macro but
it's just easier to have it written the way I want to read it so
anything works, like LIST or TYPE or whatever editor I might want to
use.

Also I found a big difference in speed in writing to the screen. One
number per line was much longer than 4 or 5 numbers per line to execute
in interpreted 1.1 QBASIC. I don't know why but the difference suprised
me and it's long enough of a difference to be annoying. Maybe my
threshhold for attention if 4-5 seconds :)

If you want to work with really, really big numbers, download BIGCALC.ZIP
from my website below. :-)
--
Judson McClendon XXXX@XXXXX.COM (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Now that's what I call a calculator.

But why the Reverse Polish Notation? Is that not what the HP
calculators used to do? Drove me crazy. Polish notation is bad enough
but Reverse?

I guess it's most efficient. You might want a simple example of how to
multiply 2 x 2. I know it sounds absurd but it took me a while just to
do something like that comfortably. Just a sentence or two. For those
of us who detested HP's RPN - not everybody thinks in stacks :)

Nicely done. Nice Overflow recovery. Lots of digits and powers.

I did test it with all 50 digits, squaring a few times and then taking
the square roots to see if I could get back the original number. I kept
losing by one, that is the very last digits kept decrementing by one
when going up and back. So I gather the 50th digit is rounded off?

But that's pretty good.

If you are from the South Side of Milwaukee (as am I) Polish notation (of
any directional flavor) is just fine, because as you grew up that was your
second language anyway.

Not that Milwaukee Polish Notation is a real language: it might be better
labelled "butchered English."

Of course, Milwaukee Butchered Engish is still closer to the Queen's English
than is Chicago Standard English. (Pittsburgh English a close second).


MCM
PS: Urban legend nothwithstanding, Real Milwaukeans never add "hey" after
"ainna."

lt; XXXX@XXXXX.COM > wrote:

Thank you. BIGCALC's maximum precision is 1075 digits (execute: BIGCALC
1075). BIGCALC keeps 8 extra 'guard' digits during calculations and (IIRC)
rounds calculated results to the displayed size.

Actually, RPN (Reverse Polish Notation) is just different from what you are
used to. But RPN is very logical and efficient, with a number benefits you
might not realize. For one thing, there are never any 'pending' operations,
everything is done on the keystroke. For another, algebraic notation
sometimes takes several more keystrokes to do a function than RPN. And
programming algebraic is a nightmare compared to programming RPN. RPN simply
blows away algebraic on programming, no comparison. Some real computer CPUs
(e.g. Unisys A Series mainframes) do calculations using a stack. Once you
spend just a little time getting used to RPN and how the stack works, you
will find it is actually easy, and more powerful and flexible than
algebraic. The more you use RPN, the more you will appreciate its power.
Below are some simple BIGCALC principles.

Older and current inexpensive RPN calculators have a 4 register stack
(X,Y,Z,T) like BIGCALC. Newer more expensive RPN calculators (e.g. HP48)
have an 'infinitely extensible' (memory limited, of course :) stack. The
number visible on the calculator will be the X register, then the Y, Z and T
registers, if the calculator has a multi-line display. In RPN you *always*
enter the numbers *before* operating on them. The function keys act
immediately on the number(s) already in the stack. One-number functions
always act on the X register. Two-number functions always act on the X and Y
registers. There are keys to do stack operations, such as exchange the
contents of X & Y and roll (rotate) the values in the stack up or down.
There are also keys to store and recall numbers between the X register and
storage registers.You can also do arithmetic as you store/recall (e.g. STO +
4 adds X to storage register 4).

If a number on the stack is complete (calculated or otherwise terminated),
entering a new number will automatically 'push' (lift) the stack up to hold
the new number. When you press 'Enter', it pushes the stack, copying X into
Y, and prepares X to be overwritten with a new number. Keying a new number
after pressing 'Enter' will not push the stack again. On a 4 register stack,
when the stack is pushed (lifted) the old contents of register 'T' are lost.
When the stack drops, the current contents of register 'T' are duplicated
into register 'Z'.
If you want to do a one-number function (e.g. sin,sqrt), type the number and
press the function key. If the number is already in X, just press the
function key. The number is replaced by the function result.

If you want to do a two-number function (e.g. add,divide), type the first
number, press the 'Enter' key, type the second number and press the function
key. If the numbers are already in X and Y, just press the function key. If
the two numbers are in X and Y, but reversed, press the X<>Y (exchange X &
Y) key first. The two numbers are replaced by the function result.

All this may sound complicated, but in practice, once you get the hang of
it, RPN is easy and intuitive. Below are sample expressions and the
keystrokes needed to calculate them in algebraic and RPN. In RPN 'E' means
the 'Enter' key.

4 + 5
Alg: 4 + 5 =
RPN: 4 E 5 +