Happy new year to any that may pass here! Yea, I know I bit late, but, hey, happy new year!
Good time to start of the new year with what I hope to blog about here in the year to come...
1. Document Euclid for 35s. Particular I would like to make somekind of cheat sheet that shows what labels are assigned to which programs, what variables are used to what and user input/output. I realy missed this a while ago when wanted to use program at day time job. Good thing I had this blog then!
2. Learn to use and program the 50g. I started out fine, but then holidays happened and real job has been keeping me busy so fare in 08. First programming project will propably be a UserRPL Euclid. Later I hope to look into C programming on it. I make my living hacking Java these days, but I started out as a C programmer, this could be way to get to do some good old C hacking again :-).
3. I realy would enjoy to program the 41CV to, say ... ahem ... make an Euclid version for that to. What I would like with the 41CV compared to the 35s is the ability to name programs and assigne program to keys while in user mode. For these types of problem I for sure is going to miss 35s' vector type...
Well, see if get time to do any of this sometimes (may be a bit quiet here for a while...).
Monday, January 14, 2008
Monday, November 12, 2007
Fixing the HP-41CV - IV : More HP calculator stuff from the past recovered
After got back the HP-41CV in as good as new condition I got motivated to dig into the old stuff stored away at my parents place to see what else could be found from the good old days. After this time's digging my HP inventory (not counting the 35s) is:
Machines
One working HP-41CV (thanks to FixThatCalc).
One not working HP-29C (details at the end of this blog entry) with manuals (in Swedish).
HP-41 manuals
Instruktionsbok Och Programmeringshandledning - The instruction and programming manual in Swedish! Apperently they did not bother to do a translation to Norwegian!
Hur man använder kalkulatorer från HP - Small booklet explaining the RPN paradigm, also in sweedish.
HP-41C Standard Applications
HP-41 accessories
Modules:
Miscellaneous
A module holder with my two missing port 'protectors' :-)
Keyboard layovers for the modules AND two blank ones and one unidentified one!
Comments
I know I got magnetic cards laying around somewhere so I would be interesting in using the card reader. Actual found some cards that I remembered put aside because damaged. However, still the way reader behaved on them may suggest it is suffering from old age (that and the fact they usual do). The good news (yep been chating with FixThatCalc) is that it can fixed, may very well soon be another package on it's way...
The 29C sadly is not for any practical reasons repairable I have been assured. It look brand new (did not have a long and active life), it may have a future as spare parts!
It bugs me that manual for the X functions is missing. I never got much time to play around with those and there is some I would like to utilize in my nowadays programming. Well, it may still turn up and anyway eventual I am going to get the museum's dvd set which includes the manual.
Machines
One working HP-41CV (thanks to FixThatCalc).
One not working HP-29C (details at the end of this blog entry) with manuals (in Swedish).
HP-41 manuals
Instruktionsbok Och Programmeringshandledning - The instruction and programming manual in Swedish! Apperently they did not bother to do a translation to Norwegian!
Hur man använder kalkulatorer från HP - Small booklet explaining the RPN paradigm, also in sweedish.
HP-41C Standard Applications
HP-41 accessories
Modules:
- Math I, with manual, quick reference card and keyboard overlays.
- X Functions, manual missing.
- Games, with manual and keyboard overlays.
Miscellaneous
A module holder with my two missing port 'protectors' :-)
Keyboard layovers for the modules AND two blank ones and one unidentified one!
Comments
I know I got magnetic cards laying around somewhere so I would be interesting in using the card reader. Actual found some cards that I remembered put aside because damaged. However, still the way reader behaved on them may suggest it is suffering from old age (that and the fact they usual do). The good news (yep been chating with FixThatCalc) is that it can fixed, may very well soon be another package on it's way...
The 29C sadly is not for any practical reasons repairable I have been assured. It look brand new (did not have a long and active life), it may have a future as spare parts!
It bugs me that manual for the X functions is missing. I never got much time to play around with those and there is some I would like to utilize in my nowadays programming. Well, it may still turn up and anyway eventual I am going to get the museum's dvd set which includes the manual.
Saturday, November 10, 2007
Fixing the HP-41CV - III : An old machine reports for duty again!
Got it (HP-41CV serial nr. 2103A07854) back from FixThatCalc!
Belive they did a great job, seems to be working just fine AND they do a fantastic job cleaning the machines: Can not remember it have looked this good. Sure it must have when I got it, but that is 26 years ago!
There is a note returned with the machine telling me I should not put it back in it's pouch since it has started to deteriorate and it may harm the calculator. It has the undertone of a caring mother telling children to take good care of their fine toys... I belive we who cares for these devices are very lucky that FixThatCalc exists!
Belive they did a great job, seems to be working just fine AND they do a fantastic job cleaning the machines: Can not remember it have looked this good. Sure it must have when I got it, but that is 26 years ago!
There is a note returned with the machine telling me I should not put it back in it's pouch since it has started to deteriorate and it may harm the calculator. It has the undertone of a caring mother telling children to take good care of their fine toys... I belive we who cares for these devices are very lucky that FixThatCalc exists!
Thursday, November 8, 2007
Got my hands on a HP-48GX
A co-worker discovered my interest for HP calculators and remembered he had some kind of graphing calculator while at engineering shool. Belived it was some kind of a TI model. Turned out he had a HP-48GX collecting dust home!
To cut a short story shorter, he has kindly borrowed me the machine. Later this year I will get my self a HP-50g and this will allow me to learn the RPL language up front!
I may do a RPL port of the HP-35s Euclid Pack implementation...
Resources related to getting to know the RPL series of machines:
Manuals downloadable from Educalc.net here.
HP 48G Series Advanced User's Reference Manual available here at hpcalc.org.
Short but good introduction to RPL at the museum.
UserRPL stack commands, article at the museum.
The usenet group ofcourse.
FAQs found at the Internet FAQ Archieves.
To cut a short story shorter, he has kindly borrowed me the machine. Later this year I will get my self a HP-50g and this will allow me to learn the RPL language up front!
I may do a RPL port of the HP-35s Euclid Pack implementation...
Resources related to getting to know the RPL series of machines:
Manuals downloadable from Educalc.net here.
HP 48G Series Advanced User's Reference Manual available here at hpcalc.org.
Short but good introduction to RPL at the museum.
UserRPL stack commands, article at the museum.
The usenet group ofcourse.
FAQs found at the Internet FAQ Archieves.
Tuesday, November 6, 2007
A HP-35s hacker
Stefan is a HP calculator enthusiast that got himself a HP-35s and have a done a man's work providing two (so fare) rather lengthy programs for Curve Fitting and Matrix Operations on the HP-35s.
Mind you, as this thread (about Stefan's matrix program) at the MoHPC forum shows: If you need to do serious matrix work, clearly you should consider a RPL machine.
By the way, do check out Stefan web content, he is an inspiration to any kind of web author and also he turns out to be a norgesvenn!
Mind you, as this thread (about Stefan's matrix program) at the MoHPC forum shows: If you need to do serious matrix work, clearly you should consider a RPL machine.
By the way, do check out Stefan web content, he is an inspiration to any kind of web author and also he turns out to be a norgesvenn!
Monday, October 22, 2007
A programmer's HP-35s review
Some thoughts on the HP-35s after been programming it for a while: Doing the HP-35s Euclid Pack implementation.
Two features I learned to love when programming the 35s: Vector type and equations.
Vector type
The vector type has been critizised for missing key features:
Some focus has been on using 3D vectors to augment the machine's 800 indirect registers. For the things I do and the fact that it is a closed system (no I/O), I can't imagine applications using a large fraction of the 800 registers even without packing 3 real numbers in one register!
But, I find the data packing offered by 3D vectors to be very valuable in the 'more valuable real estate territories' of near end user variable registers (A-Z) and working registers (stack and lastx).
For example, for the design of the euclid pack project I ended up with wanting to store definition of two lines (four 2D or 3D points), two planes (two 3D points and two normal vectors) and one triangle (three 3D points) in variables.
If all data entered is in 3D, that would require minimum use 33 registers! And this is data I would like to be close to the end user, so I would like to use variables: Unless had vector type would not have room. Since have the vector type minimum register use is 11.
And implementation actual ended up storing additional data in variables to make certain computations easy and results handy. And I still did not use up all variable registers...
Also now we can have 12 real numbers on the stack! That becomes usefull when using programs that take more than 4 numbers as input. For example to define a 3D triangle (the T program) end user must give in nine numbers (three 3D numbers), without the ability to just put the points on the stack and run the program, the program would had to prompt for the data.
Also the vector type, RPN paradigm and the use of equation is very powerfull when programming:
Equations in programs
I find programming complex calculations in need of much intermediate results to be easy on the 35s by combining the RPN paradigm, vector type and equations:
A very nice feature of the HP 35s that helps programming this way is that when in programming mode and to insert a stack register as a variable in an equation using the RDN key one sees the content of the registers user side. If one has a worked example of the problem being programmed and is programming equation by equation and running the program before programming a new equation then when programming the equation it is easy to see where on the stack needed numbers are.
One drawback of this style of programming is that the evaluation of equation makes for much slower execution then a pure RPN version. For programs that intention is to be called a large (or small...) number of times as subroutines by other programs this style of programming may not be appropiate.
On an improved HP 35s (HP 35s+ :-) perhaps one could have some kind of equation compilation?
No need for me to get into any of the now well known short commings or bugs of the device documented by the community of the MoHPC here, except to say that the reported vector syntax bug is indeed real on some machines and makes this type of programming much harder than needed. I know, I got one... Still I have been able to do whatever I did without ever needing to reset the thing.
Two features I learned to love when programming the 35s: Vector type and equations.
Vector type
The vector type has been critizised for missing key features:
- No cross product. Must make a program.
- No native way to unpack or address vector components. Must use 'dot product mask vectors'.
- No operation to tell a vector's dimension (dim or size).
Some focus has been on using 3D vectors to augment the machine's 800 indirect registers. For the things I do and the fact that it is a closed system (no I/O), I can't imagine applications using a large fraction of the 800 registers even without packing 3 real numbers in one register!
But, I find the data packing offered by 3D vectors to be very valuable in the 'more valuable real estate territories' of near end user variable registers (A-Z) and working registers (stack and lastx).
For example, for the design of the euclid pack project I ended up with wanting to store definition of two lines (four 2D or 3D points), two planes (two 3D points and two normal vectors) and one triangle (three 3D points) in variables.
If all data entered is in 3D, that would require minimum use 33 registers! And this is data I would like to be close to the end user, so I would like to use variables: Unless had vector type would not have room. Since have the vector type minimum register use is 11.
And implementation actual ended up storing additional data in variables to make certain computations easy and results handy. And I still did not use up all variable registers...
Also now we can have 12 real numbers on the stack! That becomes usefull when using programs that take more than 4 numbers as input. For example to define a 3D triangle (the T program) end user must give in nine numbers (three 3D numbers), without the ability to just put the points on the stack and run the program, the program would had to prompt for the data.
Also the vector type, RPN paradigm and the use of equation is very powerfull when programming:
Equations in programs
I find programming complex calculations in need of much intermediate results to be easy on the 35s by combining the RPN paradigm, vector type and equations:
- The vector type allows 12 values to be stored on the stack.
- Equations in programs can use all these number while being evaluated, only when done is maximum three numbers lost on the stack: A 3D vector in the T stack register.
- The result of evaluating an equation may very well be a 3D vector: A single line in a program may execute three equation which result raises the stack only once.
A very nice feature of the HP 35s that helps programming this way is that when in programming mode and to insert a stack register as a variable in an equation using the RDN key one sees the content of the registers user side. If one has a worked example of the problem being programmed and is programming equation by equation and running the program before programming a new equation then when programming the equation it is easy to see where on the stack needed numbers are.
One drawback of this style of programming is that the evaluation of equation makes for much slower execution then a pure RPN version. For programs that intention is to be called a large (or small...) number of times as subroutines by other programs this style of programming may not be appropiate.
On an improved HP 35s (HP 35s+ :-) perhaps one could have some kind of equation compilation?
No need for me to get into any of the now well known short commings or bugs of the device documented by the community of the MoHPC here, except to say that the reported vector syntax bug is indeed real on some machines and makes this type of programming much harder than needed. I know, I got one... Still I have been able to do whatever I did without ever needing to reset the thing.
Sunday, October 21, 2007
HP-35s Euclid Implementation - XV : The inscribed and circumscribed circle of a triangle
The final program to fullfill the requirements! Problem 16 and 17: Finding the inscribed (incircle) and circumscribed (circumcircle) circles of a triangle.
Finding the inscribed circle is the same as solving the problem of finding the circle tangent to three lines (lines defined by the triangle edges) and finding the circumscribed circle is the same as solving the problem of finding the circle that passes through three points (triangle's vertexes).
The triangle in question has been entered using the T program.
Inscribed circle:
The barycentric coordinates for the incenter are:
The radius of the inscribed circle is:
Circumscribed circle:
With the intermediate results
Stack Input/Output:
Variables:
Reads:
Terms of use.
Mnemonics: O since letter is a circle (or more or less depeding on font, rather circular on the 35s).
Reason for not converting to cartesian coordinates is that since the barycentric coordinates are relative to the vertices it is much easier to 'see' where the center points are relative to the triangle. If one where to be presented the cartesian coordinates one must remember the nine vertex coordinates to know where (relative to triangle) the center points are. Particular one see at once if the circumscribed circle's center is inside or outside the triangle.
Cartesian coordinates are easily obtained using the A program by the following key sequence:
Finding the inscribed circle is the same as solving the problem of finding the circle tangent to three lines (lines defined by the triangle edges) and finding the circumscribed circle is the same as solving the problem of finding the circle that passes through three points (triangle's vertexes).
The triangle in question has been entered using the T program.
Refering to the above triangle I give the formulas used in the HP-35s program presented here:
v3
/ \
/ \
/ \
v1------v2
Inscribed circle:
The barycentric coordinates for the incenter are:
(l1/p, l2/p, l3/p)Where p is the perimeter of the triangle (sum of all edges lengths) and l1 is the length of the edge v3-v2, l2 is the length of the edge v1-v3 and l3 is the length of the edge v2-v1.
The radius of the inscribed circle is:
(2A)/pWhere A is the area of the triangle.
Circumscribed circle:
With the intermediate results
d1=-e2*e3the barycentric coordinates for the circumcenter are:
d2=-e3*e1
d3=-e1*e2
(e1=v3-v2, e2=v1-v3, e3=v2-v1, * is the dot product)
c1=d2d3
c2=d3d1
c3=d1d2
c=c1+c2+c3
((c2+c3)/2c, (c3+c1)/2c, (c1+c2)/2c)The radius of the circumscribed circle is:
sqrt((d1+d2)(d2+d3)(d3+d1)/c)/2These formulas are taken from the excelent book 3D Math Primer for Graphics and Game Development that also provide background for much of the geometric problems in the Euclid Pack specification.
Stack Input/Output:
No input on stack-> XEQ O ->[[bc1, bc2, bc3], cr, [bi1, bi2, bi3], ir | L]Where (bc1, bc2, bc3) are the barycentric coordinates for the circumscribed circle's center (circumcenter) , cr is its radius, (bi1, bi2, bi3) are the barycentric coordinates for the inscribed circle's center (incenter) and ir is its radius.
Variables:
Reads:
K : First vertex (3D vector). Populated by the T program.Writes:
L : Second vertex (3D vector). Populated by the T program.
M : Third vertex (3D vector). Populated by the T program.
Z : Scratch data.Program:
O001 LBL OComments:
O002 5
O003 STO I
O004 STO(I)
O005 4
O006 STO I
O007 LASTX
O008 STO(I)
O009 eq M-L
0O10 eq M-K
O011 eq [ABS(REGY),ABS(REGX),ABS(L-K)]
O012 STO Z
O013 eq REGX/([1,0,0]xREGX+[0,1,0]xREGX+[0,0,1]xREGX)
O014 R^
O015 R^
O016 XEQ X001
O017 R^
O018 X<>Y
O019 ABS
O020 eq REGX/([1,0,0]xZ+[0,1,0]xZ+[0,0,1]xZ)
O021 X<>Y
O022 RDN
O023 X<>Y
O024 RCL(I)
O025 ABS
O026 RDN
O027 XEQ U001
O028 eq M-L
O029 eq K-M
O030 eq L-K
O031 eq [-REGYxREGX,-REGXxREGZ,-REGZxREGY]
O032 eq [([0,1,0]xREGX)x([0,1,0]xREGX),
([0,0,1]xREGX)x([1,0,0]xREGX),
([1,0,0]xREGX)x([0,1,0]xREGX)]
O033 eq [1,0,0]xREGX+[0,1,0]xREGX+[0,0,1]xREGX
O034 eq 0.5xSQRT((([1,0,0]xREGZ+[0,1,0]xREGZ)x
([0,1,0]xREGZ+[0,0,1]xREGZ)x
([0,0,1]xREGZ+[1,0,0]xREGZ))/REGX)
O035 eq [([0,1,0]xREGZ)+([0,0,1]xREGZ),
([0,0,1]xREGZ)+([1,0,0]xREGZ),
([1,0,0]xREGZ)+([0,1,0]xREGZ)]/(2xREGY)
O036 XEQ U079
O037 RTN
Terms of use.
Mnemonics: O since letter is a circle (or more or less depeding on font, rather circular on the 35s).
Reason for not converting to cartesian coordinates is that since the barycentric coordinates are relative to the vertices it is much easier to 'see' where the center points are relative to the triangle. If one where to be presented the cartesian coordinates one must remember the nine vertex coordinates to know where (relative to triangle) the center points are. Particular one see at once if the circumscribed circle's center is inside or outside the triangle.
Cartesian coordinates are easily obtained using the A program by the following key sequence:
XEQ AThe last two RDN are only provided to get content of stack in same order as before except that barycentric positional vectors are now replaced with cartesian ones.
RDN
RDN
XEQ A
RDN
RDN
Subscribe to:
Posts (Atom)
