ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/library/random-test.cpp

109 lines
3.2 KiB
C++
Raw Normal View History

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
/*
Random(Test) - verify framework for controlled random number generation
Copyright (C) Lumiera.org
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file random-test.cpp
** unit test \ref Random_test
*/
#include "lib/test/run.hpp"
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
#include "lib/random.hpp"
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
namespace lib {
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
namespace test {
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 demonstrate simple access to random number generation,
Invocation: consider minimal test setup and verification __Analysis__: what kind of verifications are sensible to employ to cover building, wiring and invocation of render nodes? Notably, a test should cover requirements and observable functionality, while ''avoiding direct hard coupling to implementation internals...'' __Draft__: the most simple node builder invocation conceivable...
2024-10-13 03:49:01 +02:00
* as well as the setup of controlled random number sequences.
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
* @see random.hpp
*/
class Random_test : public Test
{
virtual void
run (Arg)
{
simpleUsage();
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
verify_reproducibleSequence();
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 demonstrate usage of default random number generators */
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
void
simpleUsage()
{
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
int r1 = rani();
CHECK (0 <= r1 and r1 < RAND_MAX);
int r2 = rani();
CHECK (0 <= r2 and r2 < RAND_MAX);
CHECK (r1 != r2);
}
/** @test demonstrate that random number sequences can be reproduced
* - use a rigged SeedNucleus, always returning a fixed sees
* - build two distinct random sequence generators, yet seeded
* from the same source; they will produce the same sequence
* - sequences can be re-shuffled by a seed value, so that
* the following random numbers will start to differ
* - but even this re-shuffling is deterministic
*/
void
verify_reproducibleSequence()
{
class : public SeedNucleus
{
uint64_t getSeed() override { return 55; }
}
coreOfEvil;
Random src1{coreOfEvil};
int r1 = src1.i32();
uint64_t r2 = src1.u64();
double r3 = src1.uni();
Random src2{coreOfEvil};
CHECK (r1 == src2.i32());
CHECK (r2 == src2.u64());
CHECK (r3 == src2.uni());
Library: consider how to handle randomness in tests Using random or pseudo-random numbers as input for tests can be a very effective tool to spot unintended behaviour in corner cases, and also helps writing more principled test verifications. However, investigating failures in randomised tests can be challenging. A well-proven solution is to exploit the **determinism** of pseudo-random-numbers by documenting a randomly generated seed, that can be re-injected for investigation. Up to now, most tests rely on the old library function `rand()`, while at some places already the C++ standard framework for random number generation is used, packaged into a custom wrapper. Adding adequate support for documented seed values seems to be easy to achieve, after switching existing usages of `rand()` to a suitable drop-in replacement. After some consideration, I decided ''against'' wiring random generator instances explicitly, while allowing to do so on occasion, when necessary. Thus the planned seeding mechanism will rather re-seed a ''implicit default'' generator, which could then be used to construct explicit generator instances when required (e.g. for multithreaded tests) As a starting point, this changeset replaces the `randomise()` API call by a direct access to the ''reseeding functionality'' exposed by the C++ framework and all default generators. Since we already provide a dedicated static instance of the plattform entropy source, re-randomisation can be achieved by seeding from there. NOTE: there was extended debate in the net, questioning the viability of the `std::random_seq` -- these arguments, while valid from a theoretical point of view, seem rather moot when placed into a practical context, where even 2^32 different generation-paths(cycles) are more than enough to provide sufficient diffusion of results (unless the goal is really to engage into Monte-Carlo simulations for scientific research or large model simulations). Notable most of the more catchy reprovals raised by Melissa O'Neill have been refuted by experts of the field, even while being still propagated at various places in the net, often combined with promoting PCG-Random.
2024-11-09 23:25:25 +01:00
src1.reseed (coreOfEvil);
CHECK (src1.u64() != src2.u64());
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
Library: consider how to handle randomness in tests Using random or pseudo-random numbers as input for tests can be a very effective tool to spot unintended behaviour in corner cases, and also helps writing more principled test verifications. However, investigating failures in randomised tests can be challenging. A well-proven solution is to exploit the **determinism** of pseudo-random-numbers by documenting a randomly generated seed, that can be re-injected for investigation. Up to now, most tests rely on the old library function `rand()`, while at some places already the C++ standard framework for random number generation is used, packaged into a custom wrapper. Adding adequate support for documented seed values seems to be easy to achieve, after switching existing usages of `rand()` to a suitable drop-in replacement. After some consideration, I decided ''against'' wiring random generator instances explicitly, while allowing to do so on occasion, when necessary. Thus the planned seeding mechanism will rather re-seed a ''implicit default'' generator, which could then be used to construct explicit generator instances when required (e.g. for multithreaded tests) As a starting point, this changeset replaces the `randomise()` API call by a direct access to the ''reseeding functionality'' exposed by the C++ framework and all default generators. Since we already provide a dedicated static instance of the plattform entropy source, re-randomisation can be achieved by seeding from there. NOTE: there was extended debate in the net, questioning the viability of the `std::random_seq` -- these arguments, while valid from a theoretical point of view, seem rather moot when placed into a practical context, where even 2^32 different generation-paths(cycles) are more than enough to provide sufficient diffusion of results (unless the goal is really to engage into Monte-Carlo simulations for scientific research or large model simulations). Notable most of the more catchy reprovals raised by Melissa O'Neill have been refuted by experts of the field, even while being still propagated at various places in the net, often combined with promoting PCG-Random.
2024-11-09 23:25:25 +01:00
src2.reseed (coreOfEvil);
CHECK (src1.u64() != src2.u64());
(void) src2.u64();
CHECK (src1.u64() == src2.u64());
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
CHECK (src1.i32() == src2.i32());
Library: consider how to handle randomness in tests Using random or pseudo-random numbers as input for tests can be a very effective tool to spot unintended behaviour in corner cases, and also helps writing more principled test verifications. However, investigating failures in randomised tests can be challenging. A well-proven solution is to exploit the **determinism** of pseudo-random-numbers by documenting a randomly generated seed, that can be re-injected for investigation. Up to now, most tests rely on the old library function `rand()`, while at some places already the C++ standard framework for random number generation is used, packaged into a custom wrapper. Adding adequate support for documented seed values seems to be easy to achieve, after switching existing usages of `rand()` to a suitable drop-in replacement. After some consideration, I decided ''against'' wiring random generator instances explicitly, while allowing to do so on occasion, when necessary. Thus the planned seeding mechanism will rather re-seed a ''implicit default'' generator, which could then be used to construct explicit generator instances when required (e.g. for multithreaded tests) As a starting point, this changeset replaces the `randomise()` API call by a direct access to the ''reseeding functionality'' exposed by the C++ framework and all default generators. Since we already provide a dedicated static instance of the plattform entropy source, re-randomisation can be achieved by seeding from there. NOTE: there was extended debate in the net, questioning the viability of the `std::random_seq` -- these arguments, while valid from a theoretical point of view, seem rather moot when placed into a practical context, where even 2^32 different generation-paths(cycles) are more than enough to provide sufficient diffusion of results (unless the goal is really to engage into Monte-Carlo simulations for scientific research or large model simulations). Notable most of the more catchy reprovals raised by Melissa O'Neill have been refuted by experts of the field, even while being still propagated at various places in the net, often combined with promoting PCG-Random.
2024-11-09 23:25:25 +01:00
CHECK (src1.uni() == src2.uni());
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
}
};
LAUNCHER (Random_test, "unit common");
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
}} // namespace lib::test
Reference in a new issue Copy permalink