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: