Add new data type and /or concept for better handling of refractory/non_refractory state about nestml HOT 3 CLOSED

I'm totally in favor of this!
This would allow us to handle refractoriness properly depending on the precision the user wants and thus we can make sure that it is handled properly.

from nestml.

I would in principle be against introducing special functions, such as set_refractory() and is_refractory(), unless it confers a specific advantage. The current method uses resolution() to generate an integer number of counts to represent the refractory period; I was wondering earlier why not just use a solution that represents time as a floating point:

parameters:
    t_refractory ms = 5 ms
end

initial_values:
    t_sp ms = -1
end

update:
    if V_m > V_th:
        emit_spike()
        t_sp = t
    end
    if t_sp < 0 or t - t_sp > t_refractory:
        integrate_odes()
    end
end

The precision is dependent on the simulation resolution in any of these scenarios.

from nestml.

I guess time might be useful in other models so this could be an option with added value, though I must say that for the specific task of handling refractoriness I do find the former option's explicitness more appealing

from nestml.