Announce node-red-contrib-math

Hi Dave,
I would like to calculate it only on a single message (which contains an array), since my calc-node only operates on a single message. The other nodes (like average-node) seem to operate on data from multiple messages:
image

So a split then a join in reduce mode with a suitable expression could do same - albeit in two nodes.

If you are adding new features should it not go to 1.1.0?

Yes that is true. But I was in the mood to spoil the NR users. Remember that in Belgium tonight Saint Nicholas will throw presents through the chimney, since it is tomorrow Saint Nicholas Day ...

Yep, you are right. I shall update it, as soon as I add a new operation ... So if you have good ideas for extra operations on my node, I can set this right much faster :wink:

1 Like

Spoil or confuse ? Too much choice (or chocolate) can be a bad thing :wink:

Now I would also like to implement a moving average operation. I don't think this exist yet in other contributions?

node-red-contrib-statistics does that. You can set a window size for all of the statistical measures and pass in arrays of data.

Or are you wanting to output an array of moving averages, like a data reduction/smoothing?

Hey Dean, long time no seen ...
Yes I wanted to create an array of moving averages, based on an input array and a window size (like in my example above). But didn't know where to specify the window size, since all other operations expect (as input) an array of numbers OR a single number. But not both ...

Use the property/property type approach so that it can be specified wherever the user chooses - msg property, flow/global property, static value, calculated (jsonata).

That is indeed a possible solution.
But currently - when an operation needs two parameters - I expect them to arrive as an array of length two. Some examples:

  • Round 1.23456 at a 3 decimal places:

    Input = [1.23456, 3] => Output = [1.234]

  • 2 to the power of 3:

    Input = [2, 3] => Output = 8

But I cannot use this approach when the input is both an array AND a number (since the extra number at the end of the array will just be considered as a longer array). So when I now require an extra field to be filled in, it might be confusing.

Perhaps it is better if I drop this new operation.
Moreover, I don't want to give Dave an overdose of chocolate ...

1 Like

The property/property type approach will handle this as you can do deep object specification ie msg.payload[2] or msg.payload[1] or msg.payload.length or even msg.payload[1][0] (that's an array of arrays).

In all honesty, hard coding stuff like this just makes life difficult for everyone and really reduces the usefulness of utility nodes like this.

Let me give you an example. I have a climate monitoring flow that passes around an object containing current temp, humidity, and air pressure readings. All these readings need to stay together as they are related and represent a complex measurement. Along the way I do some calculations for heat factor which come out with an excessive number of decimal places. It would be nice to be able to pass my object through your node and tell it to round the heat factor property to a sensible 1 decimal place. In your current approach, I need to save the original climate object somewhere, extract the heat factor property, turn it into an array, add the required decimal places, pass it through your node, extract the result from the array, and insert the result back into the original climate object before sending it on its merry way. I would much prefer to just be able to pass the entire object through your node and tell it to operate on a specific property of that object.

Morning Dean, that is indeed correct. What a pitty that you were not available at the start of this discussion. Now I have published it with the array behaviour already ...

You can still do it and maintain backwards compatibility - the property/property type approach is really flexible.

Give me a shout if you would like some assistance

@BartButenaers

Just a modest question:

Did you consider the effort/effectiveness' relationship for this contrib node?

It seems to me, that it's a wrap of the Math() function. I generally use Math() in function nodes or in a contrib node, I can't see the benefit of using your node in a flow.

Could you show some practical examples?

E.g. who would use Hyperbolic cosine (cosh) in a node-red flow?

@cflurin: You haven given a very bad example :face_with_raised_eyebrow: Normally I try to add documentation for all functionalities, but on my readme page you will see that I haven't even added examples for those kind of operations. Have just added them for completeness, but they are at the end of the list to make sure they don't disturb users. I have experienced in the last two years that people do complete crazy things with my nodes, so it is just there in case some weird mind needs it...

And yes, performance will be much better when you just call the Math functions in a Function node (without type checks, and so on ....). However, this node is aimed at another user group, who prefer to search hours on Google to find an out-of-the-box solutions instead of writing a single line of Javascript... When I'm in a social mood, I develop nodes that I'm never going to use myself ... And you are also not part of my target audience :wink:

Have put it on my TODO list...

Hi Bart,

Well, it's your node and it's open source :grinning:. I hope some users will post interesting flow examples.

Generally I try to use the core nodes and only add specific contrib-nodes.
This way I can reduce the software maintenance and increase the stability.

@BartButenaers
Thank you so much for this node :slight_smile: just what i needed :smile:

1 Like

Hi all, I'd always planned to add a date/time calculator node to moment. Of course, I'm always happy to receive pull requests :wink:

As it stands, you can do a simple +/- adjustment to the input date/time using the moment node. That works well if you need to know the input date + 30 days or whatever.

Please let me know - in a new thread - if you would like to see other calculations available.

And don't forget that there is already the node-red-contrib-moment-humanizer node to help interpret time spans from/to human-readable strings... e.g. "2 hours ago", "next week", etc.

1 Like

Actually, there is a humanizer node in node-red-contrib-moment as well - written by someone else but he contributed it to my node.

Ah, yes, that is the one I was thinking about... the humanizer node inside your module, not a separate module.

1 Like