The Math ain't mathing

[CoePaul]

Nipping in the bud

Some bad mathematical habits are already appearing, like moss, in what should be the freshly greensward dodal code base.
( Remember computers rarely do arithmetic - they mostly simulate it )

Background

Examples to make grown developers weep include:

1: Expensive computation: Redundant usage

1a: Trig functions
`// setting a bad example'
'rotation_matrix = np.array(
[
[np.cos(theta), np.sin(theta)],
[-np.sin(theta), np.cos(theta)],
]
)'

'// prefer - although the value of building a 2 x 2 matrix at all is also (separately) debatable
c = np.cos(theta) # expensive call - only needed once
s = np.sin(theta) # expensive call - only needed once

rotation_matrix = np.array(
[
[ c, s ]
[-s, c ]
]
)'

1b: Unnecessary sqrt calls

Example in a test to check that two vectors ( defined in an x,y plane ) have the same length
'original_length = sqrt( x * x + y * y)'
' rotated_length = sqrt( x_rot * x_rot + y_rot * y_rot)'
'assert rotated_length == pytest.approx(original_length)'

Really !?! 😭

This could have easily been

'original = x * x + y * y
rotated = x_rot * x_rot + y_rot * y_rot
assert rotated == pytest.approx(original)'

2 Use of equality operators with floating point numbers

Equality is not a meaningful floating point operator, stick to greater than and less than.

Example
'self.get_min_x() <= x <= self.get_max_x()'
should be
' self.get_min_x() < x < self.get_max_x() # you don't lose the edge cases - they were a dubious illusion'

Test ( try testing the float equality of 1.0 + epsilon vs 1.0 as epsilon dips below 10^-14 ... )

Citation Needed ?

Read Numerical Recipes - screenshot attached below of pages 173/4 from the 2nd edition
( for example NR in C originally from 1986 - this stuff isn't new )

The authors of that work joked "People who write code like this will be executed but their code will not"

Plea for sanity

Why are people not consciously picking these weevils out of the code as they write it / review it?

[CoePaul]

Admittedly some of the other "sins" I was going to rant about here - were actually seen in mx-bluesky :
That does lead to the second order complaint that the dodal library is not providing enough good maths and so bad maths is being written in some of the "customer" libraries which use dodal.

Most memorable example in mx-bluesky

'p(x) = a0 + a1 * x + a2 * x ** 2 + a3 * x *** 3'

should have been
'p(x) = ( (a3 * x + a2) * x + a1 ) * x + a0'

because underflow is a thing ( not to mention the waste of recomputing x to some power )

Any polynomial calculator could do with having unit tests - we have them in gda-mx.git Jython scripts

[CoePaul]

[DominicOram]

Why are people not consciously picking these weevils out of the code as they write it / review it?

Because readability is more important than clock cycles. The speed of dodal is primarily limited by the speed of hardware like motor moves etc.

Any polynomial calculator could do with having unit tests

I would go further and say we shouldn't be writing polynomial calculators, just farm them off to https://numpy.org/doc/2.2/reference/routines.polynomials-package.html#module-numpy.polynomial, it's quicker and better tested.