Jump to content

Talk:ITP method

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

How to tune kappa parameters?

[edit]

One of the weak spots in this article is how to tune the parameters, particularly . The original paper discusses the question a bit, but doesn't itself give any clear guidance. After a bit of experimentation (mostly on inverse arc length problems), I'm pretty confident that is a reasonable default choice, suitable in most cases unless experiment or analysis strongly suggests a different value. But is a bit of a different question. The current example in this article uses a value of , which is the same numerical value as the examples in the paper, but I think that fact is a bit misleading. The examples in the paper have , while the example here has , and there is scaling involved. If , then I think the heuristic that captures the intent of the paper is , and this is what I have documented in the kurbo implementation. Also note, if the example were to adopt this recommendation, then would work with fast convergence; I think you can say that you need more "slack" as provided by when is lowballed.

On that last point, I feel like I might be skating a little close to the edge of WP:NOR here. I personally consider an open source project such as kurbo a reasonably reliable source, but can see how others may feel differently. Ideally there would be some survey paper or textbook chapter that we could cite, but, partly due to the technique being so new, there's precious little out there. I'm going to shamelessly self-promote in the interest of providing useful resources to readers, but open to hearing better ways to handle this. Raph Levien (talk) 16:19, 5 April 2021 (UTC)[reply]

Raph Levien, I have added a small note to link to your library (I *feel* that's compliant to NOR). Cheers 🦀🍺. --Artoria2e5 🌉 12:56, 4 July 2021 (UTC)[reply]
Oh, while we are at it, I feel the description has a gap in the description of . The paper (and this Wikipedia article) only mentions it's ≥ 0, while your documentation seems to suggest a smaller useful range of [0,1] further constrained by the optimization to use usize? --Artoria2e5 🌉 13:13, 4 July 2021 (UTC)[reply]

Observations from tuning of epsilon, n0 and k1

[edit]

As the WP:NOR policy does not apply to Talk pages, I think it's OK to share a some yet-unpublished recommendations here: I have conducted a quasi Monte Carlo parametric study of epsilon and , using two alternative monotonic curves of the form and , where is a ranomized constant in the range , and is in the range . Simulations were conducted in Visual Basic (machine floating-point epsilon = 1E-15). was kept constant for reasons given above. My findings are as follows:

Tuning of epsilon

[edit]
  • I tried values 1E-16 0.1, in steps of factor 10.
  • As is reduced, the number of iterations increases and precision improves. However this effect levels out for small values of 1E-10.
  • For large values of : 1E-9 to 0.1, there is little benefit of this algorithm compared to basic Bisection, both in terms of number of iterations, and precision of .
  • For small values of : 1E-16 to 1E-10, there is negligible difference in performance, both in terms of number of iterations and precision of . It levels out, with median 8 iterations.
  • Therefore I recommend to set equal to the machine epsilon (1E-15 in my case), as there are no drawbacks compared to using lower precision.

Tuning of n0

[edit]
  • I tried values in steps of +1, and from 20 up to 50 in steps of +10. This was repeated for a range of values; see below. Results here apply for a wide-range of values.
  • is identical to Bisection.
  • halves the number of iterations compared to Bisection, and improved precision of (median 100000 times more accurate, and 3rd quartile 30 times more accurate), assuming small 1E-10.
  • Increasing further (i.e. and higher) leads to further improvements in precision (median and Q3 statistics) with the added benefit of reducing the Mean number of iterations (median and Q3 remain static). The effect levels out exponentially, with no further improvement over .
  • The maximum possible number of iterations increases with : Max iterations = . However, the likelihood of this hapening sinks for higher , so the Mean number of iterations actually sinks for higher , but the effect levels out exponentially, with a minimum in the range = 14 to 17, as mentioned above.
  • Thus I recommend as an all-round value. I see little benefit in developing adaptive algorithms that automatically tune , as I found little difference in the range .

Tuning of k1

[edit]
  • I tried scaling factors in the range in increments of 0.01, in calculating .
  • The arithmentic mean number iterations reduces exponentially as increases from zero towards approx 0.33, above which the number of iterations flattens out in the region , so the optimal value of may be anywhere in this region. Above , the number of iterations increaces again gradually.
  • The median number of iterations is minimum in the range , and the third-quartile is minimum in the range .
  • Thus I recommend as an all-round value, together with and 1E-15, which worked well for the large range of monotonic function shapes that I tested. This gives a mean number of iterations (9.8) that is a third that of Bisection (30). This finding is obviously influenced by the distribution of monotonic function shapes that I tried.

Comment written by Peter.schild (talk) 15:28, 2 January 2023 (UTC)[reply]

Projection Step

[edit]

In the computation of , the term must be non-negative. Round-off errors could result in a negative value for this term, and this can cause the algorithm to be unstable. This is explained in the ITP paper, but it is not shown in the Algorithm in the ITP paper. So it should be . One should also add r=max(0,r) in the pseudo-code. One should also subtract the unit of least precision before computing max(0,r), so the full expression should be r=max(0,r-ulp(r)). This is also in the ITP paper. One last interesting fact is that if r is ever equal to 0, then the ITP algorithm is the same as the bisection algorithm, so one can check for this case and switch to the bisection algorithm. KennethBaclawski (talk) 16:34, 22 March 2023 (UTC)[reply]

P.S. Yes, this is explained in Appendix B in the original paper. For programming languages that don't have the ULP() function, one can use Peter.schild (talk) 06:42, 16 May 2023 (UTC)[reply]
A practitioner technique that attempts to address a similar issue is to perform the three steps in a diffeerent order: Interpolate, Project and then Truncate. When inverting the order of the last two steps then only the last one needs to make sure the truncation step still produces an estimate inside the desired region. Trojan.chess (talk) 22:48, 12 November 2024 (UTC)[reply]