`precompute_size_scattering` should always return a tuple (`detail=False`)

Came up in conversation with @MuawizChaudhary

The detail kwarg in precompute_size_scattering isn’t really justified:

• it is True by default
• it creates type instability (int or tuple)
• getting the False version is trivial: it suffices to call sum on the output
• our object-oriented method self.output_size, has detail=False by default. I suggest removing that kwarg and simply summing across orders after calling precompute_size_scattering

Hence i propose to remove it. The only occasion where we need self.output_size() in the codebase is in the Keras frontend. Perhaps we can set up a helpful error message if people ever call the non-default: self.output_size(detail=True), telling them to call self.meta() instead?

[lostanlen]

So just to make sure I’ve got this right, precompute_size_scattering will fix detail=True and output_size will fix detail=False?

Yes, that’s what we just said … but that would remove useful functionality, namely the out_size(detail=True) non-default. So i’m no longer in favor of it (at first, i believed that out_size() was currently detail-ed by default, but the opposite is true)

Looking back at it, i don’t think there’s much to be done here, except maybe removing the confusing detail keyword argument from precompute_size_scattering, and doing the summation inside out_size. This will be fully backwards compatible and will reduce the number of conditional branches in unit tests.

[lostanlen]

If you think its a good idea, we can add a error message stating that we removed detail=True.

Then, i suggest we go with the breaking change, release v0.3, and if anyone complains about output_size() got an unexpected keyword argument 'detail', i’ll write a helpful error message for v0.3.1. Deal?

Personally, I think we should have a variable in Scattering1D that holds the size of the scattering, and this variable should be named num_coefficents or something like that. That is, I dont think we should even have this be a user exposed function.

I disagree. If it’s a variable in the state of the program, then potentially people can modify/delete it, which will lead to antipatterns and strange hacks. Whereas making it the return value of a method (self.output_size()) prevents that problem. I see this method as a “getter” on a private field.