Add logspace constructor

[JP-Ellis]

This pull requests adds the logspace constructor for Array1 that works in the same way as linspace but creates logarithmically spaced floats.

This implementation supports both positive and negative intervals, though
(obviously) not intervals which cross 0.0.

[LukeMathWalker]

Thanks for working on this @JP-Ellis!
It definitely looks like a piece of functionality that we were missing.

To move this forward it would be nice to have tests for these new functions, testing both happy and unhappy paths 👍

[JP-Ellis]

@LukeMathWalker All done, I have added tests within a tests submodule of the new logspace module.

[jturner314]

I haven't had a chance to review this in detail, but at first glance, I had a couple of thoughts:

• We should name this geomspace instead of logspace to be consistent with NumPy and Matlab. (logspace in NumPy and Matlab takes the exponent bounds as parameters, while geomspace in NumPy takes the actual value bounds as parameters, like this PR.)

• I'm interested that the implementation of this PR multiplies by a step for each element. In contrast, NumPy's geomspace is implemented in terms of logspace, which is implemented by using linspace as an exponent. I would guess that directly computing base ^ (log_start + log_step * i) for each element (like NumPy) would be more accurate than (base ^ log_start) * step * step * ⋯ * step (this PR) due to accumulated errors, but I'm not really sure. There's also some advantage to maintaining consistency with NumPy, but that's not necessarily important. Any thoughts on this?

[LukeMathWalker]

• We should name this geomspace instead of logspace to be consistent with NumPy and Matlab. (logspace in NumPy and Matlab takes the exponent bounds as parameters, while geomspace in NumPy takes the actual value bounds as parameters, like this PR.)

If we decide to keep compatibility with their naming convention, then I'd advice to add a logspace-like method to our API as well. geomspace picks its name from geometric progression, but for searchability purposes I think most people looking for such a functionality (and I put myself in there) would expect something named after a logarithm, like logspace. If we provide both, I think we should be fine.

• I'm interested that the implementation of this PR multiplies by a step for each element. In contrast, NumPy's geomspace is implemented in terms of logspace, which is implemented by using linspace as an exponent. I would guess that directly computing base ^ (log_start + log_step * i) for each element (like NumPy) would be more accurate than (base ^ log_start) * step * step * ⋯ * step (this PR) due to accumulated errors, but I'm not really sure. There's also some advantage to maintaining consistency with NumPy, but that's not necessarily important. Any thoughts on this?

I have the same gut feeling that base ^ (log_start + log_step * i) would lead to a more precise estimate, but no theoretical/practical example to back it up. We could run a quick check comparing errors for an (long) exact sequence.

[JP-Ellis]

Great, so I've renamed the logspace function to geomspace, and I've added a new logspace function to be in line with NumPy and Matlab.

Additionally, I've changed the way each step is calculated to avoid a possible small error from accumulating.

Before merging this, I would recommend that this pull request be squashed into one commit.

[LukeMathWalker]

It looks good to me - happy to squash and merge 🚀