Can the `Calculate`

node be changed to allow for integer arithmetic? I know the automatic type converters kick in when it's hooked up to nodes that take `Integers`

, but being able to set the type of the `Calculate`

to `Integer`

node would cause less clutter, less time selecting how to round the result, and less processing time in a loop.

Additionally, can it be changed to also allow `2`

/`3`

/`4D Points`

? In the event that a `3D Point`

is being used in a calculation, and the result is another `3D Point`

, right now three `Calculate`

nodes need to be used, one per dimension. A point could be constructed within an expression using `[these]`

brackets. A number could be used in an expression without any change, but perhaps a `2D Point`

could be written with `_XY`

as a suffix, a `3D Point`

with `_XYZ`

, etc. A dimension could be used from a point with just that dimension (instead of all dimensions) specified in the suffix.

The node could either take a single expression to calculate all dimensions in the point, or it could take an expression per dimension. Allowing for a bit of vector-style arithmetic could further open up some flexibility too, for example, by allowing adding two points, multiplying a point by a constant, multiplying dimensions (as in `X1*X2`

, `Y1*Y2`

, etc.), dot/cross products, a magnitude function (perhaps with `|this|`

syntax...

Expressions might look like this:

```
radius * [cos(theta), sin(theta)] //Point on a circle at angle theta
deltaTime * velocity_XY + location_XY //New location after applying velocity
[velocity_X, deltaTime * gravity + velocity_Y] //New velocity after applying gravity
```

## Comments

## Opened for voting.

Jaymie(@jstrecker)Opened for voting.

## I like this FR a lot! Math

Alastair(@usefuldesign)I like this FR a lot! Math Expression was my favourite patch in QC and the Kineme multiple Expression patch was even cooler.

I think one expression per dimension makes more sense, less confusion in the expressions (but yes more canvas real-estate).

And if we wrote expressions as expressions, we could also have multiple outputs.

E.g.

I came to this same FR idea thinking about situations where you might have different input and output datatypes… or multiple input datatypes.

E.g. 2x 2D Points in and 1 2D Point Out 2D Point and Real in and 3D Point Out 4x4D Point in and 1x Real Out (Calculation of matrix determinant)

Not sure how best to denote the components from, say, multiple 4D Point inputs… matrix notation is

`b₂₄`

becomes`B24`

, where the 2 is the second input datatype (in this case must be a 4D Point) and 4 is W value of that input datatype.This might be hard for the math parser if it's using a standard C library. Guess the expressions need pre-parsing already for the

`I`

(Calculate List node) and`A`

variables.Or it could use X = X1 + Y1 * X2 * A, where X is value X in the output, X1 is the X value from the first input (say a 2D Point), Y1 is the Y from the first input point and X2 is the X from the second input datatype (say a real number) and A is a real value input.

For Calculate List nodessometimes it would be very useful to get to a value in the following index i.e. i + 1 to test the distance to that object or something like that.In cases where the index was indicated as

`[i]`

rather than`I`

and calculation within the square brackets could be done to work out the index number (wrapping indexes the overflow would be very handy to access the first element from a calculation of the last element).E.g. [i+1], [i-1]