hp48 working with large lists

[snrowe]

Hi is there a way to explode a list such that the original list doesn't stay in memory (none of the elements reference the original list)?

Am looking for a solution that doesn't involve cycling through each element using NEWOB. The problem I have with that approach is I may not have enough memory to create a new object of each element before removing the original list from memory. For example the program below would generate insufficient memory error if any of the elements were bigger than the available memory.

<< DEPTH 1 - -> d
<< LIST-> 1 SWAP
START
DEPTH d - ROLL NEWOB
NEXT >>
>>

[Han]

I presume that you don't actually need a duplicate copy (in exploded form) of the original list (since it would be impossible under RAM limitations given your description of the issue). Is it not feasible to only extract the elements you need? Or what about an alternative: instead of duplicating the list, why not just refer to the list's contents by their index.

[snrowe]

(03-04-2017 11:57 PM)Han Wrote:  I presume that you don't actually need a duplicate copy (in exploded form) of the original list (since it would be impossible under RAM limitations given your description of the issue). Is it not feasible to only extract the elements you need? Or what about an alternative: instead of duplicating the list, why not just refer to the list's contents by their index

Hi Han, Thanks for the reply.
Yes that is correct I can't afford a duplicate copy due to memory. In fact I purge the variable the list was stored in after recalling to the stack. So the only copy of the list is on the stack.

My understanding is that if you have a large list or composite object that isn't stored anywhere if you have an extracted element (via # GET) the entire list is kept in memory as long as that element exists. (ref William Wicks 'HP48 Insights PART I: PRINCIPLES AND PROGRAMING' Section 11.6 Composite Objects and Memory'). So if the element I'm extracting to modify is larger than available memory and there are other elements also larger than memory I can't modify one of the large elements and recreate the list without running into memory problems.

Was hoping there would be a SYSRPL solution that would explode a list without creating reference to the old one.

[Werner]

I don't quite understand what the issue is.
You're trying to modify an element of a list under low memory conditions so you can't afford to have the list there twice, right?
Then, how would it be possible to assemble the list again?
I'm afraid there's no miracle possible here - both exploding and assembling lists will take the memory of the list plus the memory of its constituting objects...

BTW deleting the variable that contains a list merely moves the list from USEROB to TEMPOB and will not gain you anything memory-wise, except longer garbage collections for large (exploded) lists ;-)
(some list commands purposefully save the list in a user variable to avoid the gc issue)

Cheers, Werner

Update: exploding a list does not take twice the memory as it only uses up stack pointers to point within the list - but you wanted the objects themselves with NEWOB, and that does take twice the memory.

[snrowe]

(03-06-2017 11:10 AM)Werner Wrote:  I don't quite understand what the issue is.
You're trying to modify an element of a list under low memory conditions so you can't afford to have the list there twice, right?
Then, how would it be possible to assemble the list again?

That's my question is it possible to explode the list into its elements destroying the original so memory is available to perform modifications to the elements then reassemble into a list.

(03-06-2017 11:10 AM)Werner Wrote:  I'm afraid there's no miracle possible here - both exploding and assembling lists will take the memory of the list plus the memory of its constituting objects...

Thanks that's the answer to my question. In this case Think I'll reprogram my application to use a directory with variables instead of a list with elements. That way I'll be able to modify the variables independent of the directory object.

(03-06-2017 11:10 AM)Werner Wrote:  BTW deleting the variable that contains a list merely moves the list from USEROB to TEMPOB and will not gain you anything memory-wise, except longer garbage collections for large (exploded) lists ;-)
(some list commands purposefully save the list in a user variable to avoid the gc issue)

Yes I'm aware of this issue as mentioned it's outlined in William Wicks hp48 Insights. Was hoping there was a way (in SysRPL) to split the list without saving to the tempob area. I imagine there's a way to do it in assembly, but I'm not ready for assembly language yet.

(03-06-2017 11:10 AM)Werner Wrote:  Cheers, Werner

Thanks for confirming the behavior of lists for me as I'm a beginner with SysRPL and wouldn't know if SysRPL allowed such things. Since I'm using mainly UsrRPL with a little SysRPL . I already partially reprogramed my application to store data using variables in directories opposed to elements in a lists. Now I'm able to perform the operations I need, even in very low memory conditions.

Thanks again for the help,
Scott