Programs for 15C and 35S


« Next Oldest  Next Newest »

▼
05192013, 01:28 PM
▼
05202013, 04:39 AM
Thank you, very useful! ▼
05202013, 05:46 AM
+1. BTW, is anybody collecting such programs in a program library of some kind? The collective knowledge of RPN programmers shouldn't vanish in time IMHO. I know the RPL folks have their place at hpcalc.org. Is there anything alike for RPN? If true, where? d:) ▼
05202013, 08:05 AM
05202013, 02:54 PM
I have some programs on my HP15C simulator page and some of Eddie's programs are part of the simulator distributions. I am looking forward to receiving more HP15C programs to be published and included with the simulator. Preferably already as .15c program file with the documentation included. ▼
05202013, 03:48 PM
The listings that your simulator creates are very nice! Congratulations! Just had a glimpse at Little Gauss. Here's a third variant: LBL C
In the article
Kind regards Edited: 20 May 2013, 6:34 p.m. ▼
05212013, 02:43 PM
Quote:More computational effort, I think, but a record for conciseness! Increasing the constants by one will give the sum of the first n triangular numbers. Increasing them by one again will give the sum of the latter, and so on it appears. Cheers, Gerson. ▼
05212013, 11:27 PM
If you define as the
This is similar to how differentiation and integration operate upon the functions f_{k}(x) = x^{k}/k!. Hence the similarity of Newton's Forward Difference Formula with the Taylor series expansion.
Cheers
06032013, 10:37 PM
On the HP42S Little Gauss can be made the same size in bytes without using COMB. One step longer, however:
00 { 13Byte Prgm }
Since we're at it, here is Gauss Little (Inverse Little Gauss :) 00 { 21Byte Prgm } Cheers, Gerson.
▼
06042013, 12:39 AM
Very nice! Do you still remember that thread: Short Quadratic Solver (HP42S)
This solution is based on it: 00 { 17Byte Prgm }
Best regards
The port to HP15C is straight forward: 001  42,21,11 LBL A Edited: 4 June 2013, 4:27 a.m. ▼
06042013, 10:53 AM
Quote: Great saving, more than I expected!
Just an interesting result: 2 SQRT 23 + XEQ GL XEQ GL Cheers, Gerson. [sub]Edited to fix a typo per Thomas's observation below[/pre]
Edited: 4 June 2013, 12:03 p.m. after one or more responses were posted ▼
06042013, 12:01 PM
How on earth did you stumble upon this? That's amazing! But it took me a while to figure out that XL is probably a typo.
Best regards ▼
06042013, 12:10 PM
Okay, I guess I figured it out:
#!/usr/bin/python 6.505598527340 I'm still impressed.
Cheers ▼
06042013, 12:46 PM
Quote:How accurate should that be? On the WP34S I get679065481033757312.000000000000 679065481033757541.1897711439112775
Another interesting nearinteger, not related to the above: pi^34 = 8.00010471505e16or pi^34*10^{16}  pi/3*10^{4} = 7.99999999529
Yet another one involving sqrt(2) and pi: 1/2*pi^34 = 141422281.793 Whether these are a coincidence or not, I don't know. Best regards, Gerson
Edited: 4 June 2013, 12:49 p.m. ▼
06042013, 01:38 PM
Also, I hear the 4th root of (9^2 + 19^2/22) is pi. ▼
06042013, 09:27 PM
Quote:http://jsmarkovitch.files.wordpress.com/2009/11/coincidencedatacompressionandmach_sconceptofeconomyofthoughtjsmarkovitch.pdf
Quote: This is a bit closer, but still too far away:
Edited: 4 June 2013, 9:41 p.m.
06042013, 12:11 PM
Quote: PI XEQ LG XEQ LG 2 SQRT  > 22.9999918008Cheers, Gerson.
06042013, 05:34 AM
For those interested in the math behind it: Quadratic equation:
Solution:
Logarithmic representation of inverse hyperbolic function:
This implies:
Try to bring the solution of the quadratic equation to this form:
Substitution:
Move the negative sign through sinh^{1}:
Use e^{x}=1/e^{x}:
05202013, 08:32 AM
Quote:
G = (1,030.469  1,000) / 870.545 = 0.035
So it seems a factor 2 is missing somewhere. As I'm not an engineer I wonder why the length L is divided into two parts similar to G:H (or rather G:H) to determine the peak. Why would somebody want to do that? What's the real world application of it?
Kind regards ▼
05232013, 03:56 PM
Quote: I am looking into this. I got the formulas from the Fundamental of Engineering Handbook reference book, if it helps. You determination for G and H are straight forward. Update: It seems to be a factor of 2 at peak point. Vertical curves, to my understanding, are symmetrical in a sense of tangent lines: one created from the beginning of the curve and on at the end of the curve. If a line is drawn at the intersection of the tangent line perpendicular to the base, that line bisects the length of the base. The grade is determined from where the tangent lines meet. In a perfectly symmetrical vertical curves the tangent lines meet at the curve's peak elevation. For this case: G = (y0  I)/(L/2) and H = (I  y0)/(L/2) where y0 is the peak elevation. Some more information is provided here: http://www.wsdot.wa.gov/publications/manuals/fulltext/M2223/Vertical.pdf http://www.iowadot.gov/design/dmanual/02b01.pdf I am not an engineer either, I just have an interest in the subject. Hope this helps, Eddie
Edited: 23 May 2013, 10:09 p.m. ▼
05252013, 07:33 AM
I completely mixed up the peak point of the curve and the Vertical Point of Intersection. But I didn't realize that we're dealing with a curve (a parabola to be more specific) because it's missing in your sketch. I assumed the two intersecting lines, that's the curve. Thanks for providing the links to the papers. It clarified a lot.
Cheers ▼
05292013, 07:24 AM
Quote: Thomas, Thanks for posting the question  you helped me become clearer on the subject. Much appreciated. ▼
05292013, 08:52 AM
Just compare these two images:
VERTICAL CURVE EQUATIONS
HP35S Vertical Curve: Elevation at Peak and at End Point
LEGENDg_{1} = Approach gradient in %
EQUATIONSX = g_{1}{L/A} Your sketch suggest that (x_{0}, y(x_{0})) is the Vertical Point of Intersection where instead it is the peak of the curve. I recommend to change the sketch.
Kind regards
05202013, 10:28 AM
Eddie, I tried the Julian date program and noticed that it will work only for dates since the introduction of the Gregorian calendar on October 15, 1582 (JD 2299161). Every date before produces a JD result that is off by some days, simply because the rules for leap years introduced with the Gregorian calendar did not apply earlier.
Example: date Julian Day 15C program errorIn other words, the 15C program assumes a proleptic (perpetual) Gregorian calendar, so that even dates before Oct 15, 1582 are assumed Gregorian. This means that even dates in medieval times are assumed to be given in a calendar system introduced many centuries later. This is at least not very common, so that either the program should be modified or a respective note should be added. Dieter ▼
05232013, 03:58 PM
Quote: Dieter, I will do the note. Thanks for pointing this out. Always appreciated. Eddie
Edited: 23 May 2013, 10:09 p.m. 