"select" object, not working good , with floats !
hi,
can you reproduce what i'm experiencing ?
there's a metro, a counter , and then a select object.
with integers , the select object will bang its outputs perfectly.
But with floats, many of them are gone.
And i can't manage to know why.
Are you able to reproduce,
or have i something somewhere,
causing this ?
here 's a simple test patch.
thanks a lot !
[select] can only properly select what you send it, and (797/10.) simply does not exist as float:
select-ing floats? just dont do it.
on the one hand for some of these things you have to understand how float works in general.
on the other hand, trying that in conjunction with [select] would be a bit an unlucky example.
i am afraid one would also need to have an overview about what objects truncate doubles to 32 bit or how symbols and floats are parsed as arguments by certain objects.^^ same issue as with tapin~ i think...
thanks a lot Roman, for your fast answer.
That's a sure thing,
i'll never select floats, anymore.
Huge thank-you for that !
Matthieu
Recent versions of [select] include @matchfloat and @fuzzy attributes.
But really, "just don't do it". To be honest, I don't understand how match float & fuzzy work - it seems more buggy than anything else. If someone can explain...
Thanks for your example Jean-François,
that illustrates your words very well :)
I absolutely don't know why, but seems to work if you set fuzzy attribute to 0.0001!?
Trying to go deeper, surely the problem depends on the truncation of doubles as pointed out by Roman, but in this case reducing the value of fuzzy seems to reduce the distance from the given float selector .
This is what I understand from the sel Reference: "thefuzzy attribute can be used to match floats within a specified distance of the given float selector".
In any case I agree: don't do it, aside from speculation.
Thanks Riccardo, for the workaround.
That could be helpful, in some cases.
the "don't do it" advice, is a clear winner here.
I know i'll never forget that.
Also,
thanks Roman, for showing the "printit" object.
i didn't know about it , it made me have a look again,
at the package manager, and update some tools .
:)
pointing you to printit was my main intention. :)
Riccardo, indeed, 0.0001 - I would not have guessed...
...unless the difference to the next real float number is smaller than that?
Also, maybe the most usual way of working with floats should be:
@matchfloat 1 @fuzzy epsilon
i came to the conclusion that the "truncation" and/or the fact that you have to enter the "real" float value into select/route could be intended because of backwards compatibility.
if you have a preexisting patch where someone correctly entered [select 79,699997] to match to an input of "79,7" in a 32-bit data rate max runtime, you dont want the object to treat things differently now.
of course you "just dont do it", but someone could.
I do not think there is any common programming language that encourages users to compare floats. The problem is always the same. One strategy are constructions such as "if (a > 4.999) and (a < 5.001)", another one is just stick with integers – for example instead of coding a second as "1.0", representing it by the microseconds "1000".
Often, floats lead to assume a precision that in fact is not existing. For example, you are measuring something which can be between 0.4 and 5.0 Volts, with a precision of 8 bits. This means your range of 4.6 Volts is divided by 256, so your values would be 0.00000000, 0.01796875, 0.03593750, 0.05390625. Apparently the many decimals are just random here, consequence of imprecise measuring. – Integer values as 0, 18, 36, 54 would do just as well.