- Previous message: Charles Dawson: "[Fwd: 237 issue]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Precedence: bulk
The following reply was made to PR errata/140; it has been noted by GNATS.
From: Kurt Baty <kurt@wsfdb.wsfdb.com>
To: etf-bugs@boyd.com
Cc: kurt@wsfdb.wsfdb.com
Subject: Re: errata/140 "**" as an integer trucated operator try2
Date: Mon, 19 May 2003 13:38:24 -0500 (CDT)
>Category: errata
>Confidential: no
>Originator: Kurt Baty <kurt@wsfdb.wsfdb.com>
>Release: 2001b
>Submitter-Id: etf
>Class: TBD
>Description:
Description The 3rd paragraph of Section 4.1.5 attempts to define
the result type of the power operator.
The following BTF thread discusses several issues with
this definition.
http://boydtechinc.com/btf/archive/btf_2002/1776.html
Submitting for consideration by the ETF.
Fix
Part I:
REPLACE (3rd paragraph of 4.1.5):
The result of the power operator shall be real if either operand is a
real, integer or signed. If both operands are unsigned then the
result shall be unsigned. The result of the power operator is
unspecified 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.
WITH (new 3rd and 4th paragraphs of 4.1.5):
If either operand of the power operator is real, then the result type
shall be real.
If neither operand of the power operator is real, then the result type
shall be determined as outlined in 4.4.1 and 4.5.1, with the second
operand treated as self-determined. The result value is 'bx if
the first operand is zero and the second operand is negative.
remove-> The result value is 1 if the first operand is zero.
The result value is 1 if the second operand is zero.
op1 ** op2 where op1, op2 are not real:
op1 is negative<-1 -1 zero 1 positive>1
---------------------------------------------------------------------
op2 is
positive int(op1 ** op2) op2 is odd -> -1 1 0 1 int(op1 ** op2)
op2 is even -> 1
zero 1 1 1 1 1
negative 0 op2 is odd -> -1 'bx 1 0
op2 is even -> 1 'bx
------------------------------------------------------------------------
Part II:
REPLACE (Title of Table 15 in 4.1.5):
Examples of modulus operators
WITH (new Title of Table 15 in 4.1.5):
Examples of modulus and power operators
------------------------------------------------------------------------
Part III:
REPLACE (The sentence immediately prior to Table 15):
Table 15 gives examples of modulus operations.
WITH
Table 15 gives examples of some modulus and power operations.
------------------------------------------------------------------------
Part IV:
REPLACE (heading of first column in Table 15):
Modulus expression
WITH (new heading of first column in Table 15):
Expression
------------------------------------------------------------------------
Part V:
Append the following power operator examples to Table 15:
Expression Result Comments
3**2 9 3*3
2**3 8 2*2*2, same result as 1<<3
2**0 1 By definition, and same result as 1<<0
2**-3'sb1 0 -3'sb1 treated as unsigned 7, same as 1<<-3'sb1
2.0**-3'sb1 0.5 -3'sb1 coerced to -1.0, giving real reciprocal
0**-1 'bx Integer division by zero is 'bx
9**0.5 3.0 Real square root
9.0**(1/2) 1.0 Integer division truncates exponent to zero
-3.0**2.0 9.0 Defined, because real 2.0 is still integral value
2**(-3'so4/3'so2) 0 Exponent is -3'so2, = 1/4, Integer division truncates 0
----- Begin Included Message -----
>From kurt Tue May 13 10:30:51 2003
Date: Tue, 13 May 2003 10:30:46 -0500 (CDT)
>From: Kurt Baty <kurt>
To: etf@boyd.com
Subject: Re: errata/140 "**" as an integer trucated operator
Cc: kurt
OK how about this:
integer x ** y results table
in the form of the integer number plane
|
x values -> | -4 -3 -2 -1 0 1 2 3 4
y values -v |
----------------+-------------------------------------------------------------------------------
|
4 | 256 81 16 1 0 1 16 81 256
|
3 | -64 -27 -8 -1 0 1 8 27 64
|
2 | 16 9 4 1 0 1 4 9 16
|
1 | -4 -3 -2 -1 0 1 2 3 4
|
0 | 1 1 1 1 1 1 1 1 1
|
| -1/4 -1/3 -1/2 Inf 1/2 1/3 1/4
-1 | = 0 = 0 = 0 -1 = x 1 = 0 = 0 = 0
|
| 1/16 1/9 1/4 Inf 1/4 1/9 1/16
-2 | = 0 = 0 = 0 1 = x 1 = 0 = 0 = 0
|
| -1/64 -1/27 -1/8 Inf 1/8 1/27 1/64
-3 | = 0 = 0 = 0 -1 = x 1 = 0 = 0 = 0
|
| 1/256 1/81 1/16 Inf 1/16 1/81 1/256
-4 | = 0 = 0 = 0 1 = x 1 = 0 = 0 = 0
|
or going up the x = 4 column ... 1/256 1/64 1/16 1/4 1 4 16 64 256
= 0 = 0 = 0 = 0
or:
x ** y where x, y are integers:
x is negative zero positive
---------------------------------------------------
y is
positive int(x ** y) 0 int(x ** y)
zero 1 1 1
negative x = -1 and x x = 1 -> 1
y is odd -> -1 else 0
x = -1 and
y is even -> 1
else 0
two things not to like:
1) 0 ** 0 = 1 ?
but:
Summary of Algebraic Rules for Powers
Rule for Multiplication: x ** n × x ** m = x ** (m+n)
Rule for Division: x ** n ÷ x ** m = x ** (n-m)
Rule for Raising a Power to a Power: (x ** n) ** m = x ** (n * m)
Negative Exponents: A negative exponent indicates that the power is in the denominator: x ** -n = 1 / x ** n
Identity Rule: Any nonzero number raised to the power of zero is equal to 1, x ** 0 = 1 (x not zero).
where 0 ** 0 is explicit called out as not = 1
however:
The discussion of 0^0 is very old. Euler argues for 0^0 = 1 since a^0 = 1 for a
not equal to 0 . The controversy raged throughout the nineteenth century, but
was mainly conducted in the pages of the lesser journals: Grunert's Archiv
and Schlomilch's Zeitshrift. Consensus has recently been built around setting
the value of 0^0 = 1 .
read http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
2) 0 ** negative = x ?
If we follow the way verilog does the "/" for integers then 1 / 0 = x
feedback?
kurt
----- Begin Included Message -----
>From kurt Tue May 13 08:26:19 2003
Date: Tue, 13 May 2003 08:26:18 -0500 (CDT)
>From: Kurt Baty <kurt>
To: etf@boyd.com
Subject: Re: errata/140 and errata/192: real values vs integer values
Cc: kurt, Shalom.Bresticker@motorola.com
> From Shalom.Bresticker@motorola.com Tue May 13 08:09:55 2003
> I ran this in VCS. Results attached.
some quick editing of the log files shows that
the results are all in agreement for an integer "/"
with trucation.
should the integer results of "**" be as if
the last step (in the negetive exponent cases)
was an integer "/" with trucation?
so that 2 ** -1 = 0 not 1?
kurt
wsfdb% diff vxl_results vcs_results
1c1
< VERILOG-XL 4.00.s003 log file created May 13, 2003 07:19:19
---
> Compiler version 6.2R10; Runtime version 6.2R10; May 13 16:13 2003
14c14
< 4 / 3 as int = 1 as real = 1 = 1.333333333333333
---
> 4 / 3 as int = 1 as real = 1 = 1.33333
16,17c16,17
< 2 / 3 as int = 0 as real = 1 = 0.6666666666666666
< 1 / 3 as int = 0 as real = 0 = 0.3333333333333333
---
> 2 / 3 as int = 0 as real = 1 = 0.666667
> 1 / 3 as int = 0 as real = 0 = 0.333333
19,20c19,20
< -1 / 3 as int = 0 as real = 0 = -0.3333333333333333
< -2 / 3 as int = 0 as real = -1 = -0.6666666666666666
---
> -1 / 3 as int = 0 as real = 0 = -0.333333
> -2 / 3 as int = 0 as real = -1 = -0.666667
22c22
< -4 / 3 as int = -1 as real = -1 = -1.333333333333333
---
> -4 / 3 as int = -1 as real = -1 = -1.33333
41,44c41,44
< 4 / 0 as int = x as real = 0 = Infinity
< 3 / 0 as int = x as real = 0 = Infinity
< 2 / 0 as int = x as real = 0 = Infinity
< 1 / 0 as int = x as real = 0 = Infinity
---
> 4 / 0 as int = x as real = 0 = Inf
> 3 / 0 as int = x as real = 0 = Inf
> 2 / 0 as int = x as real = 0 = Inf
> 1 / 0 as int = x as real = 0 = Inf
46,49c46,49
< -1 / 0 as int = x as real = 0 = -Infinity
< -2 / 0 as int = x as real = 0 = -Infinity
< -3 / 0 as int = x as real = 0 = -Infinity
< -4 / 0 as int = x as real = 0 = -Infinity
---
> -1 / 0 as int = x as real = 0 = -Inf
> -2 / 0 as int = x as real = 0 = -Inf
> -3 / 0 as int = x as real = 0 = -Inf
> -4 / 0 as int = x as real = 0 = -Inf
68c68
< 4 / -3 as int = -1 as real = -1 = -1.333333333333333
---
> 4 / -3 as int = -1 as real = -1 = -1.33333
70,71c70,71
< 2 / -3 as int = 0 as real = -1 = -0.6666666666666666
< 1 / -3 as int = 0 as real = 0 = -0.3333333333333333
---
> 2 / -3 as int = 0 as real = -1 = -0.666667
> 1 / -3 as int = 0 as real = 0 = -0.333333
73,74c73,74
< -1 / -3 as int = 0 as real = 0 = 0.3333333333333333
< -2 / -3 as int = 0 as real = 1 = 0.6666666666666666
---
> -1 / -3 as int = 0 as real = 0 = 0.333333
> -2 / -3 as int = 0 as real = 1 = 0.666667
76c76
< -4 / -3 as int = 1 as real = 1 = 1.333333333333333
---
> -4 / -3 as int = 1 as real = 1 = 1.33333
86c86
< End of VERILOG-XL 4.00.s003 May 13, 2003 07:19:21
---
> V C S S i m u l a t i o n R e p o r t
wsfdb%
----- End Included Message -----
----- Begin Included Message -----
>From kurt Tue May 13 07:36:27 2003
Date: Tue, 13 May 2003 07:36:26 -0500 (CDT)
>From: Kurt Baty <kurt>
To: etf@boyd.com
Subject: errata/140 and errata/192: real values vs integer values
Cc: kurt
I am wondering if the integer "/" in verilog should be a guide,
the correct result in the "**" case?
what is the group thinking?
re:
> If you applied this methodology to integer division, what result would
> you get for 1 / 2?
>
if the real typed, answer = 0.5
and verilog converts real to integer by rounding then, 1
if integer division is truncated by definition then
integer = truncate(real typed, answer) then 0
also:
> 1. Make it inconsistent with all other operators in the Verilog language.
so I rewrote the little test program:
wsfdb% more ieee_etf_140_test.v
module ieee_etf_140_test;
`include "fphdl64_real_functions.inc"
parameter limit = 4;
integer x,y,answer,int_answer;
real x_real,answer_real;
reg [63:0] x_bits,answer_bits;
initial
begin
x_real = 0.5;
x = x_real;
$display("x = %0d = x_real =",x,x_real);
$display;
for(y=limit;y>=-limit;y=y-1) begin
for(x=limit;x>=-limit;x=x-1) begin
x_real = x;
// x_bits = $realtobits(x_real);
// answer_bits = pow(x_bits,y);
// answer_real = $bitstoreal(answer_bits);
answer_real = x_real / y;
int_answer = x / y;
answer = answer_real;
// $display("%0d ** %0d = %0d = ",x,y,answer,answer_real);
$display("%0d / %0d as int = %0d as real = %0d = ",x,y,int_answer,answer,answer_real);
end
end
end
endmodule
wsfdb%
results:
wsfdb% verilog ieee_etf_140_test.v
VERILOG-XL 4.00.s003 May 13, 2003 07:19:19
Copyright (c) 1995 Cadence Design Systems, Inc. All Rights Reserved.
Unpublished -- rights reserved under the copyright laws of the United States.
Copyright (c) 1995 UNIX Systems Laboratories, Inc. Reproduced with Permission.
THIS SOFTWARE AND ON-LINE DOCUMENTATION CONTAIN CONFIDENTIAL INFORMATION
AND TRADE SECRETS OF CADENCE DESIGN SYSTEMS, INC. USE, DISCLOSURE, OR
REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF
CADENCE DESIGN SYSTEMS, INC.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013 or
subparagraphs (c)(1) and (2) of Commercial Computer Software -- Restricted
Rights at 48 CFR 52.227-19, as applicable.
Cadence Design Systems, Inc.
555 River Oaks Parkway
San Jose, California 95134
For technical assistance please contact the Cadence Response Center at
1-877-CDS-4911 or send email to support@cadence.com
For more information on Cadence's Verilog-XL product line send email to
talkv@cadence.com
Compiling source file "ieee_etf_140_test.v"
Compiling included source file "fphdl64_real_functions.inc"
Compiling included source file "fphdl64_real_functions_base.inc"
Continuing compilation of source file "fphdl64_real_functions.inc"
Continuing compilation of source file "ieee_etf_140_test.v"
Highest level modules:
ieee_etf_140_test
x = 1 = x_real =0.5
4 / 4 as int = 1 as real = 1 = 1
3 / 4 as int = 0 as real = 1 = 0.75
2 / 4 as int = 0 as real = 1 = 0.5
1 / 4 as int = 0 as real = 0 = 0.25
0 / 4 as int = 0 as real = 0 = 0
-1 / 4 as int = 0 as real = 0 = -0.25
-2 / 4 as int = 0 as real = -1 = -0.5
-3 / 4 as int = 0 as real = -1 = -0.75
-4 / 4 as int = -1 as real = -1 = -1
4 / 3 as int = 1 as real = 1 = 1.333333333333333
3 / 3 as int = 1 as real = 1 = 1
2 / 3 as int = 0 as real = 1 = 0.6666666666666666
1 / 3 as int = 0 as real = 0 = 0.3333333333333333
0 / 3 as int = 0 as real = 0 = 0
-1 / 3 as int = 0 as real = 0 = -0.3333333333333333
-2 / 3 as int = 0 as real = -1 = -0.6666666666666666
-3 / 3 as int = -1 as real = -1 = -1
-4 / 3 as int = -1 as real = -1 = -1.333333333333333
4 / 2 as int = 2 as real = 2 = 2
3 / 2 as int = 1 as real = 2 = 1.5
2 / 2 as int = 1 as real = 1 = 1
1 / 2 as int = 0 as real = 1 = 0.5
0 / 2 as int = 0 as real = 0 = 0
-1 / 2 as int = 0 as real = -1 = -0.5
-2 / 2 as int = -1 as real = -1 = -1
-3 / 2 as int = -1 as real = -2 = -1.5
-4 / 2 as int = -2 as real = -2 = -2
4 / 1 as int = 4 as real = 4 = 4
3 / 1 as int = 3 as real = 3 = 3
2 / 1 as int = 2 as real = 2 = 2
1 / 1 as int = 1 as real = 1 = 1
0 / 1 as int = 0 as real = 0 = 0
-1 / 1 as int = -1 as real = -1 = -1
-2 / 1 as int = -2 as real = -2 = -2
-3 / 1 as int = -3 as real = -3 = -3
-4 / 1 as int = -4 as real = -4 = -4
4 / 0 as int = x as real = 0 = Infinity
3 / 0 as int = x as real = 0 = Infinity
2 / 0 as int = x as real = 0 = Infinity
1 / 0 as int = x as real = 0 = Infinity
0 / 0 as int = x as real = 0 = NaN
-1 / 0 as int = x as real = 0 = -Infinity
-2 / 0 as int = x as real = 0 = -Infinity
-3 / 0 as int = x as real = 0 = -Infinity
-4 / 0 as int = x as real = 0 = -Infinity
4 / -1 as int = -4 as real = -4 = -4
3 / -1 as int = -3 as real = -3 = -3
2 / -1 as int = -2 as real = -2 = -2
1 / -1 as int = -1 as real = -1 = -1
0 / -1 as int = 0 as real = 0 = -0
-1 / -1 as int = 1 as real = 1 = 1
-2 / -1 as int = 2 as real = 2 = 2
-3 / -1 as int = 3 as real = 3 = 3
-4 / -1 as int = 4 as real = 4 = 4
4 / -2 as int = -2 as real = -2 = -2
3 / -2 as int = -1 as real = -2 = -1.5
2 / -2 as int = -1 as real = -1 = -1
1 / -2 as int = 0 as real = -1 = -0.5
0 / -2 as int = 0 as real = 0 = -0
-1 / -2 as int = 0 as real = 1 = 0.5
-2 / -2 as int = 1 as real = 1 = 1
-3 / -2 as int = 1 as real = 2 = 1.5
-4 / -2 as int = 2 as real = 2 = 2
4 / -3 as int = -1 as real = -1 = -1.333333333333333
3 / -3 as int = -1 as real = -1 = -1
2 / -3 as int = 0 as real = -1 = -0.6666666666666666
1 / -3 as int = 0 as real = 0 = -0.3333333333333333
0 / -3 as int = 0 as real = 0 = -0
-1 / -3 as int = 0 as real = 0 = 0.3333333333333333
-2 / -3 as int = 0 as real = 1 = 0.6666666666666666
-3 / -3 as int = 1 as real = 1 = 1
-4 / -3 as int = 1 as real = 1 = 1.333333333333333
4 / -4 as int = -1 as real = -1 = -1
3 / -4 as int = 0 as real = -1 = -0.75
2 / -4 as int = 0 as real = -1 = -0.5
1 / -4 as int = 0 as real = 0 = -0.25
0 / -4 as int = 0 as real = 0 = -0
-1 / -4 as int = 0 as real = 0 = 0.25
-2 / -4 as int = 0 as real = 1 = 0.5
-3 / -4 as int = 0 as real = 1 = 0.75
-4 / -4 as int = 1 as real = 1 = 1
0 simulation events (use +profile or +listcounts option to count)
CPU time: 0.3 secs to compile + 0.2 secs to link + 0.1 secs in simulation
End of VERILOG-XL 4.00.s003 May 13, 2003 07:19:21
wsfdb%
> >From: Steven Sharp <sharp@cadence.com>
> > The advantage of allowing real values for ranges is that it allows the
> > power operator to always return a real, which simplifies implementation.
>
> I suppose that making the power operator always return a real might save
> some time for a few simulator implementors. It is hardly a convincing
> argument. We could make the same argument about eliminating integer
> addition, subtraction, multiplication, division and comparison operations,
> and just producing reals for those too. I don't think users would be
> happy about that.
>
> Making the power operator produce reals from integer inputs would
> 1. Make it inconsistent with all other operators in the Verilog language.
> 2. Make it impossible to get a correct value for integral results larger
> than 56 bits.
> 3. Call for the use of expensive floating point operations instead of
> cheaper integer operations.
> 4. Make synthesis of any expression with a power operator problematic.
>
> Steven Sharp
> sharp@cadence.com
>
> From drm@xilinx.com Mon May 5 14:04:03 2003
> Date: Mon, 05 May 2003 13:11:00 -0600
> From: Dennis Marsa <drm@xilinx.com>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Kurt Baty <kurt@wsfdb.wsfdb.com>
> Cc: etf@boyd.com
> Subject: Re: 1364 issue 140 and negative exponents
> Content-Transfer-Encoding: 7bit
> X-BigFish: v
>
> Kurt Baty wrote:
> >
> > Precedence: bulk
> >
> > > From drm@xilinx.com Mon May 5 13:41:55 2003
> > >
> > > > 2 ** -1 = 1 = 0.5
> > > > -2 ** -1 = -1 = -0.5
> > >
> >
> > please note that:
> >
> > initial
> > begin
> > x_real = 0.5;
> > x = x_real;
> > $display("x = %0d = x_real =",x,x_real);
> > $display;
> > for(y=limit;y>=-limit;y=y-1) begin
> >
> > displays:
> >
> > Highest level modules:
> > ieee_etf_140_test
> >
> > x = 1 = x_real =0.5
>
> I am not sure what you are trying to convey with that
> first $display statement before the main loop in your
> test program.
>
> Are you trying to show that reals are being rounded
> to nearest as opposed to being rounded towards zero?
>
> I had figured the results
>
> 2 ** -1 = 1
> -2 ** -1 = -1
>
> were a result of rounding to nearest.
>
> But, my specific question is, are these the results you are
> advocating for these particular operands?
>
> >From James' email today and from the discussion this morning, I had
> thought the desired results would be:
>
> 2 ** -1 = 0
> -2 ** -1 = 0
>
> Dennis
>
>
> From kurt Mon May 5 14:55:03 2003
> Date: Mon, 5 May 2003 14:55:02 -0500 (CDT)
> From: Kurt Baty <kurt>
> To: drm@xilinx.com
> Subject: Re: 1364 issue 140 and negative exponents
> Cc: kurt
>
> > I am not sure what you are trying to convey with that
> > first $display statement before the main loop in your
> > test program.
>
> Yes, I to noticed the
>
> > 2 ** -1 = 1
> > -2 ** -1 = -1
>
> rounding cases so the extra display statement shows that
> verilog-XL does in fact round the real value 0.5
> to the integer value 1
>
> >
> > Are you trying to show that reals are being rounded
> > to nearest as opposed to being rounded towards zero?
> >
> > I had figured the results
> >
> > 2 ** -1 = 1
> > -2 ** -1 = -1
> >
> > were a result of rounding to nearest.
> >
>
> Actually, this rounding is not "round nearest"
> this is "round up" (I say "round away-from-zero"
> so as to not be confused in negative numbers).
> 0.5 would round to 0 in "round nearest".
>
> > But, my specific question is, are these the results you are
> > advocating for these particular operands?
>
> yes, to took x ** y where x,y are integers and converted
> x (integer -> real -> bits(ieee 64 floating point))
>
> did a x_bits ** y using the pow function
>
> function [63:0] pow; // l**r, where l is fp64 and r is integer
>
> converted answer_bits (bits(ieee 64 floating point) -> real -> integer)
>
> and I make the claim that this is the most "math correct answer".
>
> >
> > >From James' email today and from the discussion this morning, I had
> > thought the desired results would be:
> >
> > 2 ** -1 = 0
> > -2 ** -1 = 0
> >
>
> I too was taken in!! (fished-in?!)
>
> kurt
>
>
> > Kurt Baty wrote:
> > >
> > > Precedence: bulk
> > >
> > > > From drm@xilinx.com Mon May 5 13:41:55 2003
> > > >
> > > > > 2 ** -1 = 1 = 0.5
> > > > > -2 ** -1 = -1 = -0.5
> > > >
> > >
> > > please note that:
> > >
> > > initial
> > > begin
> > > x_real = 0.5;
> > > x = x_real;
> > > $display("x = %0d = x_real =",x,x_real);
> > > $display;
> > > for(y=limit;y>=-limit;y=y-1) begin
> > >
> > > displays:
> > >
> > > Highest level modules:
> > > ieee_etf_140_test
> > >
>
>
> From owner-etf@boyd.com Mon May 5 15:12:57 2003
> X-Authentication-Warning: max.boyd.com: majordomo set sender to owner-etf@boyd.com using -f
> Date: Mon, 5 May 2003 15:12:02 -0500 (CDT)
> From: Kurt Baty <kurt@wsfdb.wsfdb.com>
> To: etf@boyd.com
> Subject: Re: 1364 issue 140 and negative exponents
> Cc: kurt@wsfdb.wsfdb.com
>
> Precedence: bulk
>
> x ** y where x, y are integers:
>
> x is positive zero negative
> ---------------------------------------------------
> y is
>
> positive x ** y 0 x ** y
>
> zero 1 0 1
>
> negative x = 1 -> 1 0 x = -1 and
> x = 2 and y is odd -> -1
> y = -1 -> 1 x = -1 and
> else 0 y is even -> 1
> x = -2 and
> y = -1 -> -1
> else 0
>
>
> maybe someone could run the same thing in C,
> and maybe VCS also?
>
>
> kurt
>
>
>
> From drm@xilinx.com Mon May 5 15:36:01 2003
> Date: Mon, 05 May 2003 14:43:07 -0600
> From: Dennis Marsa <drm@xilinx.com>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Kurt Baty <kurt@wsfdb.wsfdb.com>
> Cc: etf@boyd.com
> Subject: Re: 1364 issue 140 and negative exponents
> Content-Transfer-Encoding: 7bit
> X-BigFish: v
>
> Kurt Baty wrote:
> >
> > > I had figured the results
> > >
> > > 2 ** -1 = 1
> > > -2 ** -1 = -1
> > >
> > > were a result of rounding to nearest.
> > >
> >
> > Actually, this rounding is not "round nearest"
> > this is "round up" (I say "round away-from-zero"
> > so as to not be confused in negative numbers).
> > 0.5 would round to 0 in "round nearest".
>
> Then I'm confused. If the rounding was "away from zero",
> then wouldn't all of the combinations whose real result
> is in the range (0.0,1.0) round to an integer result of 1,
> and likewise results in the range (-1.0,0.0) would round to
> a integer result of -1? Your test program results don't
> indicate this.
>
> In case it isn't already obvious, I am not a floating point
> expert.
>
> > > But, my specific question is, are these the results you are
> > > advocating for these particular operands?
> >
> > yes, to took x ** y where x,y are integers and converted
> > x (integer -> real -> bits(ieee 64 floating point))
> >
> > did a x_bits ** y using the pow function
> >
> > function [63:0] pow; // l**r, where l is fp64 and r is integer
> >
> > converted answer_bits (bits(ieee 64 floating point) -> real -> integer)
> >
> > and I make the claim that this is the most "math correct answer".
>
> If you applied this methodology to integer division, what result would
> you get for 1 / 2?
>
> Dennis
>
>
> From kurt Mon May 5 16:01:57 2003
> Date: Mon, 5 May 2003 16:01:56 -0500 (CDT)
> From: Kurt Baty <kurt>
> To: etf@boyd.com
> Subject: Re: 1364 issue 140 and negative exponents
> Cc: kurt
>
> > >
> > > > I had figured the results
> > > >
> > > > 2 ** -1 = 1
> > > > -2 ** -1 = -1
> > > >
> > > > were a result of rounding to nearest.
> > > >
> > >
> > > Actually, this rounding is not "round nearest"
> > > this is "round up" (I say "round away-from-zero"
> > > so as to not be confused in negative numbers).
> > > 0.5 would round to 0 in "round nearest".
> >
> > Then I'm confused. If the rounding was "away from zero",
> > then wouldn't all of the combinations whose real result
> > is in the range (0.0,1.0) round to an integer result of 1,
> > and likewise results in the range (-1.0,0.0) would round to
> > a integer result of -1? Your test program results don't
> > indicate this.
>
> some functions:
>
> truncate -> real result in the range (0.0 <= fract < 1.0)
> goes to 0
> ceiling -> real result in the range (0.0 < fract <= 1.0)
> goes to 1
> round -> real result in the range (0.0 < fract < 0.50)
> goes to 0
> real result in the range (0.5 < fract <= 1.0)
> goes to 1
> real result is exactly (fract = 0.5)
> case(rounding mode)
> up: goes to 1 (round "away from zero")
> down: goes to 0 (round "towards zero")
> nearest: if(low bit of abs(integer) part is:
> zero: goes to 0
> one: goes to 1
>
> does this help?
>
> >
> > In case it isn't already obvious, I am not a floating point
> > expert.
>
> I must be.
>
> >
> > > > But, my specific question is, are these the results you are
> > > > advocating for these particular operands?
> > >
> > > yes, to took x ** y where x,y are integers and converted
> > > x (integer -> real -> bits(ieee 64 floating point))
> > >
> > > did a x_bits ** y using the pow function
> > >
> > > function [63:0] pow; // l**r, where l is fp64 and r is integer
> > >
> > > converted answer_bits (bits(ieee 64 floating point) -> real -> integer)
> > >
> > > and I make the claim that this is the most "math correct answer".
> >
> > If you applied this methodology to integer division, what result would
> > you get for 1 / 2?
> >
>
> if the real typed, answer = 0.5
> and verilog converts real to integer by rounding then, 1
>
> if integer division is truncated by definition then
> integer = truncate(real typed, answer) then 0
>
>
> kurt
>
>
>
> From kurt Mon May 5 16:32:47 2003
> Date: Mon, 5 May 2003 16:32:46 -0500 (CDT)
> From: Kurt Baty <kurt>
> To: etf@boyd.com
> Subject: Re: 1364 issue 140 and negative exponents
> Cc: kurt
>
> > >
> > > In case it isn't already obvious, I am not a floating point
> > > expert.
> >
> > I must be.
>
>
> In 1997 I was luck enough to hear Dr. Leo Mildenberg talk at Havard University
> he was billed as the "world's greatest expert on ancient greek coins".
> In the Q&A at the end of his talk, he was asked how he got to be
> the "world's greatest expert", his answer was "All the real experts have died!"
> Dr. Mildenberg passed away in 2001.
>
> He may have figured out where all experts come from!
>
>
> kurt
>
>
>
----- End Included Message -----
----- End Included Message -----
----- End Included Message -----
- Next message: etf@boyd.com: "errata/140: PROPOSAL - Section 4.1.5: Definition of power operator result type"
- Previous message: Charles Dawson: "[Fwd: 237 issue]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Mon May 19 2003 - 11:51:54 PDT
and
sponsored by Boyd Technology, Inc.