On Wed, 21 Apr 2021 at 03:33, Matt Juntunen <matt.juntu...@hotmail.com> wrote:
> Hi Alex, > > First of all, thanks for all of the work you've done here! Second, I vote > to go with the fast dot2s implementation for LinearCombination and use it > as a static method in commons-geometry. The reason is that the scale of > accuracy improvements we're talking about here is not going to mean much > for practical purposes, whereas a performance hit in a critical piece of > code like this definitely is. Also, I'd prefer to keep the choice of > LinearCombination algorithm internal to the library and not make it > configurable. The vast majority of users are not going to want to have to > think about it and it will keep the API cleaner if we don't explicitly > allow it to be changed. If users want to use a different algorithm for > something in commons-geometry, they can write a utility method that > leverages other parts of commons-numbers. > OK. Note that exact computation is most important when small absolute differences result in large relative differences between the computed and actual answer. The case for the Complex class was in a computation that approaches zero. Here the relative error can be very large. If this type of computation is not being done in Geometry then favouring speed over precision makes sense. If a critical computation requires this precision then support can be added for specific use cases when they are found. I'll create a PR that updates the current method to the faster (and essentially the same accuracy) dot2s method. Alex
