Lookup & TABLE 6.08 - Revision history

LegacyKing at 07:59, 22 January 2018

2018-01-22T07:59:56Z

Tom Parker at 04:20, 21 January 2018

2018-01-21T04:20:01Z

Tom Parker at 04:19, 21 January 2018

2018-01-21T04:19:37Z

Tom Parker at 04:14, 21 January 2018

2018-01-21T04:14:39Z

Tom Parker at 23:47, 20 January 2018

2018-01-20T23:47:29Z

LegacyKing: Created page with " ===raw=== TABLE and COLUMN will be special types. Both are complicated types, meaning they will look something like: TABLE[NUMBER,STRING] or COLUMN[STRING] Note th..."

2018-01-13T23:42:25Z

Created page with " ===raw=== TABLE and COLUMN will be special types. Both are complicated types, meaning they will look something like: TABLE[NUMBER,STRING] or COLUMN[STRING] Note th..."

New page

===raw===
TABLE and COLUMN will be special types. Both are complicated types, meaning they will look something like:
TABLE[NUMBER,STRING]
or
COLUMN[STRING]

Note that a MODIFY doesn't look any different. It's still:
MODIFY:TABLENAME|SET|SomeTable

"SomeTable" is still a string to a naive reader, but what the system will do at that point is make sure that SomeTable can actually be interpreted as a TABLE[x,y]... rather than just treating it as a String. Similar for the column names.

In that way, the first variable will allow multiple tables to be swapped in, AS LONG AS they are the right format. If the format is not compatible, then all bets are off and you'll get an error. Note that a table that has formats like this:

NUMBER,NUMBER,STRING

... will have multiple valid places it can be used, including:
TABLE[NUMBER,NUMBER]
TABLE[NUMBER,STRING]

This doesn't mean you can assign one TABLE format to another if the table happens to be compatible. I'm not even going to TRY to manage that one... and the use case is probably pretty narrow anyway.

Note that this still allows some runtime errors, but catches a lot of possible issues. It is still possible to do a lookup on a Table that doesn't contain a specific column of the given name. So if the third variable is COLUMN[NUMBER], we can check at load that the TABLEFORMAT has columns of FORMAT=NUMBER, but we can't guarantee the variable will resolve to a name actually in that table... that will have to wait for a runtime error. That's life, but it does allow us to know the formats at load time, so we do get a lot of error checking in the context of the usage, if not the exact table and column names.

Tom

STARTTABLE:Carrying Capacity,
Strength,Capacity
NUMBER,NUMBER
1,10
2,20
...
29,1400
ENDTABLE:Carrying Capacity,

Ignoring some of the diagnosis of bad inputs that will be necessary, this is the key logic:
(1) This format of START and END allows more than one table per file (avoids sprawl)
(2) Trailing commas are ignored (this allows the STARTTABLE and ENDTABLE lines to have blank cells where the rest are the table contents... we don't want to complain on minor things that may tools will do.)
(3) Blank lines will be ignored. This includes lines with commas but without content. (allows tables to be separated by blank lines or lines of all commas)
(4) The column names (Strength,Capacity) are always the first line of the table. The Formats are always the second line. The rest of the lines are content of the table
(5) Attempts to use embedded line breaks or embedded quotes may or may not be supported by the parsing system, but certainly aren't supported for purposes of PCGen.
Optionally:
(6) Lines that have the first cell starting with "#" are considered comment lines and will be ignored. This will likely need to include if the first cell is escaped in quotes, just for protection from any tools that quote by default.

The dicestep then becomes more like:

STARTTABLE:Dice Step,,,,,,,,,
Dice,DOWN5,DOWN4,DOWN3,DOWN2,DOWN1,SELF,UP1,UP2,UP3,UP4,UP5,...
DICE,DICE,DICE,DICE,DICE,DICE,DICE,DICE,DICE,DICE,DICE,DICE,...
...
1d3,-,-,0,1,1d2,1d3,1d4,1d6,1d8,2d6,3d6,...
...
ENDTABLE:Dice Step,,,,,,,,,

Note that "self" here is clearly defined, and it's a matter of pulling out of the correct column. Since the CSV format ignores leading/trailing spaces, one can easily have a spaced out version that is a table in a text editor if folks don't want to edit in a spreadsheet. (Having someone write a "PrettyTable" ... a trivial perl or python program to do that for the data team seems fairly easy)

I haven't fleshed it out, but there are some nuances here about what is "invalid" vs "empty" vs something else. Lots of "-" used in various tables in rules and we'd need to decide what those mean so we don't just crash if it happens...

The second major issue is how to do the lookup in data. We can borrow some inspiration from things like Excel and Google Docs:

lookup(X,Y,Z)

X is a table name. This must resolve in the formula system to a String that is a valid table name.
Y is the lookup value in the table. It must match the format of the column in the table.
Z is the target column name. This must resolve in the formula system to a String that is a valid table column name in the table named X

Thus max load calculation would be something like:
lookup("Carrying Capacity",roundDown(StrScore),"Capacity")*SizeMult

In a formula - data controlled in a MODIFY.
(This ignores the over 29 logic, as well as how SizeMult was initialized (presumably from the SIZE: object), but those are not difficult.)

To make the Dice Step example work, we would need something to find the correct column from the offset:
STARTTABLE:Step Column,
Steps,Name
NUMBER,STRING
-5,DOWN5
-4,DOWN4
...
0,SELF
1,UP1
...
ENDTABLE:Step Column,

The query would then look up the correct column name and use that column from Dice Step:

lookup("Dice Step",BaseDamage,lookup("Step Column",CurrentSize-BaseSize,"Name"))

There are probably some nuances around things like range lookup (having it correctly deal with an input like 4.5 so the rounddown isn't necessary), but that is easy mechanics as part of the lookup function.

One neat item would be that we could alter the query above to extract the table name into the Global Modifier file:
MODIFY:DiceStepTable|SET|"Dice Step"
lookup(DiceStepTable,BaseDamage,lookup("Step Column",CurrentSize-BaseSize,"Name"))

Now, if someone needs different dice steps for some reason... they can override the DiceStepTable variable and it will look up in a different table... so expansions could truly be expansions and not have to reach back into core PCC files in order to change key behaviors.

Another neat item is identical cast/known tables could be shared - the numbers would only need to be typed in once... :) ... since they are external to the Class file at that point... or if a subclass alters the default, just create a new table rather than having to BONUS/MODIFY all the numbers with adding and subtracting...

← Older revision		Revision as of 07:59, 22 January 2018
Line 93:		Line 93:

	Another neat item is identical cast/known tables could be shared - the numbers would only need to be typed in once... :) ... since they are external to the Class file at that point... or if a subclass alters the default, just create a new table rather than having to BONUS/MODIFY all the numbers with adding and subtracting...		Another neat item is identical cast/known tables could be shared - the numbers would only need to be typed in once... :) ... since they are external to the Class file at that point... or if a subclass alters the default, just create a new table rather than having to BONUS/MODIFY all the numbers with adding and subtracting...
		+
		+	Additional Information on 'get()'
		+	get(<format>,<string representation>)
		+	e.g.
		+	get("SKILL","Hide")
		+	get("TABLE[NUMBER]","Carrying")
		+	etc.

@@ Line 1: / Line 1: @@
-===raw===
+===current as of Jan 20 2018===
 TABLE and COLUMN will be special types.  Both are complicated types, meaning they will look something like:
     TABLE[NUMBER]

@@ Line 13: / Line 13: @@
     MODIFY:TABLENAME|SET|SomeTable
-"SomeTable" is still a string to a naive reader, but what the system will do at that point is make sure that SomeTable can actually be interpreted as a TABLE[x,y]... rather than just treating it as a String.  Similar for the column names.
+"SomeTable" is still a string to a naive reader, but what the system will do at that point is make sure that SomeTable can actually be interpreted as a TABLE[x]... rather than just treating it as a String.  Similar for the column names.
 In that way, the sub variable will allow multiple tables to be swapped in, AS LONG AS they are the right format.  If the format is not compatible, then all bets are off and you'll get an error.

@@ Line 57: / Line 57: @@
     lookup(X,Y,Z)
-X is a table name.  This must resolve in the formula system to a String that is a valid table name.
+X is a table.  This must resolve in the formula system to a valid table.  For now, a get(...) function may be required.
-Y is the lookup value in the table.  It must match the format of the column in the table.
+Y is the lookup value in the table.  It must match the format of the first column in the table.  At this time, it does an EXACT match.
-Z is the target column name.  This must resolve in the formula system to a String that is a valid table column name in the table named X
+Z is the target column.  This must resolve in the formula system to a valid table column. It must appear in the table named X
 Thus max load calculation would be something like:
-    lookup("Carrying Capacity",roundDown(StrScore),"Capacity")*SizeMult
+    lookup(get("TABLE[NUMBER]","Carrying Capacity"),roundDown(StrScore),get("COLUMN[NUMBER]","Capacity"))*SizeMult
 In a formula - data controlled in a MODIFY.
@@ Line 81: / Line 81: @@
 The query would then look up the correct column name and use that column from Dice Step:
-lookup("Dice Step",BaseDamage,lookup("Step Column",CurrentSize-BaseSize,"Name"))
+lookup(get("TABLE[NUMBER]","Dice Step"),BaseDamage,get("COLUMN[NUMBER]",lookup("Step Column",CurrentSize-BaseSize,"Name")))
-There are probably some nuances around things like range lookup (having it correctly deal with an input like 4.5 so the rounddown isn't necessary), but that is easy mechanics as part of the lookup function.
+There are potential future enhancements around things like range lookup (having it correctly deal with an input like 4.5 so the rounddown isn't necessary), but that is easy mechanics as part of the lookup function.
 One neat item would be that we could alter the query above to extract the table name into the Global Modifier file:
     MODIFY:DiceStepTable|SET|"Dice Step"
-    lookup(DiceStepTable,BaseDamage,lookup("Step Column",CurrentSize-BaseSize,"Name"))
+    lookup(get("TABLE[NUMBER]",DiceStepTable),BaseDamage,get("COLUMN[NUMBER]",lookup("Step Column",CurrentSize-BaseSize,"Name")))
 Now, if someone needs different dice steps for some reason... they can override the DiceStepTable variable and it will look up in a different table... so expansions could truly be expansions and not have to reach back into core PCC files in order to change key behaviors.
 Another neat item is identical cast/known tables could be shared - the numbers would only need to be typed in once... :) ... since they are external to the Class file at that point... or if a subclass alters the default, just create a new table rather than having to BONUS/MODIFY all the numbers with adding and subtracting...

@@ Line 3: / Line 3: @@
 ===raw===
 TABLE and COLUMN will be special types.  Both are complicated types, meaning they will look something like:
-    TABLE[NUMBER,STRING]
+    TABLE[NUMBER]
 or
     COLUMN[STRING]
 Note that a MODIFY doesn't look any different.  It's still:
@@ Line 12: / Line 15: @@
 "SomeTable" is still a string to a naive reader, but what the system will do at that point is make sure that SomeTable can actually be interpreted as a TABLE[x,y]... rather than just treating it as a String.  Similar for the column names.
-In that way, the first variable will allow multiple tables to be swapped in, AS LONG AS they are the right format.  If the format is not compatible, then all bets are off and you'll get an error.  Note that a table that has formats like this:
+In that way, the sub variable will allow multiple tables to be swapped in, AS LONG AS they are the right format.  If the format is not compatible, then all bets are off and you'll get an error.
-Tom
+Note that this still allows some runtime errors, but catches a lot of possible issues.  It is still possible to do a lookup on a Table that doesn't contain a specific column of the given name.  So if the third variable is COLUMN[NUMBER], we can check at load that the TABLEFORMAT has columns of FORMAT=NUMBER, but we can't guarantee the variable will resolve to a name actually in that table... that will have to wait for a runtime error.  That's life, but it does allow us to know the formats at load time, so we do get a lot of error checking in the context of the usage, if not the exact table and column names.