jordanrl / fermat Goto Github PK

There is currently a CartesianCoordinate class, however it is fairly unintegrated with other parts of the library. Additionally, a PolarCoordinate class in needed to complete #14 as it is the easiest way to implement things such as pow().

This will involve formalizing the CoordinateInterface, making an abstract Coordinate class, creating the new PolarCoordinate class, and correctly utilizing the existing classes to allow for smooth transition between other classes in the library and coordinates.

Related to #15 it would be nice to somehow uncap the precision of the trig operations. In order for this to happen there needs to be a way of getting several constants, namely e and pi, to "arbitrary" precision. I'm currently exploring the best way to implement this.

I think precision to 100 digits hits the vast majority of cases, so it might be okay to keep the constants for most cases and call a generator of some kind in the special cases where greater precision is required.

Add comments for all methods for /Types/Number.php class

Requires Algebra Expressions to be at v1.0 (due to the polynomial foil function being utilized in the multiply() implementation)

• Fix and test divide()
• Fix and test pow()
• Fix and test sqrt()

• Test coverage of at least 80%
• Implementation of Exponential and Logarithmic Expressions
• Implementation of add(), subtract(), and multiply()

I thought that maybe it'd be nice if complex numbers are supported including their operations.

I've created this issue mainly because I wanted to check if it's actually something @JordanRL wants in this project. If so, I think I can get started on a PR.

The exceptions in Fermat already provide/contain the information needed for spatie/ignition. Providing integration with the solution aspect of spatie/ignition should be fairly simple.

There are some areas of the documentation that still do not exist, even though the associated code is tested and considered stable. This documentation needs to be created and deployed so that it is available for developers to reference.

This might be something that is most relevant to some of the modules. Affected modules might include:

• Algebra Expressions
• Coordinate Systems
• Complex Numbers
• Matrices and Vectors
• Stats

Currently, both ImmutableVector and MutableVector implement the VectorInterface, but don't implement any of its methods nor are declared abstract. Either remove the classes altogether, mark them as abstract, create the methods from VectorInterface or remove implements VectorInterface from the signatures.

Allow options for printing and exporting in more formats:

• Grouping
  • Control of grouping: 100,000,000 vs 100000000
    • Export/Print
    • Import
  • Control of grouping size: 100,000,000 vs 1,0000,0000
    • Export/Print
    • Import
  • Control of grouping delimiter: 100,000,000 vs 100.000.000
    • Export/Print
    • Import
• Radix
  • Control of radix character: 3.14159 vs 3,14159
    • Export/Print
    • Import

The GammaFunction returns an incorrect value for $z, because $x isn't altered each loop. This should cause it to loop infinitely.

Similar blocks of code found in 2 locations. Consider refactoring.

https://codeclimate.com/github/JordanRL/Fermat/src/Samsara/Fermat/Complex/Types/Traits/ArithmeticComplexTrait.php#issue_6353a91fe0e81400010000cc

• Test coverage of at least 80%
• Matrix multiplication
• Vector support

Create a matrix type that can handle how matrix math is done.

• Add
  • Scalar
  • Matrix
• Subtract
  • Scalar
  • Matrix
• Multiply
  • Scalar
  • Matrix
• Determinant
• Inverse Matrix

Providing the DocBlock comments for all items allows the documentation generated by Roster to be more complete and helpful, particularly where the descriptions or examples are given.

• Add DocBlock for all items
• Add descriptions where appropriate
• Add examples where appropriate

The php-decimal/ext-decimal library implements a better C version of the string/arbitrary precision math than ext-bcmath, and can replace some of the core parts of Type\Number.

Add a type for number collections that allows for working on groups of numbers together. Operations:

• Add
• Subtract
• Multiply
• Divide
• Power
• Exponentiate
• Normal Distribution From Collection
• Poisson Distribution From Collection
• Exponential Distribution From Collection

Arithmetic operations are really only limited by the BCMath library in precision, so with the proper redesign a few method signatures, this could easily be increased to the 2^32-1 digits that BCMath supports.

The main reason I shied away from doing this for the initial release is that the trig functions can really only be accurate to the number of decimal places that the constants are available at. However, it is probably more of an edge case to need trig functions to > 100 digits than it is to need arithmetic operations to > 100 digits.

Now that the minimum version of PHP for the project has been set at 8.0, it makes sense to update all of the interfaces, classes, and methods to utilize the proper union types.

The same process would need to be done for each of the modules individually (which would also increment their minor version since public signatures change).

• #97
• #98
• #99
• #100
• #101

Matrix has 32 functions (exceeds 20 allowed). Consider refactoring.

https://codeclimate.com/github/JordanRL/Fermat/src/Samsara/Fermat/Types/Matrix.php#issue_5ebcefc647dff600010000ae

The Scrutinizer report for the current codebase has several methods with a high CRAP score. These methods need to be refactored to be simplified, or they need to be more well tested.

• IntegerMathTrait::isPrime()
• RoundingProvider::round()
• RandomProvider::randomInt()

NumberCollection has 31 functions (exceeds 20 allowed). Consider refactoring.

https://codeclimate.com/github/JordanRL/Fermat/src/Samsara/Fermat/Types/NumberCollection.php#issue_5ebcefc647dff6000100006b

Create a calculus provider that can, at the very least, compute the integral over a range (both definite and indefinite) given that the integrand is provided.

Currently the inverse trig functions average around 50 operations per second, and the normal trig functions around 600-700. Current performance: (NOTE: the numerical values depend on the system and are only relevant in comparison to future numbers generated on my development box.)

Current bottlenecks are primarily:

• Dependence on Bernoulli Number generation (extremely slow to calculate, need implementation based on D. Harvey et. al. binary algorithm)
• Dependence on compound and iterative calls to other expensive functions (such as natural log)
• Lack of shortcuts for easier to calculate values (i.e., values within the bounds and scale of the native functions)
• Implemented mainly as Maclauren/Taylor series (slower converging)

This issue was discovered by me while attempting to write some unit tests (those for statistics distributions). So, good argument for decent test coverage. This means that about half the purpose of the library has been non-functional since v1.0

The native calculation mode has been available since v1.1.0, however it only controls the behavior of arithmetical operations. None of the trigonometry or exponential methods take advantage of this setting currently, and these are some of the heaviest functions within the entire library.

Though their would eventually see benefit from the mode setting, once the operation had been reduced to a series of multiply, divide, add, and subtract operations, this is fundamentally unnecessary if the program has indicated it is alright with accepting the limitations of int and floats in PHP. The purpose of this setting is to allow a program to use this library as a common fluent interface for math itself, instead of arbitrary precision.

• Make basic trig functions mode aware
• Make inverse trig functions mode aware
• Make hyperbolic trig functions mode aware
• Make exponentials and logs mode aware
• Make pow and sqrt mode aware

Related (and depending) on #18, update the sequence provider to be able to return sequences as number collections in the case that the developer needs to operate on the whole range in the sequence.

To start with, it should handle 1-dimensional functions of these types:

• Polynomials (ax + b)
• Exponentials (a * b^x)
• Logarithmic (b log a)

Should be able to:

• Provide the derivative function
• Provide the integral function

Currently there is stuff that slips through, and the processes that I have in place are not very organized. This results in changes being made without corresponding tickets, or extremely lazy PR's that don't probably explain or track what is being merged and why.

By adopting some workflows that actually formalize all of this, it makes it easier for the changelog to be accurate, it encourages me to properly ticket and document what is being updated, and most importantly it makes it easier for others to contribute changes if anyone ever wishes to do so.

Add comments for all methods for /Types/Cartesian.php class

Is your feature request related to a problem? Please describe.
In combinatorics, derangements for a set of a given size can be given using the subfactorial method. This method appears in other places, including some probability distributions.

Describe the solution you'd like
The implementation is fairly straightforward:

function subfactorial($n) {
  return floor( factorial($n)/$e + 0.5 ); // For $n > 0
}

Describe alternatives you've considered
This function is fairly simple, and so could easily be implemented by consumers of the library, but it seems an easy candidate for an implementation

The current base conversion library is a bit overkill for what this library needs, and it also presents some problems when it comes to keeping the library up to date with current versions of PHP.

To solve this, add a small BaseConversionProvider.

• Add BaseConversionProvider
• Update base conversion to happen JIT when output is requested
• Update getValue() calls inside calculations to explicitly call NumberBase::Ten to avoid calculation errors when an object's base is not 10.

Despite the fact that Fermat was originally conceived of as an arbitrary precision expansion to the bcmath library (originally only because there was no way to do logs or trigonometry in bcmath), the PHP landscape has changed.

The ext-stats extension no longer exists for any supported versions of PHP, meaning that there aren't any decently complete stats options in PHP. Additionally, some of the other features such as a fraction type, matrix math, complex & imaginary numbers, and base conversion are not at all dependent on precision.

Thus, there is a real use for Fermat as nothing but a more complete math library that only worries about precision to the extent that other functions in PHP do.

In these cases, where the developer using the library wants the features of Fermat without the precision, a native implementation that is unconcerned with losing precision during arithmetic would likely be at least an order of magnitude faster.

To support this use case, there should be an option or supported development pattern that uses only native PHP functions to perform all math operations.

Similar to the calculation modes, it might be useful to create a run-time configuration for rounding modes to affect the behavior of the round() and roundToScale() methods.

Possible Rounding Modes Include:

• Implementation
  • Deterministic Modes
    • Ceil
    • Floor
    • Half Up
    • Half Down
    • Half Even
    • Half Odd
    • Half To Zero
    • Half To Infinity
  • Non-Deterministic Modes
    • Random Tie-Break
    • Alternating Tie-Break
    • Stochastic (this is particularly useful for Machine Learning applications)
• Unit Tests
• Integration
• Regression
• Documentation

Add comments for all methods of /Types/Vector.php class