Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-08-02 04:16:06


"Philippe A. Bouchard" wrote:
>
> > > I've just placed a 3-state boolean type in the sandbox, available here:
> > >
> > Maybe it can make sense also to create tribool_bitset<> and
> vector<tribool>.
> > /Pavel
>
> I would suggest using a 'quadbool' instead in this case because
> vector<tribool> won't be optimal at all to reserve bits since tribool
> already takes 2 bits... why not a 2 bits quadbool?... Let's say: true,
> false (1st bit), probably true, probably false (2nd bit).

It depends on what you need. Sometimes, a tribool is needed, sometimes a
quadbool. I even had a case to store a quintbool. The names are somewhat
ugly, as it is no longer a "bool", I thus suggest calling it:

tristate, quadstate and quintstate or state3, state4, state5 or
state<N>?

As a short explanation of what I used the quintstate for:

Consider a series of integers. Now detect when it crosses zero without
the possibility to backreference previous values. You are passed one
value after another. Of course you might store the old value, but this
has one problem: When the first 10000 values are all 0, you have to
store them all to preserve the state :) You need to store when they are
the same and what the previous state was. In the beginning the state was
'0,unknown', as long as the series is 0, is remains '0,unknown'. later
it became '+', '-', '0,previously+' or '0,previously-'.

What I'd like to express by this example is the problem of the
enumerated values and especially their identifiers. It depends on your
usage and it's hard no find names that fit nice into every context.
Well, yet another problem but no solution - maybe someone else has an
enlightening idea :)

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk