Fix array_finalize for beams

[e-koch]

minajor -> minor in array_finalize for Beams.

I found this trying to do arithmetic with a Beams object, which also doesn't work correctly. But I'm not sure if we need it to?

[keflavich]

Oops, that's a bug.

Why not have a majors * minors * 2 * pi / fwhmfactor test instead of assuming symmetric beams?

[e-koch]

I didn't get that far in the test. Here's an updated version, but it's not working. The original self object seems to lose its attributes? I don't understand where array_finalize is getting called when doing an operation and my assumption that the original and new sr are both accessible is probably wrong

[keflavich]

Right. I don't think arithmetic operations should work on Beams or Beams, it doesn't really make a ton of sense.

[e-koch]

Multiplication/division could be made to work if applied on the areas. But I can't think of a case where you would want to that.

We should probably raise some sort of InvalidBeamOperationError. Right now it happily returns wrong answers without error.

Addition/subtraction can be treated as convolution/deconvolution like it does in Beam

[keflavich]

on areas: why not just do Beams.sr * 5 instead of (Beams*5).sr?

And, yes, agreed, raising descriptive errors is a good idea

[e-koch]

I've defined a number of operations for Beams to match (mostly) the operations in Beam.

One weird thing in Beam: convolution is multiplication, but deconvolution was subtraction? I think making it division makes more sense as the opposite operation

[keflavich]

agreed, division and multiplication make more sense as the de/convolve operations

[e-koch]

I've kept the __sub__ operator in Beam in case it's a breaking change. Otherwise, mult/div are used.

I'm happy to merge this. Let me know if you have any more comments.

[keflavich]

minor: are we deprecating subtraction-as-deconvolution?

[e-koch]

@keflavich - I think we should deprecate subtraction-as-deconvolution. I'll add a warning