eDay

07022018, 12:41 PM
Post: #1




eDay
Hi all,
a perfect day to introduce myself. Today I'm celebrating eDay. At least in the rest of the date format world a look at the calendar shows 2.718! Euler found there is a limit to infinitesimal exponential growth resulting in (1+1/n)^n equals 2.718.. for large n. There is beauty (e^iPi = 1) and magic (e = lim n>inf (n^1/n)^Prime(n). I wondered how large n should be to meet today's event « 1 2.718 > n eday « CLLCD DO 'n' INCR INV 1 + n ^ DUP n 1 DISP 2 DISP eday UNTIL > END n » » A simple SOLVE command should suffice but somehow I love to watch calculators at work. Patrick 

07022018, 01:57 PM
Post: #2




RE: eDay
Code: char One of the many ways to calculate e. 

07022018, 06:24 PM
Post: #3




RE: eDay
.
Hi, Patrick: First of all, welcome to the forum. I fully expect you'll enjoy the place and enrich us all with your own contributions. That said: Quote:Today I'm celebrating eDay. At least in the rest of the date format world a look at the calendar shows 2.718! Indeed, it shows in that order where I live. To contribute to your celebration, here's a very short program I wrote many many years ago to compute e to in excess of 200 digits in an HP15C. Here's an extract taken from my article "Long Live the HP15C !": This 64step program will compute from 8 to 208 decimal places of Euler’s constant, the wellknown transcendental number e = 2.71828+ . It is by no means optimized for performance but tries instead to be as short and straightforward as possible. Although you can compute more decimal places in an HP15C, for the purposes of this article this simpler program will do nicely. Program listing: Very Important: steps 30 and 43 must be entered in USER mode, while all the rest must be entered out of USER mode. An ulike character must appear next to the step number only for steps 30 and 43, and no others. 01 LBL A 23 RCL A 45 FRAC 02 MATRIX 0 24 X=0? 46 CHS 03 MATRIX 1 25 ISG 2 47 RTN 04 1 26 LBL 0 48 LBL 5 05 DIM A 27 RCL A 49 FRAC 06 DIM B 28 RCL÷ I 50 RCL B 07 RESULT B 29 INT 51 INT 08 STO 2 30u STO A 52 RCL RAN# 09 STO I 31 GTO 2 53 * 10 EEX 32 RCL I 54 + 11 8 33 PSE 55 R/S 12 STO A 34 RCL MATRIX A 56 GTO 4 13 1/X 35 MATRIX 7 57 LBL 2 14 STO RAN# 36 TEST 0 58 RCL* I 15 LBL 1 37 GTO 1 59  16 RCL MATRIX A 38 RCL MATRIX B 60 RCL RAN# 17 RCL MATRIX B 39 RCL RAN# 61 ÷ 18 + 40 * 62 STO+ A 19 RCL 2 41 FIX 8 63 RCL A 20 STO O 42 LBL 4 64 GTO 0 21 ISG I 43u RCL B 22 LBL 3 44 GTO 5 The constant e is computed using the wellknown formula: e = 1 + 1/1! +1/2! + 1/3! + 1/4! + ... using enough terms to achieve the desired precision. We use the powerful matrix capabilities of the HP15C, holding the current term in a vector (matrix A), and the running sum in another vector (matrix B). Steps 0114 dimension and initialize both matrices, as well as some indexes and ancillary constants. Starting with 1, each term is computed by dividing the previous one by the corresponding divisor up to a maximum of 208 decimal digits, until we arrive at a term that is zero to the specified precision. This multiprecision arithmetic is done by considering each term as composed of N blocks (126), each holding 8 digits, the extra digits in each register being carried out to the next block. Since we may use divisors up to 125, each block is limited to 8 digits, lest the carry would make the next block larger than the 10 digits an HP15C storage register can hold. The addition of each multiblock term to the running total is done using matrix arithmetic in steps 1618. Steps 1925 increment the divisor and keep track of the first nonzero block of each term to optimize speed by avoiding unnecesary operations. Steps 2631 and 5764 perform the multiprecision division. The process ends when the current term has all its blocks equal to zero. As all blocks always hold positive values, we can use an advanced matrix operation, the Row Norm, to test for finalization, because in this case the Row Norm will equal zero if and only if all block values are zero. This is tested in steps 3437. Once this condition is met, the result matrix which holds the running sum is scaled down for display using matrixscalar arithmetic (steps 3840). The computed answer is then displayed by recalling each block in turn, adding the carry from the previous block, and marking the last one negative (steps 4156). As you can see, though simple, this program does use some of the HP15C’s advanced programming capabilities (as well as a trick or two), including basic matrix operations (MATRIX 1), advanced matrix functions (MATRIX 7), recall arithmetic (RCL÷ I), using registers as indexes including incrementandtest operations (ISG 2) , autoincrementtestandloop matrix element access (uSTO A, uRCL B), matrix arithmetic (steps 18 and 40), etc. Usage instructions: 1) After keying in the program, make sure you’re not in complex mode (press CF 8 if in doubt), then you must commit enough storage registers to the common pool for the matrix operations. To that effect, press: 2, f DIM (i) 2) Now, enter the number of 8digit blocks you want to use, from 1 (8 digits) to 26 (208 digits). For example, if you want to compute 200 decimal digits of e, you must specify 200/8 = 25 blocks. Start the program by pressing either f PRGM, R/S or GSB A or (in User mode) A While running, it will briefly show each succesive divisor used (2, 3, ...), then once the computation is over, it will display each block of 8 decimal digits (with an initial “0.”, in order to preserve leading zeros at the left end of the block), starting with decimals 1st8th. The very last block will be marked negative, to signal the end of the output. Let’s see an example: to compute the first 24 decimal digits of e, we specify 24/8 = 3 blocks, and proceed like this (in USER mode): 3, A > (2.00000000) [divisor = 2] ... [after 2’26”] > (25.00000000) [divisor = 25] > 0.71828182 [decimals 1st 8th] R/S > 0.84590452 [decimals 9th16th] R/S > 0.35360274 [decimals 17th24th] so, after adding a “2.” at the front and writing down all 8digit blocks (that is, minus the initial “0.” or “0.”) in their proper order, we finally get: e = 2.71828182 84590452 35360274 where, due to the accumulation of rounding errors during the process, the last block of the computed answer comes out as “3536 0274” while correct is “3536 0287”, so we have an error of 13 ulps (units in the last place). 3) Should you need to display the output again, press: GSB 4 For 208 decimal digits, the final result is: e = 2.71828182 84590452 35360287 47135266 24977572 47093699 95957496 69676277 24076630 35354759 45713821 78525166 42742746 63919320 03059921 81741359 66290435 72900334 29526059 56307381 32328627 94349076 32338298 80753195 25101901 15738281 The last block of the computed answer comes out as “1573 8281” while correct is “1573 8341”, so the error is 60 ulps, and thus after rounding the last two places we’ve got 206 decimals fully correct. Regards. V. . All My Articles & other Materials here: Valentin Albillo's HP Collection 

07032018, 11:53 AM
Post: #4




RE: eDay
Thank you for showing tremendous ideas to approximate e.
The real fun in programming seems to come from how you deal with given technical restrictions. I remember a nice review about the HP25 published in Creative Computing outlining how these limitations strengthen strategic thinking. Article I should give up my Prime and go back to HP25 or TI57... Regarding my little program to find n for 2.718 there are interesting forensic effects. In fact, the numerical solver delivers another n. Graphing (1+1/n)^n and zooming around 4822.55 a pronounced sawtooth alternates above and below eday. 

07032018, 09:37 PM
Post: #5




RE: eDay
(07032018 11:53 AM)Pjwum Wrote: Regarding my little program to find n for 2.718 there are interesting forensic effects. In fact, the numerical solver delivers another n. Graphing (1+1/n)^n and zooming around 4822.55 a pronounced sawtooth alternates above and below eday. Of course the is no such sawtooth, mathematically. What you see is the result of roundoff errors, especially when calculating 1+1/n. After the addition of 1 only 8 out of 12 digits of the original 1/n value are left. Maybe you can try rewriting the equation as exp[n · ln1+x(1/n)]. BTW the exact result is n = 4821,66555538... Dieter 

07032018, 11:25 PM
Post: #6




RE: eDay
.
Hi again, Patrick: (07032018 11:53 AM)Pjwum Wrote: Thank you for showing tremendous ideas to approximate e. You're welcome. I wrote the HP15C program as part of my series of articles "Long Live the ..." intended as a celebration of classic HP calcs and sometimes particular Modules or ROMs (such as the Advantage module for the HP41C or the Math ROM for the HP71B). The C program posted by Mr. Klemm was obviously taken from the book "Obfuscated C and other mysteries", page 260. The program was written by Roemer B. Lievaart and it won the 1989 Obfuscated C Code Contest prize for Best Layout. It's a very interesting book, I can heartily recommend it. Quote:The real fun in programming seems to come from how you deal with given technical restrictions. I remember a nice review about the HP25 published in Creative Computing outlining how these limitations strengthen strategic thinking. Article Completely agree, and thanks a lot for the link to the HP25 article, I also agree with its author and really enjoyed my HP25 (my very first HP calc) back then at the end of the 70's. If you liked that article, I really think that you'd also like to read my "Long Live the HP25" article where, among other interesting things, you'll find two HP25 programs implementing both 3rdorder and 4thorder RungeKutta differential equations solvers in less than 49 steps and leaving enough steps to define the differential equation to solve. They make 3 and 4 calls to the equation's definition, respectively, in a machine without subroutines. That's overcoming technical restrictions for you ! Regards. V. . All My Articles & other Materials here: Valentin Albillo's HP Collection 

07042018, 06:46 PM
Post: #7




RE: eDay
Quote:Of course the is no such sawtooth, mathematically. What you see is the result of roundoff errors, especially when calculating 1+1/n. After the addition of 1 only 8 out of 12 digits of the original 1/n value are left. Maybe you can try rewriting the equation as exp[n · ln1+x(1/n)]. Yes, correct interpretation. The ramp is the exponent, the step the new rounded 1+1/n. And your result is dead on; today I found n = 4821.66555538178034.. but can't go beyond that. Quote:I wrote the HP15C program as part of my series of articles "Long Live the ..." intended as a celebration of classic HP calcs Cool! Thank you.. 

07042018, 07:06 PM
Post: #8




RE: eDay
(07032018 11:25 PM)Valentin Albillo Wrote: The C program posted by Mr. Klemm was obviously taken from the book "Obfuscated C and other mysteries", page 260. Nah, I found it in Pi Unleashed by Arndt, Jörg, Haenel, Christoph on page 36. Quote:It's a very interesting book, I can heartily recommend it. Pi Unleashed is another book that we fullheartedly recommend. Later on page 85 they show this small program that calculates e to 15,000 places: Code: /* note: N=15000, LEN=87700 >= 1.4*N*log10(N), 84700=LENN/5 */ Cheers Thomas PS: Here's a link to Roemer B. Lievaart wining contribution of 1989 for the best layout. 

07062018, 09:27 PM
Post: #9




RE: eDay
Related programs in the General Software Library:


« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)