无心人 发表于 2008-10-14 15:51:11

似乎,好像,大概,可能

也许
某些资料显示
查阅网络
猜测
C++ 0x STD扩展TR1可能加入无限整数

呵呵

无心人 发表于 2008-10-14 15:51:37

现在问题 x = 9么?

无心人 发表于 2008-10-14 16:01:40

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf

gxqcn 发表于 2008-10-14 20:52:05

上面那个文档中标记的日期是:2005-01-13

记得几年前 CSDN 上也曾有人提及此事,当时我就发现其头文件声明的与我的及其相似。
可惜刚才我去搜那个帖子未得。

但估计成为标准是很困难的,因为大数运算的算法还有许多可挖掘之处,
即便完成估计也只能适用于小规模的大数计算,因为其预定的复杂度并不够好。

无心人 发表于 2008-10-14 21:05:33

:)

底层小规模的运算缺少硬件支持很难做的
但如果加入GMP的帮助
也许能改善

gxqcn 发表于 2008-10-14 21:49:50

近期我一直在脑袋里规划未来的 HugeCalc,下面抛出一些构想:

1、底层用标准 C 写;最后才用 C++ 包装;
2、让用户预先设定运算规模,依规模而切换不同的数据类型(比如2进制系统中,可能用2^32,也可能用2^24作进制);
3、核心层为与硬件相关的函数,依用户硬件环境自动切换函数指针;
4、而后是多核的全面支持:基本的加、减、乘等;
5、将十进制/二进制内核系统不同的基本函数(加、减、乘等)用一个函数指针数组包装,方便切换,类似于 OpenSSL;
6、上层不再用 HugeInt/HugeIntX 区分,而是指定其内核类型,除非用户指定转换系统内核,否则保持不变;
7、这样功能更强大,比如允许不同系统内核的变量混合运算;
8、win32/win64 尽量用同一套代码。

无心人 发表于 2008-10-15 08:27:13

1、建议增加汇编,和 C平行就可以了
      核心保持同一套函数接口,使用自动切换
8、我想,如果能做到核心接口的一致,这个也能做到

    关键在内核的设计
2、我想大数据运算,还是2^32合适吧
4、多核支持,我觉得不应该在内核实现
      应该在算法级实现
6、上层建议使用C++的强大功能,实现一个统一接口
    不同环境的定制,可借助类的静态变量作标志来切换

gxqcn 发表于 2008-10-15 08:46:09

上述观点基本认同。

但“多核支持”应用时机上:

大数算法,很多并不容易切分任务以合理分配给多核运算,尤其是不限定核数时,
倒是最基本的算法 + - * 等方便任务切分,同时在线程池设计上更容易。

将“多核支持”应用在最基本的算法 + - * 上的另一个好处是:
全面提升算法库效率,而不是单个函数的效率,
且后者在线程池的维护上也会非常麻烦。

无心人 发表于 2008-10-15 09:04:39

:)

你会后悔的
===============
好吧
你设定个开关
能决定是否开启这个功能
===============
否则,某些运算可能非常
消耗资源,但会被不消耗
资源的运算抢占CPU
由用户决定吧
==============
呵呵

无心人 发表于 2008-10-15 09:09:28

另外,我觉得核心功能要高度精简
越少函数,越少功能越好
连错误检查和参数检查,通用性都
不要在内核进行,内核必须假定输
入正确,假定资源充足
====================
多核计算在上层未必损失效率
页: [1] 2
查看完整版本: 似乎,好像,大概,可能