Doubles & NaN


carl@...
 

Great! I've tested the 0.17.35 Linux variant and it seems to have solved the issue. I can get both the `nan?` function and the gsl_isnan function to correctly report as NaN. 

Thanks!


 

Thank you so much for the report.

I replicated it and managed to fix it. The root cause is the x86 implementation of the floating-point comparison operators, and hadn't taken full account of all the NaN cases.

Fixed in Stanza 0.17.35.


carl@...
 

> so it is odd that both the GSL nan? and the LoStanza nan? function seem to be working incorrectly.

Ya - agreed. I'd be interested to hear if you can replicate or not. It might be something wrong with my setup. 


 

Hi Carl,

A connection to GSL would be so useful.

I will dig into this and take a look. We are not doing anything special in the storage of floating point numbers, so it is odd that both the GSL nan? and the LoStanza nan? function seem to be working incorrectly.

Patrick


carl@...
 

Hi, 

I'm looking at creating a stanza wrapper of GSL . I've started with just the simple elementary functions. Please see this PR: 

https://github.com/callendorph/lbstanza-gsl/pull/1

I've successfully wrapped some basic functions with lostanza. Where I'm running into trouble is with the expression of `NaN` Double values.

When I run the tests I get the following result: 

```
[Test 1] gsl-elementary-test
Nan: 1.#QNAN nan?: false
[FAIL]
  tests\ELementaryFuncs_tests.stanza:33.2: Expectation "gsl-isnan(obsNan) == true" failed.
    gsl-isnan(obsNan) = false
 
Tests Finished: 0/1 tests passed. 0 tests skipped. 1 tests failed.
 
Failed Tests:
[FAIL] gsl-elementary-test (7978 us)
 
Longest Running Tests:
[FAIL] gsl-elementary-test (7978 us)
```

To recap - I'm running `acosh` with a value (0.5) whose range should not be in the reals - and I expect `NaN`. When I print out the returned value - it seems to indicate that it is `NaN` with `1.#QNAN`. However, the `nan?` function does not indicate that this value is nan. The `gsl-isnan` implementation also doesn't think it is a nan value which is interesting. I did some further expansion: 

```
[Test 1] gsl-elementary-test
Nan: 1.#QNAN nan?: false
Nan Bits Value: 9221120237041090560L
Nan Bits Hex: "7FF8000000000000"
```

If I look in the code for lbstanza - I see this definition: 

https://github.com/StanzaOrg/lbstanza/blob/af3530b4faa476ca3244056e93d3fdb21c66d9e2/oldtests/vmcore.stanza#L4344

Which indicates that `0x7ff8000000000000L` is indeed Nan which matches with the `Long` value representation I'm printing out. 

So then I tried to take a step back and compiled this: 

```
  val expNan = 0.0 / 0.0
  val expNanRet = nan?(expNan)
  println("exp Nan: %_ Res: %_" % [expNan, expNanRet])
 
```
Which outputs: 

```
exp Nan: -1.#IND Res: false
```

So that Nan string representation is different but the `nan?` function still returns false when I expect it to return true. 

Do you have any thoughts ? Am I missing something about how to do floating point math in lbstanza ?