Jeremie Vandenplas

Most of them are due to specific compiler flags. I would first remove the useless ones, and then check the remaining warnings.

> I agree with the proposition, and would like to make it available such a function rather soon, even if the implementation will change later. I agree. > Having a...

> Assuming we want to be able to produce NaNs of various kinds, I suggest the following API > > ```fortran > pure elemental function nan_(x) > real(), intent(in) ::...

It sounds like we have a consensus on the name and API. Based on this thread: ## nan ### Description `nan(x)` is an elemental function that returns a NaN value...

> I don't see an issue with allowing `nan` to be called without arguments. However, it should return a default `real`, not `real(sp)`. Our API should not make reference to...

Question: Which compilers do not support IEEE `NaN`? (to test a few things) http://fortranwiki.org/fortran/show/Fortran+2003+status

I would propose the following API: ``` is_approximated( x [, tol]) is_approximated( x, y, [, tol]) ``` where `tol` is `optional` for both functions. A default `tol` can be determined...

> Is this something useful for stdlib? I think it is indeed something for stdlib. It could even be used inside stdlib for the different tests with real values (and...

> Re: int32 vs int64. You'll need both. Let me elaborate. The most common application of sparse matrices is in the inner steps of some PDE solver, dealing with a...

> But I think it is still worth having a nice API to dense eigensolver via Lapack, and a sparse eigensolver on top of this sparse functionality, so that people...