1. Forum
  2. USENET
  3. comp.arch

  • Re: Tonights Tradeoff - NaN boxed precisions

    From Thomas Koenig@tkoenig@netcologne.de to comp.arch on Sat Nov 29 19:11:30 2025
    From Newsgroup: comp.arch

    Kent Dickey <kegs@provalid.com> schrieb:

    This is my point: I don't see a great way to encode the first NaN, which
    is why I propose not making that a goal. You're not getting the first
    NaN in any case even if you try to do so in hardware, since the order of operations is a fragile thing that's hard to control unless you write assembly code, or the most tedious source code imaginable.

    Using Fortran, parentheses have to be honored. If you write

    A = (B + C) + (D + E)

    then B + C and D + E have to be calculated before the total sum.
    If you write

    A = B + (C + (D + E))

    then you prescribe the order completetely.

    I can imagine source code that is much more tedious than this :-)
    --
    This USENET posting was made without artificial intelligence,
    artificial impertinence, artificial arrogance, artificial stupidity,
    artificial flavorings or artificial colorants.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From EricP@ThatWouldBeTelling@thevillage.com to comp.arch on Sat Nov 29 15:08:05 2025
    From Newsgroup: comp.arch

    Thomas Koenig wrote:
    Kent Dickey <kegs@provalid.com> schrieb:

    This is my point: I don't see a great way to encode the first NaN, which
    is why I propose not making that a goal. You're not getting the first
    NaN in any case even if you try to do so in hardware, since the order of
    operations is a fragile thing that's hard to control unless you write
    assembly code, or the most tedious source code imaginable.

    Using Fortran, parentheses have to be honored. If you write

    A = (B + C) + (D + E)

    then B + C and D + E have to be calculated before the total sum.
    If you write

    A = B + (C + (D + E))

    then you prescribe the order completetely.

    I can imagine source code that is much more tedious than this :-)

    That doesn't control which variable is assigned to each source operand.
    If both operands were Nan's and the two-Nan-rule was "always take src1"
    then the choice of which to propagate would still be non-deterministic.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From MitchAlsup@user5857@newsgrouper.org.invalid to comp.arch on Sat Nov 29 22:07:04 2025
    From Newsgroup: comp.arch


    EricP <ThatWouldBeTelling@thevillage.com> posted:

    Thomas Koenig wrote:
    Kent Dickey <kegs@provalid.com> schrieb:

    This is my point: I don't see a great way to encode the first NaN, which >> is why I propose not making that a goal. You're not getting the first
    NaN in any case even if you try to do so in hardware, since the order of >> operations is a fragile thing that's hard to control unless you write
    assembly code, or the most tedious source code imaginable.

    Using Fortran, parentheses have to be honored. If you write

    A = (B + C) + (D + E)

    then B + C and D + E have to be calculated before the total sum.
    If you write

    A = B + (C + (D + E))

    then you prescribe the order completetely.

    I can imagine source code that is much more tedious than this :-)

    That doesn't control which variable is assigned to each source operand.
    If both operands were Nan's and the two-Nan-rule was "always take src1"
    then the choice of which to propagate would still be non-deterministic.


    In addition, the compiler is still allowed to perform the FORTRAN
    equation as::

    A = (C + B) + (E + D)

    instead of the way expressed in ASCII.

    Parenthesis order calculations not operands.
    --- Synchronet 3.21a-Linux NewsLink 1.2