thane and mr. wolfe, you'll love this
Author Message
thane and mr. wolfe, you'll love this

fujitsu cobol seems to have learned math from "outcome-based education"
now am in the programs to print estimates/invoices.  (thane has seen the
pgm in action)  on the "create estimate" screen, when a part is added to
the estimate, the totals update correctly (it's 6% sales tax). but when
printing, and i used the identical coding for the subroutines, a \$100
part (taxable) comes up as \$101.40 in the sub-total line of the report.
i like mark-up as much as anyone (am on straight commission and all) but
this won't work.  can you advise, as i have a .45 currently pointed at
this machine and i'm not afraid to shoot!

Sat, 17 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

>fujitsu cobol seems to have learned math from "outcome-based education"
>now am in the programs to print estimates/invoices.  (thane has seen the
>pgm in action)  on the "create estimate" screen, when a part is added to
>the estimate, the totals update correctly (it's 6% sales tax). but when
>printing, and i used the identical coding for the subroutines, a \$100
>part (taxable) comes up as \$101.40 in the sub-total line of the report.
>i like mark-up as much as anyone (am on straight commission and all) but
>this won't work.  can you advise, as i have a .45 currently pointed at
>this machine and i'm not afraid to shoot!

Mike, if you will simply structure your expressions so that the multiplies
are done before the divides, you will eliminate the vast majority of such
problems.  For example, when you are computing a percent, don't write it:

COMPUTE Percent = Pct-Value / Tot-Value * 100.

but write it:

COMPUTE Percent = Pct-Value * 100 / Tot-Value.

In other words, don't just write the expression dumb, *think* about what
the compiler is going to do with your expression, and how it is going to
evaluate it.  I learned this as a newbie programmer 30 years ago, and
have rarely a problem getting a COMPUTE to work as I intend.

This issue is a prime example of why programmers should know at least
one assembly language.  The compiler's task of evaluating an expression
using fixed point arithmetic, without overflow or undue truncation, is
not an easy one.  Having an understanding of how the expression will be
processed at assembly language level really helps you to articulate what
you want so the compiler will get it right.  I have always been glad to
have learned assembly language first.  It always pays to have a solid
understanding of what is really going on inside the box.
--

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."

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

(snip)
> Mike, if you will simply structure your expressions so that the multiplies
> are done before the divides, you will eliminate the vast majority of such
> problems.  For example, when you are computing a percent, don't write it:

>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

> but write it:

>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

> In other words, don't just write the expression dumb, *think* about what
> the compiler is going to do with your expression, and how it is going to
> evaluate it.  I learned this as a newbie programmer 30 years ago, and
> have rarely a problem getting a COMPUTE to work as I intend.

> This issue is a prime example of why programmers should know at least
> one assembly language.  The compiler's task of evaluating an expression
> using fixed point arithmetic, without overflow or undue truncation, is
> not an easy one.  Having an understanding of how the expression will be
> processed at assembly language level really helps you to articulate what
> you want so the compiler will get it right.  I have always been glad to
> have learned assembly language first.  It always pays to have a solid
> understanding of what is really going on inside the box.

My approach to this issue has been to use parentheses to make the
calculation clear, even when they are not required. Certainly agree with
Judson that it's important to learn and remember the compiler's rules
for evaluating expressions, arithmetic & otherwise.

Bill {*filter*}

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

>> Mike, if you will simply structure your expressions so that the
multiplies
>> are done before the divides, you will eliminate the vast majority of such
>> problems.  For example, when you are computing a percent, don't write it:

>>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

>> but write it:

>>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

>My approach to this issue has been to use parentheses to make the
>calculation clear, even when they are not required. Certainly agree with
>Judson that it's important to learn and remember the compiler's rules
>for evaluating expressions, arithmetic & otherwise.

Bill, the issue here is not really parenthesis but the fact some compilers
will truncate the result of the division to an integer, parenthesis or not.
Multiplying first solves that problem. Knowing assembler or how the
machine REALLY works is not important; knowing what the
compiler does is.

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

>>> Mike, if you will simply structure your expressions so that the multiplies
>>> are done before the divides, you will eliminate the vast majority of such
>>> problems.  For example, when you are computing a percent, don't write it:

>>>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

>>> but write it:

>>>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

>>My approach to this issue has been to use parentheses to make the
>>calculation clear, even when they are not required. Certainly agree with
>>Judson that it's important to learn and remember the compiler's rules
>>for evaluating expressions, arithmetic & otherwise.

>Bill, the issue here is not really parenthesis but the fact some compilers
>will truncate the result of the division to an integer, parenthesis or not.
>Multiplying first solves that problem. Knowing assembler or how the
>machine REALLY works is not important; knowing what the
>compiler does is.

You are correct about the parentheses.  But what the compiler does is
generate machine instructions.  How can you understand that, if you
have no concept about how they work? :-)  The answer is that you must
depend on round-about descriptions which may or may not be correct or
actually address the issue at hand.  Without knowing English, I might
know, because somebody told me, that English had certain strengths or
weaknesses for expressing a given concept.  But that is a very pale
substitute for actually knowing English, and being able to evaluate
first-hand what the difficulties are.  I'll bet that very few COBOL
programmers with much assembly language experience would need to ask
why you would multiply before divide when handling fixed point numbers.
--

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."

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

>(snip)
>> Mike, if you will simply structure your expressions so that the
multiplies
>> are done before the divides, you will eliminate the vast majority of such
>> problems.  For example, when you are computing a percent, don't write it:

>>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

>> but write it:

>>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

understanding of what is really going on inside the box.

Quote:

>Bill {*filter*}
>My approach to this issue has been to use parentheses to make the
>calculation clear, even when they are not required. Certainly agree with
>Judson that it's important to learn and remember the compiler's rules
>for evaluating expressions, arithmetic & otherwise.

I tend to agree with Bill.  I use redundant parentheses a lot, both in
compute
statements and in logical IF statements where there is more than one
condition.  While the order of evaluation is supposed to be set by a
standard,
I still find that it is an area that often causes problems not only within
particular compilers but also in conversions.  Specifying a specific order
of evaluation by using parentheses is a cheap (compile time only) and
simple surety that has the advantage of also documenting the order.

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this
thanks, next round on me.  actually, i found out the prob tonite.  all
of the math is done in dll's and i didn't remember to write right below
procedure division "move zeroes to..."  i was getting totals from
previous estimates and invoices in the program.  (i think the blonde
roots are starting to show, where is my grecian formula?!)
i try to keep my math simple for the next programmer to tackle this
turkey, one computation per line.  guess when i get to the cost-per-job
and gross-profit stuff it may get hairy.  meanwhile, in fujitsu 3.0 how
do i get a nice source code printout that doesn't run over the
perforations in the paper and includes copy files for the w-s and f-d
entries?
Quote:

> >(snip)
> >> Mike, if you will simply structure your expressions so that the
> multiplies
> >> are done before the divides, you will eliminate the vast majority of such
> >> problems.  For example, when you are computing a percent, don't write it:

> >>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

> >> but write it:

> >>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.
> understanding of what is really going on inside the box.

> >Bill {*filter*}
> >My approach to this issue has been to use parentheses to make the
> >calculation clear, even when they are not required. Certainly agree with
> >Judson that it's important to learn and remember the compiler's rules
> >for evaluating expressions, arithmetic & otherwise.

> I tend to agree with Bill.  I use redundant parentheses a lot, both in
> compute
> statements and in logical IF statements where there is more than one
> condition.  While the order of evaluation is supposed to be set by a
> standard,
> I still find that it is an area that often causes problems not only within
> particular compilers but also in conversions.  Specifying a specific order
> of evaluation by using parentheses is a cheap (compile time only) and
> simple surety that has the advantage of also documenting the order.

Sun, 18 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

>turkey, one computation per line.  guess when i get to the cost-per-job
>and gross-profit stuff it may get hairy.  meanwhile, in fujitsu 3.0 how
>do i get a nice source code printout that doesn't run over the
>perforations in the paper and includes copy files for the w-s and f-d
>entries?

[Compile Options]
COPY=Yes
LINECOUNT=60
PRINT=Yes
SOURCE=Yes

Mon, 19 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

(snip)

> Bill, the issue here is not really parenthesis but the fact some compilers
> will truncate the result of the division to an integer, parenthesis or not.
> Multiplying first solves that problem. Knowing assembler or how the
> machine REALLY works is not important; knowing what the
> compiler does is.

I didn't want to take this fork in the code, but I don't use the COMPUTE
verb - too many problems with truncated results, different
implementations, etc. My point in bringing up parentheses is that coding
them even when they aren't required is good documentation.

Bill {*filter*}

Who does not COMPUTE :-)

Mon, 19 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:
> fujitsu cobol seems to have learned math from "outcome-based education"
> now am in the programs to print estimates/invoices.  (thane has seen the
> pgm in action)  on the "create estimate" screen, when a part is added to
> the estimate, the totals update correctly (it's 6% sales tax). but when
> printing, and i used the identical coding for the subroutines, a \$100
> part (taxable) comes up as \$101.40 in the sub-total line of the report.
> i like mark-up as much as anyone (am on straight commission and all) but
> this won't work.  can you advise, as i have a .45 currently pointed at
> this machine and i'm not afraid to shoot!

I don't have the code here, but can you post the code and the working
storage entries.  I think there's an intermediate result problem here.
Let's have a look.

Put the gun down.  Slowly.

Mon, 19 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this

Quote:

> Date: Wed, 02 Sep 1998 14:50:56 GMT

> Mike, if you will simply structure your expressions so that the multiplies
> are done before the divides, you will eliminate the vast majority of such
> problems.  For example, when you are computing a percent, don't write it:

>    COMPUTE Percent = Pct-Value / Tot-Value * 100.

> but write it:

>    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

> In other words, don't just write the expression dumb, *think* about what
> the compiler is going to do with your expression, and how it is going to
> evaluate it.  I learned this as a newbie programmer 30 years ago, and
> have rarely a problem getting a COMPUTE to work as I intend.

Anyone who took and passed basic arithmetic should know this, as the compiler
uses the standard math rules for evaluating an arithmetic expression:

PEMDAS.

Frank Ney  N4ZHG  WV/EMT-B  VA/EMT-A  LPWV  NRA(L)  GOA  CCRKBA  JPFO
Are you ready for Y2K?  Read "Time Bomb 2000" by Ed Yourdon
Abuses by the BATF  http://www.access.digex.net/~croaker/batfabus.html

Sun, 25 Feb 2001 03:00:00 GMT
thane and mr. wolfe, you'll love this
actually the problem turned out to be a carless mistake on my part in
not initializing all the fields to zero at the start.  so when i hit the
command compute retail-comp-1 = quantity-sto * retail-sto, for some
reason quantity-sto instead of 1.0 (as i intended) had 1.4 as a value.
i'll be more careful next time.

Quote:

> > Date: Wed, 02 Sep 1998 14:50:56 GMT

> > Mike, if you will simply structure your expressions so that the multiplies
> > are done before the divides, you will eliminate the vast majority of such
> > problems.  For example, when you are computing a percent, don't write it:

> >    COMPUTE Percent = Pct-Value / Tot-Value * 100.

> > but write it:

> >    COMPUTE Percent = Pct-Value * 100 / Tot-Value.

> > In other words, don't just write the expression dumb, *think* about what
> > the compiler is going to do with your expression, and how it is going to
> > evaluate it.  I learned this as a newbie programmer 30 years ago, and
> > have rarely a problem getting a COMPUTE to work as I intend.

> Anyone who took and passed basic arithmetic should know this, as the compiler
> uses the standard math rules for evaluating an arithmetic expression:

> PEMDAS.

> Frank Ney  N4ZHG  WV/EMT-B  VA/EMT-A  LPWV  NRA(L)  GOA  CCRKBA  JPFO
> Are you ready for Y2K?  Read "Time Bomb 2000" by Ed Yourdon
> Abuses by the BATF  http://www.access.digex.net/~croaker/batfabus.html

Sun, 25 Feb 2001 03:00:00 GMT

 Page 1 of 1 [ 12 post ]

Relevant Pages