Ichthyostega
777024ee40
...the implementation was way too naive; in some cases we could go into an infinite loop. In the end, using Newton approximation was not necessary (and thus there is no loop anymore), but it helped me get at a much better solution with very small error margin on average case. All these corner cases are obviously "academic" to some degree, but it turns out there is no clear-cut point where you'd be able just so set a limit and be sure that fractional integer arithmetic works flawless in all cases. Thus the choice is - give up (fractional) integers and work with floats and have to deal with error accumulation - or do something as chosen here, namely add a boundary zone, where fractional integer arithmetic can be kept under control, while admitting small errors, and in turn get the absolutely precise integers in all everyday standard cases |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| model | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| gen-node-location-query.hpp | ||
| README | ||
| session-structure-mapping-test.cpp | ||
| test-gui-test.cpp | ||
GUI backbone tests The tests in this subtree are a bit special: they cover the generic and backbone internals of the Lumiera GTK GUI. They are linked against the complete GUI-module (gui plugin), and thus may use all related ABIs. Yet these tests are *deliberately* compiled without any GTK, GTKmm or SigC includes. This effectively rules out the use, even indirectly, of any GTK widgets and APIs -- forcing the covered GUI backbone entities to stay clean and generic at API level. This is a decision done on purpose. The concrete GUI framework technology shall be treated as an implementation detail. There is no point in writing tests which click buttons in the GUI -- better delegate any significant logic or functionality to GUI agnostic components. GUI is meant to be a presentation layer and must not develop intelligence on its own.