真随机数之略思

今大以Mersenne Twister以作PRNG,大多以梅林旋转演之算。此算法乃基于有限二元场上之矩阵线性递归,且该算法更有状态位反射及回火之合理正形 (TGFSR(R)),即扭曲广义反馈移位寄存器是也,论其法之本,大体以递归之法,反复算之以输,此法可在623维之中,满足精确之32位K分布。 然依余之需求,视之颇有弊端,只因所谓随机性一事,其认见未必符于天地自然之道,盖古之术算,既有纲纪、亦有大定,且有皇极之数,此类数等,已然从天地之纷杂间,析得定数之所在,又加以变数相算,始可定确,盖伪随机之算法,只求之乱,却失其常,此常者,本在天地之间矣。 故余等若用此算,反倒使其乱,本术算之法,其欲于浊中求清以显明,若先搅之为浑,再依浑为算,岂不难乎,更此随机之算,若依随机而生随机,反复而叠,若超之623维之外,又必失其本。 又观其以用以神经网络之算,虽初权以随机相布,然算之每次皆有不同,颇不稳定,盖只可生之一随机序列以作固定之数,再用则同之,如此反复方可。 以余之见,世间万物皆有其周期,但此天地已然成,故若言之尽为随机之或然,则难有此天地,依量子之学,言生五百多亿之宇宙,方产一吾等所在之天地,其辞虽理备,但亦不过预设前提,以先天无定,故后天无所依凭,只可依随机而生,概率相推,方得此大数。 又至于微者,确有未可知之可定,即测不准之古怪,虽微者之茫然,于宏观仍其有定,此于现实可审,如拾筷夹菜,未见此筷随机忽变它物是也。 即宏观之有定,必有大势之相趋,此所趋者,必于天地之有所定,既有所定,故宇宙之道,虽有其浑沦未具之形处,亦有其大定之趋处,吾等研讨,必寻其定处,如此方是其法。 若依量子之学,如始观一物,虽未知波函数坍缩于何处,然观之众物,则必有其方,故世间有大数之理,有正态之分布,又有二向之分布,更有泊松之分布,不然何来吾等稳定之宇宙。 又按此理,虽今日随机之算数,反从分布之法以逆推,故能足各类已知分布之需,然其所缺者,可有未知之分布,今人未知?若是有之,则此不合于自然也。

Read More

Inter CPU 中 RDRAND and RDSEED的区别

在考虑制作测试真正随机数生成卦的时候,发现有文件指出,RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节) 在Inter的《The Difference Between RDRAND and RDSEED》中指出,两者使用间的区别: “The decision process for which instruction to use is mercifully…

Read More

Inter cpu 获取真随机数

Intel在IVB架构的第三代CPU酷睿处理器内置了一个利用电阻热噪声取得硬件真随机数的功能,这里的代码原理就是直接用汇编指令读取16位随机数到aex寄存器。2013年的时候,英国的Kyle Condon在Change.org发起请愿,请求维护者Linus Torvalds为改进内核安全从/dev/random中移除RdRand。因为RdRand是用于生成随机数的一个指令,包含在Intel 64和IA-32指令集架构中,它依赖的一个加密标准是NSA制定的NIST SP800-90,被怀疑存在后门。Linus Torvalds对请愿迅速做出了回应,痛骂了请愿者一顿,称对方太无知。因为在Linux系统中的随机器发生器上/dev/random,会在RdRand的随机数基础上再次进行随机处理,不但能避免出现有后门的情况,同时也可以改进随机数生成的质量。   int rdrand16_step(uint16_t *rand) { unsigned char ok; /* rdrand dx */ __asm { volatile(".byte 0x0f,0xc7,0xf0; setc %1" : "=a" (*rand), "=qm" (ok) :…

Read More

由推论出错谈谈梅花易数起卦中的有趣现象

  上篇文章<<解决了起卦使用真随机数的问题>> 本以为解决了计算机上以九取模的平均分布问题,但是经过实践,发现这样不但得不到平均分布,得到的反而是正态分布,原因是让两个随机数进行了相加。所以如何让九宫的概率严格平均分布暂时还没有解决。   连续的不同的单概率事件累加,总体上它就会出现正态分布,这个满足中心极限定理。   更通俗一点说,0~8中随机取一个数,这个是平均分布的,但是先在0~4个中取1个,再取0~4中取1个,它们累计的和,却是正态分布的,与直接在0~8中任意取一个数的概率分布并不一样。   这是因为0~8中一共是9个数字,而两次的0~4虽然看起来和还是0~8,实际上却是在两次是在10个数字中取了,于是概率就发生了叠加,这就导致了正态分布的出现。        比如按上述方式先取0~4中一个,然后再取,相加起来看是什么卦,进行1000次,结果会形成这样的分布:        乾 63        兑 112        离 178        震 235        巽 192        坎 124        艮 60        坤 36…

Read More

解决起卦的九宫的同余的概率分布问题

  无论是采用九宫模拟还是八卦模拟,产生随机数都会遇到一个问题,即在9或8上不能平均分布,比如产生的随机数范围是0~65535,一共65536个数,而6+5+5+3+6 = 25,2+5=7,余下为7,这会导致生成的随机数分布概率并不均等,所以它们无法满足在9的空间上能够平均分布,这是不符合自然现状的。如果是对于8来说,已知65536为2的16次方,而2的15次方是可以被8整除的,所以分布下来就多了2个,同样会导致在8的空间分布上不平均。   有一种思路是取一个足够大的数,把误差降到最低,比如取值范围为2的64次方,那么多出来的2个不平均分布,只占1/264    的比重影响,可以说是微乎极微。   不过这样始终让人感觉不完美,所以为了追求完美,完全可以改进一下。   因为通常用八卦时不一定要用九宫,用九宫时一定要用到八卦,所以这个问题并不难解决。   需要构造出一个方法,让它都能整除,即存在一个数S        S%8=0  S%9=0   并且 S =2N (n=0,1,2,3,4....)   但这个是没有解的,所以是不现实的,那么就把问题改一下:   如果是2某个次方加上一个数满足这个条件的话,那就会大大减低计算量。     于是搜了一下解集,发现如下可以满足条件:        式  次方值   2^6+8  64   2^12+8 4096   2^18+8 262144   2^24+8 16777216   2^30+8…

Read More

解决了起卦使用真随机数的问题

  对于灵机起卦的术数来说,要做到术数上的准确预测,先要找到目前不可预测的数据,然后从这个数据才可推出可预测的结果,这是个颇为矛盾的逻辑。   而不可预测的数据,自然是真随机数了,至于真正的随机数到底是存在还是不存在,这个很难说,是个哲学问题,万物虽然都是概率的呈现,但是概率又是什么决定的?   回正题,一开始从淘宝上查有没有硬件的真随机数发生器,可惜万能的淘宝令人失望了,然后检查电脑的CPU是Inter的,Inter的CPU正好提供有真随机数的发生器,于是动念头想直接访问Inter的CPU,查了一下,需要下载Inter的数学库,于是就去慢慢下载。   下完后竟然发现不能运行,因为版本太老不支持XCode6,所以竟然连安装都不让安装,只好放弃。   于是又查有没有其它办法可以通过这种方式获取随机数,花了许久,运气不错发现篇文章表示Inter提供直接使用汇编指令来访问CPU。   然后麻烦就来了,这个是MAC的系统,编译出来是dylib库,然后尝试通过mono去调用,无论如何也提示调用不了,找不到文件。然后又继续翻网站,终于发现,原来编译时,只能编译成32位的,这样Mono才能调用,来回折腾了几次后,成功实现真随机数的调用了。   不得不说,国内的资料实在不好查,还是英文网站上的资料比较全一些,虽然折腾了一个晚上,但还是值得的,能够实现真随机数的调用,能够解决很多问题。   产生的真随机数图如下:      而相同绘图算法C#生成随机数如下:      比较奇怪的是,差异并不是很明显,是MAC底层的随机数算法做得极好的缘故?所以近似于真实随机数的效果了?   不过想来伪随机数与真随机数还是会有差别,这个需要用大量的卦例进一步检验了。      其它还有一些真随机数的生成办法,不过没有实现,这里也提一下:   在IPAD或是IPhone或是Android机上,是没有CPU能够支持随机数的,要做到能在这些上面更准确的起卦,尤其是梅花卦,应该考虑如下方案来生成熵池起卦:   1、通过访问重力感应,求测者随意摇晃手机,从中搜集精确的数据用来起卦,类似于真实的摇签或摇卦,据在下所知,现在还没有真正如此来实现的,大多的摇晃起卦,实际上是早就用伪随机数起好了,然后摇晃只是发个声而已。   2、求测者随意在屏幕上乱点乱划,然后搜集数据来综合起卦,这样得到的卦测算起来就更加方便,不过这种效果直觉上有略有折扣。   3、打开麦克风,通过麦克风搜集实际的噪音,动态调整振幅后,随机采集数据。这个还可以更加改进,让求测者念一句话,因为发音总有变化,通过提取变化,可以得到真实随机的采样。     4、对使用者用摄像头拍照,根据照片的色彩矩阵做一个运算,从而得到卦,这种起卦方式应该是比较灵验的,顺便还能让卦师结合面相也一起看了,不过有影响隐私的嫌疑。     以上四种起卦方式,可以在移动设备上进行。

Read More

计算机伪随机数会对起卦准确率造成影响

  计算机上的随机数是伪随机,它要么是固定的序列,要么是利用当前的时间来生成的一个随机器。测试了一下MONO在MAC上调用的随机器发生器:让它随机产生坐标,然后标记成白点,产生的结果如下:    如果是在Windows上,使用C#进行生成的300x300的随机图像值是这样:   然而,如果是根据真实的自然环境,由大气的运动(空气中的雷暴产生的噪声)而自然产生随机数应该是这样:   明显可以看出,在MAC上的mono的C#中代码所产生的随机数所形成的密度远远低于真实的随机数,不过唯一值得庆幸的是,如果见到php的随机数生成的样子是多么糟糕,就会更有感触了:    随机数的正确与否,直接关系到起卦的关联性,因为计算机上使用的虽然普遍是伪随机数,但是来的人时间却是不一定的,这样就在一定程度上模拟了随机,但是在出现生成随机比较紧密的时候,它对自然的模拟所体现出来的随机真实度就会大大降低。   术数最讲究的就是对自然的模拟,如果不能进行一个真实的模拟,也就谈不上预测。   典型的一种表现就是,在网上起卦,比如六爻卦,或随机梅花卦,其准确率都会降低,如果是手起摇的卦,大多看事一目了然,看是什么就是什么,但是换成网络起卦后,会出现信息不同程度偏移(注意是不同程度的,有时小有时大)。   信息偏移,比如看是收获当为一万块,网络用卦结果发现只有五千或八千,本来手卦经验很准的数,在网上起卦也就产生了模糊偏差。这就是因为同样的随机数发生器被频繁使用,而导致了整体上的真实度降低。   虽然大多数时候还是可以看事,也多能断得准,但其中难免会有不同程度的信息失真,准的时候就如同上面的点与自然随机点的分布密集恰好重合,不准的时候就是不符合真实随机的时候。   自然的随机性,正如清澈的海边,尽管水一直在波动,但并不会影响人通过清晰地看到水下的鱼。现在网上起卦的,从上面的自然分布来看,很容易明白,信息失真最大的便是php的网站,因为它用的随机数的分布可以说最不自然,所以在起卦上相对也就更加不准。   其次是asp,asp.net等网站,它们的随机数发生器,调用的是相同的低层,生成的随机数模拟度显然比真实的要淡得多,信息也有一定程度的失真。   要成功使用真正有效的随机器,有不少的办法,一种是动态监测系统运行状况或者其它方面搜集信息,然后汇总信息构成随机数生成器,这样产生的随机数值会更加准确,或者直接使用硬件通过USB接口之类的来传送信息,或者如果是使用的Inter的CPU的话,可以直接调用CPU的接口来生成随机数。   如此使用了真随机数,起卦才能有所保证。          

Read More