Mirror of forum.nim-lang.org

543 :: Generic floating point math

• shiv (orginal) [2014-09-02T21:17:01+02:00] view original

  I noticed that the math module has only defined functions (sqrt, sin, cos, ...) for float which is defined to be the same as float64 (double precision). Looking at the implementation in the standard library it looks like it should be easy to add the definitions for single precision also, at least for the C backend.

  1. Is there a reason for not adding single precision math functions?
  2. Is there interest if I decide to add it?

  Thanks.

  --shiv--

---

• Araq (orginal) [2014-09-02T22:10:19+02:00] view original

  Sure, just make a PR against the devel (or bigbreak) branch.

---

• shiv (orginal) [2014-09-02T22:26:48+02:00] view original

  I am not comfortable with git but I can cross that bridge when I get there. I am assuming I can just edit my local math.nim file....

  In the mean time I noticed the same problem for the "complex" module: it is not generic. Is there a Nimrod way to make this generic without loosing performance? Is there interest?

---

• Araq (orginal) [2014-09-03T08:05:14+02:00] view original

  Sure there is intest. In general generics have no performance overhead whatsoever.

---

• mason_mcgill (orginal) [2014-09-04T00:28:38+02:00] view original

  I work primarily with 32-bit floating point values (for bandwidth/memory/GPU-interfacing), and I'd definitely appreciate this!

---

• shiv (orginal) [2014-09-04T02:05:56+02:00] view original

  I am almost there, but I just noticed that Nimrod 0.9.4 seems to do all float32 arithmetic as float64. For example, the code

  
  proc compEpsilon32 () : float32 =
    var x: float32 = 1.0'f32
    while (1.0'f32 + x > 1.0'f32):
      x = x / 2.0'f32
    result = x
  Run

  returns 1.1102230246251565e-16, the identical value if I replace all float32 with float64 (including all constants). Even in C the above code can do this if FLT_EVAL_METHOD is 2, for example. But I am curious to know if nimrod automatically converts all float32 calculations to double? If so, is there a way around it, for example by doing what Jehan showed for complex arithmetic via the emit pragma?

  Thanks.

---

• shiv (orginal) [2014-09-04T05:46:31+02:00] view original

  There is something even more bothersome about the behavior of float32. For example the C function fminf(x,y) returns the minimum of x and y. So no bit mangling should occur. Nevertheless the following code fails at run-time:

  
  proc fminf (x, y: float32): float32 {.importc, header: "<math.h>".}
  assert ( fminf(1.2'f32, 2.3'f32) == 1.2'f32 )
  Run

  Am I missing something? Thanks.

---

• shiv (orginal) [2014-09-04T06:13:02+02:00] view original

  I have finished interfacing (almost) all the math routines in GCC C standard library for float, double, complex float and complex double. I am not sure where to post the files? In the meantime if somebody needs them I can just email it to them.

  There are still some issues:

  1. Not sure about the behavior of single precision in nimrod and whether I did things correctly.
  2. Only tested on Fedora 20 x86_64 machine.
  3. More unit tests should be added.

---

• shiv (orginal) [2014-09-04T06:28:58+02:00] view original

  Going through the source I now see that all float32 arithmetic operations are done using float64. Is it a wise idea to use the emit pragma to re-implement this to remain in single precision (the way Jehan showed for single precision complex)? I fear that there is some compiler magic that is at play here. Thanks.

---

• Araq (orginal) [2014-09-04T10:50:40+02:00] view original

  I will make this a showstopper (codegen) bug.

---

• shiv (orginal) [2014-09-06T02:31:23+02:00] view original

  Not sure exactly how, but it looks like the following code to compute machine precision now works in both float32 and float64 as expected (with Nimrod version 0.9.5.)

  
  proc compEpsilon [T] () : T =
    result = 1.0
    while (1.0 + result / 2.0 > 1.0):
      result = result / 2.0
  Run

---