I have taken bit 9 (512). IMO bit boolean ( bit 8 ) is useful.
On Aug 1, 2016 10:09 PM, "Henry Rich" <henryhr...@gmail.com> wrote: > Yes. I think it would be a good idea to coordinate with Jsoftware about > future plans. Bits 8 and 9 are available for new types and would be the > best candidates. Bit 8 is provisionally assigned to bit-booleans, but that > type is pretty far from being implemented. Variable-length float and > complex are even farther from being implemented. > > I laid out the bits as I did to avoid long chains of ?: tests. > > Henry Rich > > On 8/1/2016 9:49 AM, Thomas Costigliola wrote: > >> So as long as the conversion constant (e.g., VQQ) matches the type >> constant(e.g., RAT) the result bit could be anything as long as it is >> unique to the rest? So, this would be okay: >> >> #define VYY XD // This has to >> match the type bit? >> #define VARGMSK (VBB|VII|VDD|VZZ|Vxx|VQQ|VYY) >> #define VY (VSB<<1) // This can be anything unique >> to the rest? >> #define VRESMSK (VB|VI|VD|VZ|VX|VQ|VSB|VY) >> >> >> On 07/29/2016 03:06 PM, Henry Rich wrote: >> >>> It wouldn't be necessary to change VRESX to 29; we would put in >>> bit-by-bit tests as needed. I wanted to eliminate as much bit-testing >>> as possible for the usual cases. >>> >>> I don't think reordering the type bits is possible, since user code >>> depends on the assignment. >>> >>> Henry Rich >>> >>> On 7/29/2016 3:00 PM, Thomas Costigliola wrote: >>> >>>> Are the changes to the bit patterns at the top of va.h supposed to >>>> eliminate an extra lookup later? >>>> >>>> #define VBB B01 /* convert arguments to >>>> B */ >>>> #define VII INT /* convert arguments to >>>> I */ >>>> #define VDD FL /* convert arguments to >>>> D */ >>>> #define VZZ CMPX /* convert arguments to >>>> Z */ >>>> #define Vxx XNUM /* convert arguments to >>>> XNUM */ >>>> #define VQQ RAT /* convert arguments to >>>> RAT */ >>>> #define VARGMSK (VBB|VII|VDD|VZZ|Vxx|VQQ) // mask for >>>> argument requested type >>>> #define VRESX 8 // bit position for result flags >>>> >>>> But what happens if the extended floating point type (XD) gets >>>> implemented? That would push VRESX to 29 and leave no room for >>>> VXCVTTYPEX on 32 bit machines. I do have custom types beyond bit 29 >>>> and I would like to conform to the official source, what is the >>>> recommendation? Reorder the type bit patterns? >>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>> >>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
