error: ‘isinf’ was not declared in this scope

[Zahra Sheikh]

Hi,

I have used math.h library to import 'NAN' and 'INFINITY' values in my code and check the variables assigned to them somewhere in my code.
cdef extern from "<math.h>" nogil:
    float INFINITY
    float NAN
    int isinf(long double)   # -1 / 0 / 1
    bint isfinite(long double)
    bint isnan(long double)

cdef np.ndarray[ndim=1, dtype=np.float64_t] bound
bound = np.zeros(2, dtype=np.float64)
cdef np.ndarray[ndim=1, dtype=np.int64_t] is_bound
is_bound = np.zeros(2, dtype=np.int64)
bound[0] = -INFINITY
bound[1] = INFINITY
if (isinf(bound[0])!=0):
   s_bound[0]=0
                    
if (isinf(bound[1])!=0):
   is_bound[1]=0
However, I got compilation error:

error: ‘isinf’ was not declared in this scope
 ybuffer.buf, __pyx_t_16, __pyx_pybuffernd_bound.diminfo[0].strides))) != 0) !=
                                                                     ^
 What is the reason for getting this error message?

Regards,
Z.

[Jeroen Demeyer]

Maybe you need to enable C99 mode in your C compiler?

[Pierre Complex]

The compile builds fine for me cython 0.25.2b0 (py2) or 0.23.4 (py3).

What version of Cython are you using?

[Zahra Sheikh]

Well I ended up defining a function as follows:
cdef extern from "math.h":
     cdef double INFINITY
     cdef double NAN
cdef bint _isinf(double x):
    return (x == INFINITY)

I have another question: I am trying to pass a string as an argument to a function in my cython code
ctypedef unsigned char char_type
def sample(int n, char_type[:] interval_method ='doubling'):
     cdef int doubling_used=1
     if (interval_method!='doubling'):
        doubling_used=0
but it raises the following error message:
char_type[:] interval_method ='doubling'):
  File "stringsource", line 644, in View.MemoryView.memoryview_cwrapper
  File "stringsource", line 345, in View.MemoryView.memoryview.__cinit__
BufferError: Object is not writable.

Is there any other approaches  to pass a character or string as an argument to a function in cython?

Thanks,
Z.

[Stefan Behnel]

Am 18. Oktober 2017 15:14:46 MESZ schrieb Zahra Sheikh:
>Well I ended up defining a function as follows:
>cdef extern from "math.h":
> cdef double INFINITY
> cdef double NAN
>cdef bint _isinf(double x):
> return (x == INFINITY)

If positive infinity is enough, then that's probably ok.

>I have another question: I am trying to pass a string as an argument to
>a function in my cython code
>

>*ctypedef unsigned char char_typedef sample(int n, char_type[:]

>interval_method ='doubling'): cdef int doubling_used=1 if

>(interval_method!='doubling'): doubling_used=0but it raises the

>following error message:char_type[:] interval_method ='doubling'):
>File
>"stringsource", line 644, in View.MemoryView.memoryview_cwrapper File
>"stringsource", line 345, in
>View.MemoryView.memoryview.__cinit__BufferError: Object is not

>writable.*

>
>Is there any other approaches to pass a character or string as an
>argument to a function in cython?

Sure. Just pass it, don't specify a type.

More details are here:

http://docs.cython.org/en/latest/src/tutorial/strings.html

Stefan

[Pierre Complex]

If you only need the value of interval_method to set an integer flag, do not cdef the argument.

def sample(int n, interval_method='doubling'):
    cdef int doubling_used
    if interval_method!='doubling':
        doubling_used = 0
    else:
        doubling_used = 1

[Zahra Sheikh]

What about doing something like this:
def slice_sampler(int n,
                          char* interval_method ='doubling'):

     cdef unicode s= interval_method.decode('UTF-8', 'strict')
     cdef int doubling_used=1
     if (s!=u'doubling'):
        doubling_used=0

Is it a correct way to deal with this bug?
Regards,
Z.

[Stefan Behnel]

Am 18. Oktober 2017 16:41:30 MESZ schrieb Zahra Sheikh:
>What about doing something like this:
>def slice_sampler(int n,
> char* interval_method ='doubling'):
>
> cdef unicode s= interval_method.decode('UTF-8', 'strict')
> cdef int doubling_used=1
> if (s!=u'doubling'):
> doubling_used=0
>
>Is it a correct way to deal with this bug?

That's not really a bug, but you definitely shouldn't do that. Just read the docs.

Stefan