math operators and floats
It seems my math operators change floats to ints kinda arbitratily. How can I constrain this, for example
----------begin_max5_patcher---------- 599.3oc2WtsbaBCDF9ZxL4cPitlPPBwodWeN5jIivn3nLXgGPN0oY56d0AiM 0olCNAbStvvnURq92OIsK90quxAlUtkUCAeC7CfiyqJKNFaZKNMFbfqnaWTP qMCDthUWSWxft65Tx1JMcfi1a6gRgTPWwL1+dEmVruKdtwXY1S2jjt2pXyJt nfIMKAtsap4+x3FD1yu0nK2HaFNpw7Zpbwibwx6qXKj1fBEl5EDG5BRiSUyG D5qehR77A20LMqqjurlYmCDBtyz0uu9J8a0K2ASmGJJUpCdPRUJLHYU2yDzr ByJ3ORJQ92T5PXWwpYBIUxKEsBcLIwKQG5IDSn6u6wg.eX3E2AdwjHKdSHwZ 2SB7TMv9chWEhnRnK.lQEK+Oi03yj09nFNDMYr1G2re90f0nyi0nPS3mDhmJ RuOowWDRG2WFjO.jgBMaJWBfIX+TEkusdT1l77W.jQVTJ9Do.HiCVjA.KaII TLwdutGdoQ09eS.ttcjfJZFpdmD4gLrIkXtnGfGvAKtPNE74lwxm3d3yIxuQ vlRHopRJui7acgUrJCp8ihPnOcTMb5O0Yud9tgic7vBt3MehsYU0cbDxpK2T snwoMgKn0Jmypkbg4HSqQo+PZ.5vndjmmyD+Ukhbdst5gAj9mdW7CVX5bDsG 0LHLc96AHrvKivPCRXy6Vo9OXzOwLxOXdEFdvBCOuBCMXgMuakwCeq7Bb3On 2C+wyOwN5zSGBadI1wKYGIXOehsqDEc85mYU06bsUSpx2OUVoaG4ZayE11VO CqXOyalBQYw3U0i+.7VoJXB -----------end_max5_patcher-----------
to be floats throughout?
is that not just a case of giving an initial value with a decimal in i.e. [- 0.0] and [/ 1.0] ?
I could do that, but my iunderstanding was that this was not necessary – ie it would default to input.
Now I think about it, I may have run into this before, still, it is very sad that it cannot look at input and use it to decide.
the ref says otherwise
it is not sad, it simply saves CPU.
where needed, you can always do
[route int float]
[* 0] [* 0.]
I’ve read somewhere that’s a legacy issue as Max was originally designed for handling integers only.
it is a feature not an issue. :)
that would be very strange if
would return 3.5, dont you think.
the normal case is that you want to calculate only int OR float and not both.
and if objects would do a typcheck in [/ 2] they would not only need more CPU,
but they would also not know what to do when you send "7.0" into the left inlet
after you sent a new divisor of "3" before – or which of the inlets would like to
set the objects´ mode? 7/2.5 = 3 and 7.0/2 = 3.0 ? …
furthermore, imagine how your patch would read when [/ 2 ] would return the
same type as [/2.7] is doing.
dont forget that any float argumented object also takes ints and converts them,
and every float object takes ints and truncates them.
so you can use [/ 2.] at any time to do 8/2=4.0 when you need 4 (int) at the
output, because 4.0 will work with the next int object just fine (except [umenu]
or [vst~] mabye)
after 17 edits i am now finished 110ing this post together.
i just noticed that there is a contradiction in my post.
of course [* ] has to do a typecheck anyway, so i have to pull my "save CPU" propaganda.
The "save CPU" aspect is still valid to some extent because the format [* ] vs. [* 1.] determines which type of operation (integer vs. float) will be used. So it’s not necessary to derive the operation type at runtime from the input types which may save some CPU cycles. But from the users view, I find it rather inconvenient.
yeah what is used, but they _take both. i am probably not a programmer enough
to have the right picture about how much of a difference it makes to do typecheck
vs "just taking" two different types and route them to different processes.
When Max was young, there was a huge performance difference between integer math and floating point math. As processors have gotten better, this difference has at least been reduced, and perhaps has largely gone away. The trouble is that at this point, it couldn’t really be changed without potentially breaking thousands of patches.
I for one think it’s best to have to be explicit. Yes, I’ve been stung by this too (or stung myself, more accurately), and spent considerable time trying to figure out the problem, only to discover a truncation somewhere. But I wouldn’t change it for anything, because all you need to do is be specific everywhere you need to be. It also makes you be really sure about what you’re doing mathematically and why.
@jamesson: There should be no objects that change them "arbitrarily" from floats to ints etc. They do what their arguments or their incoming values tell them to do, and if they don’t, it’s a bug. Is this what you found?