ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/lib/random.cpp

91 lines
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.cpp - storage and implementation for random number framework
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2024, Hermann Vosseler <Ichthyostega@web.de>
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
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** 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. See the file COPYING for further details.
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
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
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
/** @file random.cpp
** Implementation details and common storage for random number generation.
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
** @todo 3/2024 work out how some executions or performances are configured reproducibly.
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
*/
#include "lib/random.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 <string>
using std::string;
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 lib {
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 {
const string ENTROPY_SOURCE_SPEC{"/dev/random"};
class EntropyNucleus
: public SeedNucleus
{
std::random_device entropySource_;
uint64_t
getSeed() override
{
return entropySource_();
}
public:
EntropyNucleus(string const& SPEC)
: entropySource_{SPEC}
{ }
};
class EternalNucleus
: public SeedNucleus
{
uint64_t
getSeed() override
{
return LIFE_AND_UNIVERSE_4EVER;
}
};
/** static global entropy source instance */
EntropyNucleus entropyNucleus{ENTROPY_SOURCE_SPEC};
/// @todo this one should somehow be configurable
EternalNucleus eternalNucleus;
Library: implement test access to hidden global `RandomSequencer` this seems to be the ''classical problem situation'' where a »clean« Dependency-Injection would require to waste storage for a pointer to the same global resource in each and every distinct test class. Since the Test-Suite is effectively global — even more so now due to the reliance on "the" global `RandomSequencer` (PNRG) — we'll have to bite the bullet and access a global static variable hidden behind teh scenes.
2024-11-10 16:22:46 +01:00
Random::Seed defaultNucleus{defaultGen};
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
}
Random defaultGen{eternalNucleus};
Random entropyGen{entropyNucleus};
Library: implement test access to hidden global `RandomSequencer` this seems to be the ''classical problem situation'' where a »clean« Dependency-Injection would require to waste storage for a pointer to the same global resource in each and every distinct test class. Since the Test-Suite is effectively global — even more so now due to the reliance on "the" global `RandomSequencer` (PNRG) — we'll have to bite the bullet and access a global static variable hidden behind teh scenes.
2024-11-10 16:22:46 +01:00
SeedNucleus&
seedFromDefaultGen()
{
return defaultNucleus;
}
SeedNucleus::~SeedNucleus() { }
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
void
randomiseRandomness()
{
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
entropyGen.reseed(entropyNucleus);
defaultGen.reseed(entropyNucleus);
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: 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: implement test access to hidden global `RandomSequencer` this seems to be the ''classical problem situation'' where a »clean« Dependency-Injection would require to waste storage for a pointer to the same global resource in each and every distinct test class. Since the Test-Suite is effectively global — even more so now due to the reliance on "the" global `RandomSequencer` (PNRG) — we'll have to bite the bullet and access a global static variable hidden behind teh scenes.
2024-11-10 16:22:46 +01:00
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 lib
Reference in a new issue Copy permalink