I just got a new Prime with software version 2015 4 27 (7820). When running programs, if I get a legitimate "Bad argument type" error on a function... say... idivis(), then I continue to get that same error no matter what I do. And not just on that function, but on others. Once this occurs, can write a program that is nothing but the begin and end statements with:
idivis(12);
in between and I get "Bad argument type. If I replace the idivis(12) with nextprime(14), I still get the error. The only thing that gets me around it is a warm reboot. Then everything works until I get another error. What's going on?
You must update the firmware using the Connectivity Kit.
The error you mention is typical of that version you have, it was necessary to put the CAS. prefix in several commands.
Thanks. But I was afraid someone was going to say that. I'm Linux only, with no access to Windows. I can transfer files to the calculator with libhpcalcs. But my understanding is that the upgrade absolutely requires the Windows Connectivity Kit. My 50g, its bullet-proof reliability, and the its elegant RPL are looking better and better the more I learn about the Prime. Are you saying that using CAS.nextprime(7) might help? Or is that just another issue?
Hmmm. I upgraded to 06/27/2015 (8151) and am still seeing the same behavior. Also, in Catalog, I have to hit an alphabetic key several times before it jumps to that letter in the drop-down. Is the Prime really just that buggy? If so, I might as well save myself some time and aggravation just return it to the store. All my other HP calcs over the years have just worked.
I am not experiencing the problem you describe. Can you provide a program example?
EXPORT TEST()
BEGIN
nextprime(12);
END;
======
Then write some real programs using other functions like idivis() and ∑list() and run them. At some point, out of the blue, I get a "Bad argument type" error on one of those. (It doesn't happen in the middle of a long run. It always happens immediately when a program is started.) And when I try other programs I get the same thing, consistently. And when I go back to the toy program test() I get the same thing. An On-Symb warm boot "fixes" it for a little while... until it happens again a few minutes later. Brand new unit. Latest ROM image. And I'm careful to use only local variables in my programs to try to isolate them as much as possible. It doesn't help. After updating to 8151, I did an On-Apps-Esc's to clear memory and reset to factory defaults, and then re-keyed my programs manually. The issue remains. I'm happy as a clam with my 50g. It would probably remain my daily driver even if the Prime worked flawlessly. But it *is* really disappointing. HP used to be the cat's pajamas. Second to none in quality. And the Prime really is beautiful. The hardware is top notch. So much potential!
A note up front: It probably wouldn't hurt to run, "format disk C," by selecting option 4 after holding C-F-O keys down, and pressing "On." (The diagnostic page).
Usually, when things begin to act strangely, I have found it time to RESET the hw or emu. You can do that from the diagnostic screen on the hw, or the menu bar item: "Calculator | Reset," on the emu.
If either of those doesn't fix the problem for you, the underlying problem may have already been fixed, or taken under advisement, for the next public release.
The usual reminder, "back up your device," before the format is performed, is just to state the obvious. Your program has worked without error on my hw device, about 10 tries so far. I hope this is helpful, Good luck!
-Dale-
I tried that. But I'm still seeing the problem *very* frequently. (Reproduceable within minutes.) Here are the programs I'm working with. I enter them. Switch around between running them. Eventually, I get the "Bad argument type" error on one of them. And once I do, all three programs immediately come up with the error when I try to start them. Even NP(). Warm reboot with an On-Symb and everything works again. Rinse and repeat.
Code:
----------------------------
EXPORT PR()
BEGIN
LOCAL p:=1;
WHILE 1 DO
p:=nextprime(p);
PRINT();
PRINT(p);
END;
END;
----------------------------
EXPORT AM()
BEGIN
LOCAL r,s,t;
FOR r FROM 2 TO 1000000 DO
s:=∑LIST(idivis(r))-r;
IF r <> s THEN
t:=∑LIST(idivis(s))-s;
IF t == r THEN
PRINT();
PRINT({r, s});
END;
END;
END;
END;
----------------------------
EXPORT NP()
BEGIN
nextprime(12);
END;
----------------------------
I can reproduce the problem reasonably reliably with just the 'AM' program, above. Run it. And as soon as it gets to {1210, 1184}, stop it with On On. Then try to run it again. Do that a few times, and the problem always turns up . Usually on the first try, for me. If I change the range of the for loop to stop at 1300 and let the program terminate normally, the problem does *not* occur. Something is not getting initialized properly when breaking out of a program with On On.
Congrats... it seems you were able to crash the idivis() function! I start/stopped your AM() program until the Error: "Bad Argument" response occurred. After that, the idivis() command no longer works, even from the command line with the example provided in help for that command.
Resetting the device, (I was using the VC), clears the error, and both the command and program work again. So there appears to be a memory related issue there, and the great team will probably track it down.
-Dale-
It's worse than that. Other functions, like nextprime() are also affected. Now that I've determined that it's not just me, is there someplace that I should file a formal bug report?
I'm pretty sure they are aware of this from your thread.
It doesn't seem to be idivis(). The simplest program I've come up with to trigger the bug is this:
EXPORT TEST()
BEGIN
LOCAL w;
FOR X FROM 1 to 1000000 DO
w:=∑LIST(idivis(x));
print();
print(w);
END;
END;
It seems to require ∑LIST(), the printing of the value to the terminal screen, and breaking out of the program with "On" at a specific instant. All of these things happening to be involved in my first HP PPL program. With this test program, I can usually get it to fail in around 10 tries.
Yes, I've been watching this thread. Now that there seems to be some more exact information I'll give it a try in the current public release, and the current development version and try to replicate it.
My first thought was wondering whether your original was just a test program you wrote, or if there was any application in mind for it? (not trying to trivialize what very well may be a problem you discovered, just curious to give it some context)
Also, I was wondering if your original program was causing a nasty memory leak or something. In the "memory" screen, there is an "Info" button. Could you see if the memory suspiciously lowers in your original stuff before and up until you see the problem?
Traditionally, when learning a new programming language, I start by listing primes and pairs of Amicable Numbers the old-fashioned way, as I would have done it on my TI-59 or Apple ][ basic. Then I see what the platform allows in the way of optimization. The 50g and Prime offer idivis() and ∑LIST. The AM() program just lists members of Amicable Number pairs. Please let me know if there are any specific tests you need me to run. I'll check the memory levels and report back.
OK. Now I cannot get it to fail at all with the TEST() program, as I was able to before. However, I can still get it to fail frequently with the AM() program when I warm reboot with On-Symb, run AM(), and hit 'On' instantly when I see {1210, 1184} pop up.
What I'm seeing in Mem->Info is:
Before problem occurs:
Memory: 10.76MB
Storage: 197.83MB
After problem has occurred:
Memory: 10.75MB
Storage: 197.83MB
Have filed an issue to make sure this gets investigated. Thanks!