Calculators that allow direct operations on data stored on persistent storage?

[DavidM]

(02-18-2018 03:00 PM)pier4r Wrote:  I have an object that is growing almost every day on the 50g. For the moment it is 21kb, and I need to have twice-three times its size of ram (port0) free for additional operations because I cannot edit directly the object saved on the persistent storage (at least not if I use the hp 2.15 firmware). For my predictions, unless I develop a paging solution, at the end of this year I may run out of ram.
Hence the question.

I would think that most all calculators will have some inherent limitations to the size of discrete objects that can be stored and manipulated. While it's possible that custom code could be created that might provide the ability to append new data to an existing object in storage, I'm wondering if that's really the best approach. Perhaps you could simply use a different format for the data you're storing which would require less space.

Consider the following...

Entering a list of the numbers 1-10 from the command line of the 50g creates an object as follows:

(Exact mode)
{ 1 2 3 4 5 6 7 8 9 10 }
Size: 34 bytes

(Approx. mode)
{ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. }
Size: 38 bytes

Coding the above as a string of successive 2-digit numbers (no spaces) results in this (mode doesn't matter):

"01020304050607080910"
Size: 25 bytes

The string is smaller, but the first two are relatively close because those numbers are actually available as ROM objects, which means that each entry only takes 2.5 bytes/element. But watch what happens if we change to a different set of 2-digit numbers:

(Approx. mode)
{ 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. }
Size: 110 bytes

(Exact mode)
{ 50 51 52 53 54 55 56 57 58 59 }
Size: 70 bytes

"50515253545556575859"
Size: 25 bytes

Clearly we begin to see that there could be a substantial savings in storage space required if we store the data in string format. Yes, there would now be overhead to translate the data to/from the required string format, but as long as the discrete data elements are all the same size, we can access each one individually as needed by computing its offset.

Further refinements could be made, of course, depending on the domain/range of the data you need to store. Storing the data in hex strings would provide even greater density of data if the individual numbers fit in the range 0-255.

Is there a possibility of using a different format for the data you are storing that would require less space?