[1] | 1 | <html> |
---|
| 2 | <head> |
---|
| 3 | <title>Phase Space Cuts</title> |
---|
| 4 | <link rel="stylesheet" type="text/css" href="pythia.css"/> |
---|
| 5 | <link rel="shortcut icon" href="pythia32.gif"/> |
---|
| 6 | </head> |
---|
| 7 | <body> |
---|
| 8 | |
---|
| 9 | <h2>Phase Space Cuts</h2> |
---|
| 10 | |
---|
| 11 | <code>PhaseSpace</code> is base class for all hard-process phase-space |
---|
| 12 | generators, either generic <i>2 -> 1</i> or <i>2 -> 2</i> ones, |
---|
| 13 | or specialized ones like for elastic and diffractive scattering. |
---|
| 14 | |
---|
| 15 | <p/> |
---|
| 16 | In it, it is possible to constrain the kinematics of most processes. |
---|
| 17 | (Exceptions are "soft physics", i.e. minimum bias, elastic and |
---|
| 18 | diffractive processes. The Coulomb singularity for elastic scatterings, |
---|
| 19 | if simulated, is <a href="TotalCrossSections.html" target="page">handled separately</a>.) |
---|
| 20 | These constraints apply in the rest frame of the hard subprocess, and |
---|
| 21 | topologies normally would be changed e.g. by subsequent showering |
---|
| 22 | activity. The cross section of a process is adjusted to only |
---|
| 23 | correspond to the allowed phase space. |
---|
| 24 | |
---|
| 25 | <p/> |
---|
| 26 | The more particles in the final state, the more cuts could be applied. |
---|
| 27 | Here we have tried to remain with the useful minimum, however. More |
---|
| 28 | generic possibilities could be handled by the |
---|
| 29 | <a href="UserHooks.html" target="page">user hooks</a> facility. |
---|
| 30 | |
---|
| 31 | <h3>Cuts in all processes</h3> |
---|
| 32 | |
---|
| 33 | <p/><code>parm </code><strong> PhaseSpace:mHatMin </strong> |
---|
| 34 | (<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 35 | The minimum invariant mass. |
---|
| 36 | |
---|
| 37 | |
---|
| 38 | <p/><code>parm </code><strong> PhaseSpace:mHatMax </strong> |
---|
| 39 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 40 | The maximum invariant mass. |
---|
| 41 | A value below <code>mHatMin</code> means there is no upper limit. |
---|
| 42 | |
---|
| 43 | |
---|
| 44 | <h3>Cuts in <i>2 -> 1</i> processes</h3> |
---|
| 45 | |
---|
| 46 | When a resonance <code>id</code> is produced, the |
---|
| 47 | <code><a href="ParticleDataScheme.html" target="page">mMin(id)</a></code> and |
---|
| 48 | <code><a href="ParticleDataScheme.html" target="page">mMax(id)</a></code> |
---|
| 49 | methods restrict the allowed mass range |
---|
| 50 | of this resonance. Therefore the allowed range is chosen to be the |
---|
| 51 | overlap of this range and the <code>mHatMin</code> to |
---|
| 52 | <code>mHatMax</code> range above. Most resonances by default have no |
---|
| 53 | upper mass limit, so effects mainly concern the lower limit. |
---|
| 54 | Should there be no overlap between the two ranges then the process |
---|
| 55 | will be switched off. |
---|
| 56 | |
---|
| 57 | <h3>Cuts in <i>2 -> 2</i> processes</h3> |
---|
| 58 | |
---|
| 59 | <p/><code>parm </code><strong> PhaseSpace:pTHatMin </strong> |
---|
| 60 | (<code>default = <strong>0.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 61 | The minimum invariant <i>pT</i>. |
---|
| 62 | |
---|
| 63 | |
---|
| 64 | <p/><code>parm </code><strong> PhaseSpace:pTHatMax </strong> |
---|
| 65 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 66 | The maximum invariant <i>pT</i>. |
---|
| 67 | A value below <code>pTHatMin</code> means there is no upper limit. |
---|
| 68 | |
---|
| 69 | |
---|
| 70 | <p/><code>parm </code><strong> PhaseSpace:pTHatMinDiverge </strong> |
---|
| 71 | (<code>default = <strong>1.</strong></code>; <code>minimum = 0.5</code>)<br/> |
---|
| 72 | Extra <i>pT</i> cut to avoid the divergences of some processes |
---|
| 73 | in the limit <i>pT -> 0</i>. Specifically, if either or both |
---|
| 74 | produced particles have a mass below <code>pTHatMinDiverge</code> |
---|
| 75 | then <i>pT</i> is limited from below by the larger of |
---|
| 76 | <code>pTHatMin</code> and <code>pTHatMinDiverge</code>. |
---|
| 77 | |
---|
| 78 | |
---|
| 79 | <p/><code>flag </code><strong> PhaseSpace:useBreitWigners </strong> |
---|
| 80 | (<code>default = <strong>on</strong></code>)<br/> |
---|
| 81 | Allows masses to be selected according to Breit-Wigner shapes in |
---|
| 82 | <i>2 -> 2</i> processes, whenever particles have been declared |
---|
| 83 | with a nonvanishing width above the threshold below. In those cases |
---|
| 84 | also the limits below will be used for the mass selection. For |
---|
| 85 | <i>2 -> 1</i> processes the Breit-Wigner shape is part of the |
---|
| 86 | cross section itself, and therefore always included. |
---|
| 87 | |
---|
| 88 | |
---|
| 89 | <p/><code>parm </code><strong> PhaseSpace:minWidthBreitWigners </strong> |
---|
| 90 | (<code>default = <strong>0.01</strong></code>; <code>minimum = 1e-6</code>)<br/> |
---|
| 91 | The minimum width a resonance must have for the mass to be dynamically |
---|
| 92 | selected according to a Breit-Wigner shape, within the limits set below. |
---|
| 93 | Only applies when <code>useBreitWigners</code> is on; else the nominal |
---|
| 94 | mass value is always used. |
---|
| 95 | |
---|
| 96 | |
---|
| 97 | <p/> |
---|
| 98 | For a particle with a Breit-Wigner shape selected, according to the |
---|
| 99 | rules above and to the rules of the particle species itself, the |
---|
| 100 | <code><a href="ParticleDataScheme.html" target="page">mMin(id)</a></code> and |
---|
| 101 | <code><a href="ParticleDataScheme.html" target="page">mMax(id)</a></code> |
---|
| 102 | methods restrict the allowed mass range of the particle, just like for |
---|
| 103 | the <i>2 -> 1 </i> processes. |
---|
| 104 | |
---|
| 105 | <h3>Cuts in <i>2 -> 3</i> processes</h3> |
---|
| 106 | |
---|
| 107 | There are two main classes of <i>2 -> 3</i> processes. One is the |
---|
| 108 | processes such as <i>WW/ZZ</i>-fusion Higgs production, i.e. |
---|
| 109 | <i>q q -> q q H</i>, where there are no special singularities |
---|
| 110 | associated with two partons in the final state being collinear, |
---|
| 111 | or even for <i>pT -> 0</i>. For this class, no further cuts |
---|
| 112 | have been introduced than those already available for <i>2 -> 2</i> |
---|
| 113 | processes. Specifically, for now all three are restricted exactly the |
---|
| 114 | same way by <code>pTHatMin</code> and <code>pTHatMax</code>. As above, |
---|
| 115 | Breit-Wigner mass ranges can be restricted. |
---|
| 116 | |
---|
| 117 | <p/> |
---|
| 118 | The other <i>2 -> 3</i> event class is QCD processes, such as |
---|
| 119 | <i>g g -> g g g</i>. Here the soft and collinear singularities |
---|
| 120 | play a major role, and the phase space generation and cuts have |
---|
| 121 | been adapted to this. For this class, an alternative set of cuts |
---|
| 122 | is used, as outlined in the following. First of all the three |
---|
| 123 | outgoing partons are ordered in falling <i>pT</i>, i.e. |
---|
| 124 | <i>pT_3 > pT_4 > pT_5</i> (where the labelling 3, 4, 5 of the outgoing |
---|
| 125 | partons is random, i.e. unrelated to the order specified in the |
---|
| 126 | process name). The allowed ranges of <i>pT_3</i> and <i>pT_5</i> |
---|
| 127 | can be specified, but obviously <i>pT_3max >= pT_5max</i> and |
---|
| 128 | <i>pT_3min >= pT_5min</i>. The <i>pT_4</i> is not constrained |
---|
| 129 | explicitly, but is constructed from the vector sum of <i>pT_3</i> |
---|
| 130 | and <i>pT_5</i>, subject to the constraint that it has to lie |
---|
| 131 | between the two in magnitude. While the <i>pT</i> cuts take care |
---|
| 132 | of singularities collinear with the incoming beams, it is also |
---|
| 133 | necessary to handle final-state singularities, when two outgoing |
---|
| 134 | partons become collinear. This is done by requiring a minimal |
---|
| 135 | separation in <i>R</i>, where |
---|
| 136 | <i>R^2 = (Delta eta)^2 + (Delta phi)^2</i>. |
---|
| 137 | Finally, a note about efficiency. The QCD <i>2 -> 3</i> phase space |
---|
| 138 | is not set up to explicitly include <i>mHat</i> as one of the basic |
---|
| 139 | variables. Such a cut is only done after a phase space point is already |
---|
| 140 | selected, which means that a narrow mass choice will slow down the |
---|
| 141 | program appreciably. Also narrow <i>pT_3</i> and <i>pT_5</i> bins |
---|
| 142 | are likely to give inefficient generation, if it gives rise to |
---|
| 143 | significant indirect restrictions on <i>pT_4</i>. |
---|
| 144 | |
---|
| 145 | <p/><code>parm </code><strong> PhaseSpace:pTHat3Min </strong> |
---|
| 146 | (<code>default = <strong>10.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 147 | The minimum invariant <i>pT</i> of the highest-<i>pT</i> parton in |
---|
| 148 | QCD <i>2 -> 3</i> processes. |
---|
| 149 | |
---|
| 150 | |
---|
| 151 | <p/><code>parm </code><strong> PhaseSpace:pTHat3Max </strong> |
---|
| 152 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 153 | The maximum invariant <i>pT</i> of the highest-<i>pT</i> parton in |
---|
| 154 | QCD <i>2 -> 3</i> processes |
---|
| 155 | A value below <code>pTHat3Min</code> means there is no upper limit. |
---|
| 156 | |
---|
| 157 | |
---|
| 158 | <p/><code>parm </code><strong> PhaseSpace:pTHat5Min </strong> |
---|
| 159 | (<code>default = <strong>10.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 160 | The minimum invariant <i>pT</i> of the lowest-<i>pT</i> parton in |
---|
| 161 | QCD <i>2 -> 3</i> processes. |
---|
| 162 | |
---|
| 163 | |
---|
| 164 | <p/><code>parm </code><strong> PhaseSpace:pTHat5Max </strong> |
---|
| 165 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 166 | The maximum invariant <i>pT</i> of the lowest-<i>pT</i> parton in |
---|
| 167 | QCD <i>2 -> 3</i> processes |
---|
| 168 | A value below <code>pTHat5Min</code> means there is no upper limit. |
---|
| 169 | |
---|
| 170 | |
---|
| 171 | <p/><code>parm </code><strong> PhaseSpace:RsepMin </strong> |
---|
| 172 | (<code>default = <strong>1.</strong></code>)<br/> |
---|
| 173 | The minimum separation <i>R</i> in <i>(eta, phi)</i> space between |
---|
| 174 | any two outgoing partons in QCD <i>2 -> 3</i> processes. |
---|
| 175 | |
---|
| 176 | |
---|
| 177 | |
---|
| 178 | <h3>Cuts for a second hard process</h3> |
---|
| 179 | |
---|
| 180 | If you use the machinery that allows the generation of a specified |
---|
| 181 | <a href="ASecondHardProcess.html" target="page">second hard process</a> then, |
---|
| 182 | by default, the same phase space cuts will be used for it as listed |
---|
| 183 | above. Optionally, however, you may use a second set of cuts, as |
---|
| 184 | described here. In this context "first" and "second" is merely a |
---|
| 185 | technical distinction; you are welcome e.g. to pick <i>pT</i> ranges |
---|
| 186 | such that the second interaction always has a larger <i>pT</i> than |
---|
| 187 | the first. |
---|
| 188 | |
---|
| 189 | <p/><code>flag </code><strong> PhaseSpace:sameForSecond </strong> |
---|
| 190 | (<code>default = <strong>on</strong></code>)<br/> |
---|
| 191 | By default use the same cuts for a second hard process as for the |
---|
| 192 | first. If <code>off</code> then instead use the mass and <i>pT</i> |
---|
| 193 | cuts below, where relevant. (The other cuts above still remain the same.) |
---|
| 194 | |
---|
| 195 | |
---|
| 196 | <p/><code>parm </code><strong> PhaseSpace:mHatMinSecond </strong> |
---|
| 197 | (<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 198 | The minimum invariant mass for a second interaction, if separate. |
---|
| 199 | |
---|
| 200 | |
---|
| 201 | <p/><code>parm </code><strong> PhaseSpace:mHatMaxSecond </strong> |
---|
| 202 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 203 | The maximum invariant mass for a second interaction, if separate. |
---|
| 204 | A value below <code>mHatMin</code> means there is no upper limit. |
---|
| 205 | |
---|
| 206 | |
---|
| 207 | <p/><code>parm </code><strong> PhaseSpace:pTHatMinSecond </strong> |
---|
| 208 | (<code>default = <strong>0.</strong></code>; <code>minimum = 0.</code>)<br/> |
---|
| 209 | The minimum invariant <i>pT</i> for a second interaction, if separate. |
---|
| 210 | |
---|
| 211 | |
---|
| 212 | <p/><code>parm </code><strong> PhaseSpace:pTHatMaxSecond </strong> |
---|
| 213 | (<code>default = <strong>-1.</strong></code>)<br/> |
---|
| 214 | The maximum invariant <i>pT</i> for a second interaction, if separate. |
---|
| 215 | A value below <code>pTHatMin</code> means there is no upper limit. |
---|
| 216 | |
---|
| 217 | |
---|
| 218 | <h3>Generation strategy and documentation</h3> |
---|
| 219 | |
---|
| 220 | During the initialization stage a simplified function is found, |
---|
| 221 | that is intended to be above the true cross-section behaviour |
---|
| 222 | over the whole of phase space. It is chosen to be easily integrable |
---|
| 223 | and invertible. That way a trial phase space point can be selected |
---|
| 224 | according this simple function, and then be accepted by the ratio of |
---|
| 225 | true to the simple function. For a good efficieny the ratio should be |
---|
| 226 | close to unity, yet never above it. This constrains the absolute |
---|
| 227 | normalization of the simple function. The initial search may fail to |
---|
| 228 | find the phase space point where the true-to-simple ratio is maximal, |
---|
| 229 | however. This then can lead to subsequent maximum violations, where the |
---|
| 230 | ratio is above unity. Two alternative strategies are implemented to |
---|
| 231 | handle such situations, see below. |
---|
| 232 | |
---|
| 233 | <p/><code>flag </code><strong> PhaseSpace:showSearch </strong> |
---|
| 234 | (<code>default = <strong>off</strong></code>)<br/> |
---|
| 235 | Possibility to print information on the search for phase-space |
---|
| 236 | coefficients that (in a multichannel approach) provides an analytical |
---|
| 237 | upper envelope of the differential cross section, and the |
---|
| 238 | corresponding upper estimate of the cross section. Of interest |
---|
| 239 | for crosschecks by expert users only. |
---|
| 240 | |
---|
| 241 | |
---|
| 242 | <p/><code>flag </code><strong> PhaseSpace:showViolation </strong> |
---|
| 243 | (<code>default = <strong>off</strong></code>)<br/> |
---|
| 244 | Possibility to print information whenever the assumed maximum |
---|
| 245 | differential cross section of a process is violated, i.e. when |
---|
| 246 | the initial maximization procedure did not find the true maximum. |
---|
| 247 | Also, should negative cross sections occur, print whenever a more |
---|
| 248 | negative value is encountered. |
---|
| 249 | |
---|
| 250 | |
---|
| 251 | <p/><code>flag </code><strong> PhaseSpace:increaseMaximum </strong> |
---|
| 252 | (<code>default = <strong>off</strong></code>)<br/> |
---|
| 253 | Strategy for handling cases where a larger cross section is |
---|
| 254 | obtained during the event generation than was assumed at initialization, |
---|
| 255 | i.e. when a violation occurs. |
---|
| 256 | <br/><b>off:</b>each event comes with a weight, which normally is unity |
---|
| 257 | (as a consequence of the acceptance/rejection step), and is found in |
---|
| 258 | <code><a href="EventInformation.html" target="page">Info::weight()</a></code>. |
---|
| 259 | For events which exceed the maximum instead the true-to-simple ratio |
---|
| 260 | is stored as event weight, which then is above unity. If the user so |
---|
| 261 | wishes this weight can then be carried along when event properties are |
---|
| 262 | histogrammed. Since normally such violations should be rare and not |
---|
| 263 | too much above unity one could expect most users to ignore such issues |
---|
| 264 | be default. Should maximum violations turn out to be frequent (visible |
---|
| 265 | in the <code><a href="EventStatistics.html" target="page">Pythia::statistics()</a></code> |
---|
| 266 | output) the option exists to use the information. |
---|
| 267 | <br/><b>on:</b>the maximum is increased whenever it is exceeded. Thus |
---|
| 268 | events generated after this point will be "correctly" distributed, |
---|
| 269 | while ones generated previously obviously then have had too high a |
---|
| 270 | relative weight. If violations occur early on and/or are small this |
---|
| 271 | strategy should do a good job of correcting to the desired phase-space |
---|
| 272 | distribution. This strategy may be more convenient for the normal user, |
---|
| 273 | who would not wish to worry about event weights. It does have the |
---|
| 274 | disadvantage that the raised maximum introduces an extra amount of |
---|
| 275 | "history memory" to the generation sequence, so that it becomes less |
---|
| 276 | easy to save-and-restore the <a href="RandomNumbers.html" target="page">random-number |
---|
| 277 | state</a> for debugging purposes. |
---|
| 278 | |
---|
| 279 | |
---|
| 280 | <h3>Reweighting of <i>2 -> 2</i> processes</h3> |
---|
| 281 | |
---|
| 282 | Events normally come with unit weight, i.e. are distributed across |
---|
| 283 | the allowed phase space region according to the appropriate differential |
---|
| 284 | cross sections. Sometimes it may be convenient to have an uneven |
---|
| 285 | distribution of events. The classical example here is that many cross |
---|
| 286 | sections drop off with transverse momentum <i>pT</i>, such that few |
---|
| 287 | events are generated at large <i>pT</i> scales. If one wants to |
---|
| 288 | plot the <i>pT</i> cross section, and all that comes with it, the |
---|
| 289 | statistical error will then degrade with increasing <i>pT</i> |
---|
| 290 | where fewer events end up. |
---|
| 291 | |
---|
| 292 | <p/> |
---|
| 293 | One solution is to split the full <i>pT</i> range into several |
---|
| 294 | separate subranges, where the events of each subsample obtains a |
---|
| 295 | different overall normalization. Specifically, if you generate a |
---|
| 296 | comparable number of events in each <i>pT</i> bin, such that |
---|
| 297 | larger <i>pT</i> bins are oversampled, these bins come with a |
---|
| 298 | correspondingly reduced overall weight, that needs to be taken into |
---|
| 299 | account when the bins are combined. The other is to have a continuously |
---|
| 300 | increasing oversampling of events at larger <i>pT</i> scales, which |
---|
| 301 | is compensated by a continuously decreasing weight for the event. |
---|
| 302 | |
---|
| 303 | <p/> |
---|
| 304 | Both of these solutions are supported. Specifically, for |
---|
| 305 | <i>2 -> 2</i> processes, the <i>pTHat</i> scale offers a |
---|
| 306 | convenient classification of the event. (Of course, two events |
---|
| 307 | starting out from the same <i>pTHat</i> scale will experience |
---|
| 308 | different parton shower evolutions, etc., and may therefore look |
---|
| 309 | quite different at the end.) The two cuts |
---|
| 310 | <code>PhaseSpace:pTHatMin</code> and <code>PhaseSpace:pTHatMax</code> |
---|
| 311 | therefore offers a way to slice a <i>pT</i> range into subranges, |
---|
| 312 | see e.g. <code>main08.cc</code>. Alternatively the |
---|
| 313 | <a href="UserHooks.html" target="page">User Hooks</a> machinery offers the |
---|
| 314 | possibility for you to define your own reweighting of phase space |
---|
| 315 | sampling, with a corresponding event weight, with |
---|
| 316 | <code>UserHooks::canBiasSelection</code> and related methods. |
---|
| 317 | |
---|
| 318 | <p/> |
---|
| 319 | As a simplified option, we here offer the possibility to bias the |
---|
| 320 | <i>2 -> 2</i> sampling by a power of <i>pTHat</i>, then with |
---|
| 321 | events having a weight the inverse of this. This fast track will only |
---|
| 322 | work under a number of strict conditions, implemented to reduce the |
---|
| 323 | risk of abuse. (Whereas a <code>UserHooks</code> setup can be more |
---|
| 324 | flexible.) Specifically it will work if only high-<i>pT</i> |
---|
| 325 | <i>2 -> 2</i> processes already implemented in PYTHIA are requested, |
---|
| 326 | notably the <code>HardQCD</code> ones. That is, you cannot mix with |
---|
| 327 | <i>2 -> 1</i> or <i>2 -> 3</i> processes, nor with external |
---|
| 328 | processes (notably Les Houches input) or <code>SoftQCD</code> ones, |
---|
| 329 | and you cannot use the option to define a |
---|
| 330 | <a href="ASecondHardProcess.html" target="page">second hard process</a> in |
---|
| 331 | the same event. Furthermore you have to be careful about the choice |
---|
| 332 | of <code>PhaseSpace:pTHatMin</code>, since a <i>pTHat = 0</i> |
---|
| 333 | event would come with an infinite weight. |
---|
| 334 | |
---|
| 335 | <p/><code>flag </code><strong> PhaseSpace:bias2Selection </strong> |
---|
| 336 | (<code>default = <strong>off</strong></code>)<br/> |
---|
| 337 | Possibility to switch on a biased phase space sampling, |
---|
| 338 | with compensatingly weighted events, for <i>2 -> 2</i> processes. |
---|
| 339 | Can only be used under the specific conditions explained in |
---|
| 340 | the paragraph above; under other conditions the initialization |
---|
| 341 | will abort. |
---|
| 342 | |
---|
| 343 | |
---|
| 344 | <p/><code>parm </code><strong> PhaseSpace:bias2SelectionPow </strong> |
---|
| 345 | (<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>; <code>maximum = 10.</code>)<br/> |
---|
| 346 | If the above flag is on, then a <i>2 -> 2</i> process at a scale |
---|
| 347 | <i>pTHat</i> will be oversampled in phase space by an amount |
---|
| 348 | <i>(pTHat/pTRef)^pow</i>, where you set the power <i>pow</i> |
---|
| 349 | here. Events are assigned a compensating |
---|
| 350 | <a href="EventInformation.html" target="page">weight</a> the inverse of this, |
---|
| 351 | i.e. <code>Info::weight()</code> will return <i>(pTRef/pTHat)^pow</i>. |
---|
| 352 | This weight should then be used in the histogramming of event properties. |
---|
| 353 | The final overall normalization also involves the |
---|
| 354 | <code>Info::weightSum()</code> value. |
---|
| 355 | |
---|
| 356 | |
---|
| 357 | <p/><code>parm </code><strong> PhaseSpace:bias2SelectionRef </strong> |
---|
| 358 | (<code>default = <strong>10.</strong></code>; <code>minimum = 1.</code>)<br/> |
---|
| 359 | The reference scale <i>pTRef</i> introduced above, such that events |
---|
| 360 | with this <i>pTHat</i> obtain unit weight in the reweighting procedure. |
---|
| 361 | The value of this parameter has no impact on the final result of the |
---|
| 362 | reweighting procedure, but is only there for convenience, i.e. to |
---|
| 363 | give "reasonably-sized" weights. |
---|
| 364 | |
---|
| 365 | |
---|
| 366 | </body> |
---|
| 367 | </html> |
---|
| 368 | |
---|
| 369 | <!-- Copyright (C) 2012 Torbjorn Sjostrand --> |
---|