www.sicortex.com
|
From: Bernd Paysan on 14 Apr 2008 11:25 Del Cecchi wrote: > True random numbers are a real pain to generate on a chip. Would > pseudo-random work? Usually, yes. Last time I embedded such a random number generator into a chip (for Audio DSP stuff), I used an xorshift RNG. The main requirement is that all bits are shuffled around for the next cycle, and that the overall bit pattern is unpredictable from the program's point of view. For all current CPUs, generating a new pseudo random number every cycle (regardless what the CPU is doing) is sufficient, and if you have several units using such a random number for rounding, have a different random number sequence (different start value should be sufficient) for each unit is a good idea, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
From: Greg Lindahl on 14 Apr 2008 13:13 In article <44e9d5-b3j.ln1(a)vimes.paysan.nom>, Bernd Paysan <bernd.paysan(a)gmx.de> wrote: >E.g. if you do your 14 days weather forecast with "the >required precision", you forget that your actual data is not that precise, >either. You may not lose any precision during the calculation process, but >if you change one of the inputs by just one bit, you end up with completely >different weather. .... which is why many weather forecasts are done as an ensemble computation. >It's a shame that random rounding is not supported by common number >crunching hardware. You can always randomly perturb the data during the computation; no need for hardware. -- greg
From: Nick Maclaren on 24 Apr 2008 05:20 In article <4803909e$1(a)news.meer.net>, lindahl(a)pbm.com (Greg Lindahl) writes: |> In article <44e9d5-b3j.ln1(a)vimes.paysan.nom>, |> Bernd Paysan <bernd.paysan(a)gmx.de> wrote: |> |> >It's a shame that random rounding is not supported by common number |> >crunching hardware. |> |> You can always randomly perturb the data during the computation; no |> need for hardware. That's not equivalent, and doesn't have the same advantages, but you can obviously do random rounding in software just as well as in hardware (if much more slowly). Regards, Nick Maclaren.
From: Nick Maclaren on 24 Apr 2008 05:23 In article <8k9cd5-2jf.ln1(a)annette.mikron.de>, Bernd Paysan <bernd.paysan(a)gmx.de> writes: |> Del Cecchi wrote: |> > True random numbers are a real pain to generate on a chip. Would |> > pseudo-random work? |> |> Usually, yes. Last time I embedded such a random number generator into a |> chip (for Audio DSP stuff), I used an xorshift RNG. The main requirement is |> that all bits are shuffled around for the next cycle, and that the overall |> bit pattern is unpredictable from the program's point of view. ... Yes, precisely. It is an open theoretical question whether that it is always possible, but all practical evidence is that it is. You need to do a bit better than a simple shift-register RNG, but there is no problem in implementing extremely fast, excellent quality RNGs in hardware. Regards, Nick Maclaren.
From: Nick Maclaren on 24 Apr 2008 05:26
In article <44e9d5-b3j.ln1(a)vimes.paysan.nom>, Bernd Paysan <bernd.paysan(a)gmx.de> writes: |> |> > You can't even solve a large, well-conditioned set of linear equations |> > in single precision, if the matrix is banded - there is a limit of |> > about a million on the number of equations at which point ALL accuracy |> > is lost. See Wilkinson and Reinsch. Solving a mere 10,000 (which can |> > be done easily even for unbanded matrices) won't give you more than |> > about 1% accuracy. And those are the BEST cases - any ill-conditioning |> > and forget it! |> |> Question: How do you get the coefficients for such a matrix to be more |> accurate than SP? I mean for a real-world problem. ... I could give examples (not many), but that's not my point. My point is that the actual OPERATION (i.e. solution of equations) introduces an error of the dimension times the precision times the condition number. Even if the last is 1.0 (fairly rare in practice), single precision solutions are grossly inaccurate. As I said, see Wilkinson and Reinsch. Regards, Nick Maclaren. |