× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: more on EVAL
  • From: Jim Langston <jlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 07 Oct 1999 13:04:27 -0700
  • Organization: Conex Global Logistics Services, Inc.





> Comments in line...
>
> boldt@ca.ibm.com wrote:
>
> > <SNIP>
> > I noticed you haven't mentioned PL/I.  Interesting.  PL/I has
> > different rules yet again!  It has it's own set of quirks regarding
> > decimal arithmetic, yet many people still use it.
>
> You are right, I have never even seen PL/I.  I have no idea what PL/I does.
>
> > <SNIP>
>
> > You do offer an interesting suggestion, though:  Perhaps we should
>
> > have a "CURRENCY" attribute on decimal numeric variables, which
> > would ensure that decimal precision never drops below the declared
> > number of decimal digits within expressions.  (Basic's 2 decimal
> > place currency format seems a bit restrictive.  Not all countries
> > use 2 decimal places in their currency.)
>
> That would be nice, then I wouldn't have any problem at all using the Eval.
>
> > I'm like you - I wouldn't do computer programming if I didn't
> > enjoy it and wasn't good at it.
> >
> > Sure, the title of that point was meant to be provocative. But I
> > stand by it.  In my humble opinion, too many programmers are too
> > complacent about their craft.  It is all too easy these days to
> > pick up something new, have some early successes, and think you
> > know all about it.
>
> When I program, my objective is to write a program without bugs that
> does the objective given to me.  And, so far, I have done it every time.
> I always double check my answers on pencil to make sure they are
> correct.  I do not think I know everything about any language, I don't
> think anyone does.  But I know the things I use.
>
> When I first started programming and started getting into mathematical
> formulas, I looked real closely at how math was done.  I studied how
> they were stored in the computer, I studied the overflow bit, I studied
> 2's compliment, I studied multiplication, division, raising to the power of
> et al.  The reason I got so into it was because I was doing graphical
> programming, and was writing my own 3d engine, and I had to know
> how accurately I could depend on my answers.
>
> And when I pick up a new language and started using math I would
> look and make sure they were doing it the same way, and they did.
>
> After 5 or 6 languages, I still usually check to make sure they are doing
> it the same way.  And so far I haven't run across any problems, not even
> with the MULT statement in RPG.
>
> And, when I started using EVAL I did check the manual, as I quoted you,
> as I check every command I haven't used before, with no indication of
> any difference between how it worked and how the MULT works.  I had
> no reason to think it would be any different.  As stated, it seems I have
> the first version of the manual, which gave no indication of any change from
> every other language I have programmed in, or RPG's own MULT statement.
>
> > You mentioned Perl in your own list of languages.  Do you read
> > comp.lang.perl.misc?  I see many people post questions and
> > very often the answer is "Did you use -w and use strict?"  A
> > beginner can quickly learn enough to write a Perl program, but
> > it takes more understanding to appreciate the importance of
> > things like "-w" and "use strict".  It's that kind of
> > necessary wisdom that's hard.
>
> As I have said, I know a "little bit" of Perl.  I do not consider myself
> proficient
> in it.  I have written small programs in it, but didn't understand enough of
> what
> I was doing to consider myself learned in that language.  I did start a study
> course in it, but never finished it (wound up with my Linux box bombing out
> with a crashed motherboard about 3 years ago, and haven't gotten a new
> box at home to install linux on.  I did just buy 3 manuals on Linux, one on 
>the
> operating system, one on programming in linux and on on C for linux).
>
> > <SNIP>
> > Me, I started learning programming in 1976.  And I'm still learning
> > programming.  I didn't stop learning when I quit school in 1980.
>
> I am always reading up on programming.  At home I am reading a
> box on Linux right now that I just started and is about 3" thick, I got
> 3 of them to go though.  That is not counting my 80836 Programmer's
> Reference Manual I got from 1986 to learn more about Assembly and
> how Intel CPUs work.
>
> > Then I take it you haven't yet learned object-oriented programming.
> >
> > Learning programming is much more than just learning the peculiarities
> > of particular programming languages.  Take OOP for instance.  In my
> > opinion, no-one schooled in procedural programming can really understand
> > object-oriented programming without first feeling like a complete
> > idiot.  If you think you know OOP without going through that phase, you
> > really don't know OOP.
>
> Of course I know OOP.  I picked it up at the last company I worked at
> where they used Delphi.  They didn't use OOPs too much, but I started
> looking at it, bought the compiler at home and read the manuals.  Then
> I wrote a few programs, logged onto Delphi news groups, downloaded
> OPPs (Other People's Programs) and looked at them, etc...
>
> And then I looked at OOPs in C and VBasic and, know what?  They
> worked just about the same way.
>
> > The realization that one must pass through through that "complete
> > idiot" phase is hard for many people to accept.  We don't like
> > feeling like idiots.  Yet, IMHO, it's often necessary to shake off
> > old prejudices and beliefs in order to learn and accept new things.
>
> Oh yes,  I definitely felt like a complete idiot with OOPs, Pascal in
> Delphi was no problem, but the OOPs had me scratching my head,
> because I had never seen it before.  I say if you don't learn something
> new every day, it was a wasted day.
>
> > (On the other hand, IMHO, over time, the teaching of OOP will improve to
> > make the process less painful.  But then again, the need to teach new
> > tricks to us old dogs will decrease as we retire and more and more new
> > programmers learn OOP right from the start.)
>
> True.
>
> > But here's what I don't understand with this discussion:  Learning a
> > new set of arithmetic rules in a programming language really doesn't
> > compare with learning a whole new way of approaching programming or
> > a whole new operating system.  Many RPG programmers have made the
> > transition to RPG IV with little effort and few complaints.
>
> The only problem I had was there was no indication at all that it was a
> "new set of arithmetic rules".
>
> > Here's where I really take offense at your assertions.  You claim that
> > we want RPG to be different for no good reason?  You have no idea what
> > went into the design for decimal arithmetic.  The fact is, we looked
> > at many different sets of rules, and for each, we found cases where the
> > rules would cause possibly unexpected results.  Unless we did the
> > arithmetic with infinite precision and infinite speed, there was no way
> > we could satisfy everyone.  That's the reality of programming language
> > design.
>
> Of course, but why did you try to reinvent the wheel and wind up making
> it square instead of round?  All the other programming languages way of
> dealing with overflow is going to effect me very seldom.  I know about it,
> I know how it works, I keep it in the back of my mind as I write my formulas
> and it just doesn't effect me.  Maybe one out of 100 or 1000 times am I
> going to have to change the way I am doing something because what I am
> doing is going to overflow.
>
> RPG's way of doing it, on the other hand, has the potential of affecting me
> quite a bit.  Even though now I know about it, every time I write something
> I am going to have to start counting decimal places and interger places on
> my fingers and toes and then juggle around my equations so that the formulas
> will come out right.
>
> I learned a long, long, long time ago to make my variables large enough to 
>hold
> my answers or I would get an overflow, and make sure there are no intermediary
> results that will go past my variables allotted space, which is perfectly 
>fine.
>
> That is not good enough for RPG, now, because now I am also going to have
> to determine the precision, or make absolutely sure that I have the header 
>spec
> specified (and even then, I am going to test the heck out of it to make sure 
>it
> works 100% as advertised).
>
> > If you think you can design a programming language better, then please
> > feel free to do so.
>
> Actually, I once bought a book on compiler design to do just that, but the
> book was so full of gobblygook I couldn't' understand a word it was saying.
> I don't know if the book was just written horribly or I don't know enough
> higher mathematics to understand it.
>
> > <SNIP>
> > Look, I've stated before that, sure, we could have made some better
> > design choices.  But we have a policy of trying to ensure that a
> > working program compiled several years ago will work the same today
> > when compiled on a newer release.  We can't go back and arbitrarily
> > change the rules, and our customers expect that.
>
> Okay, that I can agree with.  You know, I wouldn't even of thought anything
> of it if I didn't already know so many other programing languages that all
> did things the same way.
>
> And I can respect this answer, Hans.  This thread would of died a long, long
> time ago if that was stated from the beginning instead of RTFM.  "Okay, we
> did not make the best design decision there, we've added the fact that you
> have to be careful with math in LATER versions of the manual."
>
> This whole thread I think derived from the fact that the first version of the
> manual said nothing about the math being any different than the MULT and
> DIV statements.
>
> The fact is, it is now in later versions of the manual so people know about it
> (and I'm talking about the RPG reference manual under the EVAL section,
> not some section on math).  I'm just wondering where the replacement page
> for my manual is.  Probably got lost in the mail <g>
>
> Regards,
>
> Jim Langston
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
>
>   ------------------------------------------------------------------------
> Received: from ns.learningco.com ([198.112.0.7]) by mail.learningco.com with
> SMTP
>   (IMA Internet Exchange 3.12) id 000262F8; Thu, 7 Oct 1999 14:10:27 -0400
> Received: by ns.learningco.com; id OAA19941; Thu, 7 Oct 1999 14:06:50 -0400
> (EDT)
> Received: from kitten.mcs.com(192.160.127.90) by ns.learningco.com via smap
> (V4.2)
>         id xma019816; Thu, 7 Oct 99 14:06:23 -0400
> Received: from uucphost.mcs.net (Uucp1.mcs.net [192.160.127.93]) by
> Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id MAA04756; Thu, 7 Oct 1999 12:26:36
> -0500 (CDT)
> Received: (from uucp@localhost)
>         by uucphost.mcs.net (8.8.8/8.8.8) id MAA02700;
>         Thu, 7 Oct 1999 12:26:19 -0500 (CDT)
> Received: (from majordom@localhost)
>         by midrange.com (8.9.3/8.9.3) id LAA00839
>         for rpg400-l-outgoing; Thu, 7 Oct 1999 11:19:28 -0500
> Received: (from uucp@localhost)
>         by midrange.com (8.9.3/8.9.3) with UUCP id LAA00132
>         for RPG400-L@midrange.com; Thu, 7 Oct 1999 11:03:34 -0500
> Received: from internet-server.conexfreight.com ([207.113.62.33])
>         by uucphost.mcs.net (8.8.8/8.8.8) with ESMTP id KAA23105
>         for <RPG400-L@midrange.com>; Thu, 7 Oct 1999 10:25:00 -0500 (CDT)
> Received: from conexfreight.com ([207.113.62.33])
>           by internet-server.conexfreight.com (post.office MTA v2.0 0813
>           ID# 0-40010U100L2S100) with ESMTP id AAA96
>           for <RPG400-L@midrange.com>; Thu, 7 Oct 1999 08:15:17 -0700
> Message-ID: <37FCB904.FE8CE26C@conexfreight.com>
> Date: Thu, 07 Oct 1999 08:15:17 -0700
> From: Jim Langston <jlangston@conexfreight.com>
> Organization: Conex Global Logistics Services, Inc.
> X-Mailer: Mozilla 4.61 [en] (WinNT; I)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: RPG400-L@midrange.com
> Subject: Re: [Re: RPGILE V4.3 Gotcha]
> References: <87256803.00489F5B.00@d53mta02h.boulder.ibm.com>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Sender: owner-rpg400-l@midrange.com
> Precedence: bulk
> Reply-To: RPG400-L@midrange.com
> X-List-Name: RPG/400 Discussion Mailing List (RPG400-L@midrange.com)

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.