Re: errata/140: Section 4.1.5: Definition of power operator result type

From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Tue May 27 2003 - 03:10:02 PDT

  • Next message: Shalom.Bresticker@motorola.com: "errata/170: ANALYZED - formatting of bnf non-terminals"

    Precedence: bulk

    The following reply was made to PR errata/140; it has been noted by GNATS.

    From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    To: Kurt Baty <kurt@wsfdb.wsfdb.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/140: Section 4.1.5: Definition of power operator result type
    Date: Tue, 27 May 2003 13:07:39 +0300

    > I like:
    >
    > non-real case truncates all fractions toward 0
     
     OK
     
     
    > > > If either operand of the power operator is real, then the result type
    > > > shall be real.
    > >
    > > It is unclear what happens if base is 0 and power is 0 or negative.
    >
    > yes, and this is by intent, talking to steve, verilog for the real cases
    > wants "to be able" to call the c-lib pow function, which depends on which machine
    > you are running on and which c-lib you have, and does not return the same answer
    > on all machines and all c-libs. I thought maybe say that "the answer may depend
    > on the target machine and c-lib" steve thought not, so the verilog standard
    > says nothing.
     
     Then you should say it is "undefined", as in the previous proposal:
     
     "The result value is undefined if the first operand
     is zero and the second operand is non-positive, or if the first operand
     is negative and the second operand is not an integral value."
     
     
    > op1 is negative<-1 -1 zero 1 positive>1
    > --------------------------------------------------------------------------
    > op2 is
    > positive op1 ** op2 op2 is odd -> -1 0 1 op1 ** op2
     
     OK.
     

    This archive was generated by hypermail 2.1.4 : Tue May 27 2003 - 03:10:47 PDT and
    sponsored by Boyd Technology, Inc.