• Manfred Nowak (31/31) Feb 19 2004 I am playing with a hashing function `f'.
• Sean Kelly (21/21) Feb 19 2004 Why not make 'f' a function object?
• Manfred Nowak (7/9) Feb 19 2004 [...]
• Sean Kelly (3/11) Feb 19 2004 But where is the explicit signalling? The hash is computed on-demand.
• Manfred Nowak (11/12) Feb 19 2004 Ahh, I got your proposal wrong. The `f.hash' is intended as a pure

Manfred Nowak <svv1999 hotmail.com> writes:

I am playing with a hashing function `f'.

`f' is able to yield a hash value from memory areas of unrestricted
length. Because relevant memory areas may be spread over main
memory and explicitly concatenating those areas is inefficient
`f' must be able to implicitely concatenate those areas.

So, if there are `n' memory areas `area.1', `area.2', .., `area.n',
instead of calling `f( area.1 ~ area.2 ~ ... ~ area.n)', let thereby be
`~' the correct concatenation operator, `n' subsequent calls `f(area.1)',
`f(area.2)', ..., `f(area.n)' must be executed.

Now assume, that it would be inefficient to compute the hash value at
every call. Then only the last call should compute it. This can be
signalled in several ways:
  hash= f( area.n, COMPUTE);
  f(area.n); hash= f(null);
  f(area.n); hash= f();
  ...

Disadvantage of this is, that the signalling of the final call must always
be present, even when only one memory area has to be hashed. I do not see
a solution that does not need any signalling except overloading the comma
operator:

  struct HashFunc{
    void opComma( areaType ...){ ... accumulate data }
    uint opCall( areaType ...){ ... last data item, compute hash value }
  } HashFunc f;
  
  hash= f(area.1);               //only one area
  hash= (f(area.1), f(area.2), ... , f(area.n)); //several areas
  hash= f(area.1), f(area.2), ... , f(area.n); // error: void value

I believe that this of interest in several data accumulating areas.

So long. 
   

Sean Kelly <sean ffwd.cx> writes:

Why not make 'f' a function object?

class compute_hash
{
public:
     void operator()( char[] str )
     {
         // store reference or compute partial hash or some such
     }

     int hash()
     {
         // compute hash if not yet computed
         // return hash value
     }
};

Then to use it:

compute_hash f;
f( area.1 ); f( area.2 ); ... f( area.n );
int hash = f.hash;

I'm sure it would be possible to make the interface even cleaner, but 
you get the idea.


Sean

Manfred Nowak <svv1999 hotmail.com> writes:

Sean Kelly wrote:

[...]
 f( area.1 ); f( area.2 ); ... f( area.n );
 int hash = f.hash;

[...]

I see. But this is only one of the many ways _with_ explicit signalling
the end of the data collecting phase. I am searching for something without
this explicit signalling.

So long. 

Sean Kelly <sean ffwd.cx> writes:

Manfred Nowak wrote:
 Sean Kelly wrote:
 
f( area.1 ); f( area.2 ); ... f( area.n );
int hash = f.hash;

 
 I see. But this is only one of the many ways _with_ explicit signalling
 the end of the data collecting phase. I am searching for something without
 this explicit signalling.

But where is the explicit signalling?  The hash is computed on-demand.


Sean

Manfred Nowak <svv1999 hotmail.com> writes:

Sean Kelly wrote:

 But where is the explicit signalling?  The hash is computed on-demand.

Ahh, I got your proposal wrong. The `f.hash' is intended as a pure
computing function. But then you need a third definition for the reset of
the internal data to an initial value.

By overloading the comma the user of the class would be reliefed from the
burdon to remember the two or even three syntactical variants.

But I just notice, that I open the door to a further class of notational
errors: accidentically interchanging a comma with a semicolon.

Thank you for your patience. I end evaluating this idea with negative
result.

So long.