Hi all. Pd has a t_float
type that is either defined as a single or double precision depending (I presume) on the word size of the architecture. The question is: if I need to use functions from math.h
like fmin
, fmod
and so on, do I have to write my code twice depending on the word size, or is there some other clever trick that I'm not seeing?
-
math.h, float or double?
-
@morpheu5 the canonical supported pd only uses 32-bit floats in messages (and signals). the question of how to write/format externals that support both floats and doubles is an ongoing discussion afaik. Right now almost everyone uses "normal" pd w/32-bit floats, and externals generally aren't available for pd-double.
most architectures support doubles now, so t_float isn't based on the machine. (but I presume the reason supported pd uses 32-bit floats is so it can run on an abbacus)However, there's nothing to restrict external developers from using doubles in their externals internally. It's just that when the message/signal goes back into pd it will be 32-bit.
I think functions like fmod are fine to use for both doubles and floats (I wouldn't be surprised if the compiler will just use fmodf instead if the inputs are floats)
But I don't know how far off pd-double is from being supported or used anyways, so right now
I'd say right now you don't need to worry about t_floats or t_samples being doubles at all. No externals support pd double, because I don't think the loading mechanism/convention has been completely fleshed-out yet. (and barely anyone uses pd-double) -
@seb-harmonik.ar Aha, thanks! That explains it clearly enough. Yeah, I learned to trust the compiler to do the right thing most of the time but since this is C I wouldn't expect it to select the most appropriate implementation. Chances are the compiler will only be able to safely do implicit casts, which have costs. I'll stick to 32 bit functions if this is the canon at the moment.