How much memory may a HPPL program use on a G2?

[komame]

(09-21-2023 01:27 AM)jte Wrote:  ⋮
(Hmmm.... looking over the above now, though... I cooked up the above by looking at convAccents(), but now I notice there isn't a "Ù" in there, but I do see "Ù" in dictionary words... So, dear reader, please make the necessary adjustments to this post :-&.)
⋮

In the entire dictionary, there is only one occurrence of the character "Ù", and it's for 2-character words that weren't originally supposed to be here, which is why this character was omitted. It would probably make more sense to remove the 2-character dictionary, or I will add a dedicated condition for the 2-character dictionary in the conversion procedure. Nevertheless, thanks for this observation.

(09-21-2023 01:27 AM)jte Wrote:  To defend the honour of lists, one could try doing as much work as possible with lists. A faster encoding / decoding may be possible by employing lists in the encoding / decoding; just as a single BITAND could be used to mask all the words in an encoded dictionary (of short words - <= 10 characters) for matching purposes, BITAND, comparisons, etc. may be used on lists of lists during encoding / decoding.

It may well be that adding some list / string slicing methods to PPL might make this sort of coding more efficient.

The first step to go from strings to a 6-bit-per-char encoding might, if working with a 9-character dictionary, be to use MAKELIST(ASC(MID(...)),...) on 9-character chunks of the string dictionary (to generate a list of lists - with possibly one more level of looping / construction due to the limit of 10,000 elements per list).

When binary search could somehow be integrated here, it might have a chance to work quickly. However, if we have to operate on entire lists, which have 10,000 elements each (and it's well-known that such large lists perform very slowly in PPL), such a solution is probably not feasible at the moment. Performing a single BITAND, BITSL operation on a list of 10,000 binary integers (64b) takes over 70ms, and you would need to perform at least few similar operations based on what you're describing. Moreover, even the dictionary preparation itself, which involves something like MAKELIST(ASC(MID(words,X,9)),X,1,DIM(words)/9,9), takes over 1800ms, and this operation needs to be repeated multiple times for a larger dictionary when the word count exceeds 10,000. Such a dictionary should already be stored in a 6-bit binary version before the program is executed, but I'm afraid the time required for decoding the result would completely exclude this solution in terms of performance. And yet we haven't even mentioned 21-character words

Text strings are a very basic data type, and low-level operations will always be faster on them than on lists, which are a compound data type and have several disadvantages in PPL.
Nevertheless, thank you for these considerations. Regardless of the fact that we're planning a solution in PPL here, what you're writing is a very interesting approach. It's clear that you're familiar with algorithms and can come up with creative solutions.

Piotr