Even though I vowed not to post on the forum again (a promise which I have been breaking), I have to chime in here and say that both parties are partly correct and partly incorrect.
Some Moving Averages, like the SMA can only have "integer" periods, but others, like the EMA can technically have "floating point" periods, because the period is converted into a weight. In the case of EMA, the resulting weight for a floating point value for the period, is not only possible, but can also be useful and have a true effect on the resulting moving average.
For the SMMA and LWMA it can also be true, but depends on how they are implemented. For example, a SMMA can be implemented as a special case of an EMA, and in that case a floating point period is possible and useful. However, if the SMMA is implemented as a sum over a certain period, then only integer periods are possible. The same applies for LWMA depending on how it is implemented in the code.
For the MetaQuotes implementations, only the EMA would benefit from a floating point period, but for other custom implementations that use the weight based approach, all three - EMA, SMMA and LWMA, would benefit from floating point periods (if coded properly for such a possibility).
PS! So, in this case specifically, i.e. the MACD, the EMA parts would benefit from using floating point periods, but not the SMA part (as implemented by MetaQuotes, even though the original also uses an EMA for the signal line).
Yes that is correct! That is why I stated "(if coded properly for such a possibility)" and that the MACD would "benefit" from a floating point period and not that it can accept such a value.
However, to clarify things for the OP, there are MACD implementations out there, that do accept "floating point" periods.
maybe, not pure MACD if you edit the value
U can read about how to do that here: svinozavr