Location/Table Type Identifier
Page 1 of 1

Author:  Fred [ Sun Jun 10, 2012 1:51 pm ]
Post subject:  Location/Table Type Identifier

This might be kept as meta-data or embedded in the table, but I want to post the possible types.




UINT8 (1)
UINT16 (2)
UINT32 (4)
SINT8 (1)
SINT16 (2)
SINT32 (4)


7^2 + 7^3 = 392 types

+ other arbitrary types, such as 1D lookups (7), config, ram vars, etc

If we include 64 bit values it jumps to 1100

If we drop float it falls to 252 just for 2d/3d

If we drop all 32 bit stuff it is a mere 80, and this is all we're likely to use.

Types including 64 bit:

UINT8 (1)
UINT16 (2)
UINT32 (4)
UINT64 (8)
SINT8 (1)
SINT16 (2)
SINT32 (4)
SINT32 (8)

For a single region, that's less than 4 bits, even if you include BITS 8,16,32,64. If we make the type field 16bit and store it as metadata then we could do:


Or something like that and be completely future-proof. Type would be group, 1d, 2d, 3d, ram-vars, config-structure, etc. Those 6 cover all of our current needs and leave headroom for 10 more.

What have I missed? Thoughts?


Author:  Fred [ Sun Jun 10, 2012 2:07 pm ]
Post subject:  Re: Location/Table Type Identifier

If we forgo the neatness then we get

14 + 14^2 + 14^3 = 2954

Which still occupies 12 bits "101110001010" leaving the same 4 spare, no change.

If we give special values 0 = unused 15 = mixed, it could mean things such as type of structure on it's own.

XXXX00000000???? = 1D
XXXXYYYY0000???? = 2D
111111111111???? = config or ram or group

Or, if all four first bits are one, then reuse the later bits in any way.

Or, more clearly, and differently, first 4 mean something, such as a group of types:

0000: ???? ???? ????
0001: XXXX ---- ----
0010: XXXX YYYY ----
0100 to 1111: ???? ???? ????

Or reduce the leading to 2:

00: ?? ???? ???? ????
01: ?? XXXX ---- ----
10: ?? XXXX YYYY ----

Where the bonus bits could mean something?

So many possibilities :-)


Author:  Fred [ Mon Jul 06, 2015 6:47 am ]
Post subject:  Re: Location/Table Type Identifier

Bump, does anyone know what factory computers use for this sort of task? IIRC Subaru have a similar scheme.

It might also be useful to have a flag data type for the Z axis of a 3D table, Y axis of a 2D table, and data from a 1D table. But not useful in the axes, that's for sure. You'd have to ensure no interpolation went on, and instead, a closest vertex algorithm was used.

To reitterate for my own thought process:

  1. Config/structure
  2. 1D lookup
  3. 2D curve
  4. 3D contour
  5. 4D spacial

Where config/structure can be ram variables, config settings, in various forms, and the usage is determined by what type of memory it lives in, and whether it can be written, or not. 4D could be possible, but would blow our type listing out of the water. It would also eat memory like there's no tomorrow, and require some fairly special behaviour which is a super set of existing 3D behaviour, so maybe best in a custom managed high level structure utilising ordinary 3D tables in a set.

And types:

  1. UINT8 (1)
  2. UINT16 (2)
  3. UINT32 (4)
  4. UINT64 (8)
  5. SINT8 (1)
  6. SINT16 (2)
  7. SINT32 (4)
  8. SINT64 (8)
  9. FLOAT (4)
  10. DOUBLE (8)
  11. BITS8 (1)
  12. BITS16 (2)
  13. BITS32 (4)
  14. BITS64 (8)

So if we just multiply out, we get:

  • confg/ramvars = 1, requires strucural definition.
  • 1D = 14 data types with lookup always being by unsigned value with memory and usually ADC bit count being the limiting factors
  • 2D = 10x14 = 140 possible types
  • 3D = 10x10x14 = 1400 possible types
  • 4D = 10x10x10x14 = 14000 possible types, if done this way.

If we shoot our own feet and say "64 bits, who'll need that!" then we reduce to the following:

  • 1
  • 10
  • 7x10 = 70
  • 7x7x10 = 490
  • 7x7x7x10 = 3430

So then, if we have the first 8 bits mean type, and rule out 4D tables, then we have 4 types (2 bits), and 252 type / 6 bit headroom/wasted space, or space for existing flags. If we ignore 4D then it's a maximum of 2 8 bit bytes and 1 16 bit shortword.

If the metadata was read first, the axes types could exist at the head of the block, although it's wasteful to put this in RAM, especially completely brain dead for variable blocks such as the current CoreVars etc. So instead, it could come at the end of the metadata block, and to save space, each type could use only what it needed, and the unused parts could be random and ignored for smaller types.


MaxType mt;
getDetails(mt, id); // populates mt based on ID
uint8 type = (mt.type & mask);
if (type == Type3D) {
    Type3D threeD = (Type3D) mt;
    // Do 3D things
    zType = threeD.ZaxisType; // Unsafe for 2D, 1D, and config/structure
    yType = threeD.YaxisType; // Unsafe for 1D and config/structure
    xType = threeD.XaxisType; // Unsafe for configh/structure
    // And only if 3D, because if not 3D, ZaxisType would have random bits in it and not be safe to use, let alone meaningful. etc.

Current flags are:


And eliminating one of them should be easy enough. backup/restore necessary/used? Not likely. It's implicit from being in flash. Indexable is good to know. Verified is good to know (UI tool should do pre-verification of its own). Parent is only good fof config anyway, I think. The flag needs to stay, but the actual value could occupy the same bytes as the axes/data types for the table types. Rather than be dedicated. Read only is good to know, too.

Yep, I'm tired, the above may not make perfect sense. But hey, better than nothing :-)


Author:  Fred [ Mon Jul 06, 2015 7:25 am ]
Post subject:  Re: Location/Table Type Identifier

Actually, the verified flag will become pointless, as everything will be verified except 1D lookup tables, which by definition can't be. Thus any app can just know that, and the flag can go away.

Page 1 of 1 All times are UTC [ DST ]
Powered by phpBB® Forum Software © phpBB Group