You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The model wherein a NEW checkpoint is always available is problematic: this means that the table size can never be zero. This is not good: we want the decoder to be able to specify table size zero.
Instead, a NEW checkpoint should be created implicitly whenever required, which is in two cases:
INSERT_ENTRY command is issued
REUSE_ENTRY command is issued
The cost of the newly created NEW checkpoint is added to the table size at that time. This means that the encoder may not be able to create a NEW checkpoint due to table size constraints. (Which is exactly what we want if the decoder advertizes zero table size.)
The text was updated successfully, but these errors were encountered:
The model wherein a NEW checkpoint is always available is problematic: this means that the table size can never be zero. This is not good: we want the decoder to be able to specify table size zero.
Instead, a NEW checkpoint should be created implicitly whenever required, which is in two cases:
INSERT_ENTRY
command is issuedREUSE_ENTRY
command is issuedThe cost of the newly created NEW checkpoint is added to the table size at that time. This means that the encoder may not be able to create a NEW checkpoint due to table size constraints. (Which is exactly what we want if the decoder advertizes zero table size.)
The text was updated successfully, but these errors were encountered: