I think there are already enough evidences to call for further investigation to prove or disprove the bug.
Чт, 17 дек 2015, Raul Miller написал(а): > On Thu, Dec 17, 2015 at 12:40 PM, 'Pascal Jasmin' via Programming > <[email protected]> wrote: > > ?. 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 > > 2 2 2 2 2 2 2 2 2 2 2 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 > > 0 0 0 0 1 1 0 0 0 1 1 1 0 0 0 0 1 0 0 0 0 1 1 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 > > 0 1 1 1 1 0 0 1 1 1 8 9 6 8 14 7 12 9 1 15 2 15 3 13 3 > > > > ?. 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 > > 2 2 2 2 2 2 2 2 2 2 2 2 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 > > 0 1 0 1 1 0 0 1 1 1 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 > > 1 0 1 1 1 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 1 1 > > > > > > one less leading 2 in first example. 47 leading 2s, correct result. 48 > > leading 2s and everything is 2. > > So? > > Consider this: > > ?.4#4 > 2 0 0 2 > 4{.?.400#4 > 2 0 2 0 > > The size of the right argument influences the values generated at each > position. > > You would need to perform a large number of experiments to show a > statistical flaw in the results. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
