You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1) Missing assignment operators for hydra::FunctionArgments
12
+
13
+
2) Covering composite of composites (https://github.com/MultithreadCorner/Hydra/issues/100)
14
+
15
+
16
+
### Hydra 3.2.1
17
+
18
+
This release:
19
+
20
+
1) In certain corner cases, a substantial part of the calculations performed to evaluate a functor depends only on the functor's state and it's parameters; i.e. it does not depend on the current functor's arguments that can be dataset points, numerical integration abscissas and so on. To further optimize the calculations in these cases, Hydra now provides the method ``virtual void hydra::Parameter::Update(void)``, which can be overridden by the functors
21
+
in order to pre-calculate the factors only depending in the parameters, before the calculations are distributed to one of the parallel backends.
22
+
23
+
2) Introduction of `hydra::random_range` and retirement of `hydra::random_uniform_range`, `hydra::random_gaussian_range`, `hydra::random_exp_range` , to define iterators for drawing samples from functors. Examples updated accordingly.
24
+
25
+
26
+
Bug fixes:
27
+
28
+
1) ROOT examples updated and tested against ROOT/6.22.00. ( https://github.com/MultithreadCorner/Hydra/commit/acd303e7fb21d220beb7986ab7122206ac6a8eed )
29
+
30
+
2) Correction of `hydra::CrystalBallShape` math. ( https://github.com/MultithreadCorner/Hydra/commit/a7ce56d4c9efad46351ddee630f7afce245c9909 )
31
+
32
+
3) Spelling of some words (in code) accross the tree. (https://github.com/MultithreadCorner/Hydra/commit/d2161898bd9ed4e09ee6593d27372c8ad43347b1)
33
+
34
+
4) Fixing fallback path in `MSB.h`. ( https://github.com/MultithreadCorner/Hydra/commit/5b10e05e2517c27f270507c27ea76c85a62e24f5 )
35
+
36
+
5) Reimplementation of `hydra::detail::is_valid_type_pack` ( https://github.com/MultithreadCorner/Hydra/commit/f30b97a414f513e3e410195555bd0eb8f44eb9f9 )
37
+
38
+
39
+
-------------------------------------
40
+
41
+
42
+
### Hydra 3.1.0
43
+
44
+
This release substantially expands the set of pseudorandom number generators available in Hydra.
45
+
From Random123 (see: *John K. Salmon and others, (2011) "Parallel random numbers: as easy as 1, 2, 3"*. https://dl.acm.org/doi/10.1145/2063384.2063405), Hydra provides wrappers and implementations for
46
+
47
+
1)*Philox*
48
+
2)*Ars*
49
+
3)*Threefry*
50
+
51
+
*Squares* PRNG ( see: *Widynski, Bernard (2020). "Squares: A Fast Counter-Based RNG"*. https://arxiv.org/abs/2004.06278v2 ), are available from now, in two versions:
52
+
53
+
1)*Squares3*
54
+
2)*Squares4*
55
+
56
+
All the new generators belong to the *count-based family*, have excelent statistical properties, passing BigCrush (TestU01) and other tests easily, without any failure. All implementations provide very long periods (2^64 -1 or higher). For Squares{3,4}, users get a set of 2500 precalculated seeds for generation of sequences (streams) without statistical artifacts among them (all credits to Bernard Widynski!).
57
+
58
+
In summary, ***Squares3, Squares4 and Philox are way faster*** than the any option available in the previous releases. Ars and Threefry are competitive, being most of the time slightly faster than the fastest native `Thrust` rng.
59
+
60
+
**From this release, the defaut PRNG in Hydra is set to hydra::squares3**.
61
+
62
+
#### General
63
+
64
+
* Bug fixed in ```hydra::unweight``` implementation.
65
+
* Other minor fixes and modifitions across the tree.
66
+
67
+
______________________________
68
+
69
+
3
70
### Hydra 3.0.0
4
71
5
72
It is the first release of the longly waited 3 series. Overall, this release is expected to be faster
@@ -23,7 +90,7 @@ This is probably the most impacting change in this release, making **Hydra3** se
23
90
24
91
1. New interface for calling functors and lambdas.
25
92
26
-
a) Extensive statically-bound named parameter idiom support. This new idiom for specification of function call interfaces makes the definition callable objects in **Hydra3** much more safe, straight forward, transparent and user friendly, without compromise performance. In many cases enhancing performance, indeed. From **Hydra3**, users will be able to define new types, with *ad hoc* names wrapping around primary types, using the macro ```declvar(NewVar, Type)```.
93
+
a) Extensive statically-bound named parameter idiom support. This new idiom for specification of function call interfaces makes the definition callable objects in **Hydra3** much more safe, straight forward, transparent and user friendly, without compromise performance. In many cases enhancing performance, indeed. From **Hydra3**, users will be able to define new types, with *ad hoc* names wrapping around primary types, using the macro ```declarg(NewVar, Type)```.
27
94
These new types are searched in compile time to bind the function call, if the type
28
95
is not found a compile error is emitted, avoiding the generation of invalid or error prone code.
29
96
See how it works:
@@ -33,7 +100,7 @@ See how it works:
33
100
#include <hydra/functions/Gaussian.h>
34
101
...
35
102
36
-
declvar(Angle, double)
103
+
declarg(Angle, double)
37
104
38
105
int main(int argv, char** argc)
39
106
{
@@ -52,9 +119,9 @@ See how it works:
52
119
#include <hydra/multivector.h>
53
120
...
54
121
55
-
declvar(X, double)
56
-
declvar(Y, double)
57
-
declvar(Z, double)
122
+
declarg(X, double)
123
+
declarg(Y, double)
124
+
declarg(Z, double)
58
125
59
126
int main(int argv, char** argc)
60
127
{
@@ -105,9 +172,9 @@ See how it works:
105
172
#include <hydra/Lambda.h>
106
173
...
107
174
108
-
declvar(X, double)
109
-
declvar(Y, double)
110
-
declvar(Z, double)
175
+
declarg(X, double)
176
+
declarg(Y, double)
177
+
declarg(Z, double)
111
178
112
179
int main(int argv, char** argc)
113
180
{
@@ -137,7 +204,7 @@ is not found a compile error is emitted, informing and suggesting the user to us
137
204
#include <hydra/functions/Gaussian.h>
138
205
...
139
206
140
-
declvar(Xvar, double)
207
+
declarg(Xvar, double)
141
208
142
209
int main(int argv, char** argc)
143
210
{
@@ -165,7 +232,40 @@ The filling functions can be called also with a specific backend policy and with
165
232
166
233
#### Data fitting
167
234
168
-
1. Adding support to simultaneous fit.
235
+
1. Added support to multi-layered simultaneous fit of different models, over different datasets, deploying different parallelization strategies for each model. No categorization of the dataset is needed, but just to set up preliminarly the different component FCNs, that can be optimized in isolation or in the context of the simultaneous FCN. Simultaneous FCNs can be created via direct instantiation or using the convenience function `hydra::make_simultaneous_fcn(...)`, as shown in the following snippet.
auto fcnX = hydra::make_loglikehood_fcn(modelX, dataX);
256
+
auto fcnY = hydra::make_loglikehood_fcn(modelY, dataY);
257
+
auto fcnW = hydra::make_loglikehood_fcn(modelY, dataY);
258
+
auto fcnZ = hydra::make_loglikehood_fcn(modelZ, dataZ);
259
+
auto fcnV = hydra::make_loglikehood_fcn(modelv, datav);
260
+
261
+
auto sim_fcn1 = hydra::make_simultaneous_fcn(fcnx, fcny);
262
+
auto sim_fcn2 = hydra::make_simultaneous_fcn(fcnw, fcnz);
263
+
auto sim_fcn = hydra::make_simultaneous_fcn(sim_fcn1, sim_fcn2, fcnV);
264
+
...
265
+
}
266
+
```
267
+
Moreover, the generic interface allows to build up a simultaneous FCN object by composing usual FCNs and simultaneous FCNs. An example of such new method can be found in `examples/fit/simultaneous_fit.inl`.
Copy file name to clipboardExpand all lines: docs/containers.rst
+26-22Lines changed: 26 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,39 +1,40 @@
1
1
Containers
2
2
==========
3
3
4
-
Hydra framework provides one dimensional STL-like vector containers for each supported back-end, aliasing the underlying Thrust types. Beyond this, Hydra implements two native multidimensional containers: ``hydra::multivector`` and ``hydra::multiarray`` .
5
-
In these containers, the data corresponding to each dimension is stored in contiguous memory regions and when the container is traversed, each entry is accessed as
6
-
a ``hydra::tuple``, where each field holds a value corresponding to a dimension. Both classes implement an interface completely compliant with a STL vector and
7
-
also provides constant and non-constant accessors for the single dimensional data. The container
8
-
``hydra::multivector`` is suitable to store data-sets where the dimensions are represented by entries with different POD types. ``hydra::multiarray`` is designed to store data-sets where all dimensions are represented by fields with the same type. Data is always copyable across different back-ends and movable between containers on the same back-end.
9
-
10
-
4
+
Hydra framework provides an one-dimensional STL-like vector container for each supported back-end, aliasing the underlying Thrust types. The framework also implements two native multidimensional containers called hydra::multivector`` and ``hydra::multiarray`` .
5
+
6
+
In these containers, the data corresponding to each dimension is stored in contiguous memory addresses that can be traversed in a CPU/GPU cache friendly way, independently of the other dimensions. In the case of multidimensional containers, when the data is traversed each entry is accessed as
7
+
a ``hydra::tuple`` object, where each field holds a value corresponding to a dimension.
8
+
11
9
One-dimensional containers
12
10
--------------------------
13
11
14
-
Hydra's one-dimensional containers are aliases to the corresponding [Thrust]_ vectors and defined for each supported back-end. They are:
12
+
Hydra's one-dimensional containers are aliases to the corresponding [Thrust]_ vectors and are defined for each supported back-end. They are:
15
13
16
-
1. ``hydra::device::vector`` : storage allocated in the device back-end defined at compile time using the macro ``THRUST_DEVICE_SYSTEM``
17
-
2. ``hydra::host::vector`` : storage allocated in the device back-end defined at compile time using the macro ``THRUST_HOST_SYSTEM``
14
+
1. ``hydra::device::vector`` : storage allocated in the device back-end defined at compile time using the macro ``HYDRA_DEVICE_SYSTEM``
15
+
2. ``hydra::host::vector`` : storage allocated in the device back-end defined at compile time using the macro ``HYDRA_HOST_SYSTEM``
18
16
3. ``hydra::omp::vector`` : storage allocated in the [OpenMP]_ back-end. Usually the CPU memory space.
19
17
4. ``hydra::tbb::vector`` : storage allocated in the [TBB]_ back-end. Usually the CPU memory space.
20
18
5. ``hydra::cuda::vector`` : storage allocated in the [CUDA]_ back-end. The GPU memory space.
21
19
6. ``hydra::cpp::vector`` : storage allocated in the [CPP]_ back-end. Usually the CPU memory
22
20
23
-
The usage of these containers is extensively documented in the [Thrust]_ library.
21
+
The usage of these containers is extensively documented in STL and [Thrust]_ library. Hydra also implements range-semantics for many of these containers.
24
22
25
23
Multi-dimensional containers
26
24
----------------------------
27
25
28
26
Hydra implements two multidimensional containers:``hydra::multivector`` and ``hydra::multiarray``.
29
27
These containers store data using [SoA]_ layout and provides a STL-vector compliant interface.
30
28
31
-
The best way to understand how these containers operates is to visualize them as a table, there each row corresponds to a entry and each column to a dimension. The design of ``hydra::multivector`` and ``hydra::multiarray`` makes possible to iterate over the container to access a complete row
32
-
or to iterate over one or more columns to access only the data of interest in a given entry, without to load the entire row.
29
+
Both classes provides constant and non-constant accessors for the single dimensional data. The container
30
+
``hydra::multivector`` is suitable to store data-sets where the dimensions are represented by entries with different POD types. ``hydra::multiarray`` is designed to store data-sets where all dimensions are represented by fields of the same type. Data is always copyable across different back-ends and movable between containers on the same back-end.
31
+
32
+
The best way to understand how these containers operate is to visualize them as a table, there each row corresponds to a entry and each column to a dimension. The design of ``hydra::multivector`` and ``hydra::multiarray`` makes possible to iterate over the container to access a complete row
33
+
or to iterate over one or more columns to access only the data of interest in a given entry, without loading the entire row.
33
34
34
-
When the user iterates over the whole container, each entry (row) is returned as a ``hydra::tuple``. If the user iterates over one single column, the entries have the type of the column. If two or more columns are accessed, entry's data is returned as again as ``hydra::tuple`` containing only the elements of interest. Hydra's multi-dimensional containers can hold any type of data per dimension, but there is not real gain using these containers for describing dimensions with non-POD data.
35
+
When the user iterates over the whole container, each entry (row) is returned as a ``hydra::tuple``. If the user iterates over one single column, the entries have the type of the column. If two or more columns are accessed, entry's data is returned as again as ``hydra::tuple`` containing only the elements of interest. Hydra's multi-dimensional containers can hold any type of data per dimension, but there is not real gain using these containers for describing dimensions with non-POD or non alignable data.
35
36
36
-
Both containers can store the state of arbitrary objects and perform type conversions on-the-fly, using suitable overloaded iterators and ``push_back()`` methods.
37
+
These containers can store the state of arbitrary objects and perform type conversions on-the-fly, using suitable overloaded iterators and ``push_back()`` methods.
37
38
38
39
39
40
``hydra::multivector``
@@ -70,7 +71,7 @@ this will print in stdout something like it :
70
71
...
71
72
(9, 18, 9.0, 18.0)
72
73
73
-
To access the columns the user needs to deploy ``hydra::placeholders``: _0, _1, _2,...,_99;
74
+
To access the columns the user needs ``hydra::placeholders``: _0, _1, _2,...,_99;
74
75
75
76
.. code-block:: cpp
76
77
:name: multivector-example2
@@ -90,7 +91,8 @@ To access the columns the user needs to deploy ``hydra::placeholders``: _0, _1,
90
91
}
91
92
92
93
for(auto x = mvector.begin(_1, _3);
93
-
x != mvector.end(_1, _3); x++ )
94
+
x != mvector.end(_1, _3); ++x )
95
+
94
96
std::cout << *x << std::endl;
95
97
96
98
now in stdout the user will get:
@@ -120,13 +122,13 @@ It is not necessary to access each field stored in each entry to perform a conve
120
122
mvector.push_back(hydra::make_tuple( i, 2*i, i, 2*i));
for(auto x = mvector.begin(caster); x != mvector.end(caster); x++ )
@@ -142,9 +144,11 @@ stdout will look like:
142
144
...
143
145
((9, 18), (9.0, 18.0))
144
146
147
+
Same effect can be
148
+
145
149
146
150
``hydra::multiarray``
147
-
......................
151
+
.................
148
152
149
153
150
154
``hydra::multiarray`` templates are instantiated passing the type and the number of dimensions via and the back-end where memory will be allocated. The snippet
0 commit comments