1. Forum
  2. Usenet
  3. LINUX.DEBIAN.PORTS.MIPS

  • NA and NaN representation on mips64el

    From Rafael =?utf-8?Q?Laboissi=C3=A8re?=@21:1/5 to All on Mon May 12 18:40:01 2025
    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:

    ***** assert (degrees2dm (NA), [NA NA]) !!!!! test failed ASSERT errors for: assert (degrees2dm (NA), [NA,NA])

    Location | Observed | Expected | Reason
    (1) NaN NA 'NA' mismatch
    (2) NaN NA 'NA' mismatch

    It seems to be a problem related to how floating point NA and NaN are represented.

    Strangely, I cannot reproduce this problem. I built the package manually
    on a mips64el porterbox using schroot and everything worked fine.

    We discussed a similar issue on the upstream bug tracking system for
    Octave back in 2021: https://savannah.gnu.org/bugs/?59830

    One of the upstream authors seems to suggest that this problem is related
    to cross-compiling.

    Do you know if there is a way to work around this?

    Best,

    Rafael Laboissière

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John W. Eaton@21:1/5 to YunQiang Su on Tue May 13 06:20:01 2025
    On 5/12/25 8:49 PM, YunQiang Su wrote:

    I guess that octave uses sNaN as NA?

    No, it uses a specific NaN value to represent NA that aims to be
    compatible with the bit pattern used by R.

    What does R do for setting (or testing) the value of NA on this platform?

    jwe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rafael =?utf-8?Q?Laboissi=C3=A8re?=@21:1/5 to All on Tue May 13 09:50:02 2025
    * YunQiang Su <wzssyqa@gmail.com> [2025-05-13 08:49]:

    Rafael Laboissière <rafael@debian.org> 于2025年5月13日周二 00:30写道：

    […]

    It seems to be a problem related to how floating point NA and NaN are
    represented.

    Strangely, I cannot reproduce this problem. I built the package manually
    on a mips64el porterbox using schroot and everything worked fine.

    I see. The problem is that the machine (mipsel-osuosl-03.debian.org) is Loongson 3A4000. The problem is that MIPS swap the encodings of sNaN
    and qNaN since MIPSr5.

    I guess that octave uses sNaN as NA? We have no good solution for it.
    We have meet some other packages with this case. Let's just ask the
    help from DSA to pin this package on non-3A4000 machines.

    Could you please tell me how to make do such a request?

    Best,

    Rafael Laboissière

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aurelien Jarno@21:1/5 to All on Fri May 16 00:00:01 2025
    Hi,

    On 2025-05-13 09:24, Rafael Laboissière wrote:
    * YunQiang Su <wzssyqa@gmail.com> [2025-05-13 08:49]:

    Rafael Laboissière <rafael@debian.org> 于2025年5月13日周二 00:30写道：

    […]

    It seems to be a problem related to how floating point NA and NaN
    are represented.

    Strangely, I cannot reproduce this problem. I built the package
    manually on a mips64el porterbox using schroot and everything worked fine.

    I see. The problem is that the machine (mipsel-osuosl-03.debian.org) is Loongson 3A4000. The problem is that MIPS swap the encodings of sNaN and qNaN since MIPSr5.

    I guess that octave uses sNaN as NA? We have no good solution for it. We have meet some other packages with this case. Let's just ask the help
    from DSA to pin this package on non-3A4000 machines.

    Could you please tell me how to make do such a request?

    You should contact the wanna-build team [1], but the possibility to
    block a package on a specific machine is being phased-out with the
    switch to pybuildd.

    Ideally you should disabled the test on nan 2008 machine, for instance by looking at "nan_2008" in /proc/cpuinfo (as opposed to "nan_legacy").

    Regards
    Aurelien

    [1] debian-wb-team@lists.debian.org

    --
    Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rafael =?utf-8?Q?Laboissi=C3=A8re?=@21:1/5 to All on Fri May 16 07:50:01 2025
    * James Cloos <cloos@jhcloos.com> [2025-05-15 20:15]:

    some years ago (how time flies) someone pushed a patch for R (upstream)
    to stop using nan-with-payload for na. it looks like octave also needs
    such a change for architectures which support only canonical nans.

    such as riscv. (and mips?)

    the respective licenses (2or3 -> 3) would permit any octave patch to
    borrow from how R now handles na.

    I am not familiar with NaN/NA coding in either R or Octave, so I
    apologise if my comment below is irrelevant.

    I found this explanation of the internal representation of NA in R: https://stackoverflow.com/questions/70471859/difference-between-na-real-and-nan/70472081#70472081

    It seems that R is still using NaN-with-payload to represent NA
    internally: https://github.com/wch/r-source/blob/2016493d7e73252d5e0cdf302ea4ba9e814b392f/src/main/arithmetic.c#L90

    @JimC, could you please provide more information about the patch you
    mentioned?

    Best,

    Rafael

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Cloos@21:1/5 to All on Fri May 16 16:00:01 2025
    "RL" == Rafael Laboissire <rafael@debian.org> writes:

    could you please provide more information about the patch you mentioned?

    i looked at the src (svn trunk), and indeed they continue to use a nan
    with a payload of 1954.

    but i'm certain that i recall the patch being pushed.

    perhaps it was on a branch?

    a search thru their mailing list archives would answer it. (the
    mailing list is where i read about it.) but i lack access right
    now to my archives from back then.

    -JimC
    --
    James Cloos <cloos@jhcloos.com>
    OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Cloos@21:1/5 to All on Sat May 17 01:20:02 2025
    i took a look at all of the r-devel archves.

    it is clear my memory about separation NA from nan was not about R.

    although those archives do talk about avoiding sending NA or nan to BLAS.
    (i found a related post from me back in 2010...)

    i wonder whether the NA discussion i recalled may have been about julia?
    if so it was before they dropped mainglists in favour of discourse ☹.

    -JimC
    --
    James Cloos <cloos@jhcloos.com>
    OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rafael =?utf-8?Q?Laboissi=C3=A8re?=@21:1/5 to All on Sat May 17 06:40:01 2025
    Hi James,

    * James Cloos <cloos@jhcloos.com> [2025-05-16 19:15]:

    i took a look at all of the r-devel archves.

    it is clear my memory about separation NA from nan was not about R.

    although those archives do talk about avoiding sending NA or nan to BLAS.
    (i found a related post from me back in 2010...)

    i wonder whether the NA discussion i recalled may have been about julia?
    if so it was before they dropped mainglists in favour of discourse ☹.

    Thanks for this clarification.

    Best,

    Rafael

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)