Find preferable source of functions evaluating the founding parameters for PaymentAdjuster

[bertllll]

A dilemma that splits us by opinions. While I don't have troubles to see a point in what @dnwiebe says if he suggests that the PaymentAdjuster calls for reemployment of the PaymentThresholds, and therefore he might be thinking that it should be a shared source of an effort to put the balance and age of a debt into a single number meaning the significant of this future urgent payment, there is currently a wholly developed but different design I've chosen to apply and that conflicts with the first-glance pure and simple approach being asserted by @dnwiebe, it opens up a ground for uneasy decision-making based on delicate conditions I'll try to put down here and that make me feel like lingering to change my mind right away, out of defence. These are considerable from different standpoints, mainly technical and economical for the project.

Technical difference:

(A) Dan's idea: Let's use the existing PaymentThresholds and define the account's debt urgency as the portion of the debt that remains above the curve of the threshold.

(B) My effort has been rooted in preparing a modular system where adding another parameter to be used in evaluation of the urgency would be easy and intuitive. That, however, has involved separation of Balance and Age, treating them individually and defining a numeric evaluation of each parameter that can be sum together intuitively and form the resulting overall weight to belong to the given account. The hardest part of this lies in the common problem: how to declare and keep the translation from a single parameter that is always very likely of different input units, into a universal number disregarding the initial heterogenity. I didn't think of the existing thresholds and proceeded by brand new independent formulas for each parameter.

Where we are and what we know now:

1. Economically

Sadly, it is true that building my design has already swallowed enormous development resources and the transition to another kind of design might affect about one third of the code written (by rough approximation). The truth is it shouldn't be the only argument to say no, because qualitatively, the code should not last if we know there is a clearly better alternative.

2. Long-term evolution and maintenance of the PaymentAdjuster module.

"I do hope for the talks on embracing more parameters into this mechanism in the future are not moot". Therefore, I'd like a design that is ready to be intuitively extended by some new evaluated parameters. This might be a problem in (A) because it is already a combination of two parameters but any following one might come up as lonely-evaluated.

This might cause some inconsistency and a slight drift-away from a purely modular design.
Using the PaymentThresholds as a curve can be problematic on its own, because we are considering a 2D model that was probably invented to ensure usage of low-demand-imagination for understanding the up-set conditions and that works well in the area for where it took place initially but that we might devalue by more parameters which would left the idea of graphical representation kind of behind.

3. Thoughts on continuity

Originally the PaymentCurves, later the PaymentThresholds, came to exist understood as a borderline between two areas. We only cared about in which of these two areas we are with the debt being examined. There was also moment in the history where a simplification of them took place, and instead of a hyperbola, it ended up being a string of straight lines. The curves might serve just perfect for telling apart two areas, while the same curves might be too simple to want it to also work for newly coming applications.

A question is how sure we are that we want the two different occasions lead to manipulation with possibly the same curves? Is that so sensible as it sounds? My curves that I defined for each parameter are smoother, more precise, clear when rendered by myself-developed developer tools, representable and progressing individually and configurable according to what is believed as the right trend over the growth of that parameter. It has its cost in math and code complexity but given how often the scans run compared to the frequency the adjuster would be used, it can be considered a special tool with some sort of finer settings.

3. Fairness, impairments and full-range applicability

Design (A) has also flaws. Let's speculate we're using the PaymentThresholds to indicate the significance of an account. In order to do that, the prospected solution is to use the exceeding part of the debt above the curve.

In the first picture you see below it shows how the Age parameter is weakened, unchanging its significance as it crosses a certain point. Consider that the three accounts on the right, according to the rules to be deployed, all of them evaluate to the same value number as their significance. That seems to be a problem because time seems to play a serious role if we want to be just and pay to others instead of ignoring them long time or forever for not creating an enough big bill on our account.

The second picture tries to demonstrate a similar problem. It shows how tricky it could be as it means we would give privilege to the biggest debts almost no matter how old they are. These are deeper questions and I don't have answers on them at the moment, honestly. "What would it help to if we pushed back the time aspect? Is that unfair for the people we had a business with in the past but we're not using their Node anymore? Should we drain the last scarce means on this young but bulky debt?"

3. Conflicting with the principal of Incremental implementation

Interestingly, I've had to come through experiments on my bi-parametrical design that resulted in the concept of "Outweighed accounts". In case it is a must to have it. It ensures that any account is never assigned with more "redistributed" money than it originally was demanding, more than the actual debt's size.

While it is possible that even (A) would turn out seeing the need of this concept it might be fairly difficult in terms of rewriting the tests so that they would not use the two parameters like now, explicitly written and advocated by the separation of Balance and Age and the effect on each other.

Or maybe not, tests might not be possible to be rewritten with the conditions following (A). Then there is the question of "Should we delete the fine code?" However, let's remember, we plan on adding another parameter in the future which is likely to cause a clear need of this concept. Should we keep the code despite we don't need it now but are firm assuming we will? Isn't that against the rules?

4. Actual implementation hardnesses

Considering the strength of (A) laying in "sharing or being based on existing code" and perhaps "one source of the truth", it would also bring challenges to overcome. I assume we wouldn't compute it first to tell if any accounts qualify for payments, second, when the PaymentAdjuster is found needed to be used, possibly calling the doubled computation code dirtiness.

That's why we might have to compute the excessive parts of the debt, over the curve, and save it for possible later use, having it traveling from the origin, the Accountant, to the BlockchainBridge, together with the qualified payables themselves, and back to Accountant to ask for an opinion of the PaymentAdjuster.

There is also the "knowledge" aspect. Accountant is currently the only owner of the knowledge about the PaymentThresholds computation. Given we made some effort at thinking of separating PaymentAdjuster from the rest of the Accountant as much as possible this might be eventually considered a move in the opposite direction.

Paradoxically, the intention of share is likely to make the PaymentAdjuster's infrastructure (and so the work on its implementation) get bigger. (Considering a compromise of incorporating the PaymentThresholds and preserving the functionality for "Outweighed accounts")

5. Indifference on the "market price issue"

I figured out that this has nothing to do with solving this additional issue. Both, the PaymentThresholds in its original purpose and the PaymentAdjuster, no matter what design it pursues, are going to be highly dependent in its effectiveness on the market price fluctuations. Which is something we had never thought of. And I do believe we need to implement the smoothing mechanism that would recompute the curves based on the current market price average. It's not possible to leave this on as only the user's responsibility. It simply must happen automatically.

This ties this superordinate card with #773.

As it starts to be getting clearer we are going to need to cope with this issue at any rate, so a card or series of cards must be made. Asides PaymentAdjuster, the PaymentThresholds are as well as vulnerable to it. Remember this.