Hi Xiao-Yong,
in that case you may consider my earlier proposal of replacing
/dev/urandom
by your own RNG in written C/C++. You can provide the initial seed
as command line
argument to the RNG in order to make it reproducible.
Also have a
On Thu, May 19, 2016 at 12:37 AM, Xiao-Yong Jin wrote:
> Now,
> (22⍴8)⊤2⊥63⍴1
> 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> Dyalog does the same thing.
> Can someone please explain to me why?
Because the result of ⊥ doesn't fit into integer and it gets converted to a
floating point numbe
Now,
(22⍴8)⊤2⊥63⍴1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Dyalog does the same thing.
Can someone please explain to me why?
> On May 18, 2016, at 1:09 PM, Juergen Sauermann
> wrote:
>
> Hi Kacper,
>
> yes, thanks. Fixed in *SVN 729*.
>
> /// Jürgen
>
>
> On 05/18/2016 07:29 PM,
We need reproducibility, so /dev/urandom isn’t an option.
⎕FIO is a wonderful thing in gnu apl.
I still want something easy to manipulate in apl so I can play with different
ideas easily.
> On May 18, 2016, at 11:56 AM, Juergen Sauermann
> wrote:
>
> Hi Elias,
>
> yes, even better! I was thin
Hi Kacper,
yes, thanks. Fixed in *SVN 729*.
/// Jürgen
On 05/18/2016 07:29 PM, Kacper Gutowski wrote:
On Wed, May 18, 2016 at 5:09 PM, Xiao-Yong Jin wrote:
(...)
relying on ¯1=2⊥64⍴1 (always a 64-bit signed integer), for which Dyalog
does differently.
I think this is a bug.
-k
On Wed, May 18, 2016 at 5:09 PM, Xiao-Yong Jin wrote:
(...)
> relying on ¯1=2⊥64⍴1 (always a 64-bit signed integer), for which Dyalog
> does differently.
I think this is a bug.
-k
Hi Elias,
yes, even better! I was thinking of */dev/random *but that one blocks
immediately
due to lack of entropy.
/// Jürgen
On 05/18/2016 06:41 PM, Elias Mårtenson wrote:
In that case, one can just open /dev/urandom and read random data from
there. That algorithm is supposed to be cryp
Hi,
does not work because Xiao-Yong is looking for a portable solution.
A simple and fast - although not portable - solution is this:
1. write your favourite RNG in C/C++ (ie. copy the source code
from Numerical
Recipes
and wr
In that case, one can just open /dev/urandom and read random data from
there. That algorithm is supposed to be cryptographically secure.
On 19 May 2016 12:39 a.m., "Juergen Sauermann" <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> does not work because Xiao-Yong is looking for a portable solut
How about implementing this as a native quad-function?
On 18 May 2016 at 23:09, Xiao-Yong Jin wrote:
> I translated a simple RNG from the book, Numerical Recipes. APL code is
> slow, probably because of the bit operations. The bit operations are not
> portable, relying on ¯1=2⊥64⍴1 (always a 6
I translated a simple RNG from the book, Numerical Recipes. APL code is slow,
probably because of the bit operations. The bit operations are not portable,
relying on ¯1=2⊥64⍴1 (always a 64-bit signed integer), for which Dyalog does
differently. I’d welcome some suggestions. Full code follows
Hi Xiao-Yong,
I have fixed the redundant %, see SVN 728.
Regarding length, the GNU APL generator is 64-bit long (and so are
GNU APL integers), which should suffice for most purposes.
Regarding bit vectors in APL, most people use integer 0/1 vectors
for
Hi,
> On May 17, 2016, at 12:06 PM, Juergen Sauermann
> wrote:
>
> Hi Xiao-Yong,
>
> the reason is that ⎕RL is defined as a single integer in the ISO standard.
> That prevents generators with a too large state.
Okay. I was thinking whether ⎕RL can be an integer vector. Even a combined
gene
Hi Xiao-Yong,
the reason is that ⎕RL is defined as a single integer in the ISO
standard.
That prevents generators with a too large state.
For somebody seriously into simulations a general purpose
generator
will never suffice, but it is fa
Hi,
The LCG used for roll may be fine for some casual uses, but I would really like
to see a higher quality RNG adopted here. Since speed may not be the main
concern here, employing the use of c++11 and preferably using the
std::mt19937_64 seems to be much better for any monte carlo type calc
15 matches
Mail list logo
