Re: NA and NaN representation on mips64el

[Rafael Laboissière <rafael@debian.org>]

* Aurelien Jarno <aurel32@debian.org> [2025-05-15 23:47]:

> On 2025-05-13 08:49, YunQiang Su wrote:
> > Rafael Laboissière <rafael@debian.org> 于2025年5月13日周二 00:30写道：
> > > Dear mips porters,
> > >
> > > I need some advice on an FTBFS problem with package octave mapping on the 
> > > mips64el architecture. Here is the log for the failed build:
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=octave-mapping&arch=mips64el&ver=1.4.3-1&stamp=1746884958&raw=0
> > >
> > > It also FTBFS on riscv64, for the same reason: the unit tests for 
> > > degrees2dm and degrees2dms fail with this error:
> >
> > Seems strange...
>
> From what I understood, "NA" in Octave is a specific qNaN with a 
> non-default mantissa. On RISC-V, by design, a floating point operation 
> that results in a qNaN generates a new default qNaN instead of picking up 
> on of the input operand. Therefore it is somehow expected that 
> degrees2dm(NA) returns [NaN, NaN].

Right. On an amd64 system, I get:

    $ echo "NA + 1" | R -q --no-save
    > NA + 1
    [1] NA

    $ echo "NA + 1" | octave-cli -q
    ans =  NA

On a riscv64 system, I get:

    $ echo "NA + 1" | R -q --no-save
    > NA + 1
    [1] NaN

    $ echo "NA + 1" | octave-cli -q
    ans =  NaN

Best,

Rafael Laboissière