FFT Multiplication (HP-48G/GX/G+)
|
02-15-2014, 09:41 PM
Post: #21
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
(02-15-2014 08:26 PM)Gerson W. Barbosa Wrote:No, the stack diagram usually lists the inputs, the way and the output.(02-14-2014 10:37 PM)Raymond Del Tondo Wrote:On my HP-48GX (and on the emulator) things go like this: [%] [%]' --> ENTER --> [%]". Is this behavior normal? The program expects two arrays, and returns another array. (02-15-2014 08:26 PM)Gerson W. Barbosa Wrote: Here is the running times table, times in seconds:You could use a simple TICKS wrapper, very similar to the tEVAL I use. Thanks for the correction about the element count. For some reason I thought the example arrays consisted of 128 elements, but it was 64 only. My fault. So the timings in my last posts actually were for two arrays of 64 elements each. Still not bad for the brave old HP 48, and still slightly faster than the 50g;-) Cheers -- Ray |
|||
02-15-2014, 10:19 PM
(This post was last modified: 02-15-2014 10:20 PM by Gerson W. Barbosa.)
Post: #22
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
(02-15-2014 09:41 PM)Raymond Del Tondo Wrote:(02-15-2014 08:26 PM)Gerson W. Barbosa Wrote: On my HP-48GX (and on the emulator) things go like this: [%] [%]' --> ENTER --> [%]". Is this behavior normal?No, the stack diagram usually lists the inputs, the way and the output. This is what I get, when I enter two arrays, for instance: [1234] [5678] FFTMLTS2 --> 3: 7006652 2: 0 1: <2d> Upon pressing ENTER, I finally get [ 700 6652 ] Even calling FFTMLTS2 inside a program, I always get a screen like that. That's why I can't time it by using TICKS or by any other means. Something wrong? Thanks! Gerson. |
|||
02-15-2014, 11:23 PM
Post: #23
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
Hi Gerson,
(02-15-2014 10:19 PM)Gerson W. Barbosa Wrote: Something wrong?Thanks for the hint. The binary in the attachment still has some debug info (like the stack view included). I updated the attachment by including a binary without debug info. Seems it was too late in the morning:-) Please re-download the zip file. Cheers -- Ray |
|||
02-15-2014, 11:53 PM
(This post was last modified: 02-16-2014 12:31 AM by Gerson W. Barbosa.)
Post: #24
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
(02-15-2014 11:23 PM)Raymond Del Tondo Wrote: Hi Gerson, It's ok now, thanks! Now I get 22.25 seconds for two 64-element arrays, close to what you've reported. Just one more question: does your SysRPL do a List->Array conversion at the end? (I don't understand the code, but it appears to do that from the behavior of your previous compiled program. My latest HP-48GX version, as of yesterday, uses lists only once, to do the Hadamard multiplication. This has improved performance significantly. Would it do the same in SysRPL? (Assuming of course your SysRPL version corresponds to the older User-RPL version). Cheers, Gerson. P.S.: Here is the updated table: Code:
The difference is most likely due to the final conversion to array, which wasn't being taken into account in the manual timing. |
|||
02-16-2014, 01:51 AM
Post: #25
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
(02-15-2014 11:53 PM)Gerson W. Barbosa Wrote: It's ok now, thanks! Now I get 22.25 seconds for two 64-element arrays, close to what you've reported. Just one more question: does your SysRPL do a List->Array conversion at the end? (I don't understand the code, but it appears to do that from the behavior of your previous compiled program. My latest HP-48GX version, as of yesterday, uses lists only once, to do the Hadamard multiplication. This has improved performance significantly. Would it do the same in SysRPL? (Assuming of course your SysRPL version corresponds to the older User-RPL version).The SySRPL version doesn't use lists for the array/vector at all. Starting after the 2nd fft call the result vector is dissolved during the multiplication loop. After that loop the input vector for the ifft call is generated via XEQ>VEC. After the ifft call the result vector is dissolved again during the rounding/cutting loop. Following that loop, the stack contains a meta object of sizeA+sizeB entries (SysRPL version). The final loop always works on the first two stack levels (elements n and n+1) of the meta object, and finally rotates out the level 1 ob. Since the meta ob will be worked on from the end to the front, one final rotation is needed after the loop to retain the correct order of elements. The conversion to a vector at the end of the program takes about 81ms for a 256 elements meta ob, so that's rather negligible. Cheers -- Ray |
|||
02-16-2014, 02:25 AM
Post: #26
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
(02-16-2014 01:51 AM)Raymond Del Tondo Wrote:(02-15-2014 11:53 PM)Gerson W. Barbosa Wrote: It's ok now, thanks! Now I get 22.25 seconds for two 64-element arrays, close to what you've reported. Just one more question: does your SysRPL do a List->Array conversion at the end? (I don't understand the code, but it appears to do that from the behavior of your previous compiled program. My latest HP-48GX version, as of yesterday, uses lists only once, to do the Hadamard multiplication. This has improved performance significantly. Would it do the same in SysRPL? (Assuming of course your SysRPL version corresponds to the older User-RPL version).The SySRPL version doesn't use lists for the array/vector at all. Thanks for the detailed explanations. Although (02-16-2014 01:51 AM)Raymond Del Tondo Wrote: The conversion to a vector at the end of the program takes about 81ms for a 256 elements meta ob, so that's rather negligible. Yes, I remember now the conversion was immediate after pressing ENTER in your debug version. I can't explain the 15 seconds difference compared to my manual timing, though. I'm sure I didn't make any mistake while taking time measurements, also my Casio wristwatch is accurate enough: only 133 seconds in advance since I bought it in Jul/2008 :-) (Time to adjust it for the first time now that our DST has just ended) Thanks again for your fast SysRPL version (Finally the sixfold increase in speed when compared to the HP-71B !). Only thing left is checking whether 5-digit groups will yield accurate results -- will do that later. Best regards, Gerson. |
|||
02-16-2014, 05:21 AM
(This post was last modified: 02-19-2014 12:39 PM by Gerson W. Barbosa.)
Post: #27
|
|||
|
|||
RE: FFT Multiplication (HP-48G/GX/G+)
Ever been curious about all digits of 253! ? Out of 500, the HP-48GX gives the first 12 only: 517346099264. Just run the program below with single argument 253 and wait for about one hour and 45 minutes. This is by no means an efficient way to do this, but might be a way to check the accuracy of the algorithm after 253 multiplications, even though one on the operands is small. (Better use Emu48 and get the result under 60 seconds or less).
Code:
where FFTMLTS2 is Raymond del Tondo's SysRPL program above and TRIM is the following program, slightly adapted from TRIM, by Wayne H. Scott, part of his POLY package: Code:
--> [ 5173 4609 9264 78 9218 433 899 7295 2746 9542 3561 2720 6639 9607 4846 3616 3134 3029 313 41 2383 1443 7828 1112 1374 4932 5428 7661 7296 3169 484 977 8527 4435 4743 3640 9654 4589 6311 9980 576 3521 219 7345 934 790 1685 4446 6163 7384 4451 7144 4589 2498 2615 9309 2898 1062 2514 4818 9873 9824 3499 6567 2944 9381 9909 5203 1087 3152 8570 9655 6175 4517 6766 2603 4976 5427 6777 1987 6267 959 7099 9373 2257 7683 9082 7849 7279 3284 6880 6763 5727 3110 3332 7966 9572 6049 2114 9638 6749 6804 5622 1513 5307 5201 4396 1440 1249 2800 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] As far as I have checked, all digits are correct, considering the hidden leading zeros in some 4-digit elements. ----- Update: I've run the User-RPL program on the emulator (50g) and formatted the output to integer. The result was exactly the same I got when computing 253! on the hp 50g in exact mode. Also, an exact match was obtained for 997! (2559 digits). This was computed using arrays with 5-digit elements. Here they are, in case someone wants to check them out :-) Code:
Update: It appears 5-digit group arrays yield reliable results up to 128 elements only (1280-digit results, 5*256). 4^2^11 has 1234 digits and is correctly computed using the program below. The next doubling (4^2^12) is not. Code:
|
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: