Answer (written in 2000):
From the 38G user's point of view this means that they need to be aware now in HOME that changing aplets may cause a change to angle and/or numeric mode settings. To help users remember this the name of the aplet is now used as a title in the HOME view. Sadly, this meant that the ability of 38G users to enter their own title had to go. The gain in control more than makes up for this.
This change also has implications for programmers wanting to upgrade their aplets from the 38G to the 39/40G.
Note: There is no way to turn an hp 39gs into an hp 40gs (and
get a CAS) by loading the 40gs operating system into the 39gs flash ROM. Both
calculators have flash ROM so that the operating system can be updated if bugs
are found. However the amount of ROM on a 40gs is larger than on a 39gs and the
operating system for a 40gs simply won't fit into the available space on a 39gs.
It's a lot simpler just to buy a 40gs!
Note: Some of this will not apply to the hp 40gs because of its CAS giving exact answers.
d/dx (appearing as in the editline): This is the differentiation operator and is also available from the MATH - Calculus menu. See the manual, page 10-7.
: This is the integration operator and is also available from the MATH - Calculus menu. See the manual, page 10-7 & 10-25.
ABS/ARG: These operators work with complex numbers or with rectangular to polar conversions and are also available from the MATH - Complex menu. For a complex number they give the modulus and the arguement. For rectangular coordinates they give the values of r and . For example, see right. Notice the double brackets. The reason for this is that the function requires brackets: ABS(....) and so does the coordinate (3,3).
!: This is the factorial operator and is also available from the MATH - Probability menu. For example, 5! would give 120.
: This 'angle' operator can be used to convert polar to rectangular coordinates. For example, if the HOME view is in degree mode then you could convert (r, ) = (2, 30o) to rectangular coordinates as shown right. There's an interesting variation on the use of this operator which will convert to r cis format. In the example shown below right, what was actually entered is not what appears on the screen. In the first example, I entered (8,45) with the HOME view in degree mode. As you can see, what appears in the History is the r cis form and in rectangular format. I then changed to radian mode and entered (3,/3). Again the result was r cis form and rectangular format.
: This is the summation operator, also available through the MATH - Loop menu. The syntax is very similar to the way that a problem is read aloud. For example, "the sum from j = 1 to 3 of j 2" would be entered as (J=1,3,J2) and would give an answer of 14 (12 + 2 2 + 32).
AND: This is mainly used by the
computer algebra system on the 40G and 40gs. However it also comes in handy when
entering domains for graphing functions. Go back to the FAQ page and check
out question #47.
Consequently when I was on the team upgrading the 38G to the 39G/40G, I was very keen to see if we could build a better way of doing this into the new models and I was overjoyed when I managed to persuade the programming team to incorporate the DISPXY command. The problem was that we did it so late in the process that the manual had already been finalised and so the command didn't make it into the manual for those models. Hence the explanation below of how it works...
The syntax is: DISPXY <x_pos>;<y_pos>;<font>;<object>:
The <x_pos> and <y_pos> are relative to the values of Xmin, Xmax, Ymin & Ymax as set in the PLOT SETUP view, and the font number can be either 1 (small) or 2 (large). For example, the program shown left will produce the result shown right if the axes are set to the default values of -6.5 to 6.5 and -3.1 to 3.2.
The <x_pos> and <y_pos> values refer to the top left corner of the text when displayed. The clipping rules are a bit complicated, probably due to the fact that the command was done in a bit of a hurry (in a hotel room late one night in Chicago!). If the <x_pos>, <y_pos> corner is off the top of the screen or off the left edge of the screen then the string will not be displayed even if part of it is onscreen. If there is sufficient room vertically for the string but part of it would display off the right edge of the screen then it will be partially displayed (see right). On the other hand, if we were to move the text one more pixel downwards so that it would display partially off the bottom of the screen then it will not display at all. The best way to satisfy yourself of this is to experiment.
Finally, the value of <object> can include variables of any kind.
DISPXY -6.5;0;1;"After "N" min the list is "L0:
Anyway, the point is that this affects your graphs and it becomes particularly obvious with circles because part of the graph does not exist (the part outside the circle). Let's look at the circle x2+y2=9 as an example. This circle only exists from -3 to 3 on the x axis and is undefined outside this domain. In order to graph it on the HP you have to rearrange it into the form y=.... so that it becomes two equations: F1(X)= (9-X2) for the top half and F2(X)= - (9-X2) for the bottom half.
If you enter these equations into the SYMB view and then graph them with the default axes (in PLOT SETUP press SHIFT CLEAR) then you get a perfect circle (see right). However, if you go into PLOT SETUP and change the x axis from the default setting to -6 to 6 and then re-PLOT then a strange thing happens! Part of the circle disappears. This is shown in the snapshot at the start of the question. There's a reason for this, and it lies in the pixels.
When the calculator draws the graph it only calculates y values for the x values which fall on pixels. After all, why bother calculating a value you can't display? It just "joins the dots" for the values in between. For the default scale of -6.5 to 6.5 this is not a problem since the edges of the circle at -3 and 3 fall on a pixel and this means that the last segment of the graph is from 2.9 to 3 and the circle reaches right down to the x axis.
However, for our new scale of -6 to 6 the pixels are no longer 'nice' values of 0.1. If you try to TRACE the circle you'll see that the pixels fall on 0, 0.0923077, 0.1846154..... In particular, near x=3 the pixel values are 2.953846 and 3.046154. This means that the calculator can't draw anything past 2.953846 because the next value doesn't exist :- remember (9-X2) is only defined for values up to 3. This is what causes the gap in the circle. There's nothing to join to past that last point.
So what's the solution? If possible, just use scales which allow the end points of your circle to fall on a pixel point. If your circle has a nice radius such as an integer then this is easily done by starting with the default axes and then ZOOMing in or out to show the circle. I would suggest using the ZOOM menu to Set Zoom Factors to either 2 or 5. This will tend to give 'nice' pixel points. If your circle is not centred on the origin then just check/tick the box in the Set Zoom Factors box to Recenter. That will allow you to turn off TRACE, move the cursor closer to the point where you'd like the centre of screen to be and then ZOOM.
Unfortunately not all circles have a nice radius! For example the end
points of the semi-circles for x2+y2=10 will not fall
exactly on a pixel point no matter what scale you choose. Judicious choice
may allow rounding to work in your favour but it's not always possible to set
will store an empty list into L1. This method can also be used to empty a statistics column inside a program since a list and a stats column are the same thing to the HP language.
67. (39G/40G only) How much can the HP38G and HP39G communicate via their infra-red links? What can I transfer?Answer: Because some changes were made to internal structures in the upgrade from the 38G to the 39G, aplets and lists cannot be transferred directly from a 38G to a 39G using the infra-red link. However there is no problem transferring Notes, programs or matrices in either direction using the IR link.
If you wish to transfer an aplet or a list from a 38G to a 39G then you will
need to save it from the 38G to a computer, update it using the HP utility
covered below and then transfer to the 39G. This process cannot be used to
transfer backwards from 39G to 38G.
There is a listing of all syntax and functions that make up HP-Basic in the manual and there are a number of examples of how to use the SETVIEWS command to link programs into a parent aplet. In fact, I wrote most of that section of the manual (and yes, I know there were mistakes in the 39G version but I wasn't the only one writing it! :-) However the manual does not cover binary/assembly code programming (sRPL) on the machine because it was never intended to be programmed that way by the average user. The average user will want to use HP-Basic but it has two big disadvantages.
Firstly, it is a bit limited in some areas. For example it has no facility to manipulate strings, which can be very frustrating. It also can't continuously check for key presses which means that games are more difficult to write.
Secondly, the program is stored on the calculator as a text file and compiled when you want to use it. This is why there is a delay the first time you run any program. Subsequent runs are faster because the calculator keeps the assembled copy. Even so, a calculator created assembly code program is seldom as efficient as a human one as it doesn't have any of the optimization that a human can add. This means that programs written in HP-Basic are seldom fast enough for good games.
If you want to produce really fast games and other material such as that then, as I understand it, you must develop your programs on a PC and compile them on the calculator. Unlike the HP48/49 family, the HP38/39/40 family members are not set up to do this directly - you have to develop the app on another platform and transfer. All the really good games available for the HP39/40G are done like this. The assembly level programming of the HP38/39/40G is VERY complex and tedious to use. I did learn a little of it but didn't really have time to become expert. All the really good games available for the HP are done like this because sRPL is so much faster and more flexible than HP-Basic.
The most knowledgable people I know of who are writing these are:
You should also check out http://www.hpcalc.org/
for more information and programs.
Last modified: 19 Dec 2007 Sitemap Home Contact Me