lumiera_/tests/16calculation.tests

TESTING "Library Test Suite: calculation" ./test-suite --group=calculation


TEST "Data Table with CSV storage" DataCSV_test <<END
return: 0
END


PLANNED "Statistic and Regression" Statistic_test << END
return: 0
END


TEST "Random numbers and Seed" Random_test << END
return: 0
END


TEST "Concurrent PRNG access" RandomConcurrent_test quick << END
return: 0
END
Library: draft tests to document the new features Yesterday I decided to include some facilities I have written in 2022 for the Yoshimi-Testsuite. The intention is to use these as-is, and just to adapt them stylistically to the Lumiera code base. However — at least some basic documentation in the form of very basic unit-tests can be considered »acceptance criteria« 2024-03-11 17:44:19 +01:00			`TESTING "Library Test Suite: calculation" ./test-suite --group=calculation`



Library: complete coverage of CSV data table including storage also encompasses some coverage for the simplistic CSV format implemented as storage backend for this data table 2024-03-14 23:44:39 +01:00			`TEST "Data Table with CSV storage" DataCSV_test <<END`
Library: draft tests to document the new features Yesterday I decided to include some facilities I have written in 2022 for the Yoshimi-Testsuite. The intention is to use these as-is, and just to adapt them stylistically to the Lumiera code base. However — at least some basic documentation in the form of very basic unit-tests can be considered »acceptance criteria« 2024-03-11 17:44:19 +01:00			`return: 0`
			`END`


			`PLANNED "Statistic and Regression" Statistic_test << END`
			`return: 0`
			`END`
Library: some first thoughts regarding random number generation Relying on random numbers for verification and measurements is known to be problematic. At some point we are bound to control the seed values -- and in the actual application usage we want to record sequence seeding in the event log. Some initial thoughts regarding this intricate topic. * a low-ceremony drop-in replacement for rand() is required * we want the ability to pick-up and control each and every usage eventually * however, some usages explicitly require true randomness * the ability to use separate streams of random-number generation is desirable 2024-03-11 22:47:29 +01:00

Library: simple default implementation for random sequences Since this is a much more complicated topic, for now I decided to establish two instances through global variables: * a sequence seeded with a fixed starting value * another sequence seeded from a true entropy source What we actually need however is some kind of execution framework to define points of random-seeding and to capture seed values for reproducible tests. 2024-03-11 23:53:18 +01:00			`TEST "Random numbers and Seed" Random_test << END`
Library: some first thoughts regarding random number generation Relying on random numbers for verification and measurements is known to be problematic. At some point we are bound to control the seed values -- and in the actual application usage we want to record sequence seeding in the event log. Some initial thoughts regarding this intricate topic. * a low-ceremony drop-in replacement for rand() is required * we want the ability to pick-up and control each and every usage eventually * however, some usages explicitly require true randomness * the ability to use separate streams of random-number generation is desirable 2024-03-11 22:47:29 +01:00			`return: 0`
			`END`
Library: investigate drawing random numbers concurrently ''In theory,'' the random number generators are in no way threadsafe, neither the old `rand()`, nor the mersenne twister of the C++ standard. However, since all we want is some arbitrarily diffused numbers, chances are that this issue can be safely ignored; because a random number computation broken by concurrency will most likely generate -- well, a garbled number or "randomly" corrupted internal state. Validating this reasoning by an empiric investigation seems advisable though. 2024-11-16 04:52:58 +01:00

Library: now using controlled seed and replaced `rand` (closes #1378) After augmenting our `lib/random.hpp` abstraction framework to add the necessary flexibility, a common seeding scheme was ''built into the Test-Runner.'' * all tests relying on some kind of randomness should invoke `seedRand()` * this draws a seed from the `entropyGen` — which is also documented in the log * individual tests can now be launched with `--seed` to force a dedicated seed * moreover, tests should build a coherent structure of linked generators, especially when running concurrently. The existing tests were adapted accordingly All usages of `rand()` in the code base were investigated and replaced by suitable calls to our abstraction framework; the code base is thus isolated from the actual implementation, simplifying further adaptation. 2024-11-17 19:45:41 +01:00			`TEST "Concurrent PRNG access" RandomConcurrent_test quick << END`
Library: investigate drawing random numbers concurrently ''In theory,'' the random number generators are in no way threadsafe, neither the old `rand()`, nor the mersenne twister of the C++ standard. However, since all we want is some arbitrarily diffused numbers, chances are that this issue can be safely ignored; because a random number computation broken by concurrency will most likely generate -- well, a garbled number or "randomly" corrupted internal state. Validating this reasoning by an empiric investigation seems advisable though. 2024-11-16 04:52:58 +01:00			`return: 0`
			`END`