Menu
▾
▴
maxima-discuss
|
From: Robert D. <rob...@gm...> - 2014-08-27 19:04:49
|
I've tagged 5.34.0 in Git and created tar.gz & rpms and uploaded them to the Sourceforge file manager: http://sf.net/p/maxima/files Changelog: https://sourceforge.net/p/maxima/code/ci/master/tree/ChangeLog-5.34 If you can give it a try, that would be terrific. If someone can create a Windows installer, that would be wonderful. If there aren't too many complaints, I'll make a general announcement. best Robert Dodier |
|
From: Andrey G. G. <A.G...@in...> - 2014-08-28 17:22:07
|
I've committed maxima-5.34.0 to Gentoo. The run times (in seconds) of the
test suite on 2 intel computers running Gentoo, 64-bit one and 32-bit one,
with various lisps are
64-bit 32-bit failures
sbcl-1.2.2 147 164
gcl-2.6.10 202 222
cmucl-20e 242
ccl-1.9 305 318 (1)
ecl-13.5.1 510 516 (2)
clisp-2.44 1010 807
[as I said, on my 32-bit computer clisp uses pari-2.3.5 to do long
integers, and hence is faster; on the 64-bit computer, I have pari-2.7.1,
and clisp cannot be compiled with any pari >= 2.5]
(1) 1 unexpected failure in rtest16
********************** Problem 64 ***************
Input:
block([L1 : [[1.2E-10, 1.2E-9, 1.2E-8, 1.2E-7, 1.2E-6, 1.2E-5, 1.2E-4,
0.0012,
0.012, 0.12, 1.2, 1.2E+1, 1.2E+2, 1.2E+3, 1.2E+4, 1.2E+5, 1.2E+6, 1.2E+7,
1.2E+8, 1.2E+9, 1.2E+10], [1.23E-10, 1.23E-9, 1.23E-8, 1.23E-7, 1.23E-6,
1.23E-5, 1.23E-4, 0.00123, 0.0123, 0.123, 1.23, 12.3, 1.23E+2, 1.23E+3,
1.23E+4, 1.23E+5, 1.23E+6, 1.23E+7, 1.23E+8, 1.23E+9, 1.23E+10],
[1.234E-10, 1.234E-9, 1.234E-8, 1.234E-7, 1.234E-6, 1.234E-5, 1.234E-4,
0.001234, 0.01234, 0.1234, 1.234, 12.34, 123.4, 1.234E+3, 1.234E+4,
1.234E+5,
1.234E+6, 1.234E+7, 1.234E+8, 1.234E+9, 1.234E+10],
[1.2344E-10, 1.2344E-9, 1.2344E-8, 1.2344E-7, 1.2344E-6, 1.2344E-5,
1.2344E-4,
0.0012344, 0.012344, 0.12344, 1.2344, 12.344, 123.44, 1234.4, 1.2344E+4,
1.2344E+5, 1.2344E+6, 1.2344E+7, 1.2344E+8, 1.2344E+9, 1.2344E+10],
[1.23443E-10, 1.23443E-9, 1.23443E-8, 1.23443E-7, 1.23443E-6, 1.23443E-5,
1.23443E-4, 0.00123443, 0.0123443, 0.123443, 1.23443, 12.3443, 123.443,
1234.43, 12344.3, 1.23443E+5, 1.23443E+6, 1.23443E+7, 1.23443E+8,
1.23443E+9,
1.23443E+10], [1.234432E-10, 1.234432E-9, 1.234432E-8, 1.234432E-7,
1.234432E-6, 1.234432E-5, 1.234432E-4, 0.001234432, 0.01234432, 0.1234432,
1.234432, 12.34432, 123.4432, 1234.432, 12344.32, 123443.2, 1.234432E+6,
1.234432E+7, 1.234432E+8, 1.234432E+9, 1.234432E+10],
[1.2344321E-10, 1.2344321E-9, 1.2344321E-8, 1.2344321E-7, 1.2344321E-6,
1.2344321E-5, 1.2344321E-4, 0.0012344321, 0.012344321, 0.12344321,
1.2344321,
12.344321, 123.44321, 1234.4321, 12344.321, 123443.21, 1234432.1,
1.2344321E+7, 1.2344321E+8, 1.2344321E+9, 1.2344321E+10],
[1.23443211E-10, 1.23443211E-9, 1.23443211E-8, 1.23443211E-7,
1.23443211E-6,
1.23443211E-5, 1.23443211E-4, 0.00123443211, 0.0123443211, 0.123443211,
1.23443211, 12.3443211, 123.443211, 1234.43211, 12344.3211, 123443.211,
1234432.11, 1.23443211E+7, 1.23443211E+8, 1.23443211E+9, 1.23443211E+10],
[1.234432112E-10, 1.234432112E-9, 1.234432112E-8, 1.234432112E-7,
1.234432112E-6, 1.234432112E-5, 1.234432112E-4, 0.001234432112,
0.01234432112,
0.1234432112, 1.234432112, 12.34432112, 123.4432112, 1234.432112,
12344.32112,
123443.2112, 1234432.112, 1.234432112E+7, 1.234432112E+8, 1.234432112E+9,
1.234432112E+10], [1.2344321123E-10, 1.2344321123E-9, 1.2344321123E-8,
1.2344321123E-7, 1.2344321123E-6, 1.2344321123E-5, 1.2344321123E-4,
0.0012344321123, 0.012344321123, 0.12344321123, 1.2344321123,
12.344321123,
123.44321123, 1234.4321123, 12344.321123, 123443.21123, 1234432.1123,
1.2344321123E+7, 1.2344321123E+8, 1.2344321123E+9, 1.2344321123E+10],
[1.23443211234E-10, 1.23443211234E-9, 1.23443211234E-8, 1.23443211234E-7,
1.23443211234E-6, 1.23443211234E-5, 1.23443211234E-4, 0.00123443211234,
0.0123443211234, 0.123443211234, 1.23443211234, 12.3443211234,
123.443211234,
1234.43211234, 12344.3211234, 123443.211234, 1234432.11234,
1.23443211234E+7,
1.23443211234E+8, 1.23443211234E+9, 1.23443211234E+10],
[1.234432112344E-10, 1.234432112344E-9, 1.234432112344E-8,
1.234432112344E-7,
1.234432112344E-6, 1.234432112344E-5, 1.234432112344E-4,
0.001234432112344,
0.01234432112344, 0.1234432112344, 1.234432112344, 12.34432112344,
123.4432112344, 1234.432112344, 12344.32112344, 123443.2112344,
1234432.112344, 1.234432112344E+7, 1.234432112344E+8, 1.234432112344E+9,
1.234432112344E+10], [1.2344321123443E-10, 1.2344321123443E-9,
1.2344321123443E-8, 1.2344321123443E-7, 1.2344321123443E-6,
1.2344321123443E-5, 1.2344321123443E-4, 0.0012344321123443,
0.012344321123443,
0.12344321123443, 1.2344321123443, 12.344321123443, 123.44321123443,
1234.4321123443, 12344.321123443, 123443.21123443, 1234432.1123443,
1.2344321123443E+7, 1.2344321123443E+8, 1.2344321123443E+9,
1.2344321123443E+10], [1.23443211234432E-10, 1.23443211234432E-9,
1.23443211234432E-8, 1.23443211234432E-7, 1.23443211234432E-6,
1.23443211234432E-5, 1.23443211234432E-4, 0.00123443211234432,
0.0123443211234432, 0.123443211234432, 1.23443211234432, 12.3443211234432,
123.443211234432, 1234.43211234432, 12344.3211234432, 123443.211234432,
1234432.11234432, 1.23443211234432E+7, 1.23443211234432E+8,
1.23443211234432E+9, 1.23443211234432E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10], [1.234432112344321E-10, 1.234432112344321E-9,
1.234432112344321E-8, 1.234432112344321E-7, 1.234432112344321E-6,
1.234432112344321E-5, 1.234432112344321E-4, 0.001234432112344321,
0.01234432112344321, 0.1234432112344321, 1.234432112344321,
12.34432112344321,
123.4432112344321, 1234.432112344321, 12344.32112344321,
123443.2112344321,
1234432.112344321, 1.234432112344321E+7, 1.234432112344321E+8,
1.234432112344321E+9, 1.234432112344321E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10], [1.234432112344321E-10, 1.234432112344321E-9,
1.234432112344321E-8, 1.234432112344321E-7, 1.234432112344321E-6,
1.234432112344321E-5, 1.234432112344321E-4, 0.001234432112344321,
0.01234432112344321, 0.1234432112344321, 1.234432112344321,
12.34432112344321,
123.4432112344321, 1234.432112344321, 12344.32112344321,
123443.2112344321,
1234432.112344321, 1.234432112344321E+7, 1.234432112344321E+8,
1.234432112344321E+9, 1.234432112344321E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10]], L2 : block([foo : 1.234432112344321],
n
makelist(block([fpprintprec : m], makelist(string(foo 10 ), n, - 10, 10)),
m,
2, 20))], map(lambda([s1, s2], if sequalignore(s1, s2) then true
else s2 # s1), flatten(L1), flatten(L2)), delete(true, %%))
Result:
[1.23E-10 # 1.2E-10, 1.23E-9 # 1.2E-9, 1.23E-8 # 1.2E-8, 1.23E-7 # 1.2E-7,
1.23E-6 # 1.2E-6, 1.23E-5 # 1.2E-5, 1.23E-4 # 1.2E-4, 1.23E+1 # 1.2E+1,
1.23E+2 # 1.2E+2, 1.23E+3 # 1.2E+3, 1.23E+4 # 1.2E+4, 1.23E+5 # 1.2E+5,
1.23E+6 # 1.2E+6, 1.23E+7 # 1.2E+7, 1.23E+8 # 1.2E+8, 1.23E+9 # 1.2E+9,
1.23E+10 # 1.2E+10, 1.234E-10 # 1.23E-10, 1.234E-9 # 1.23E-9,
1.234E-8 # 1.23E-8, 1.234E-7 # 1.23E-7, 1.234E-6 # 1.23E-6,
1.234E-5 # 1.23E-5, 1.234E-4 # 1.23E-4, 1.234E+2 # 1.23E+2,
1.234E+3 # 1.23E+3, 1.234E+4 # 1.23E+4, 1.234E+5 # 1.23E+5,
1.234E+6 # 1.23E+6, 1.234E+7 # 1.23E+7, 1.234E+8 # 1.23E+8,
1.234E+9 # 1.23E+9, 1.234E+10 # 1.23E+10, 1.2344E-10 # 1.234E-10,
1.2344E-9 # 1.234E-9, 1.2344E-8 # 1.234E-8, 1.2344E-7 # 1.234E-7,
1.2344E-6 # 1.234E-6, 1.2344E-5 # 1.234E-5, 1.2344E-4 # 1.234E-4,
1.2344E+3 # 1.234E+3, 1.2344E+4 # 1.234E+4, 1.2344E+5 # 1.234E+5,
1.2344E+6 # 1.234E+6, 1.2344E+7 # 1.234E+7, 1.2344E+8 # 1.234E+8,
1.2344E+9 # 1.234E+9, 1.2344E+10 # 1.234E+10, 1.23443E-10 # 1.2344E-10,
1.23443E-9 # 1.2344E-9, 1.23443E-8 # 1.2344E-8, 1.23443E-7 # 1.2344E-7,
1.23443E-6 # 1.2344E-6, 1.23443E-5 # 1.2344E-5, 1.23443E-4 # 1.2344E-4,
1.23443E+4 # 1.2344E+4, 1.23443E+5 # 1.2344E+5, 1.23443E+6 # 1.2344E+6,
1.23443E+7 # 1.2344E+7, 1.23443E+8 # 1.2344E+8, 1.23443E+9 # 1.2344E+9,
1.23443E+10 # 1.2344E+10, 1.234432E-10 # 1.23443E-10,
1.234432E-9 # 1.23443E-9, 1.234432E-8 # 1.23443E-8, 1.234432E-7 #
1.23443E-7,
1.234432E-6 # 1.23443E-6, 1.234432E-5 # 1.23443E-5, 1.234432E-4 #
1.23443E-4,
1.234432E+5 # 1.23443E+5, 1.234432E+6 # 1.23443E+6, 1.234432E+7 #
1.23443E+7,
1.234432E+8 # 1.23443E+8, 1.234432E+9 # 1.23443E+9,
1.234432E+10 # 1.23443E+10, 1.2344321E-10 # 1.234432E-10,
1.2344321E-9 # 1.234432E-9, 1.2344321E-8 # 1.234432E-8,
1.2344321E-7 # 1.234432E-7, 1.2344321E-6 # 1.234432E-6,
1.2344321E-5 # 1.234432E-5, 1.2344321E-4 # 1.234432E-4,
1.2344321E+6 # 1.234432E+6, 1.2344321E+7 # 1.234432E+7,
1.2344321E+8 # 1.234432E+8, 1.2344321E+9 # 1.234432E+9,
1.2344321E+10 # 1.234432E+10, 1.23443211E-10 # 1.2344321E-10,
1.23443211E-9 # 1.2344321E-9, 1.23443211E-8 # 1.2344321E-8,
1.23443211E-7 # 1.2344321E-7, 1.23443211E-6 # 1.2344321E-6,
1.23443211E-5 # 1.2344321E-5, 1.23443211E-4 # 1.2344321E-4,
1.23443211E+7 # 1.2344321E+7, 1.23443211E+8 # 1.2344321E+8,
1.23443211E+9 # 1.2344321E+9, 1.23443211E+10 # 1.2344321E+10,
1.234432112E-10 # 1.23443211E-10, 1.234432112E-9 # 1.23443211E-9,
1.234432112E-8 # 1.23443211E-8, 1.234432112E-7 # 1.23443211E-7,
1.234432112E-6 # 1.23443211E-6, 1.234432112E-5 # 1.23443211E-5,
1.234432112E-4 # 1.23443211E-4, 1.234432112E+7 # 1.23443211E+7,
1.234432112E+8 # 1.23443211E+8, 1.234432112E+9 # 1.23443211E+9,
1.234432112E+10 # 1.23443211E+10, 1.2344321123E-10 # 1.234432112E-10,
1.2344321123E-9 # 1.234432112E-9, 1.2344321123E-8 # 1.234432112E-8,
1.2344321123E-7 # 1.234432112E-7, 1.2344321123E-6 # 1.234432112E-6,
1.2344321123E-5 # 1.234432112E-5, 1.2344321123E-4 # 1.234432112E-4,
1.2344321123E+7 # 1.234432112E+7, 1.2344321123E+8 # 1.234432112E+8,
1.2344321123E+9 # 1.234432112E+9, 1.2344321123E+10 # 1.234432112E+10,
1.23443211234E-10 # 1.2344321123E-10, 1.23443211234E-9 # 1.2344321123E-9,
1.23443211234E-8 # 1.2344321123E-8, 1.23443211234E-7 # 1.2344321123E-7,
1.23443211234E-6 # 1.2344321123E-6, 1.23443211234E-5 # 1.2344321123E-5,
1.23443211234E-4 # 1.2344321123E-4, 1.23443211234E+7 # 1.2344321123E+7,
1.23443211234E+8 # 1.2344321123E+8, 1.23443211234E+9 # 1.2344321123E+9,
1.23443211234E+10 # 1.2344321123E+10, 1.234432112344E-10 #
1.23443211234E-10,
1.234432112344E-9 # 1.23443211234E-9, 1.234432112344E-8 #
1.23443211234E-8,
1.234432112344E-7 # 1.23443211234E-7, 1.234432112344E-6 #
1.23443211234E-6,
1.234432112344E-5 # 1.23443211234E-5, 1.234432112344E-4 #
1.23443211234E-4,
1.234432112344E+7 # 1.23443211234E+7, 1.234432112344E+8 #
1.23443211234E+8,
1.234432112344E+9 # 1.23443211234E+9, 1.234432112344E+10 #
1.23443211234E+10,
1.2344321123443E-10 # 1.234432112344E-10,
1.2344321123443E-9 # 1.234432112344E-9,
1.2344321123443E-8 # 1.234432112344E-8,
1.2344321123443E-7 # 1.234432112344E-7,
1.2344321123443E-6 # 1.234432112344E-6,
1.2344321123443E-5 # 1.234432112344E-5,
1.2344321123443E-4 # 1.234432112344E-4,
1.2344321123443E+7 # 1.234432112344E+7,
1.2344321123443E+8 # 1.234432112344E+8,
1.2344321123443E+9 # 1.234432112344E+9,
1.2344321123443E+10 # 1.234432112344E+10,
1.23443211234432E-10 # 1.2344321123443E-10,
1.23443211234432E-9 # 1.2344321123443E-9,
1.23443211234432E-8 # 1.2344321123443E-8,
1.23443211234432E-7 # 1.2344321123443E-7,
1.23443211234432E-6 # 1.2344321123443E-6,
1.23443211234432E-5 # 1.2344321123443E-5,
1.23443211234432E-4 # 1.2344321123443E-4,
1.23443211234432E+7 # 1.2344321123443E+7,
1.23443211234432E+8 # 1.2344321123443E+8,
1.23443211234432E+9 # 1.2344321123443E+9,
1.23443211234432E+10 # 1.2344321123443E+10,
1.234432112344321E-10 # 1.23443211234432E-10,
1.234432112344321E-9 # 1.23443211234432E-9,
1.234432112344321E-8 # 1.23443211234432E-8,
1.234432112344321E-7 # 1.23443211234432E-7,
1.234432112344321E-6 # 1.23443211234432E-6,
1.234432112344321E-5 # 1.23443211234432E-5,
1.234432112344321E-4 # 1.23443211234432E-4,
1.234432112344321E+7 # 1.23443211234432E+7,
1.234432112344321E+8 # 1.23443211234432E+8,
1.234432112344321E+9 # 1.23443211234432E+9,
1.234432112344321E+10 # 1.23443211234432E+10,
1.2344321123443212E-10 # 1.234432112344321E-10,
1.2344321123443212E-9 # 1.234432112344321E-9,
1.2344321123443211E-8 # 1.234432112344321E-8,
1.2344321123443212E-7 # 1.234432112344321E-7,
1.2344321123443213E-5 # 1.234432112344321E-5,
1.2344321123443212E-4 # 1.234432112344321E-4,
1.2344321123443212E+7 # 1.234432112344321E+7,
1.2344321123443212E+8 # 1.234432112344321E+8,
1.2344321123443213E+9 # 1.234432112344321E+9,
1.2344321123443212E-10 # 1.234432112344321E-10,
1.2344321123443212E-9 # 1.234432112344321E-9,
1.2344321123443211E-8 # 1.234432112344321E-8,
1.2344321123443212E-7 # 1.234432112344321E-7,
1.2344321123443213E-5 # 1.234432112344321E-5,
1.2344321123443212E-4 # 1.234432112344321E-4,
1.2344321123443212E+7 # 1.234432112344321E+7,
1.2344321123443212E+8 # 1.234432112344321E+8,
1.2344321123443213E+9 # 1.234432112344321E+9,
1.2344321123443212E-10 # 1.234432112344321E-10,
1.2344321123443212E-9 # 1.234432112344321E-9,
1.2344321123443211E-8 # 1.234432112344321E-8,
1.2344321123443212E-7 # 1.234432112344321E-7,
1.2344321123443213E-5 # 1.234432112344321E-5,
1.2344321123443212E-4 # 1.234432112344321E-4,
1.2344321123443212E+7 # 1.234432112344321E+7,
1.2344321123443212E+8 # 1.234432112344321E+8,
1.2344321123443213E+9 # 1.234432112344321E+9,
1.2344321123443212E-10 # 1.234432112344321E-10,
1.2344321123443212E-9 # 1.234432112344321E-9,
1.2344321123443211E-8 # 1.234432112344321E-8,
1.2344321123443212E-7 # 1.234432112344321E-7,
1.2344321123443213E-5 # 1.234432112344321E-5,
1.2344321123443212E-4 # 1.234432112344321E-4,
1.2344321123443212E+7 # 1.234432112344321E+7,
1.2344321123443212E+8 # 1.234432112344321E+8,
1.2344321123443213E+9 # 1.234432112344321E+9,
1.2344321123443212E-10 # 1.234432112344321E-10,
1.2344321123443212E-9 # 1.234432112344321E-9,
1.2344321123443211E-8 # 1.234432112344321E-8,
1.2344321123443212E-7 # 1.234432112344321E-7,
1.2344321123443213E-5 # 1.234432112344321E-5,
1.2344321123443212E-4 # 1.234432112344321E-4,
1.2344321123443212E+7 # 1.234432112344321E+7,
1.2344321123443212E+8 # 1.234432112344321E+8,
1.2344321123443213E+9 # 1.234432112344321E+9]
This differed from the expected result:
[]
(2) 1 unexpected failure in rtest16
********************** Problem 64 ***************
Input:
block([L1 : [[1.2E-10, 1.2E-9, 1.2E-8, 1.2E-7, 1.2E-6, 1.2E-5, 1.2E-4,
0.0012,
0.012, 0.12, 1.2, 1.2E+1, 1.2E+2, 1.2E+3, 1.2E+4, 1.2E+5, 1.2E+6, 1.2E+7,
1.2E+8, 1.2E+9, 1.2E+10], [1.23E-10, 1.23E-9, 1.23E-8, 1.23E-7, 1.23E-6,
1.23E-5, 1.23E-4, 0.00123, 0.0123, 0.123, 1.23, 12.3, 1.23E+2, 1.23E+3,
1.23E+4, 1.23E+5, 1.23E+6, 1.23E+7, 1.23E+8, 1.23E+9, 1.23E+10],
[1.234E-10, 1.234E-9, 1.234E-8, 1.234E-7, 1.234E-6, 1.234E-5, 1.234E-4,
0.001234, 0.01234, 0.1234, 1.234, 12.34, 123.4, 1.234E+3, 1.234E+4,
1.234E+5,
1.234E+6, 1.234E+7, 1.234E+8, 1.234E+9, 1.234E+10],
[1.2344E-10, 1.2344E-9, 1.2344E-8, 1.2344E-7, 1.2344E-6, 1.2344E-5,
1.2344E-4,
0.0012344, 0.012344, 0.12344, 1.2344, 12.344, 123.44, 1234.4, 1.2344E+4,
1.2344E+5, 1.2344E+6, 1.2344E+7, 1.2344E+8, 1.2344E+9, 1.2344E+10],
[1.23443E-10, 1.23443E-9, 1.23443E-8, 1.23443E-7, 1.23443E-6, 1.23443E-5,
1.23443E-4, 0.00123443, 0.0123443, 0.123443, 1.23443, 12.3443, 123.443,
1234.43, 12344.3, 1.23443E+5, 1.23443E+6, 1.23443E+7, 1.23443E+8,
1.23443E+9,
1.23443E+10], [1.234432E-10, 1.234432E-9, 1.234432E-8, 1.234432E-7,
1.234432E-6, 1.234432E-5, 1.234432E-4, 0.001234432, 0.01234432, 0.1234432,
1.234432, 12.34432, 123.4432, 1234.432, 12344.32, 123443.2, 1.234432E+6,
1.234432E+7, 1.234432E+8, 1.234432E+9, 1.234432E+10],
[1.2344321E-10, 1.2344321E-9, 1.2344321E-8, 1.2344321E-7, 1.2344321E-6,
1.2344321E-5, 1.2344321E-4, 0.0012344321, 0.012344321, 0.12344321,
1.2344321,
12.344321, 123.44321, 1234.4321, 12344.321, 123443.21, 1234432.1,
1.2344321E+7, 1.2344321E+8, 1.2344321E+9, 1.2344321E+10],
[1.23443211E-10, 1.23443211E-9, 1.23443211E-8, 1.23443211E-7,
1.23443211E-6,
1.23443211E-5, 1.23443211E-4, 0.00123443211, 0.0123443211, 0.123443211,
1.23443211, 12.3443211, 123.443211, 1234.43211, 12344.3211, 123443.211,
1234432.11, 1.23443211E+7, 1.23443211E+8, 1.23443211E+9, 1.23443211E+10],
[1.234432112E-10, 1.234432112E-9, 1.234432112E-8, 1.234432112E-7,
1.234432112E-6, 1.234432112E-5, 1.234432112E-4, 0.001234432112,
0.01234432112,
0.1234432112, 1.234432112, 12.34432112, 123.4432112, 1234.432112,
12344.32112,
123443.2112, 1234432.112, 1.234432112E+7, 1.234432112E+8, 1.234432112E+9,
1.234432112E+10], [1.2344321123E-10, 1.2344321123E-9, 1.2344321123E-8,
1.2344321123E-7, 1.2344321123E-6, 1.2344321123E-5, 1.2344321123E-4,
0.0012344321123, 0.012344321123, 0.12344321123, 1.2344321123,
12.344321123,
123.44321123, 1234.4321123, 12344.321123, 123443.21123, 1234432.1123,
1.2344321123E+7, 1.2344321123E+8, 1.2344321123E+9, 1.2344321123E+10],
[1.23443211234E-10, 1.23443211234E-9, 1.23443211234E-8, 1.23443211234E-7,
1.23443211234E-6, 1.23443211234E-5, 1.23443211234E-4, 0.00123443211234,
0.0123443211234, 0.123443211234, 1.23443211234, 12.3443211234,
123.443211234,
1234.43211234, 12344.3211234, 123443.211234, 1234432.11234,
1.23443211234E+7,
1.23443211234E+8, 1.23443211234E+9, 1.23443211234E+10],
[1.234432112344E-10, 1.234432112344E-9, 1.234432112344E-8,
1.234432112344E-7,
1.234432112344E-6, 1.234432112344E-5, 1.234432112344E-4,
0.001234432112344,
0.01234432112344, 0.1234432112344, 1.234432112344, 12.34432112344,
123.4432112344, 1234.432112344, 12344.32112344, 123443.2112344,
1234432.112344, 1.234432112344E+7, 1.234432112344E+8, 1.234432112344E+9,
1.234432112344E+10], [1.2344321123443E-10, 1.2344321123443E-9,
1.2344321123443E-8, 1.2344321123443E-7, 1.2344321123443E-6,
1.2344321123443E-5, 1.2344321123443E-4, 0.0012344321123443,
0.012344321123443,
0.12344321123443, 1.2344321123443, 12.344321123443, 123.44321123443,
1234.4321123443, 12344.321123443, 123443.21123443, 1234432.1123443,
1.2344321123443E+7, 1.2344321123443E+8, 1.2344321123443E+9,
1.2344321123443E+10], [1.23443211234432E-10, 1.23443211234432E-9,
1.23443211234432E-8, 1.23443211234432E-7, 1.23443211234432E-6,
1.23443211234432E-5, 1.23443211234432E-4, 0.00123443211234432,
0.0123443211234432, 0.123443211234432, 1.23443211234432, 12.3443211234432,
123.443211234432, 1234.43211234432, 12344.3211234432, 123443.211234432,
1234432.11234432, 1.23443211234432E+7, 1.23443211234432E+8,
1.23443211234432E+9, 1.23443211234432E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10], [1.234432112344321E-10, 1.234432112344321E-9,
1.234432112344321E-8, 1.234432112344321E-7, 1.234432112344321E-6,
1.234432112344321E-5, 1.234432112344321E-4, 0.001234432112344321,
0.01234432112344321, 0.1234432112344321, 1.234432112344321,
12.34432112344321,
123.4432112344321, 1234.432112344321, 12344.32112344321,
123443.2112344321,
1234432.112344321, 1.234432112344321E+7, 1.234432112344321E+8,
1.234432112344321E+9, 1.234432112344321E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10], [1.234432112344321E-10, 1.234432112344321E-9,
1.234432112344321E-8, 1.234432112344321E-7, 1.234432112344321E-6,
1.234432112344321E-5, 1.234432112344321E-4, 0.001234432112344321,
0.01234432112344321, 0.1234432112344321, 1.234432112344321,
12.34432112344321,
123.4432112344321, 1234.432112344321, 12344.32112344321,
123443.2112344321,
1234432.112344321, 1.234432112344321E+7, 1.234432112344321E+8,
1.234432112344321E+9, 1.234432112344321E+10],
[1.234432112344321E-10, 1.234432112344321E-9, 1.234432112344321E-8,
1.234432112344321E-7, 1.234432112344321E-6, 1.234432112344321E-5,
1.234432112344321E-4, 0.001234432112344321, 0.01234432112344321,
0.1234432112344321, 1.234432112344321, 12.34432112344321,
123.4432112344321,
1234.432112344321, 12344.32112344321, 123443.2112344321,
1234432.112344321,
1.234432112344321E+7, 1.234432112344321E+8, 1.234432112344321E+9,
1.234432112344321E+10]], L2 : block([foo : 1.234432112344321],
n
makelist(block([fpprintprec : m], makelist(string(foo 10 ), n, - 10, 10)),
m,
2, 20))], map(lambda([s1, s2], if sequalignore(s1, s2) then true
else s2 # s1), flatten(L1), flatten(L2)), delete(true, %%))
Result:
[12.3e-11 # 1.2E-10, 12.3e-10 # 1.2E-9, 12.3e-9 # 1.2E-8, 12.3e-8 #
1.2E-7,
12.3e-7 # 1.2E-6, 12.3e-6 # 1.2E-5, 12.3e-5 # 1.2E-4, 12.34e-11 #
1.23E-10,
12.34e-10 # 1.23E-9, 12.34e-9 # 1.23E-8, 12.34e-8 # 1.23E-7,
12.34e-7 # 1.23E-6, 12.34e-6 # 1.23E-5, 12.34e-5 # 1.23E-4,
12.344e-11 # 1.234E-10, 12.344e-10 # 1.234E-9, 12.344e-9 # 1.234E-8,
12.344e-8 # 1.234E-7, 12.344e-7 # 1.234E-6, 12.344e-6 # 1.234E-5,
12.344e-5 # 1.234E-4, 12.3443e-11 # 1.2344E-10, 12.3443e-10 # 1.2344E-9,
12.3443e-9 # 1.2344E-8, 12.3443e-8 # 1.2344E-7, 12.3443e-7 # 1.2344E-6,
12.3443e-6 # 1.2344E-5, 12.3443e-5 # 1.2344E-4, 12.34432e-11 #
1.23443E-10,
12.34432e-10 # 1.23443E-9, 12.34432e-9 # 1.23443E-8, 12.34432e-8 #
1.23443E-7,
12.34432e-7 # 1.23443E-6, 12.34432e-6 # 1.23443E-5, 12.34432e-5 #
1.23443E-4,
12.344321e-11 # 1.234432E-10, 12.344321e-10 # 1.234432E-9,
12.344321e-9 # 1.234432E-8, 12.344321e-8 # 1.234432E-7,
12.344321e-7 # 1.234432E-6, 12.344321e-6 # 1.234432E-5,
12.344321e-5 # 1.234432E-4, 12.3443211e-11 # 1.2344321E-10,
12.3443211e-10 # 1.2344321E-9, 12.3443211e-9 # 1.2344321E-8,
12.3443211e-8 # 1.2344321E-7, 12.3443211e-7 # 1.2344321E-6,
12.3443211e-6 # 1.2344321E-5, 12.3443211e-5 # 1.2344321E-4,
12.34432112e-11 # 1.23443211E-10, 12.34432112e-10 # 1.23443211E-9,
12.34432112e-9 # 1.23443211E-8, 12.34432112e-8 # 1.23443211E-7,
12.34432112e-7 # 1.23443211E-6, 12.34432112e-6 # 1.23443211E-5,
12.34432112e-5 # 1.23443211E-4, 12.344321123e-11 # 1.234432112E-10,
12.344321123e-10 # 1.234432112E-9, 12.344321123e-9 # 1.234432112E-8,
12.344321123e-8 # 1.234432112E-7, 12.344321123e-7 # 1.234432112E-6,
12.344321123e-6 # 1.234432112E-5, 12.344321123e-5 # 1.234432112E-4,
12.3443211234e-11 # 1.2344321123E-10, 12.3443211234e-10 # 1.2344321123E-9,
12.3443211234e-9 # 1.2344321123E-8, 12.3443211234e-8 # 1.2344321123E-7,
12.3443211234e-7 # 1.2344321123E-6, 12.3443211234e-6 # 1.2344321123E-5,
12.3443211234e-5 # 1.2344321123E-4, 12.34432112344e-11 #
1.23443211234E-10,
12.34432112344e-10 # 1.23443211234E-9, 12.34432112344e-9 #
1.23443211234E-8,
12.34432112344e-8 # 1.23443211234E-7, 12.34432112344e-7 #
1.23443211234E-6,
12.34432112344e-6 # 1.23443211234E-5, 12.34432112344e-5 #
1.23443211234E-4,
12.344321123443e-11 # 1.234432112344E-10,
12.344321123443e-10 # 1.234432112344E-9,
12.344321123443e-9 # 1.234432112344E-8,
12.344321123443e-8 # 1.234432112344E-7,
12.344321123443e-7 # 1.234432112344E-6,
12.344321123443e-6 # 1.234432112344E-5,
12.344321123443e-5 # 1.234432112344E-4,
12.3443211234432e-11 # 1.2344321123443E-10,
12.3443211234432e-10 # 1.2344321123443E-9,
12.3443211234432e-9 # 1.2344321123443E-8,
12.3443211234432e-8 # 1.2344321123443E-7,
12.3443211234432e-7 # 1.2344321123443E-6,
12.3443211234432e-6 # 1.2344321123443E-5,
12.3443211234432e-5 # 1.2344321123443E-4,
12.34432112344321e-11 # 1.23443211234432E-10,
12.34432112344321e-10 # 1.23443211234432E-9,
12.34432112344321e-9 # 1.23443211234432E-8,
12.34432112344321e-8 # 1.23443211234432E-7,
12.34432112344321e-7 # 1.23443211234432E-6,
12.34432112344321e-6 # 1.23443211234432E-5,
12.34432112344321e-5 # 1.23443211234432E-4,
12.344321123443212e-11 # 1.234432112344321E-10,
12.344321123443212e-10 # 1.234432112344321E-9,
12.344321123443211e-9 # 1.234432112344321E-8,
12.344321123443212e-8 # 1.234432112344321E-7,
12.34432112344321e-7 # 1.234432112344321E-6,
12.344321123443213e-6 # 1.234432112344321E-5,
12.344321123443212e-5 # 1.234432112344321E-4,
12.344321123443212e-11 # 1.234432112344321E-10,
12.344321123443212e-10 # 1.234432112344321E-9,
12.344321123443211e-9 # 1.234432112344321E-8,
12.344321123443212e-8 # 1.234432112344321E-7,
12.34432112344321e-7 # 1.234432112344321E-6,
12.344321123443213e-6 # 1.234432112344321E-5,
12.344321123443212e-5 # 1.234432112344321E-4,
12.344321123443212e-11 # 1.234432112344321E-10,
12.344321123443212e-10 # 1.234432112344321E-9,
12.344321123443211e-9 # 1.234432112344321E-8,
12.344321123443212e-8 # 1.234432112344321E-7,
12.34432112344321e-7 # 1.234432112344321E-6,
12.344321123443213e-6 # 1.234432112344321E-5,
12.344321123443212e-5 # 1.234432112344321E-4,
12.344321123443212e-11 # 1.234432112344321E-10,
12.344321123443212e-10 # 1.234432112344321E-9,
12.344321123443211e-9 # 1.234432112344321E-8,
12.344321123443212e-8 # 1.234432112344321E-7,
12.34432112344321e-7 # 1.234432112344321E-6,
12.344321123443213e-6 # 1.234432112344321E-5,
12.344321123443212e-5 # 1.234432112344321E-4,
12.344321123443212e-11 # 1.234432112344321E-10,
12.344321123443212e-10 # 1.234432112344321E-9,
12.344321123443211e-9 # 1.234432112344321E-8,
12.344321123443212e-8 # 1.234432112344321E-7,
12.34432112344321e-7 # 1.234432112344321E-6,
12.344321123443213e-6 # 1.234432112344321E-5,
12.344321123443212e-5 # 1.234432112344321E-4]
This differed from the expected result:
[]
Andrey
|
|
From: Robert D. <rob...@gm...> - 2014-08-28 16:44:25
|
Thanks a lot for the update. The failed tests for Clozure CL and ECL are due to bugs in their implementation of float formats, which I have reported to their respective projects; the tests are to verify that fpprintprec is honored. best, Robert Dodier |
|
From: Camm M. <ca...@ma...> - 2014-09-09 18:05:15
|
Greetings, and thanks for running these results! If it is convenient, I sure would be interested in seeing an update for 5.34.1 and using gcl-2.6.11. Take care, -- Camm Maguire ca...@ma... ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah |
|
From: Camm M. <ca...@ma...> - 2014-09-16 20:26:00
|
Greetings! Well, I decided to do it myself :-). All lisp versions are
latest Debian unstable.
64 bit 32 bit
------ ------
gcl-2.6.11: 134.369 128.440
sbcl: 141.856 151.168
cmucl: 200.540
ccl: 286.512 232.366 (1 failure)
ecl: 512.615 534.442 (1 failure)
clisp: 918.053 741.340
Take care,
Camm Maguire <ca...@ma...> writes:
> Greetings, and thanks for running these results! If it is convenient, I
> sure would be interested in seeing an update for 5.34.1 and using
> gcl-2.6.11.
>
> Take care,
--
Camm Maguire ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
|
|
From: Volker v. N. <vol...@gm...> - 2014-09-17 18:00:29
|
Wow, what an improvement. On Ubuntu, 32 Bit: Maxima 5.33.0 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.10 (a.k.a. GCL) No unexpected errors found out of 9,808 tests. real time : 259.529 secs Maxima 5.34.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.11 (a.k.a. GCL) No unexpected errors found out of 9,966 tests. real time : 164.740 secs Thanks a lot, Camm. Volker van Nek Am 16.09.2014 22:25, schrieb Camm Maguire: > Greetings! Well, I decided to do it myself :-). All lisp versions are > latest Debian unstable. > > 64 bit 32 bit > ------ ------ > gcl-2.6.11: 134.369 128.440 > sbcl: 141.856 151.168 > cmucl: 200.540 > ccl: 286.512 232.366 (1 failure) > ecl: 512.615 534.442 (1 failure) > clisp: 918.053 741.340 > > Take care, > > Camm Maguire <ca...@ma...> writes: > >> Greetings, and thanks for running these results! If it is convenient, I >> sure would be interested in seeing an update for 5.34.1 and using >> gcl-2.6.11. >> >> Take care, > |
|
From: Volker v. N. <vol...@gm...> - 2014-09-19 12:21:59
Attachments:
fp-constants.lisp
|
Greetings. I attached new implementations of float.lisp/fpe1, fppi1, fpgamma1, comp-log2 as a proposal. I discovered a paper by Bruno Haible and Thomas Papanikolaou about the technique of binary splitting to approximate infinite series. See http://www.ginac.de/CLN/binsplit.pdf for details if you are interested. With this technique I succeeded in implementing fast functions for computing %e, %pi, %gamma and log(2). [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. In contrast to fpe1, .. these implementions are still some kind of raw material and need more error analysis. And of course it's a lot more difficult to merge them into Maxima. My idea is to put them into /share/contrib for now. ] Below I want to describe the improvements for the 4 constants and I would like to propose these changes and commit them if there are no complains. The values of %e, %pi, %gamma and log(2) computed by the described functions are checked against reference values which were parsed and rounded to the same precision. For all 0 < $fpprec < 10000 there are no differences to the reference values. 1. Euler's number E The simple unmodified Taylor-series fits best to the binary splitting technique. Timing results for a call to (fpe1) with GCL on 32 bit Ubuntu: $fpprec = 500000 5.34.1: 2.039 secs proposed: 0.370 secs $fpprec = 1000000 5.34.1: 6.420 secs proposed: 0.790 secs 2. PI Best results with binary splitting and the Chudnovsky series. Recently there are two versions of the square-root part for different Lisp versions. I optimized the Heron/Newton version which is now the fastest for all Lisps. Timing results for a call to (fppi1): $fpprec = 100000 5.34.1: 1.720 secs proposed: 0.140 secs $fpprec = 200000 5.34.1: 6.900 secs proposed: 0.349 secs 3. GAMMA In 2013 Brent and Johansson succeeded in proving the Brent-McMillan algorithm which was a conjecture in 1980. They also proved an error bound. See http://arxiv.org/pdf/1312.0039v1.pdf The Brent-McMillan algorithm is a refinement of the Bessel function approach which is used in Maxima 5.34.1. Haible and Papanikolaou described how to compute the Bessel function approach via binary splitting and it wasn't very hard to extend this to Brent-McMillan. Timing results for a call to (fpgamma1): $fpprec = 2000 5.34.1: 1.049 secs proposed: 0.029 secs $fpprec = 4000 5.34.1: 6.590 secs proposed: 0.070 secs 4. LOG(2) Same algorithm as in 5.34.1. Just compute the Taylor series via binary splitting. Timing results for a call to (comp-log2): $fpprec = 5000 5.34.1: 1.230 secs proposed: 0.009 secs $fpprec = 10000 5.34.1: 6.599 secs proposed: 0.019 secs Volker van Nek |
|
From: Raymond T. <toy...@gm...> - 2014-09-19 18:35:52
|
>>>>> "Volker" == Volker van Nek <vol...@gm...> writes:
Volker> Greetings.
Volker> I attached new implementations of float.lisp/fpe1, fppi1, fpgamma1,
Volker> comp-log2 as a proposal.
Volker> I discovered a paper by Bruno Haible and Thomas Papanikolaou about the
Volker> technique of binary splitting to approximate infinite series.
Volker> See http://www.ginac.de/CLN/binsplit.pdf for details if you are interested.
Volker> With this technique I succeeded in implementing fast functions for
Volker> computing %e, %pi, %gamma and log(2).
Volker> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x.
Volker> In contrast to fpe1, .. these implementions are still some kind of raw
Volker> material and need more error analysis. And of course it's a lot more
Volker> difficult to merge them into Maxima. My idea is to put them into
Volker> /share/contrib for now. ]
Is there something wrong with the current implementations of these
functions?
Ray
|
|
From: Henry B. <hb...@pi...> - 2014-09-20 00:02:07
|
I don't know whether my problem is connected with e, pi, gamma, log(2), or not, but when I was recently working with cdf_normal, cdf_logistic & friends, I noticed that some of the numerical functions weren't terribly accurate in the long tails. I also tried bfloat, and that didn't improve matters, so I suspect that some of these functions need some numerical approximation work. Two of the functions I was using were quantile_logistic and quantile_normal. The accuracy was good enough for what I was doing (4-5 decimal places), but I was getting what looked like non-monotonic results in some lower order digits. I haven't the slightest idea how these functions are computed in Maxima, but perhaps a few 20-30 digit spot checks by someone who knows this stuff might be in order. At 11:35 AM 9/19/2014, Raymond Toy wrote: >>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: > > Volker> Greetings. > Volker> I attached new implementations of float.lisp/fpe1, fppi1, fpgamma1, > Volker> comp-log2 as a proposal. > > Volker> I discovered a paper by Bruno Haible and Thomas Papanikolaou about the > Volker> technique of binary splitting to approximate infinite series. > Volker> See http://www.ginac.de/CLN/binsplit.pdf for details if you are interested. > > Volker> With this technique I succeeded in implementing fast functions for > Volker> computing %e, %pi, %gamma and log(2). > > Volker> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. > Volker> In contrast to fpe1, .. these implementions are still some kind of raw > Volker> material and need more error analysis. And of course it's a lot more > Volker> difficult to merge them into Maxima. My idea is to put them into > Volker> /share/contrib for now. ] > >Is there something wrong with the current implementations of these functions? > >Ray |
|
From: Volker v. N. <vol...@gm...> - 2014-09-20 09:58:28
|
Am 19.09.2014 20:35, schrieb Raymond Toy: >>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: > > Volker> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. > Volker> In contrast to fpe1, .. these implementions are still some kind of raw > Volker> material and need more error analysis. And of course it's a lot more > Volker> difficult to merge them into Maxima. My idea is to put them into > Volker> /share/contrib for now. ] > > Is there something wrong with the current implementations of these > functions? > > Ray > Ray, as I wrote in my last sentence I do not feel any pressure to replace the current functions in src. After coding the binary splitting versions for the constants I was curious to check out the other algorithms described in this paper. I thought it is worth to share the implementation of these algorithms. Perhaps someone can use them or is simply interested to study them. The binary splitting variants are very fast and in some far future these implementations might be worth to consider. At the moment I don't want to risk breaking anything in src for the sake of speed advantages. Volker > > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |
|
From: Raymond T. <toy...@gm...> - 2014-09-20 20:54:01
|
On Sat, Sep 20, 2014 at 2:58 AM, Volker van Nek <vol...@gm...> wrote: > Am 19.09.2014 20:35, schrieb Raymond Toy: > >>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: > > > > Volker> [ I also implemented exp(x), log(x), sin(x) and friends for > bigfloat x. > > Volker> In contrast to fpe1, .. these implementions are still some > kind of raw > > Volker> material and need more error analysis. And of course it's a > lot more > > Volker> difficult to merge them into Maxima. My idea is to put them > into > > Volker> /share/contrib for now. ] > > > > Is there something wrong with the current implementations of these > > functions? > > > > Ray > > > > Ray, as I wrote in my last sentence I do not feel any pressure to > replace the current functions in src. > > After coding the binary splitting versions for the constants I was > curious to check out the other algorithms described in this paper. > > I thought it is worth to share the implementation of these algorithms. > Perhaps someone can use them or is simply interested to study them. > > The binary splitting variants are very fast and in some far future these > implementations might be worth to consider. At the moment I don't want > to risk breaking anything in src for the sake of speed advantages. > Ok. I haven't looked at your code yet, but if they're significantly faster and not (much) less accurate, we should consider adding these. I'm sure we can come up with a nice set of tests to cover the code to show that it's good. > > Volker > > > > > > ------------------------------------------------------------------------------ > > Slashdot TV. Video for Nerds. Stuff that Matters. > > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Maxima-discuss mailing list > > Max...@li... > > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > > > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > -- Ray |
|
From: Volker v. N. <vol...@gm...> - 2014-09-21 16:00:21
|
Am 20.09.2014 22:53, schrieb Raymond Toy: > > Ok. I haven't looked at your code yet, but if they're significantly faster > and not (much) less accurate, we should consider adding these. I'm sure we > can come up with a nice set of tests to cover the code to show that it's > good. > I made some timing measurements and to summarize the results I have to say that these algorithms are only of interest if you want to use precisions of $fpprec > 1000 and (much) higher. In "normal" ranges, i.e. 16 <= $fpprec <= let's say 100, they are generally much slower. The accuracy depends on the binary representation of the argument. A simple argument like 0.5b0 results in slightly better accuracy but e.g. bs_sin(bs_asin(0.5b0)) leads to significantly worse results compared to sin(asin(0.5b0)) . fpprec:30$ x:0.5b0$ asin(x); --> 5.23598775598298873077107230547b−1 bs_asin(x); --> 5.23598775598298873077107230547b−1 sin(asin(x)); --> 5.00000000000000000000000000001b−1 bs_sin(bs_asin(x)); --> 5.00000000000000000023968760547b−1 To merge them into src one has to create precision transition points from the current versions to the binary splitting versions and these transitions will vary from Lisp to Lisp, from 32 to 64 bit and from platform to platform. I am not inclined to open this can of worms. I will put these functions to /share/contrib, so that someone who needs $fpprec > 1000 can use them. Or for someone who wants to look at the implementation details. But nothing more at the moment. My functions have a bug where I need help. In case the return value is a power of 2 and fpround has rounded from below I have the problem to fix the exponent. It seems that I do not understand the mechanism of fpround and *m in float.lisp. Can someone help? Volker van Nek ASIN x:0.5b0$GCL x:0.1b0$GCL x:0.1b0$SBCL fpprec:30$ :lisp (time #$thru 10000 do asin(x)$) real time : 4.909 secs 1.759 secs 1.215 :lisp (time #$thru 10000 do bs_asin(x)$) real time : 4.409 secs 3.840 secs 2.835 fpprec:100$ :lisp (time #$thru 1000 do asin(x)$) real time : 1.490 secs 0.529 secs 0.450 :lisp (time #$thru 1000 do bs_asin(x)$) real time : 0.699 secs 0.740 secs 0.678 fpprec:1000$ :lisp (time #$thru 100 do asin(x)$) real time : 11.149 secs 2.220 secs 6.514 :lisp (time #$thru 100 do bs_asin(x)$) real time : 0.620 secs 0.579 secs 1.228 fpprec:10000$ :lisp (time #$thru 1 do asin(x)$) real time : 23.329 secs 5.619 secs 47.634 :lisp (time #$thru 1 do bs_asin(x)$) real time : 0.150 secs 0.150 secs 1.046 SIN x:0.5b0$GCL x:0.1b0$GCL x:0.1b0$SBCL fpprec:30$ :lisp (time #$thru 10000 do sin(x)$) real time : 1.169 secs 0.990 secs 0.649 :lisp (time #$thru 10000 do bs_sin(x)$) real time : 0.879 secs 2.509 secs 1.569 fpprec:100$ :lisp (time #$thru 1000 do sin(x)$) real time : 0.239 secs 0.200 secs 0.207 :lisp (time #$thru 1000 do bs_sin(x)$) real time : 0.170 secs 0.479 secs 0.389 fpprec:1000$ :lisp (time #$thru 100 do sin(x)$) real time : 0.930 secs 0.910 secs 2.243 :lisp (time #$thru 100 do bs_sin(x)$) real time : 0.140 secs 0.370 secs 0.708 fpprec:10000$ :lisp (time #$thru 1 do sin(x)$) real time : 1.700 secs 1.409 secs 12.167 :lisp (time #$thru 1 do bs_sin(x)$) real time : 0.019 secs 0.079 secs 0.634 EXP x:0.5b0$GCL x:0.1b0$GCL x:0.1b0$SBCL fpprec:30$ :lisp (time #$thru 10000 do exp(x)$) real time : 1.590 secs 1.019 secs 0.796 :lisp (time #$thru 10000 do bs_exp(x)$) real time : 0.370 secs 0.920 secs 0.672 fpprec:100$ :lisp (time #$thru 1000 do exp(x)$) real time : 0.419 secs 0.300 secs 0.311 :lisp (time #$thru 1000 do bs_exp(x)$) real time : 0.059 secs 0.170 secs 0.161 fpprec:1000$ :lisp (time #$thru 100 do exp(x)$) real time : 1.830 secs 1.490 secs 3.820 :lisp (time #$thru 100 do bs_exp(x)$) real time : 0.039 secs 0.150 secs 0.289 fpprec:10000$ :lisp (time #$thru 1 do exp(x)$) real time : 3.430 secs 2.740 secs 23.730 :lisp (time #$thru 1 do bs_exp(x)$) real time : 0.000 secs 0.039 secs 0.272 LOG x:0.5b0$GCL x:0.1b0$GCL x:0.1b0$SBCL :lisp (time #$thru 10000 do log(x)$) real time : 3.269 secs 1.899 secs 1.139 :lisp (time #$thru 10000 do bs_log(x)$) real time : 0.500 secs 1.809 secs 1.227 fpprec:100$ :lisp (time #$thru 1000 do log(x)$) real time : 1.210 secs 0.519 secs 0.549 :lisp (time #$thru 1000 do bs_log(x)$) real time : 0.070 secs 0.289 secs 0.249 fpprec:1000$ :lisp (time #$thru 100 do log(x)$) real time : 6.480 secs 3.099 secs 7.522 :lisp (time #$thru 100 do bs_log(x)$) real time : 0.070 secs 0.250 secs 0.397 fpprec:10000$ :lisp (time #$thru 1 do log(x)$) real time : 12.810 secs 6.360 secs 50.478 :lisp (time #$thru 1 do bs_log(x)$) real time : 0.009 secs 0.050 secs 0.302 |
|
From: Richard F. <fa...@be...> - 2014-09-19 15:47:13
|
These look like impressive speedups for 50,000 or 100,000 decimal digits. What is important is that they are no slower than the old programs for a small number of digits, say 30. So a useful experiment might be to set fpprec: to 30, ( time (dotimes (i 100000) (fppi))) etc. If the new method is faster for small numbers, it seems like a total winner. If it is much slower the new method could be used at some fpprec > break_even_value. (Even if the new method is a little slower, it could be used -- after all, in any particular run, the value of these constants is unlikely to be computed more than once. Setting fpprec to a lower precision means the values are rounded down, but not forgotten or recomputed; but saved at the previously "highest computed" precision. I think. Also, we could just pre-compute 100 decimal digits of these in anticipation of most needs except for the experimental number theorists.) Also it is not clear about getting the digits right. If you set fpprec to p and use the two methods, is the value rounded at the pth digit the same for all p? This may not be a big deal if if you compute a few more bits and round. Or maybe they do that anyway. Good luck! Richard On 9/19/2014 5:21 AM, Volker van Nek wrote: > Greetings. > > I attached new implementations of float.lisp/fpe1, fppi1, fpgamma1, > comp-log2 as a proposal. > > I discovered a paper by Bruno Haible and Thomas Papanikolaou about the > technique of binary splitting to approximate infinite series. > See http://www.ginac.de/CLN/binsplit.pdf for details if you are interested. > > With this technique I succeeded in implementing fast functions for > computing %e, %pi, %gamma and log(2). > > [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. > In contrast to fpe1, .. these implementions are still some kind of raw > material and need more error analysis. And of course it's a lot more > difficult to merge them into Maxima. My idea is to put them into > /share/contrib for now. ] > > Below I want to describe the improvements for the 4 constants and I > would like to propose these changes and commit them if there are no > complains. > > The values of %e, %pi, %gamma and log(2) computed by the described > functions are checked against reference values which were parsed and > rounded to the same precision. For all 0 < $fpprec < 10000 there are no > differences to the reference values. > > > 1. Euler's number E > > The simple unmodified Taylor-series fits best to the binary splitting > technique. > > Timing results for a call to (fpe1) with GCL on 32 bit Ubuntu: > $fpprec = 500000 > 5.34.1: 2.039 secs > proposed: 0.370 secs > $fpprec = 1000000 > 5.34.1: 6.420 secs > proposed: 0.790 secs > > 2. PI > > Best results with binary splitting and the Chudnovsky series. > > Recently there are two versions of the square-root part for different > Lisp versions. I optimized the Heron/Newton version which is now the > fastest for all Lisps. > > Timing results for a call to (fppi1): > $fpprec = 100000 > 5.34.1: 1.720 secs > proposed: 0.140 secs > $fpprec = 200000 > 5.34.1: 6.900 secs > proposed: 0.349 secs > > 3. GAMMA > > In 2013 Brent and Johansson succeeded in proving the Brent-McMillan > algorithm which was a conjecture in 1980. They also proved an error > bound. See http://arxiv.org/pdf/1312.0039v1.pdf > > The Brent-McMillan algorithm is a refinement of the Bessel function > approach which is used in Maxima 5.34.1. > > Haible and Papanikolaou described how to compute the Bessel function > approach via binary splitting and it wasn't very hard to extend this to > Brent-McMillan. > > Timing results for a call to (fpgamma1): > $fpprec = 2000 > 5.34.1: 1.049 secs > proposed: 0.029 secs > $fpprec = 4000 > 5.34.1: 6.590 secs > proposed: 0.070 secs > > 4. LOG(2) > > Same algorithm as in 5.34.1. Just compute the Taylor series via binary > splitting. > > Timing results for a call to (comp-log2): > $fpprec = 5000 > 5.34.1: 1.230 secs > proposed: 0.009 secs > $fpprec = 10000 > 5.34.1: 6.599 secs > proposed: 0.019 secs > > > Volker van Nek > > > > > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > > > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
|
From: Volker v. N. <vol...@gm...> - 2014-09-20 09:18:20
|
Richard, thanks for your comments. Here are the timing results for small precisions: 1. Euler's number E Timing results for 100000 calls to (fpe1) with GCL on 32 bit Ubuntu: ;; $fpprec = 30 5.34.1: 1.220 secs proposed: 1.279 secs ;; $fpprec = 60 5.34.1: 2.019 secs proposed: 1.919 secs 2. PI Timing results for 100000 calls to (fppi1): ;; $fpprec = 30 5.34.1: 1.220 secs proposed: 1.230 secs ;; $fpprec = 60 5.34.1: 2.319 secs proposed: 1.850 secs 3. GAMMA Timing results for 10000 calls to (fpgamma1): ;; $fpprec = 30 5.34.1: 10.260 secs proposed: 1.879 secs ;; $fpprec = 60 5.34.1: 21.350 secs proposed: 2.589 secs 4. LOG(2) Timing results for 10000 calls to (comp-log2): ;; $fpprec = 30 5.34.1: 1.269 secs proposed: 0.280 secs ;; $fpprec = 60 5.34.1: 2.420 secs proposed: 0.449 secs The results for E and PI are more or less the same and we don't loose anything by using the proposed version. For GAMMA and LOG2 there is a significant speedup even for small precs. Concerning the correctness of the last digits the proposed function for GAMMA results in much more consistent values. 1. E Method 1: I used a reference value string with just one additional digit character. Prior to parsing I rounded the stringed number to fpprec with respect to the additional digit (effectively I did decimal rounding) and finally I compared the parsed number to bfloat(%e). For $fpprec in [10, 1000] the following number of results had wrong last decimal digits: 5.34.1: 16 proposed: 16 Method 2: I used a reference value string with ten additional digit characters and let the parser round to fpprec. 5.34.1: 0 proposed: 0 2. PI, bfloat(%pi) Method 1: 5.34.1: 17 proposed: 17 Method 2: 5.34.1: 0 proposed: 0 3. GAMMA, bfloat(%gamma) Method 1: 5.34.1: 279 proposed: 51 Method 2: 5.34.1: 248 proposed: 0 4. LOG(2), reference compared to (bcons (comp-log2)) Method 1: 5.34.1: 80 proposed: 73 Method 2: 5.34.1: 14 proposed: 0 Volker van Nek Am 19.09.2014 17:46, schrieb Richard Fateman: > These look like impressive speedups for 50,000 or 100,000 decimal digits. > What is important is that they are no slower than the old programs for a > small number of > digits, say 30. > > So a useful experiment might be to set fpprec: to 30, ( time > (dotimes (i 100000) (fppi))) > etc. > > If the new method is faster for small numbers, it seems like a total > winner. If it is much slower > the new method could be used at some fpprec > break_even_value. > > (Even if the new method is a little slower, it could be used -- after > all, in any particular run, the > value of these constants is unlikely to be computed more than once. > Setting fpprec to a lower > precision means the values are rounded down, but not forgotten or > recomputed; but saved > at the previously "highest computed" precision. I think. Also, we > could just pre-compute 100 > decimal digits of these in anticipation of most needs except for the > experimental number theorists.) > > Also it is not clear about getting the digits right. If you set > fpprec to p and use the two > methods, is the value rounded at the pth digit the same for all p? This > may not be a big > deal if if you compute a few more bits and round. Or maybe they do that > anyway. > > Good luck! > > Richard > > > > On 9/19/2014 5:21 AM, Volker van Nek wrote: >> Greetings. >> >> I attached new implementations of float.lisp/fpe1, fppi1, fpgamma1, >> comp-log2 as a proposal. >> >> I discovered a paper by Bruno Haible and Thomas Papanikolaou about the >> technique of binary splitting to approximate infinite series. >> See http://www.ginac.de/CLN/binsplit.pdf for details if you are >> interested. >> >> With this technique I succeeded in implementing fast functions for >> computing %e, %pi, %gamma and log(2). >> >> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. >> In contrast to fpe1, .. these implementions are still some kind of raw >> material and need more error analysis. And of course it's a lot more >> difficult to merge them into Maxima. My idea is to put them into >> /share/contrib for now. ] >> >> Below I want to describe the improvements for the 4 constants and I >> would like to propose these changes and commit them if there are no >> complains. >> >> The values of %e, %pi, %gamma and log(2) computed by the described >> functions are checked against reference values which were parsed and >> rounded to the same precision. For all 0 < $fpprec < 10000 there are no >> differences to the reference values. >> >> >> 1. Euler's number E >> >> The simple unmodified Taylor-series fits best to the binary splitting >> technique. >> >> Timing results for a call to (fpe1) with GCL on 32 bit Ubuntu: >> $fpprec = 500000 >> 5.34.1: 2.039 secs >> proposed: 0.370 secs >> $fpprec = 1000000 >> 5.34.1: 6.420 secs >> proposed: 0.790 secs >> >> 2. PI >> >> Best results with binary splitting and the Chudnovsky series. >> >> Recently there are two versions of the square-root part for different >> Lisp versions. I optimized the Heron/Newton version which is now the >> fastest for all Lisps. >> >> Timing results for a call to (fppi1): >> $fpprec = 100000 >> 5.34.1: 1.720 secs >> proposed: 0.140 secs >> $fpprec = 200000 >> 5.34.1: 6.900 secs >> proposed: 0.349 secs >> >> 3. GAMMA >> >> In 2013 Brent and Johansson succeeded in proving the Brent-McMillan >> algorithm which was a conjecture in 1980. They also proved an error >> bound. See http://arxiv.org/pdf/1312.0039v1.pdf >> >> The Brent-McMillan algorithm is a refinement of the Bessel function >> approach which is used in Maxima 5.34.1. >> >> Haible and Papanikolaou described how to compute the Bessel function >> approach via binary splitting and it wasn't very hard to extend this to >> Brent-McMillan. >> >> Timing results for a call to (fpgamma1): >> $fpprec = 2000 >> 5.34.1: 1.049 secs >> proposed: 0.029 secs >> $fpprec = 4000 >> 5.34.1: 6.590 secs >> proposed: 0.070 secs >> >> 4. LOG(2) >> >> Same algorithm as in 5.34.1. Just compute the Taylor series via binary >> splitting. >> >> Timing results for a call to (comp-log2): >> $fpprec = 5000 >> 5.34.1: 1.230 secs >> proposed: 0.009 secs >> $fpprec = 10000 >> 5.34.1: 6.599 secs >> proposed: 0.019 secs >> >> >> Volker van Nek >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Slashdot TV. Video for Nerds. Stuff that Matters. >> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Maxima-discuss mailing list >> Max...@li... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > |
|
From: Richard F. <fa...@be...> - 2014-09-20 17:24:14
|
On 9/20/2014 2:18 AM, Volker van Nek wrote: > Richard, > > thanks for your comments. > > Here are the timing results for small precisions: <snip> Looks like the new methods are good enough to use all the time. I think it is unlikely that there are any parts of Maxima that depend on the old programs in secret/hidden ways. I'm in favor of inserting the replacements. I suppose if you are nervous about this, you should leave the old code in there, with ... #+ignore(defun old-fppi1 .....) for a while. At least for those of us who dislike digging through source code control programs to mess with old versions, it would be clear what was changed. Richard |
|
From: Volker v. N. <vol...@gm...> - 2014-09-21 15:19:54
|
Hendrik, some Details on e and pi. The computation of e and pi is done by the functions fpe1 resp. fppi1 which are - as Richard Fateman already posted - in src/float.lisp . Before 2007 e was computed by it's Taylor series and pi by the formula pi = 6*asin(1/2) and the asin-series. In 2007 I replaced the asin-formula by the Chudnovsky-formula and for the computation of e I implemented a mechanism that combines a lot of Taylor summands to one. This mechanism uses the fact that division is expensive and multiplication of large integers is much cheaper. At that time I didn't know binary splitting. Binary splitting is also a mechanism to combine Taylor summands and also uses large integer multiplication but in contrast to my approach it is a recursive divide and conquer algorithm and provides better timings for high precisions. Very soon I will replace the current versions by the binary splitting variants (which are attached to my first mail in this thread). Volker van Nek Am 21.09.2014 09:59, schrieb Jan Hendrik Mueller: > Maybe I overlooked that: What was the "old" way maxima computed e and pi? > Is there a possibility to look at these codes for non developers? > bw > Jan > >> Am 20.09.2014 um 22:53 schrieb Raymond Toy <toy...@gm...>: >> >> >> >>> On Sat, Sep 20, 2014 at 2:58 AM, Volker van Nek <vol...@gm...> wrote: >>> Am 19.09.2014 20:35, schrieb Raymond Toy: >>>>>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: >>>> >>>> Volker> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. >>>> Volker> In contrast to fpe1, .. these implementions are still some kind of raw >>>> Volker> material and need more error analysis. And of course it's a lot more >>>> Volker> difficult to merge them into Maxima. My idea is to put them into >>>> Volker> /share/contrib for now. ] >>>> >>>> Is there something wrong with the current implementations of these >>>> functions? >>>> >>>> Ray >>>> >>> >>> Ray, as I wrote in my last sentence I do not feel any pressure to >>> replace the current functions in src. >>> >>> After coding the binary splitting versions for the constants I was >>> curious to check out the other algorithms described in this paper. >>> >>> I thought it is worth to share the implementation of these algorithms. >>> Perhaps someone can use them or is simply interested to study them. >>> >>> The binary splitting variants are very fast and in some far future these >>> implementations might be worth to consider. At the moment I don't want >>> to risk breaking anything in src for the sake of speed advantages. >> >> Ok. I haven't looked at your code yet, but if they're significantly faster and not (much) less accurate, we should consider adding these. I'm sure we can come up with a nice set of tests to cover the code to show that it's good. >>> >>> Volker >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Slashdot TV. Video for Nerds. Stuff that Matters. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Maxima-discuss mailing list >>>> Max...@li... >>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Slashdot TV. Video for Nerds. Stuff that Matters. >>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Maxima-discuss mailing list >>> Max...@li... >>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> >> >> >> -- >> Ray >> ------------------------------------------------------------------------------ >> Slashdot TV. Video for Nerds. Stuff that Matters. >> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Maxima-discuss mailing list >> Max...@li... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |
|
From: Volker v. N. <vol...@gm...> - 2014-09-21 21:02:32
|
I used the quadratic Heron variant because it allows to compute what I want without any division. Here is how it works: The task is to compute the numerator and denominator of sqrt(10005). For merging the result into the Chudnovsky formula the quotient i.e. the sqrt is not needed. It took me some time to realize that. I start with a numerator n[0] and a denominator d[0], which are both (perfectly tailored) integer start values with a certain number p of bits so that after k iterations 2^k*p = fpprec + delta with delta very small. The quadratic Heron allows to compute n[i+1] and d[i+1] seperately by 4 multiplications, 1 addition and 1 shift: n[i+1] = n[i]^2+a*d[i]^2 d[i+1] = 2*n[i]*d[i] This is simple and fast. Am 21.09.2014 20:21, schrieb Richard Fateman: > I don't know what MPFR does for integer sqrt, but I think there may be > better for sqrt than Heron. > There are papers on cubic convergence. I found > > http://www.sciencedirect.com/science/article/pii/S0377042704004315 > > for example. > > But that may be essentially the taylor-series you already tried. > > It may actually be possible to just send email to bailey or borwein or > even plouffe, > and get an answer. I don't know plouffe, but I know the other two, and > bailey > is very near me in Berkeley. > > Have fun > > RJF > > On 9/21/2014 10:28 AM, Volker van Nek wrote: >> Am 21.09.2014 18:10, schrieb Richard Fateman: >>> I do not know if the splitting formula is the very fastest... I found >>> this reference >>> http://www.craig-wood.com/nick/articles/pi-chudnovsky/ >>> >>> which is not the most erudite discussion, but he claims his new code is >>> faster than "BPP". >>> However most of the time is spent in computing the sqrt of an integer. >>> >> Short remark: >> >> That was the page where I found the link to the paper of Haible and >> Papanikolaou. >> >> Yes, the sqrt part of the Chudnovsky formula is very time comsuming. For >> this problem I found an optimization. >> (I spent a lot of time with this problem and experimented with some >> alternatives. A binary splitted Taylor-series for the sqrt showed very >> good results but I ended I with an optimized Heron.) > |
|
From: Raymond T. <toy...@gm...> - 2014-09-22 16:57:36
|
>>>>> "Volker" == Volker van Nek <vol...@gm...> writes:
Volker> Am 20.09.2014 22:53, schrieb Raymond Toy:
>>
>> Ok. I haven't looked at your code yet, but if they're significantly faster
>> and not (much) less accurate, we should consider adding these. I'm sure we
>> can come up with a nice set of tests to cover the code to show that it's
>> good.
>>
Volker> I made some timing measurements and to summarize the results I have to
Volker> say that these algorithms are only of interest if you want to use
Volker> precisions of $fpprec > 1000 and (much) higher. In "normal" ranges, i.e.
Volker> 16 <= $fpprec <= let's say 100, they are generally much slower.
Volker> The accuracy depends on the binary representation of the argument. A
Volker> simple argument like 0.5b0 results in slightly better accuracy but e.g.
Volker> bs_sin(bs_asin(0.5b0)) leads to significantly worse results compared to
Volker> sin(asin(0.5b0)) .
Volker> fpprec:30$
Volker> x:0.5b0$
Volker> asin(x); --> 5.23598775598298873077107230547b−1
Volker> bs_asin(x); --> 5.23598775598298873077107230547b−1
Volker> sin(asin(x)); --> 5.00000000000000000000000000001b−1
Volker> bs_sin(bs_asin(x)); --> 5.00000000000000000023968760547b−1
Interesting. I'm sure this can be fixed, but it seems like an odd
artifact.
Thanks for the detailed performance results. I wasn't actually asking
for them, but it's really nice to see them.
Volker> To merge them into src one has to create precision transition points
Volker> from the current versions to the binary splitting versions and these
Volker> transitions will vary from Lisp to Lisp, from 32 to 64 bit and from
Volker> platform to platform. I am not inclined to open this can of worms.
Volker> I will put these functions to /share/contrib, so that someone who needs
Volker> $fpprec > 1000 can use them. Or for someone who wants to look at the
Volker> implementation details. But nothing more at the moment.
Volker> My functions have a bug where I need help. In case the return value is a
Volker> power of 2 and fpround has rounded from below I have the problem to fix
Volker> the exponent. It seems that I do not understand the mechanism of fpround
Volker> and *m in float.lisp. Can someone help?
Can you give an example of the problem? I have not looked at fpround
in a very long time and don't really remember how it works anymore.
Ray
|
|
From: Volker v. N. <vol...@gm...> - 2014-09-22 18:08:36
|
Am 22.09.2014 18:27, schrieb Raymond Toy:
>
> Volker> fpprec:30$
> Volker> x:0.5b0$
> Volker> asin(x); --> 5.23598775598298873077107230547b−1
> Volker> bs_asin(x); --> 5.23598775598298873077107230547b−1
> Volker> sin(asin(x)); --> 5.00000000000000000000000000001b−1
> Volker> bs_sin(bs_asin(x)); --> 5.00000000000000000023968760547b−1
>
> Interesting. I'm sure this can be fixed, but it seems like an odd
> artifact.
>
I fixed it. Now it seems that the bs_ functions are more accurate.
fpprec:32$ x:0.5b0$
asin(x); 5.2359877559829887307710723054659b−1 wrong last digit
bs_asin(x); 5.2359877559829887307710723054658b−1 OK
sin(x); 4.7942553860420300027328793521557b−1 OK
bs_sin(x); 4.7942553860420300027328793521557b−1 OK
sin(asin(x)); 5.0000000000000000000000000000001b−1
bs_sin(bs_asin(x)); 5.0b−1
asin(sin(x)); 5.0000000000000000000000000000001b−1
bs_asin(bs_sin(x)); 5.0b−1
>
> Volker> My functions have a bug where I need help. In case the return value is a
> Volker> power of 2 and fpround has rounded from below I have the problem to fix
> Volker> the exponent. It seems that I do not understand the mechanism of fpround
> Volker> and *m in float.lisp. Can someone help?
>
> Can you give an example of the problem? I have not looked at fpround
> in a very long time and don't really remember how it works anymore.
>
fpprec:30$ x:0.5b0$
asin(sin(x)); 5.0b−1
bs_asin(bs_sin(x)); 2.5b−1 BUG
The essential lines of code:
(defun bs-asincos (x fn)
(let ((phi
(let* ((fpprec (+ fpprec 12))
I leave out some lines here.
phi is now computed with 12 extra bits and
the following line is the correct result but with 12 bits extra.
(print (bs-carg1 re-z im-z fpprec)) )))
After returning from the block of higher precision I want to round back
to the original precision:
(list (print (fpround (car phi))) (print (cadr phi))) )) ; BUG
print 1 : (20769187434139310514121985316880257 -1) OK
print 2 : 2535301200456458802993406410752 OK
print 3 : -1 WRONG
The exponent must be 0 instead of -1. The binary output shows the
reason. fpround rounds from below.
print 1 :
(111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000001
-1)
print 2 :
100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
print 3 : -1
How do I get noticed when to change the exponent?
How can *m help here?
Thanks in advance
Volker
> Ray
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
|
|
From: Raymond T. <toy...@gm...> - 2014-09-22 19:41:05
|
>>>>> "Volker" == Volker van Nek <vol...@gm...> writes:
Volker> Am 22.09.2014 18:27, schrieb Raymond Toy:
>>
Volker> fpprec:30$
Volker> x:0.5b0$
Volker> asin(x); --> 5.23598775598298873077107230547b−1
Volker> bs_asin(x); --> 5.23598775598298873077107230547b−1
Volker> sin(asin(x)); --> 5.00000000000000000000000000001b−1
Volker> bs_sin(bs_asin(x)); --> 5.00000000000000000023968760547b−1
>>
>> Interesting. I'm sure this can be fixed, but it seems like an odd
>> artifact.
>>
Volker> I fixed it. Now it seems that the bs_ functions are more accurate.
What was the fix? (Did you ever post the code? I can't seem to find
it.)
>> Can you give an example of the problem? I have not looked at fpround
>> in a very long time and don't really remember how it works anymore.
>>
Volker> fpprec:30$ x:0.5b0$
Volker> asin(sin(x)); 5.0b−1
Volker> bs_asin(bs_sin(x)); 2.5b−1 BUG
Volker> The essential lines of code:
Volker> (defun bs-asincos (x fn)
Volker> (let ((phi
Volker> (let* ((fpprec (+ fpprec 12))
Volker> I leave out some lines here.
Volker> phi is now computed with 12 extra bits and
Volker> the following line is the correct result but with 12 bits extra.
Volker> (print (bs-carg1 re-z im-z fpprec)) )))
Volker> After returning from the block of higher precision I want to round back
Volker> to the original precision:
Volker> (list (print (fpround (car phi))) (print (cadr phi))) )) ;
Volker> BUG
I would look at what bigfloatp does in the case where fpprec is lower
than the actual precision of the bigfloat. It adds the value of *m
into the exponent.
Volker> print 1 : (20769187434139310514121985316880257 -1) OK
Volker> print 2 : 2535301200456458802993406410752 OK
Volker> print 3 : -1 WRONG
Volker> The exponent must be 0 instead of -1. The binary output shows the
Volker> reason. fpround rounds from below.
Hmm, that seems not right. I would expect fpround to round, and
hopefully round to even. Richard might remember how this works.
Ray
|
|
From: Volker v. N. <vol...@gm...> - 2014-09-22 21:09:16
|
Am 22.09.2014 21:40, schrieb Raymond Toy: >>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: > > Volker> Am 22.09.2014 18:27, schrieb Raymond Toy: > >> > Volker> fpprec:30$ > Volker> x:0.5b0$ > Volker> asin(x); --> 5.23598775598298873077107230547b−1 > Volker> bs_asin(x); --> 5.23598775598298873077107230547b−1 > Volker> sin(asin(x)); --> 5.00000000000000000000000000001b−1 > Volker> bs_sin(bs_asin(x)); --> 5.00000000000000000023968760547b−1 > >> > >> Interesting. I'm sure this can be fixed, but it seems like an odd > >> artifact. > >> > > Volker> I fixed it. Now it seems that the bs_ functions are more accurate. > > What was the fix? (Did you ever post the code? I can't seem to find > it.) > Not worth mentioning. Most of the code I have written during spring and I had forgotten a lot during summer. While fixing one thing I messed up another. I will commit the code tomorrow. Too late for me now. > > I would look at what bigfloatp does in the case where fpprec is lower > than the actual precision of the bigfloat. It adds the value of *m > into the exponent. Yeah! bigfloatp does it. Now I understand the mechanism. Ray, thanks a lot. Volker > > Ray > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |
|
From: Andrey G. G. <A.G...@in...> - 2014-09-24 13:43:32
|
On Tue, 16 Sep 2014, Camm Maguire wrote:
> 64 bit 32 bit
> ------ ------
> gcl-2.6.11: 134.369 128.440
> sbcl: 141.856 151.168
> cmucl: 200.540
> ccl: 286.512 232.366 (1 failure)
> ecl: 512.615 534.442 (1 failure)
> clisp: 918.053 741.340
I've finally committed gcl-2.6.11 to Gentoo (woth Fedora patches, thanks,
Jerry). Here are my usual results, maxima-5.34.1:
64-bit 32-bit
gcl-2.6.11 144 169
sbcl-1.2.2 149 164
cmucl-20e 239
ccl-1.10 302 277
ecl-13.5.1 476 509
clisp-2.49 1016 794
Andrey
|
|
From: Robert D. <rob...@gm...> - 2014-09-19 16:49:29
|
On 2014-09-19, Volker van Nek <vol...@gm...> wrote: > [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. > In contrast to fpe1, .. these implementions are still some kind of raw > material and need more error analysis. And of course it's a lot more > difficult to merge them into Maxima. My idea is to put them into > /share/contrib for now. ] OK by me. > The values of %e, %pi, %gamma and log(2) computed by the described > functions are checked against reference values which were parsed and > rounded to the same precision. For all 0 < $fpprec < 10000 there are no > differences to the reference values. Sounds good. What about differences with respect to the existing implementation? Also, as mentioned by RJF, I would be interested to know if the new algorithms are faster or slower than the existing ones for relatively small values of fpprec. best Robert Dodier |
|
From: Robert D. <rob...@gm...> - 2014-09-20 16:56:44
|
On 2014-09-20, Volker van Nek <vol...@gm...> wrote: > Here are the timing results for small precisions: Looks good. Keep up the good work! Robert Dodier |
|
From: Jan H. M. <jan...@ma...> - 2014-09-21 08:12:46
|
Maybe I overlooked that: What was the "old" way maxima computed e and pi? Is there a possibility to look at these codes for non developers? bw Jan > Am 20.09.2014 um 22:53 schrieb Raymond Toy <toy...@gm...>: > > > >> On Sat, Sep 20, 2014 at 2:58 AM, Volker van Nek <vol...@gm...> wrote: >> Am 19.09.2014 20:35, schrieb Raymond Toy: >> >>>>>> "Volker" == Volker van Nek <vol...@gm...> writes: >> > >> > Volker> [ I also implemented exp(x), log(x), sin(x) and friends for bigfloat x. >> > Volker> In contrast to fpe1, .. these implementions are still some kind of raw >> > Volker> material and need more error analysis. And of course it's a lot more >> > Volker> difficult to merge them into Maxima. My idea is to put them into >> > Volker> /share/contrib for now. ] >> > >> > Is there something wrong with the current implementations of these >> > functions? >> > >> > Ray >> > >> >> Ray, as I wrote in my last sentence I do not feel any pressure to >> replace the current functions in src. >> >> After coding the binary splitting versions for the constants I was >> curious to check out the other algorithms described in this paper. >> >> I thought it is worth to share the implementation of these algorithms. >> Perhaps someone can use them or is simply interested to study them. >> >> The binary splitting variants are very fast and in some far future these >> implementations might be worth to consider. At the moment I don't want >> to risk breaking anything in src for the sake of speed advantages. > > Ok. I haven't looked at your code yet, but if they're significantly faster and not (much) less accurate, we should consider adding these. I'm sure we can come up with a nice set of tests to cover the code to show that it's good. >> >> Volker >> >> > >> > ------------------------------------------------------------------------------ >> > Slashdot TV. Video for Nerds. Stuff that Matters. >> > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Maxima-discuss mailing list >> > Max...@li... >> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> > >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. Video for Nerds. Stuff that Matters. >> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Maxima-discuss mailing list >> Max...@li... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > -- > Ray > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X