Using scipy for consistency and efficiency (suggestion)

[spluque]

Hello,

It would be great if this package leveraged on scipy for many of its operations. For instance, using the scipy.constants would significantly reduce duplicating these in ahrs.common.constants. Similarly, scipy.spatial.transforms.Rotation could be used for many of operations in ahrs. This is of course only a suggestion to bring cohesiveness and avoid inconsistencies. I, and likely many other AHRS users, already use scipy as part of processing workflows, so this integration would have many advantages. For example, scipy uses scalar-last convention for representing quaternions, so there's at least an extra step when working with both of these tools.

[Mayitzin]

Hi! Totally agree that Scipy would really help with so many functions and algorithms. I had to re-implement some methods to be used with certain routines. And it is certainly not the first time Scipy has been used in the package. Older versions utilized Scipy's tools to read mat files and process data.

Why was it removed? There was an issue with portability. Some users are trying to apply these algorithms in small board computers (e.g. raspberry pi and simlars), and adding such a big package for so few elements was already a burden for some people.

In the spirit of keeping it simple and independent as much as possible, I opted to use NumPy as the only third-party library. For all the rest pure Python should suffice. Besides, the goal of the package is to also provide a clear structure in each algorithm, so that any Student / Developer / Researcher can easily follow how the data is being analyzed and transform. Sure, a simple call to scipy.optimize.newton would save me tons of time re-implementing it, but it would end up costing more resources for the end user, which is something I also want to avoid.

It is an excellent question, though. What would the community think about bringing Scipy back? I would like to hear some more comments.

In regard to the Scipy's Rotation class, I think it would overdo the Orientation Classes that are already implemented in ahrs, which actually offer a bigger plethora of methods than the ones in Scipy.

These classes work very well with Scipy, because they are inherited from NumPy Arrays, and you can use them as such.

The order of the quaternion is also important, indeed. The standard format of <scalar, vector> is used in most software (OpenGL, MATLAB, etc.), mainly because Hamilton originally defined them that way.

What I would suggest is to add a parameter, say "order", similar to the one in numpy.array, that will represent the quaternions with the vector part first followed by the scalar like:

>>> q = ahrs.Quaternion([1., 2., 3., 4.], order='S')
>>> str(q)
'(0.1826i +0.3651j +0.5477k +0.7303)'
>>> q.w
0.7302967433402214
>>> q.v
array([0.18257419, 0.36514837, 0.54772256])

Would this solution be adequate? What do you think?

[spluque]

Thanks for following up on this suggestion. I understand the rationale for avoiding scipy as a dependency. From a user perspective, whenever a package re-implements functionality that is already available elsewhere, there is an added opportunity for inconsistencies to creep into analysis workflows. It is onerous enough to run tests and make sure results are consistent with only one, this situation adds two more sets of test suites; the extra one being for comparisons. Of course, I am not referring to testing the packages themselves, but to the application or analyses relying on them.

For the scenario you describe where users need a tiny package for a specific and isolated task in Arduino or a board, then I can see the advantage. However, when ahrs is used as an integral and tightly coupled component of a larger set of operations, then I am not sure the advantages outweigh the added costs of maintenance and tests. Don't get me wrong, I'm not advocating for fitting a square peg in a round hole, but simply using the tools that are already available and used widely.

Something like the order argument in ahrs.Quaternion would be nice, and I wish it was available in scipy and everywhere.

None of this diminishes the value or utility of this package, and I am very thankful it's available! I hope many others chime in regarding this suggestion.

[Mayitzin]

Hi! On the contrary, thanks for bringing this up. We need to hear the community's voices to better build this package and create something that everyone can easily use. And yes, more opinions about it would be nice.

In the meantime I'll add the order option to the Quaternion classes, so that it is even easier to use them with other modules. Thanks for the suggestion!

[Mayitzin]

I've added the parameter order with commit 2e22bcd, but I haven't fully tested its use yet. I'll further work on it to ensure its compatibility, and it will be fully integrated in the next release, along with some other novelties.