> sorry, even after rereading the thread, I don't get it. A change of
> semantics implies a change of behaviour. Or do you mean you want to
> change the implementation without changing the behaviour?
the sources tell me:
inline float32 sc_trunc(float32 x)
{
// truncFloat is a number which causes a loss of precision of
// the fractional part.
// NOTE: this will only work if the FPU is set to round downward.
// That is NOT the default rounding mode. SC sets it to this mode.
float32 tmp1 = x + truncFloat;
float32 tmp2 = tmp1 - truncFloat;
return tmp2;
}
inline float32 sc_frac(float32 x)
{
return x - sc_trunc(x);
}
please note, that the FPU rounding mode is _not_ set in sclang.
unit generator implements it as:
void frac_a(UnaryOpUGen *unit, int inNumSamples)
{
float *out = ZOUT(0);
float *a = ZIN(0);
LOOP(inNumSamples,
float xa = ZXP(a);
ZXP(out) = xa - std::floor(xa);
);
}
my assumption where based on a _correct_ implementation of sc_trunc. i
prefer to have a consistent behavior based on the same implementation,
rather than having two different implementations, that behave the same
because of a floating point rounding issue.
best, tim
--
tim@xxxxxxxxxx
http://tim.klingt.org
Desperation is the raw material of drastic change. Only those who can
leave behind everything they have ever believed in can hope to escape.
William S. Burroughs
Attachment:
signature.asc
Description: OpenPGP digital signature