Re: UBF byte register question

On Thu, 24 Apr 2003, Erik Pearson wrote:

> I'm wondering what the scope and lifetime of a UBF byte register is 
> supposed to be. The byte register allows the association of an 
> arbitrary UBF value with a single byte (that byte being any byte that 
> is not reserved by UBF.)
> 
 
... good question ... :-)

> background (or my attempt at such)>
> 
> The reason for the byte register is to allow more compact UBF messages, 
> since you can first send several commonly used values which are 
> associated with a specific byte. When that byte is seen later, the 
> associated value replaces the byte.
> 
> The register is set by sending
> 
> value >B
> 
> where value is any UBF value, > means "store in", and B is any byte 
> that is not reserved by UBF(A).
> 
> E.g.
> 
>    "Universal Binary Format" >U
>    U $
> 
> would be equivalent to
> 
>    "Universal Binary Format" $
> 
> or
> 
>    'person' >p
>    "Brown" >b
>    # {p "John" b} &
>      {p "Patricia" b} &
>      {p "James" b} & $
> 
> would be equivalent to
> 
>    # {'person' "John" "Brown"}  &
>      {'person' "Patricia" "Brown"} &
>      {'person' "James" "Brown"} & $
> 
> </background>
> 
> So I'm wondering long the byte register should live for, and who should 
> see it.

There is actually an optimal (though unimplementable) algorithm -
it's comes from the old "page replacement algorithm"

It is "When you run out of byte registers, you have to throw one away -
(ie reuse it) - so all you do is reuse the next register whose next future
reference is longest away in time from the current usage."

  To implement this needs the pre-cognitive will_receive(Msg) statement
(Björn)

will_receive(X) means that the message X will be received at some 
point in time in the future, and returns the value of this time.

In pseudo code

        Ts = map(fun(I) -> {will_receive(I), I} end, ByteRegisters),
        B = element(2,hd(reverse(sort(Ts))),
                
This should work (if I understand things correctly) on a quantum computer -
otherwise don't hold your breath ...


> 
> The spec (http://www.sics.se/~joe/ubf/site/ubfa.html) doesn't specify, 
> as far as I can tell.
> 

Correct - this was *deliberate* :-)

Golly - so we actually need yet ANOTHER operator (say !) which means
"clear the byte cache" - or even

Two operators say 'atom' ^ and 'atom' = which could save and restore
a bye cache "context"

If you encounter ^ you should *save* all the byte cache entries in a
object named "context" - otherwise you restore the context - this
could make for some *very* efficient protocols.



> My best guess is that the the byte registers are only valid for the 
> single object following one or more byte register settings. The only 
> unit of transaction at UBF(A) is the data object, which is terminated 
> with a $ (dollar sign.). However, this would make the byte register 
> useful only for longish lists which contain repeated elements.
> 
> I am tempted to suggest that the byte register could live for a longer 
> span -- for the length of some sort of 'session' (network connection, 
> etc.) However, such concepts don't live in the realm of UBF(A).
> 
> It would also be tempting to think of the byte register having a longer 
> lifetime, allowing for a dynamic cache of frequently used values to 
> persist between a client and server (adjusted by analyzing the 
> frequency and size of objects being transmitted).
> 
> As to who should see a given byte register, if the span of the byte 
> register is a single object (or session), then it would clearly be 
> valid only for the current client. Since there is no concept of client 
> at UBF(A), there is really no sense in making this distinction. 
> However, if a byte register could persist for a longer period of time, 
> it would make sense to address the issue of multiple sessions or 
> clients accessing the same byte register.
> 
> Anyway, thanks for bearing with my seemingly endless UBF blitherings!
>

Carry on please

/Joe

PS the above posting contained at least one joke.
 
> 
> Erik Pearson
> Adaptations
> desk +1 510 527 5437
> cell +1 510 517 3122
>