APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Michael Gottesman
IEEE-754R defines a normal floating point number as:

2.1.38 normal number: For a particular format, a finite non-zero floating-point number with magnitude greater than or equal to a minimum bemin value, where b is the radix. Normal numbers can use the full precision available in a format. In this standard, zero is neither normal nor subnormal. 

This implies that a denormal is not a normal number.

In contrast, the current implementation of isNormal in APFloat does treat denormal numbers as normal numbers breaking this definition. This is not just a predicate that has a name that differs from IEEE-754R (which I am fine with), but is an actual name collision with IEEE-754R with a different semantic meaning. This could easily lead to programmer error and thus in my humble opinion is worth the hassle/trouble of fixing.

Does anyone have any thoughts/suggestions/objections with my renaming isNormal => isFiniteNonZero (and making all the relevant changes in the relevant codebases) and isIEEENormal => isNormal?

Awaiting the flames,
Michael



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Stephen Canon
I think it’s a splendid idea (but you already knew that).

On Jun 18, 2013, at 6:45 PM, Michael Gottesman <[hidden email]> wrote:

IEEE-754R defines a normal floating point number as:

2.1.38 normal number: For a particular format, a finite non-zero floating-point number with magnitude greater than or equal to a minimum bemin value, where b is the radix. Normal numbers can use the full precision available in a format. In this standard, zero is neither normal nor subnormal. 

This implies that a denormal is not a normal number.

In contrast, the current implementation of isNormal in APFloat does treat denormal numbers as normal numbers breaking this definition. This is not just a predicate that has a name that differs from IEEE-754R (which I am fine with), but is an actual name collision with IEEE-754R with a different semantic meaning. This could easily lead to programmer error and thus in my humble opinion is worth the hassle/trouble of fixing.

Does anyone have any thoughts/suggestions/objections with my renaming isNormal => isFiniteNonZero (and making all the relevant changes in the relevant codebases) and isIEEENormal => isNormal?

Awaiting the flames,
Michael


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Shuxin Yang
I would give you 20 thumb up if I could.

At the time I add the isDenormal() , I realized the name "isNormal()" need some change to reflect its real meaning,
but I was reluctant to make that change, partially because I was a big llvm newbie at that time.
(now, I'm just slightly smaller nut than I was :-)).

To test a real "normal" FP, I wrote the code this way "isNormal() && !isDenorma()".
With your change, this condition can be simplified.

On 6/18/13 4:21 PM, Stephen Canon wrote:
I think it’s a splendid idea (but you already knew that).

On Jun 18, 2013, at 6:45 PM, Michael Gottesman <[hidden email]> wrote:

IEEE-754R defines a normal floating point number as:

2.1.38 normal number: For a particular format, a finite non-zero floating-point number with magnitude greater than or equal to a minimum bemin value, where b is the radix. Normal numbers can use the full precision available in a format. In this standard, zero is neither normal nor subnormal. 

This implies that a denormal is not a normal number.

In contrast, the current implementation of isNormal in APFloat does treat denormal numbers as normal numbers breaking this definition. This is not just a predicate that has a name that differs from IEEE-754R (which I am fine with), but is an actual name collision with IEEE-754R with a different semantic meaning. This could easily lead to programmer error and thus in my humble opinion is worth the hassle/trouble of fixing.

Does anyone have any thoughts/suggestions/objections with my renaming isNormal => isFiniteNonZero (and making all the relevant changes in the relevant codebases) and isIEEENormal => isNormal?

Awaiting the flames,
Michael



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Eric Christopher
In reply to this post by Michael Gottesman
LGTM (and you've already gotten other positive feedback as well).

-eric

On Tue, Jun 18, 2013 at 3:45 PM, Michael Gottesman <[hidden email]> wrote:

> IEEE-754R defines a normal floating point number as:
>
> 2.1.38 normal number: For a particular format, a finite non-zero
> floating-point number with magnitude greater than or equal to a minimum
> bemin value, where b is the radix. Normal numbers can use the full precision
> available in a format. In this standard, zero is neither normal nor
> subnormal.
>
> This implies that a denormal is not a normal number.
>
> In contrast, the current implementation of isNormal in APFloat does treat
> denormal numbers as normal numbers breaking this definition. This is not
> just a predicate that has a name that differs from IEEE-754R (which I am
> fine with), but is an actual name collision with IEEE-754R with a different
> semantic meaning. This could easily lead to programmer error and thus in my
> humble opinion is worth the hassle/trouble of fixing.
>
> Does anyone have any thoughts/suggestions/objections with my renaming
> isNormal => isFiniteNonZero (and making all the relevant changes in the
> relevant codebases) and isIEEENormal => isNormal?
>
> Awaiting the flames,
> Michael
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Michael Gottesman
It seems like there is a consensus that this is a good change. Any nay sayers?

Michael

On Jun 18, 2013, at 5:07 PM, Eric Christopher <[hidden email]> wrote:

LGTM (and you've already gotten other positive feedback as well).

-eric

On Tue, Jun 18, 2013 at 3:45 PM, Michael Gottesman <[hidden email]> wrote:
IEEE-754R defines a normal floating point number as:

2.1.38 normal number: For a particular format, a finite non-zero
floating-point number with magnitude greater than or equal to a minimum
bemin value, where b is the radix. Normal numbers can use the full precision
available in a format. In this standard, zero is neither normal nor
subnormal.

This implies that a denormal is not a normal number.

In contrast, the current implementation of isNormal in APFloat does treat
denormal numbers as normal numbers breaking this definition. This is not
just a predicate that has a name that differs from IEEE-754R (which I am
fine with), but is an actual name collision with IEEE-754R with a different
semantic meaning. This could easily lead to programmer error and thus in my
humble opinion is worth the hassle/trouble of fixing.

Does anyone have any thoughts/suggestions/objections with my renaming
isNormal => isFiniteNonZero (and making all the relevant changes in the
relevant codebases) and isIEEENormal => isNormal?

Awaiting the flames,
Michael



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

Sean Silva



On Tue, Jun 18, 2013 at 6:47 PM, Michael Gottesman <[hidden email]> wrote:
It seems like there is a consensus that this is a good change. Any nay sayers?


Dude, go for it.

-- Sean Silva 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev