Author Message

In an attempt to explain to a newbie "why Cobol", I demo'd
the following to him:

10 FOR i = 1 TO 100
20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
30 NEXT i

(which fails on 4 values in the 100 under QBASIC)

I was curious how VB fares on the same test, but do not
have a copy.  Anybody willing to run the test, out of curiosity?

Mon, 18 Jun 2001 03:00:00 GMT

Quote:

>In an attempt to explain to a newbie "why Cobol", I demo'd
>the following to him:

>10 FOR i = 1 TO 100
>20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
>30 NEXT i

>(which fails on 4 values in the 100 under QBASIC)

>I was curious how VB fares on the same test, but do not
>have a copy.  Anybody willing to run the test, out of curiosity?

In VB 5.0, it failed 13 times. When I defined i to be either
an integer or long, it did not fail.
-------------------------------
Rick Smith

Mon, 18 Jun 2001 03:00:00 GMT

Quote:

>10 FOR i = 1 TO 100
>20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
>30 NEXT i
>I was curious how VB fares on the same test, but do not
>have a copy.  Anybody willing to run the test, out of curiosity?

I am a relative newbie, and I don't really understand what your test is
trying to show.  I ran it in Visual Basic and it didn't print anything.  The
results of the calculation (1/i)*(i*i) are the same as i.  Is that the
point?

-Art

Mon, 18 Jun 2001 03:00:00 GMT
In qbasic, they are not.  In fact, that program will
print four values.  Basic switches all to floating point
to do calculations, then changes it back unless you
specifically do string math.  You end up with small
differences that are almost impossible to predict.

If you are trying to balance a set of books, the
result is absolute anarchy.

That VB does not is interesting.  Could you try the same test
up to the value of 10000, instead of 100?

Quote:

>>10 FOR i = 1 TO 100
>>20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
>>30 NEXT i
>>I was curious how VB fares on the same test, but do not
>>have a copy.  Anybody willing to run the test, out of curiosity?

>I am a relative newbie, and I don't really understand what your test is
>trying to show.  I ran it in visual basic and it didn't print anything.
The
>results of the calculation (1/i)*(i*i) are the same as i.  Is that the
>point?

>-Art

Mon, 18 Jun 2001 03:00:00 GMT
'Twas Thu, 31 Dec 1998 09:18:39 -0500, when "Donald Tees"

Quote:
>In an attempt to explain to a newbie "why Cobol", I demo'd
>the following to him:

>10 FOR i = 1 TO 100
>20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
>30 NEXT i

I'm not this familiar with QBasic (though two weeks ago I billed about 40
hours of QBasic work at my A Series Cobol guru rate).  It appears to be
impossible to precisely store an intermediate result.  I tried LONG,
SINGLE and DOUBLE in the DIM statement below, but I still got your four
failures.

DIM j AS DOUBLE
FOR i = 1 TO 100
LET j = ((1 / i) * (i * i))
IF j <> ((1 / i) * (i * i)) THEN PRINT j; "-"; ((1 / i) * (i * i)); "=";
j - ((1 / i) * (i * i))
NEXT i

--
R B |\  Randall Bart

d t ||\ Greatest Unisys A Series Programmer Available is Now Available
a    |/                 http://members.aol.com/PanicYr00/RBResume.html
l    |\ The Year 2000 Bugs:           http://members.aol.com/PanicYr00
l    |/ MS^7=6/28/107   http://members.aol.com/PanicYr00/Sequence.html

Mon, 18 Jun 2001 03:00:00 GMT
The real problem with basic is that it converts to floating
point for all decimals.  As soon as you get away from integers
for dollars and cents, you are in trouble.  Ten cents expressed
as "\$0.10" is a repeating decimal, like it or not.

If you have to write financial stuff in basic, the only way it
will ever work reliably is to do all accounting in pennies, and
convert only for output.  As long as you have enough precision
that will work.  Even then, however, when it comes to stuff
like percentage calculations, you had better insure that you
convert back to integer form before you start adding and
subtracting. By the time you are done, the code is about four
times as verbose as Cobol.

This one always astonishes beginners:

10 for i = 1 to 1000000
20 x = x + 0.1
30 next  i
40 print x

Quote:

>'Twas Thu, 31 Dec 1998 09:18:39 -0500, when "Donald Tees"

>>In an attempt to explain to a newbie "why Cobol", I demo'd
>>the following to him:

>>10 FOR i = 1 TO 100
>>20 IF ((1 / i) * (i * i)) <> i THEN PRINT ((1 / i) * (i * i)), i
>>30 NEXT i

>I'm not this familiar with QBasic (though two weeks ago I billed about 40
>hours of QBasic work at my A Series Cobol guru rate).  It appears to be
>impossible to precisely store an intermediate result.  I tried LONG,
>SINGLE and DOUBLE in the DIM statement below, but I still got your four
>failures.

>  DIM j AS DOUBLE
>  FOR i = 1 TO 100
>  LET j = ((1 / i) * (i * i))
>  IF j <> ((1 / i) * (i * i)) THEN PRINT j; "-"; ((1 / i) * (i * i)); "=";
>j - ((1 / i) * (i * i))
>  NEXT i

>--
>R B |\  Randall Bart

>d t ||\ Greatest Unisys A Series Programmer Available is Now Available
>a    |/                 http://members.aol.com/PanicYr00/RBResume.html
>l    |\ The Year 2000 Bugs:           http://members.aol.com/PanicYr00
>l    |/ MS^7=6/28/107   http://members.aol.com/PanicYr00/Sequence.html

Mon, 18 Jun 2001 03:00:00 GMT

Quote:

>The real problem with basic is that it converts to floating
>point for all decimals.  As soon as you get away from integers
>for dollars and cents, you are in trouble.  Ten cents expressed
>as "\$0.10" is a repeating decimal, like it or not.

>If you have to write financial stuff in basic, the only way it
>will ever work reliably is to do all accounting in pennies, and
>convert only for output.  As long as you have enough precision
>that will work.  Even then, however, when it comes to stuff
>like percentage calculations, you had better insure that you
>convert back to integer form before you start adding and
>subtracting. By the time you are done, the code is about four
>times as verbose as Cobol.

[...]

Although your statements are correct, with respect to the older
BASICs, they are not particularly valid with Visual Basic. The
Visual Basic "currency" data type is intended for use with fixed
decimal values. It is equivalent to specifying S9(14)V9(4)
BINARY, in COBOL.
-------------------------------
Rick Smith

Mon, 18 Jun 2001 03:00:00 GMT
Thats interesting to know. It would certainly make
life a lot easier.  Is there anyway of declaring any
other "picture" types, or is that the only one?

There were also a bunch of Basics a few years back
that had "character arithmetic".  It was done with ASCII
type strings much like Cobol data but null terminated.

Quote:

>>The real problem with basic is that it converts to floating
>>point for all decimals.  As soon as you get away from integers
>>for dollars and cents, you are in trouble.  Ten cents expressed
>>as "\$0.10" is a repeating decimal, like it or not.

>>If you have to write financial stuff in basic, the only way it
>>will ever work reliably is to do all accounting in pennies, and
>>convert only for output.  As long as you have enough precision
>>that will work.  Even then, however, when it comes to stuff
>>like percentage calculations, you had better insure that you
>>convert back to integer form before you start adding and
>>subtracting. By the time you are done, the code is about four
>>times as verbose as Cobol.
>[...]

>Although your statements are correct, with respect to the older
>BASICs, they are not particularly valid with Visual Basic. The
>Visual Basic "currency" data type is intended for use with fixed
>decimal values. It is equivalent to specifying S9(14)V9(4)
>BINARY, in COBOL.
>-------------------------------
>Rick Smith

Mon, 18 Jun 2001 03:00:00 GMT

Quote:

>Thats interesting to know. It would certainly make
>life a lot easier.  Is there anyway of declaring any
>other "picture" types, or is that the only one?

This is the only one that has decimal positions.

Quote:

[...]

>>[...] The
>>Visual Basic "currency" data type is intended for use with fixed
>>decimal values. It is equivalent to specifying S9(14)V9(4)
>>BINARY, in COBOL.

-------------------------------
Rick Smith

Tue, 19 Jun 2001 03:00:00 GMT

Quote:

>The real problem with basic is that it converts to floating
>point for all decimals.  As soon as you get away from integers
>for dollars and cents, you are in trouble.  Ten cents expressed
>as "\$0.10" is a repeating decimal, like it or not.

>If you have to write financial stuff in basic, the only way it
>will ever work reliably is to do all accounting in pennies, and
>convert only for output.  As long as you have enough precision
>that will work.  Even then, however, when it comes to stuff
>like percentage calculations, you had better insure that you
>convert back to integer form before you start adding and
>subtracting. By the time you are done, the code is about four
>times as verbose as Cobol.

The same holds equally true for C and most other languages which
do not support scaled decimal math.  In my opinion, anybody who
chooses to write money handling programs in C/C++, Java, etc.,
in situations when COBOL could be used, has a{*filter*}loose.  Yes,
you could write classes in C++ and Java to handle it after a
fashion, but why should you?  Note that VB and PDS 7.1 have a
CURRENCY data type which is equivalent to PIC S9(14)V9(4).  VB
has 'Decimal' a 96 bit decimal floating point variant data type.

Quote:
>This one always astonishes beginners:

>10 for i = 1 to 1000000
>20 x = x + 0.1
>30 next  i
>40 print x

Even simpler, try this

10 FOR I=0 TO 1 STEP .1
20   PRINT I,
30 NEXT

It makes one shudder to think that people actually use this stuff
to handle money.  Ugh!
--

Sun Valley Systems     http://www.*-*-*.com/ ~judmc
"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."

Tue, 19 Jun 2001 03:00:00 GMT

Quote:

>>Thats interesting to know. It would certainly make
>>life a lot easier.  Is there anyway of declaring any
>>other "picture" types, or is that the only one?

>This is the only one that has decimal positions.

Check out VB type 'Decimal', which is 96 bit decimal floating point.
However, it can only be declared for use in a variant.
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"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."

Tue, 19 Jun 2001 03:00:00 GMT

Quote:

>>This is the only one that has decimal positions.

>Check out VB type 'Decimal', which is 96 bit decimal floating point.
>However, it can only be declared for use in a variant.
>--

I was not aware of its existence!

This allows for any representation in the form:

PIC S9(m)V9(n) BINARY; where m + n < 29.

It still has all the problems of floating point; since one would
necessarily need to force rounding or truncation to ensure that
values extending past 'n' always contain zeros.

Usable, but still clumsy when compared with COBOL!

I get to learn something new every day.
-------------------------------
Rick Smith

Tue, 19 Jun 2001 03:00:00 GMT
Curious, I tried it both as written, and with an auxilliry variable
15 J = (1/I)*(I*I)
with QuickBasic 4.5 -- when compiled to an EXE either
from the IDE or from the command line it runs fine.
(i.e., nothing printed.)  This was true for both 1 .. 100
and 1 .. 10000 ranges.  The (uncompressed) EXE is under
30k if anyone wants it by e-mail.

When executed interactively, it runs fine with the auxilliary
variable (again, nothing printed) .

When executed interactively W/O the auxilliary variable
results varied -- sometimes printing EVERY line with
two identical numbers but more often printing nothing.

But it never printed just four numbers.

I thought QBasic was just a stripped down version of
QuickBasic, but it looks like the differences may be
more fundamental.

If I get a chance I'll see if I can translate this into VB4
for windows (16 and 32 bits) and see how it does.
--
Kevin G. Rhoads, Ph.D. (Linearity is a convenient fiction.)

Tue, 19 Jun 2001 03:00:00 GMT

Quote:

> The same holds equally true for C and most other languages which
> do not support scaled decimal math.  In my opinion, anybody who
> chooses to write money handling programs in C/C++, Java, etc.,
> in situations when COBOL could be used, has a{*filter*}loose.  Yes,
> you could write classes in C++ and Java to handle it after a
> fashion, but why should you?  Note that VB and PDS 7.1 have a
> CURRENCY data type which is equivalent to PIC S9(14)V9(4).  VB
> has 'Decimal' a 96 bit decimal floating point variant data type.

The MVS C370 has an extension that allows you to define packed fields in
exactly the same way as Cobol.

Ken

Thu, 21 Jun 2001 03:00:00 GMT
I believe REXX can be set up to handle any size integers!!!  If your
integers were larger than the computer would handle natively, it slowed
down considerably.

I suppose a string handling language such as lisp may do the same
thing.  I wonder which languages are effective in calculating pi to
5,000 places.

Who here has had to fudge numbers larger than what their COBOL
implementation can handle natively?  How did you do it?

Fri, 22 Jun 2001 03:00:00 GMT

 Page 1 of 2 [ 19 post ] Go to page: [1] [2]

Relevant Pages