Re: Decimal Arith in DCL was(RE: Floating point arithmetic support in DCL) in DCL) in DCL)

From: Richard B. Gilbert (rgilbert88_at_comcast.net)
Date: 01/03/04 

Date: Fri, 02 Jan 2004 20:11:48 -0500

Sigh! Ugly ad hoc rules? It seems to me that these rules, or
something very like them already exist in both Fortran and C.
Generations of programmers survived them. I don't recall enough PL/1 to
be able to make any claims regarding its behavior in this respect. Are
these rules any uglier than a four operand division function?

The little credit card size promotional giveaway four function
calculators do everything that I'd want to see in DCL. Other than not
breaking existing integer calculations I don't see a problem. Requiring
an explicit decimal point in decimal constants seems natural and not an
unreasonable burden and seems to solve the problem of not breaking
integer calculations. If numeric constants don't have a decimal point
they are integers.

Variables might be explicitly declared
$ Integer X
$ Character Y
$ Decimal Z
or implicitly declared by the value assigned
$ X=1 ! Integer
$ Y="1" ! Character
$ Z=1.0 ! Decimal

Tom Linden wrote:

>< -----Original Message-----
>< From: Richard B. Gilbert [mailto:rgilbert88@comcast.net]
>< Sent: Thursday, January 01, 2004 5:42 PM
>< To: Info-VAX@Mvb.Saic.Com
>< Subject: Re: Decimal Arith in DCL was(RE: Floating point arithmetic
>< support in DCL) in DCL) in DCL)
><
><
>< all right, decimal arithmetic instead of floating. With the possible
>< exception of a COBOL course I took thirty years ago, I don't think I've
>< ever used decimal arithmetic!! Neither Fortran nor C support the data
>< type or the operations.
>
>That is true, but the world of commerce uses exclusively decimal arithmetic,
>which is why they use cobol and PL/I to such an extent.
><
>< Pardon me but I don't see the necessity for two operators either. One
>< operator, overloaded, seems to me to be sufficient. Integer operands
>< imply an integer calculation. If at least one operand is decimal it
>< seems to me to require a decimal operation and a decimal result. Is
>< there some ambiguity that I don't see?
>
>Overloading is not necessarily a good thing, and in this case, in an attempt
>to not break exisiting code you would have to apply some pretty (ugly) ad
>hoc
>rules, and I see no compelling reason to do so. Moreover, it is important
>to make the contemplated extensions consistent with data types of other 3GLs
>to facilitate import/export of values, which is why I suggested that SDL is
>the appropriate backdrop to employ.
>
><
>< As for the number of significant figures in the result, why would you
>< want to specify that? 5./4. = 1.25! If , for some reason, you wish to
>< display only two significant figures that seems to me to be a different
>< problem. If you are going to use the result in another calculation
>< would you really want the result to be 1.2? 4.0*1.2=4.8 not five!
>< Sorry I don't recall the correct technical term for the rule that that
>< breaks. (Yes, I know that floating point can break that rule too but
>< 4.999998 is usually close enough to 5 for government work.)
><
>< And the purpose of the third operand in your divide() function escapes
>< me completely. 3 what?
>
>the third arg is the precision, the total number of decimals and the fourth
>is
>the scale, the number of decimals to the right of the decimal point. The
>following URL describes the args
>
>ftp://freja.kednos.com/pub/html/vms/reference/6291pro_037.html#index_x_1633
><
>< You (and John) may be right but you haven't explained why!
><
>< Tom Linden wrote:
><
>< >Seems like everybody wants to have a hand at reinventing the log. This
>< >problem was solved 40 years ago. Firstly, I have never seen command
>< >interpreter that uses float, decimal yes, but float no. Secondly, they
>< >are not scaled integers. There is scaled binary and scaled decimals.
>< >
>< >As John and I have both pointed out, you will need to provide two forms
>< >of operators, one for natural numbers (5/4 =1) and one for extended
>< >precision decimal ( divide(5,4,3,2) = 1.25, note that
>< divide(5,4,3,1)=1.2) )
>< >and this will not break any existing code.
>< >
>< >Moreover, all the builtin functions from the math libs could easily be
>< >made available as lexical functions. Even BSD Unix had this in the late
>< >70's (in bc).
>< >
>< >Ok, suppose this is a fait accompli, then you might ask for the ability
>< >to write arbitrary algebraic expressions in dcl. Piece of cake,
>< just need
>< >nine or so layers of recursive descent. Oh, and what about type checking
>< >and
>< >semantic analysis? My point is that we have 3GLs for this type
>< of work and
>< >I think the key here is knowing when to cut it off and avoid clutter.
>< >
>< >Next topic?
>< >
>< >Happy New Year
>< >Tom
>< >
>< >< -----Original Message-----
>< >< From: Richard B. Gilbert [mailto:rgilbert88@comcast.net]
>< >< Sent: Wednesday, December 31, 2003 5:58 PM
>< >< To: Info-VAX@Mvb.Saic.Com
>< >< Subject: Re: Floating point arithmetic support in DCL
>< ><
>< ><
>< >< I see 5 / 4 as an integer expression that evaluates to 1! Make that
>< >< 5.0 / 4.0 (zeroes not really needed, the decimal point should
>< be enough)
>< >< and it's a float expression that evaluates to 1.25. 5./4 and 5/4. are
>< >< mixed mode expressions that would seem to require some sort of special
>< >< handling. You could make a rule that integers will be converted to
>< >< float when found in a mixed mode expression and the expression
>< evaluated
>< >< using floating arithmetic.
>< ><
>< >< Others may want to do some fairly complex calculations using DCL but my
>< >< needs are quite modest; things like calculating the percentage of free
>< >< space on a disk. . . . I certainly would not expect to need
>< logarithms,
>< >< trig functions or anything like that. Serious calculations should be
>< >< done in a language that was designed to support them; Fortran
>< or, if you
>< >< must, C.
>< ><
>< >< John Reagan wrote:
>< ><
>< >< > For
>< >< >
>< >< > A = 5 / 4
>< >< >
>< >< > my language background says that the variable on the left has no
>< >< > impact on parsing the expression on the right. That is why
>< Pascal has
>< >< > two divide operators, DIV and /. Just like PLI has two operators.
>< >< > Perhaps you want two divide operators, integer divide spelled as "/"
>< >< > for compatibility and floating divide spelled as something else?
>< >< >
>< >< > Also, we haven't talked about exceptional values, rounding
>< modes, etc.
>< >< > If you think if this as real IEEE floating numbers, then we need to
>< >< > talk about those things. If you want DCL's floating to be
>< more like a
>< >< > fixed-point/packed-decimal model, then we need to define it that way
>< >< > (and not use the underlying floating registers/instructions to do the
>< >< > work since it won't give the right answer).
>< >< >
>< >< >
>< ><
>< >< ---
>< >< Incoming mail is certified Virus Free.
>< >< Checked by AVG anti-virus system (http://www.grisoft.com).
>< >< Version: 6.0.553 / Virus Database: 345 - Release Date: 12/18/2003
>< ><
>< >---
>< >Outgoing mail is certified Virus Free.
>< >Checked by AVG anti-virus system (http://www.grisoft.com).
>< >Version: 6.0.553 / Virus Database: 345 - Release Date: 12/18/2003
>< >
>< >
>< >
><
>< ---
>< Incoming mail is certified Virus Free.
>< Checked by AVG anti-virus system (http://www.grisoft.com).
>< Version: 6.0.553 / Virus Database: 345 - Release Date: 12/18/2003
><
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.553 / Virus Database: 345 - Release Date: 12/18/2003
>
>
>

Relevant Pages