[Technical Report] Resource Allocation Functions

[ccrock4t]

Technical Report

simplicity: $s = n^{−r}$ where n is the complexity, and r a system parameter greater than zero (defaulted to 0.5). • directness: $d = b^{-t}$ where b is the length of the evidential base and, and t a system parameter. • Sharpness: $2 * |e - 0.5|$. • projectedConfidence(): $c \times (t - t' + 1)^d$, where c is the confidence, t the current time, t′ the creationTime of the truth-value, and d a system pa- rameter indicating the decay rate (defaulted to 1000). • Dividing term complexity (positive integer) in budgetInference() in (Bud- getFunctions.java) is replaced by multiplying by simplicity (real number in (0, 1])

More Info

We are missing the above functions which are needed to help us with resource allocation.

Simplicity (for Term), Directness, and Sharpness (for Sentences) are not mentioned in the code.

For projected confidence (for Events), a different formula is currently used (TemporalFunctions.py, def project())

For the Budget Inference point, see def Budget_inference()

[ccrock4t]

Term Simplicity is added in PR #54

[ccrock4t]

The rest are added in PR #54

[bowen-xu]

projectedConfidence(): $c \times (t - t' + 1)^d$, where c is the confidence, t the current time, t′ the creationTime of the truth-value, and d a system parameter indicating the decay rate (defaulted to 1000).

@ccrock4t This formula is quite strange. Suppose t is 1000, t' is 0, d is 1000, c is 1.0. Then c*(1001^1000) is almost infinite. It makes no sense.

[ccrock4t]

You are right, its not bounded between (0,1). In ONA it is a simply decay parameter < 1 (e.g., $d=0.99$) which is applied for each timestep that has passed. i.e., $c'=c*d^{(t - t')}$

[ccrock4t]

I will change it now

[ccrock4t]

I will also update the technical document

[maxeeem]

@ccrock4t @bowen-xu should we bring this up in today’s meeting?

[ccrock4t]

@maxeeem I don't think it is necessary, this is generally how we have agreed to project truth values in the past. But, it is not set in stone, meaning we can experiment with other formulas in the future (for example, Pei has suggested using a Logarithm of $t-t'$ to limit the rate of decay)

[bowen-xu]

You are right, its not bounded between (0,1). In ONA it is a simply decay parameter < 1 (e.g., d=0.99) which is applied for each timestep that has passed. i.e., c′=c∗d(t−t′)

$c^′=c∗d^{(t−t^′)}$ looks more reasonable.

[bowen-xu]

Sorry I've been too busy recently. will review the changes asap.

[maxeeem]

I guess I’m coming from the perspective that since we’re changing the technical report, we should somehow make it explicit. This case sounds like a typo in the original report based on Bowen’s example., not just another possible formula.

[ccrock4t]

I understand/agree, but which document is the original formula from? The latest conceptual design does not mention it. In the past discussion, we have settled that we need to try various formulas in the future, to find what works best. But, I think the simple decay parameter (such as in ONA) is elegant and simple, and works well in ONA

[bowen-xu]

I agree with you both. I think in the document, we can clearly mark the places where the code doesn't follow the technical report but we have sufficient arguments to do so.