Review Array and Matrix classes and related stuff
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| JQuantLib |
New
|
High
|
Unassigned | ||
Bug Description
*******
THIS IS A PARENT ISSUE.
Add children issues as necessary
*******
Classes Array and Matrix were rewritten from scratch and test cases added.
The code is known to diverge from QL implementation specially due to:
* operator overloading (not available in Java);
* user-friendly API, providing a comprehensive object model;
* need for the better performance as possible.
These are some classes related to this subject which deserve some study:
org.
org.
org.
=============
Relationships
=============
parent of http://
parent of http://
parent of http://
parent of http://
parent of http://
parent of http://
parent of http://
parent of http://
| Richard Gomes (frgomes) wrote | #1 |
| Richard Gomes (frgomes) wrote | #2 |
In v0.1.3 we've rewritten Array and Matrix classes and very good results were obtained, in particular regarding its organization, performance and aplicability to the domain of JQuantLib.
But more work is needed.
At the moment, we are employing joda-primitive classes in certain situations where we typically would like to employ our Array class. It would simplify our code, make it more flexible and even perform well as less data moves would be necessary between different data structures. These are some pros and cons:
1. Our Array and Matrix classes were crafted in order to supply functionalities we need in JQuantLib, in particular regarding interface Algebra and our implementation of iterators whilst joda-primitives do not provide such functionalities. Arrays are better here.
2. Our Array is not dynamically expandable, which prevents it to be used all around the library as a direct replacement of std::vector. Our implementationof Array does not implement java.util.List whilst joda-primitive does. Here joda-primitives are clearly much better.
3. There are a handful of situations where ideally we would like to have Array<Integer> instead of Array<Double>. In fact, Array is not parameterized and it is only made of doubles, at the moment. Whilst we dont have such flexibility in our Array class, joda-primitives offers such implementation. Unfortunately, joda-primitives are not parameterized, which means that neither Array nor joda-primitives are good enough, it seems. Actually, more thought is necessary in order to understand what is necessary and the convenience of a certain implementation A over implementation B.
So, an incomplete list of requirements for a future code review is:
1. Arrays shouls implement List<Double>, being dynamically resizable.
2. There's a need of Array<Integer> which needs to be evaluated how it could be implemented.
3. Our implementation of Array<Double> (which extends List<Double>) must substitute places where we are currently employing joda-primitive classes.
4. A full code review must be done regarding std::vector parameters in the original C++ code which should be replaced by our new Array<Double> class.