Accessing data from a separate file to be read by a program on 50g

[matalog]

Is there a way to have a program on the 50g access data from a separate file, say, to read numbers, that can then be used in a program running on the calculator?

If there is, could you please suggest some useful commands that may allow this.

There will be around 256 8 bit integers in this data file, so, it would be best not to include them in the program.

Thanks for any help.

[3298]

Assuming that we're talking about UserRPL, and that "separate file" means "string variable" (a file from the SD card without the HPHP49... header will be treated as just that), and that "8 bit integers" are stored as raw bytes (a.k.a. characters), you can just recall that variable to the stack, then n n SUB to extract the n-th character from the string, and NUM to convert the character into an ordinary real number holding its numerical value.
If NUM receives a string with more than one character, it operates on the first one only, so the step of extracting the appropriate character is necessary.
By the way, if you want to convert the number back into a character (e.g. after altering its value), there's CHR. You can then overwrite the original character using the REPL command or by building a new string with +. Storing it back should be easy enough to need no explanation ... but if you're storing to the SD card to send the file back to wherever, remember that you'll always get the HPHP49... header in front of the variable contents, even if it's a string.

Or, you know, just search through the manual for "string". Should be faster than waiting for answers from forum members.

[matalog]

(06-02-2021 08:21 PM)3298 Wrote:  Assuming that we're talking about UserRPL, and that "separate file" means "string variable" (a file from the SD card without the HPHP49... header will be treated as just that), and that "8 bit integers" are stored as raw bytes (a.k.a. characters), you can just recall that variable to the stack, then n n SUB to extract the n-th character from the string, and NUM to convert the character into an ordinary real number holding its numerical value.
If NUM receives a string with more than one character, it operates on the first one only, so the step of extracting the appropriate character is necessary.
By the way, if you want to convert the number back into a character (e.g. after altering its value), there's CHR. You can then overwrite the original character using the REPL command or by building a new string with +. Storing it back should be easy enough to need no explanation ... but if you're storing to the SD card to send the file back to wherever, remember that you'll always get the HPHP49... header in front of the variable contents, even if it's a string.

Or, you know, just search through the manual for "string". Should be faster than waiting for answers from forum members.

Thanks for the tips, although, I have an immediate response to your last paragraph only.

I have attached 2 screenshots, and they show the amount of occurrences of the word string, and the front page of the corresponding manual they come from. I assume that enlightens you to why I feel it may be a bit easier to ask a question to knowledgeable users :-).

I will definitely read through your answer, and again, thanks for taking the time to answer.

[BruceH]

> just search through the manual for "string"

When I was young, such a statement would never be taken so literally, because computerised search didn't exist. Instead it meant look in the index or the contents. I guess I'm now officially old!

Anyway, while the User's Guide may use the word "string" liberally throughout, the contents list is a little more discerning. From there you can see that chapter 26 has a section entitled "Accessing objects on an SD card" and chapter 23 covers strings.

I grant you, however, that it is not obvious from chapter 26 that reading a text file from the SD card results in a string on the stack versus, say, the results of interpreting the file contents as if typed in. If you want the latter then OBJ-> is your friend - the calc is just being nice in allowing you to process the string first. :-)

Also, and this is another sign of being old and curmudgeonly, I discover that Apple have decided that FAT16 is obsolete and the new Mac refuses to acknowledge the SD card that I use in the 50G. The 15 year old Mac, on the other hand, knows about such archaeological curiosities as FAT16 formatting and CD-ROMS, and was able to read and write to it perfectly.