Feature #1415

Feature #1290: === Core: framework ===

Feature #1712: == Code maintenance ==

onChange() should invalidate cache, and not immediately execute precompute()

Added by wuttke over 3 years ago. Updated almost 3 years ago.

Status:BacklogStart date:22 Apr 2016
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

This is not only for elegance, but improves functionality: Currently, an exception is thrown whenever one parameter is set to a geometrically impossible value. However, a user or a fit may be in the course of changing several parameters. It may happen that the final value of parameter 1 is inconsistent with the initial values of parameters 2..N though it will be consistent with their final values. In such a case, no exception should be thrown.

Implementation is straightforward, and concerns only a few lines of code, but the following must be decided first: How to trigger precompute() if not through onChange()?

Solution 1: Test for cache status at the start of evaluate_for_q(..). Drawback: evaluate_for_q(..) is 'const', and runs multi-threaded. precompute() is not 'const' and not thread-safe. Could be solved by blocking the threads during precompute(). Too unelegant in my opinion.

Solution 2: Caller must call precompute() before launching the multithreaded evaluation. For safety, evaluate_for_q(..) tests nevertheless if the cache is up-to-date, else throws a BugReportException.

History

#1 Updated by wuttke over 3 years ago

  • Status changed from New to Rfc

#2 Updated by wuttke over 3 years ago

  • Status changed from Rfc to Sprint
  • Assignee set to wuttke
  • Target version set to Sprint 31
on advise by Walter, we go for option 1:
  • each thread has it's own copy of sample parts, so threading will not be an issue
    • and if were: it is perfectly valid for a cache to be declared mutable (that's actually the only case that comes to my mind where 'mutable' is good idea)
  • since the cache is totally the responsibility of the object containing it, it ought to handle it himself (option 2 would export knowledge about existence of the cache to the caller)

#3 Updated by wuttke over 3 years ago

  • Status changed from Sprint to Backlog
  • Priority changed from Normal to Low
  • Target version deleted (Sprint 31)

#4 Updated by wuttke about 3 years ago

  • Assignee deleted (wuttke)

#5 Updated by wuttke almost 3 years ago

  • Parent task changed from #1290 to #1712

Also available in: Atom PDF