Create an account on the HP Community to personalize your profile and ask a question
10-16-2020 07:54 AM
Hi dear @Joe_Horn (and others),
I read your text in this forum at the topic for how to get thousand separator which you can find at this link:
I also write (copied) your program which goes like this (in pictures below), and do all of your staff which you described (install library LNViewer and setup a flag for approx mode, also i do attach library 256 as you mentioned ),
But after all my efforts I'm getting error which stand like this:
Also i write your code like this (picture below) i don't know if i missed something or so, because it is identically what i saw on your page....
Your code looks like this...
\<< DUP IF DUP TYPE 28. SAME THEN \->STR SREV "," 3 STRD " " SWAP + " " -72 FS? 28 16 IFTE STRD TAIL SREV ELSE \->FNUM ZZ\<-\->F SWAP "E" + SWAP DIGITS 1 - + + DUP 1. 1. SUB "." + SWAP 2. OVER SIZE SUB + " " -72 FS? 29 18 IFTE STRD END \>>
Please help me Joe because i don't know what am I doing wrong,
besides i follow the instructions as best I could follow.
Thanks and bye
Solved! Go to Solution.
10-18-2020 09:10 AM
There are some very subtle differences in the code of the program that Joe posted with what your 50g appears to show. Those differences are important in this situation.
Note that Joe's original post included both a byte count and a checksum (a practice that I should follow more often than I do). You may want to compare those items with same values for the program you've entered. This can be done by recalling the program to the stack, then execute the BYTES command. You will see 2 values returned by that command: the approximate number is the size (in bytes), the binary number is the checksum. Joe's checksum is listed as a hex number, so make sure you are comparing the checksum with the proper base set. I'm pretty sure you'll see different values for yours, mainly because of the differences I'm seeing in your posted code.
The specific error you are getting ("SREV Error: Bad Argument Type") is actually being generated by the STRD command, but that command was written in such a way that the error is seen by the calculator's OS as coming from SREV instead. That error should go away for that step if you change the approximate "3." before the first STRD command to an exact integer "3" instead. Doing this requires that your calculator is set to exact mode before initiating the edit.
Look at Joe's source code listing to see where the numbers given are exact integers as opposed to approximate numbers (ie. with the fraction mark showing). Now compare that with your version of the program; yours has only approximate numbers with no exact integers.
It also appears that your program has spaces between the "ZZ" "←→" and "F", whereas that is supposed to be a command name without the spaces. Perhaps the library wasn't attached prior to typing that in?
Try editing the program again with the above in mind, then check the size and checksum to see if they match Joe's posted values. If it matches now, I suspect you'll see the command work properly.
Hope this helps!
10-18-2020 10:28 AM
In addition to the excellent points offered by David_M, please also note that the following code is a single carriage return ( [right-shift] [ . ] ) between double quote marks, not a space as your listing shows it. This appears twice in the program.
You must also install the LongFloat library, or omit the entire ELSE clause.
10-18-2020 04:40 PM
Hello dear Joe and others,
Before i started to take out what i discover i just want to say thanks to @Joe_Horn for participating in this conversation 😃
I try what you told me in message... including installing those LongFloat library like you mention in your previous post.
So, i used only LF393.LIB library ... i mention this because i found two library files ( LF393.LIB and LF393R.LIB ).
Also i made some additional editing on my code what suggested @David_M like as example function ZZ left arrow right arrow F instead leaving space between those two letters. Also I took care of those numbers with "points" as example when i used function STRD or SREV because (i notice that later) that point following after number like "3." affects on function to work properly. So, despite all of yours and mine effort i still can't get this function for working properly...
This is what i get after all this efforts (look at video below, duration of video - about one minute )
You'll probably noticed SWAP Error: Too Few Arguments,
also numbers are correctly lined up but they are not spaced with comma after three digits ( as example if i entered 1234567 there is no 1,234,567 view) I'm in exact mode but ... nothing ...
Really i don't know what is problem right now.
Please help me, maybe with edited code for HP 50g graphing calculator at best case,
bye bye 🤗
10-18-2020 07:14 PM - edited 10-18-2020 07:34 PM
There is one decimal point that you missed. The 28 near the beginning of the program must have a decimal point after it, since the TYPE command always returns reals. After fixing that, recall the program on the stack and execute the BYTES command, and see if it's 244 #D67Fh as it's supposed to be. If not, then there are more typos. Typing listings into the 50g must be done with strict attention to detail.
EDIT: The only difference between LongFloat version 393 and 393R is the way it performs rounding. 393 rounds to even (sometimes called astronomers' rounding), and 393R round to closest (the way HP calculators round). I use 393R, but it doesn't matter for this program.
10-19-2020 02:27 AM
Hello dear Joe,
I don't have too much time for explaining what is happening when I left these decimal point after 28.
Also i do like you (wrote) said, i enter function BYTES after recalling code that you wrote.
So this is what I done (step-by-step) :
When i hit BYTES command/function i actually get this (picture below)
I don't know if this is correct, because you told me that must have less memory (or whatever else) than this mine.
So don't know if something else wrong, this is "my" source code now:
... and still when executing code like this i get errors also when both exact and approx. mode...
when approx mode i got this error..
when exact mode i got this ...
Does not man what wrong i done now, because i fixed my error of "28." , still does not work (good) for me because I'm expecting to do, when I enter this as example 1234567 to do this 1,234,567 🤔
That's it for me so far, please help me with this because I'm sick of this right now...
That's all my man, I must to go. Bye and "see you" hopefully with good results.
10-19-2020 09:59 AM - edited 10-19-2020 10:03 AM
EDIT: Since 'SREV' appeared on the stack, it means that you forgot to attach Library 256 before editing the program. Be sure to do 256 ATTACH and re-edit the program!
Since your program's byte count is too high, it might contain something that mine doesn't contain. Since the listings look identical on the screen, one hypothesis is that your second "<carriage return>" contains some extraneous spaces. Please edit it and make sure that the SECOND "<carriage return>" contains ONLY a carriage return character and no spaces.
The program was never intended to be used on real "approximate" numbers, only integer-type numbers and long-float numbers. So only use it in exact mode.
I hope the above helps!
10-19-2020 05:28 PM
Hi dear Joe,
I don't know what is the point for this program too work. Is it maybe "matching" exact amount of data to your code, i think 244 bytes (sorry if i didn't memorize well).
Man, i don't know what else to say if this was maybe main case for "not working for me". Don't know what to say for this fact.
Also what if I can't achieve, i mean at all, to match exact amount of bytes from code which i have (or planning to have) comparing to yours 😕
I mean it is too sad, if I can be honest with you, because it seems that now i go to nowhere and before this i was wondering how nice would be to have comma separated values (digits) when reading from calculator because I study (for now) "geodesy" and it's usefull to see that your data is nicely formatted when you have big numbers (like coordinates of points in local coordinate system, or gravitational acceleration expressed in mgals). I did not mention to not to enter in special modes like setting number format as fixed on who knows how many decimal places because it seems that is that method so inpractical especially when you must express result with different "accuracy" , i mean with numbers which have more or less decimal places.
Also what i read on post, which i supposed to be helpful but ... anyway is much more dissapointment because i heard or saw that HP Prime, as "brand new" programmable graphing calculator, don't have (or had not) "comma separated values" (so far if I'm familiar with this)... maybe they fixed that later, don't really know because i don't have HP Prime graphing calculator.
Sorry Joe_Horn if I waste your time with this, when i read topic about Comma Separated Values (in this community) i was hoping that implementing your code would solve this problem but unfortunatelly there is no much to do, but only hoping to fix these big, by me big issue, on HP 50g and others newer calculator.
Also you told me that i must use that program in Exact mode - don't know if you notice what i send to you in my previous message but I used in both modes - exact (most of the time) and approx. mode (used maybe once or so) and still DON'T WORKING, if you omit exact size of my file which not match your file (program) size.
Also even not mention that i used too much of these modules implemented on my HP 50g ,as additional libraries and this took my memory and doe not nothing else how it seems so far.
It's more like a Sizif job, completely waste of my time and maybe "investment".
Anyway thanks for participating, If you have something new and something hopefully usefull freelly post to this site and this topic while is still active.
Have a nice day, bye 😉
10-20-2020 06:52 AM
The BYTES command computes the size and checksum of the given object, and those two values serve as a sort of "digital fingerprint" which helps to uniquely identify the code. If your code has this same BYTES result, then you can rest assured that you have exactly the same code object that was originally shown in Joe's listing. If your program has a different result from executing BYTES, then you know that it has different steps in it somewhere.
Joe's original posting was a result of a request he received to share it -- he never suggested that it was a general-purpose program intended for everyone to use. It is something he wrote for his own needs, so it is tailored to serve the specific uses he had in mind at the time. It sounds like your needs are different than his were for a program like this, so perhaps your time and energy are better spent in coming up with your own version instead of trying to get Joe's working on your calculator.
A few things to keep in mind:
- How should the program respond to non-numeric input? (strings, arrays, lists, etc.)
- Are both positive and negative numbers important?
- Are different display modes important? (STD, FIX, SCI, etc.)
- Are different settings for fraction mark/thousands separators important?
- How should the results be presented? (left as string, shown on multiple lines of display, etc.)
The answers to the above may change how you approach this. Give it a try! We can help if you get stuck on something.
10-27-2020 05:42 PM
Hi dear Joe,
and by the way sorry if I been absent, I was busy ... all time...
So at the end I managed to get this function working properly... with these settings...
my flags ... on EXACT mode ...
Calculator modes were...
And when i match size i could not believe that I match exactly your size 244 bytes ...
this is my, or maybe better said, your code ...
and this is an example how to enter a number, but the end i did not get number, i get string in form of number spaced with comma at three digits... also i noticed that i can only, as you mentioned Joe do that when I'm in Exact mode without decimal numbers... so this is cool program but in my field pretty useless because i got decimal numbers all the times... after all thanks for explanations and i can't believe that program did not worked because i did not match size of your code... that's pretty ... don't know what to say amazing or terrifying 😅 🤔
So after all I get this ...
remember I was on Exact mode flags, and write a number without decimal places only Integer, so pretty nice and you mastered this HP 50g at phenomenal rate, so great job for you Joe 👏 ... unfortunately I'm pretty mad because HP did not implement those thousand separator in HP 50g without these improvisations ... thanks and bye bye 🤗