RE: [OT] Rounding v Truncation, was: Re: Platform Support vs.

From: O'Brien Paddy (Paddy.O'Brien_at_transgrid.com.au)
Date: 07/28/05

  • Next message: Phillip Helbig---remove CLOTHES to reply: "LaTeX ---> PDF" 
    Date: Thu, 28 Jul 2005 19:08:03 +1000

    -----Original Message-----
    From: Dave Weatherall [mailto:djw-nothere@nospam.nohow]
    Sent: Thu 7/28/2005 3:33 PM
    To: Info-VAX@Mvb.Saic.Com
    Subject: Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.
     
    On Wed, 27 Jul 2005 13:18:19 UTC, "Tom Linden" <tom@kednos.com> wrote:

    > > Every programming language has it's own set of rules for implicit
    > >> conversion.

    > > Is the difference here not down to explicit (casted) versus implicit
    > > conversion?

    > Indeed, that is why I said IMPLICIT conversion. Each language has its own
    > set of rules
    > If you don't exploit EXPLICIT conversion then you had better know the
    > rules.

    Indeed you did Tom. Sorry, I was thinking more about Simon's Ada
    Integer cast when I tapped the keyboard and your example code
    (obviously:-)) fitted in with my thought. 

    -- 
Cheers - Dave W.
********
I cannot argue with the concept of each language having it's own rules.  However, if we are doing integer arithmetic then I firmly believe that we should truncate.
In Fortran, I can do things like  IF (a/2*2.EQ.0) blah blah.
This cannot work with rounding.
Why do other languages need truncation or rounding rules?  Integer arithmetic is Integer arithmetic and in mathematics, it works as truncation.  I learnt trunction rules in integers before I learnt rounding rules in Reals.
Regards, Paddy
***********************************************************************
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the 
addressees named above.  If you are not the intended recipient of 
this email, please delete the message and any attachment and advise
the sender.  You are hereby notified that any use, dissemination, 
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid 
immediately.  Any views expressed in this email are those of the 
individual sender except where the sender expressly and with 
authority states them to be the views of TransGrid.  TransGrid uses
virus-scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now
firstname.lastname@transgrid.com.au"
***********************************************************************
  • Next message: Phillip Helbig---remove CLOTHES to reply: "LaTeX ---> PDF"

    Relevant Pages

    • Re: Rounding errors
      ... It maintains the average of the infinite precision original ... With enough digits the average is close enough to ... Rounding maintains this with an average of 0.500. ... >It only 'pushes it upwards' with respect to how much truncation ...
      (comp.lang.cobol)
    • Re: Rounding errors
      ... Rounding maintains this with an average of 0.500. ... It only 'pushes it upwards' with respect to how much truncation ... You continue to say 'rounding error' when applied to an average. ... If the set of infinite precision reals adds up to the same as the set ...
      (comp.lang.cobol)
    • Re: Rounding errors
      ... How does the rounding operation know what truncation came ... I am suggesting that you may get a different expectation 'with ... > by FACTS, ...
      (comp.lang.cobol)
    • Re: Rounding errors
      ... digits then the average is _NOT_ 0.500. ... Rounding of the original set of long numbers, ... When you round the numbers to two digits what existed beyond the 3rd ... so the truncation doesn't matter. ...
      (comp.lang.cobol)