using ieee comparisons

[wcdawn]

Replace ad-hoc comparisons with comparison to IEEE defined values.

Additionally, the Makefile had dos line endings for some reason...

[zaikunzhang]

Hi @wcdawn ,

Thank you for your input. Your implementation is very interesting, and it passes most of my tests.

Just two problems with `integer(sizeof(x)):

• sizeof is not standard Fortran;
• using byte size as the kind is not standard Fortran (for example, integer(8) is invalid in nagfor).

[wcdawn]

Thank you for taking a look! I do believe using the comparisons as I have demonstrated will be a more robust fashion than using things like huge(1d0).

I'm also stumped by how to get around the need of sizeof. I'm essentially looking for an integer that is the same size as a given real. I found a potential workaround. If you just use an oversized variable, you should be just fine.

I got something to work with c_int64_t from iso_c_binding which is included in the Fortran 2008 standard. This is twice as big as is necessary for real(SP) comparisons, but the extra zeros do no harm.

[zaikunzhang]

I got something to work with c_int64_t from iso_c_binding which is included in the Fortran 2008 standard. This is twice as big as is necessary for real(SP) comparisons, but the extra zeros do no harm.

Personally, I do not particularly like the idea of using iso_c_binding for doing things unrelated to c binding. However, I may have to accept it if this is the only workaround.

Does it work for quadruple precision real (REAL128)? Note that different compilers may implement REAL128 in different ways. Some of them implement it as "two REAL64", which is the case for nagfor, if my memory is correct.

Thanks.

[wcdawn]

This wouldn't work with quad precision in general, but could be extended. You would need a 128-bit integer like c_int128_t but that is not included in the Fortran standard. You would also need things like ieee_positive_inf to support the binary128 definition. Not sure if that works. In my opinion, quad precision is not sufficiently standardized to spend too much time on it.

If you can think of another way of guaranteeing a 64-bit integer without c_int64_t, that would work just fine as well and you could remove the dependency on iso_c_binding. This was the only idea that came to my mind.