[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NA and NaN representation on mips64el



* 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


Reply to: