Handling of extended guard point and sizes of power-of-two+1 tables

[vlazzarini]

Two related issues have been identified

1. There is no mechanism to request an extended guard point to a GEN
2. Tables using power-of-two+1 size have power-of-two length, which is confusing for users expecting the length to be equal to the size requested.

Proposed solutions

1. Use a non-zero fractional value for table size to request an extended guard point

f1 0 2000.1 7 0 2000 1   ; extended guard point

2. Use a negative size to request an actual size, disregarding the power-of-two+1 size mechanism.

f1 0 -1025 7 0 2000 1   ; flen = 1025 with standard guard point

[vlazzarini]

I did a code review and the description of the problem was slightly wrong. Currently (e.g. 6.x)

1. Negative size tables always set an extended guard point.
2. Negative size tables keep their requested size (e.g. no change from pow2 + 1 to pow2).

So the problem is just how to give the user an option to suppress (1), and set a normal guard point with a copy of the value at position 0. This is done by using a table size with decimal part > 0 as proposed.
Note that fractional sizes are rounded to the nearest integer and this behaviour has not been touched.

Implemented in PR #1872

[joachimheintz]

thanks for this, victor. (and of course all the big work on the CS7 transition.) you wrote two times "negative" in your two items, but i guess you mean one of it as "positive"?

…

On 16/04/2024 10:33, vlazzarini wrote: I did a code review and the description of the problem was slightly wrong. Currently (e.g. 6.x) 1. Negative size tables /always/ set an extended guard point. 2. Negative size tables keep their requested size (e.g. no change from pow2 + 1 to pow2). So the problem is just how to give the user an option to suppress (1), and set a normal guard point with a copy of the value at position 0. This is done by using a table size with decimal part > 0 as proposed. Note that fractional sizes are rounded to the nearest integer and this behaviour has not been touched. Implemented in PR #1872 <#1872> — Reply to this email directly, view it on GitHub <#1864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYHKSPVFPG5SRF7K4RQSDY5TO5LAVCNFSM6AAAAABFZAJOI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJYGUZTSNRYGA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[vlazzarini]

No, I mean negative in both.

ifn ftgen  1,0,-1025,10,1
print ftlen(ifn)

gives currently

ftable 1:
instr 0:  #i2 = 1025.000

[joachimheintz]

this is really a complicated area ... let me ask if i am right now in my understanding: a) (posiive table size) print(ftlen(ftgen(0,0,8,2,0))) print(ftlen(ftgen(0,0,9,2,0))) both return 8 as table size, which is against what a user would expect in setting the table sizes. the reason is that the 9nth value in size=9 is interpreted as extended guard point, but the table size itself is 8. instead, b) (negative table size) print(ftlen(ftgen(0,0,-8,2,0))) print(ftlen(ftgen(0,0,-9,2,0))) return 8 and 9 as table size, which is what a user would expect. but in the latter case, the guard point (which is always there but somehow invisible for the user) is always an extended one. with your implementation, you give the option to have the guard point as copy of index 0. if this is correct, we will keep the hard-to-understand behaviour in a). (and probably there is no way out because of backwards compatibility.) then, from a user's perspective, we should always recommend to set negative table sizes, as they are what we see?

…

On 16/04/2024 14:27, vlazzarini wrote: No, I mean negative in both. |ifn ftgen 1,0,-1025,10,1 print ftlen(ifn) | gives currently |ftable 1: instr 0: #i2 = 1025.000 | — Reply to this email directly, view it on GitHub <#1864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYHKUAQK66A4XRYSCSWATY5UKMNAVCNFSM6AAAAABFZAJOI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJYHE3TAOJRHE>. You are receiving this because you commented.Message ID: ***@***.***>

[vlazzarini]

That is it. The power of 2 + 1 case was traditionally treated as a flag for extended guard point. Once other sizes became possible, this is less clear.

yes, I am not proposing to change anything because of backwards compatibility. I would not go as far as making a blank recommendation for negative sizes unless a power of two + 1 size is requested.