Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Tetrits, bool_set and "discontinuous" bit



> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "P-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Tetrits, bool_set and "discontinuous" bit
> Date: Thu, 23 Sep 2010 07:46:07 -0500
> 
> P1788,
> 
> An argument was recently made to me, something to the extent:
> 
> "Why not just change the tetrit priority ranking value R to 3-R and then
> take the supremum of two tetrit values? The domain tetrit will then be
> consistent with the discontinuous bit (which uses disjunction)."
> 
> . . .
> 
> So if P1788 wishes the following to be true:
> 
>     -- The propagation of all decorations shall be handled uniformly, i.e.,
> with conjunction/infimum or disjunction/supremum (but not some wild
> combination of both)
> 
>     -- The IEEE 1788 definition of a tetrit shall be compatible with the
> proposed C++ bool_set standard
> 
> Then the only choice is to accept the current definition of a tetrit, i.e.,
> Motion 18, and standardize "defined and continuous" as opposed to
> "discontinuous."
> 
> Sincerely,
> 
> Nate

	Nate,

	I think it would serve us well if we specified both the nature
	of decorations & their propagation at the level of truth values
	& conjunction or disjunction of those truth values rather than
	as bits.

	Then names, what is kept during propagation, & the methods of
	propagation all become implementation details.  Some people
	can store the bad thing as zero & propagate via AND.  Some
	can store them as one & propagate via OR.  They can do it
	uniformly if they're smart.  Or wildly if they're not.  We
	don't need to know or care.  Its all a matter of how some
	software interface accesses those bits & turns them back into
	truth values when we look at them.

	Alas, this give me no preference for the bits & your way is
	as good as any other.

	We might as well go with it.


				   Dan