Mirror of forum.nim-lang.org

13538 :: Weird behavior with math.pow()

• kitkat24 (orginal) [2025-12-04T03:06:39+01:00] view original

  So, I was working on advent of code and ran into a weird behavior that I am still puzzled by. I don't want to jump to calling it a bug, but can someone explain what's going on here with powers of 10 > 10e9 using the pow proc from math? At first I thought maybe the default float literal type was float32 (no idea why that would be the case), but I added the pow10_4 test to confirm that wasn't the issue.

  I also thought maybe this was me simply using the language as it's not intended after reading https://status-im.github.io/nim-style-guide/language.integers.html, but then I added the pow10_5 case and am even more confused with why it's wrapping to a negative value there.

  Minimum working example

  
  import std/[math, sequtils, sugar]
  
  const pow10_1 = toSeq(0..11).map(x => uint64(pow(10.0, float64(x))))
  const pow10_2 = toSeq(0..11).map(x => uint64(10) ^ x)
  const pow10_3 = toSeq(0..11).map(x => pow(10.0, float64(x)))
  const pow10_4 = toSeq(0..11).map(x => uint64(toBiggestInt(pow(float64(10.0), float64(x)))))
  const pow10_5 = toSeq(0..11).map(x => toBiggestInt(pow(10.0, float64(x))))
  
  echo pow10_1
  echo pow10_2
  echo pow10_3
  echo pow10_4
  echo pow10_5
  Run

  Yields:

  
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 18446744071562067968, 18446744071562067968]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000]
  @[1.0, 10.0, 100.0, 1000.0, 10000.0, 100000.0, 1000000.0, 10000000.0, 100000000.0, 1000000000.0, 10000000000.0, 100000000000.0]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 18446744071562067968, 18446744071562067968]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, -2147483648, -2147483648]
  Run

---

• janAkali (orginal) [2025-12-04T08:27:31+01:00] view original

  Your output is very different from mine and the playground:

  
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000]
  @[1.0, 10.0, 100.0, 1000.0, 10000.0, 100000.0, 1000000.0, 10000000.0, 100000000.0, 1000000000.0, 10000000000.0, 100000000000.0]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000]
  @[1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000]
  Run

  https://play.nim-lang.org/#pasty=TFziCTwr

  Can you share your Nim configuration and OS info? Maybe you use some non-standard flags for performance?

---

• PMunch (orginal) [2025-12-04T10:57:36+01:00] view original

  The playground still runs 2.2.0, so it might even be a regression

---

• dlesnoff (orginal) [2025-12-04T14:50:29+01:00] view original

  Could you give the output of ldd on the binary as well? The error might come from an incorrect libc, musl or some library. The output is fine with nim 2.2.6, and libc.so.6 for me.

---

• kitkat24 (orginal) [2025-12-05T05:09:35+01:00] view original

  Yeah I used the ^ version for the pow10_2 example (and the code I ended up using for my own purposes).

  I'm on Windows rn, here's the ldd output from mingw

  
  $ ldd bin/pow10.exe
          ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd27120000)
          ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x774b0000)
          wow64.dll => /c/WINDOWS/System32/wow64.dll (0x7ffd25b10000)
          wow64base.dll => /c/WINDOWS/System32/wow64base.dll (0x7ffd24f90000)
          wow64win.dll => /c/WINDOWS/System32/wow64win.dll (0x7ffd26e20000)
          wow64con.dll => /c/WINDOWS/System32/wow64con.dll (0x7ffd258d0000)
  
  $ nim --version
  Nim Compiler Version 2.2.4 [Windows: i386]
  Compiled at 2025-04-22
  Copyright (c) 2006-2025 by Andreas Rumpf
  
  active boot switches: -d:release
  Run

---