e-17 is a very small number. e+17 is a HUGE number… You know, a value with seventeen decimals before the point, ie. -994626945000000000.0
Even ignoring asymmetry (in signal processing you’re dealing with ac signals, so you should always compare against absolute/magnitude values, ie. no sign), you’re checking if the input value is below -900 quadrillions… Unless, as said, you’re dealing with scaling factors, this should always be true (for every negative number). Even if this is by design, I would advise you not to, as you’re losing a lot of precision.
[quote=“daniel, post:3, topic:17779”]EDIT: thinking a second time I realize, I probably misunderstood your approach, because a smaller number than FLT_MIN is not representable and therefore does not exist. So it would be a NOP.If the code you posted is helping and you are testing against a very high negative number, it does sound like a division by zero to me…
[/quote]By definition, FLT_MIN (or std::numerical_limits< float/double>::min()) is the smallest, representable normalized number. So in case of denormals, they will be less (in magnitude) than FLT_MIN.
[quote=“zioaxiom, post:4, topic:17779”]
I’m just picking up a sample from a circular buffer and there’s a modulation involved. What is VERY strange is that the issue happens only in a precise part of my plugin while in other (involving basically the same way of picking up a sample from the circular buffer) works correctly.
[/quote]My guess is your modulation is reading out of bounds, which is why you’re picking up these huge values - it could be random uninitialized memory, or anything that isn’t a float…