fextor

F1    F2
---------
"a"  "b" 
"b"  "c" 
"c"  "a" 

• dla F1 np.: a->1, b->2, c->3
• dla F2 np.: b->1, c->2, a->3

I w ostateczności, powinniśmy mieć coś na zasadzie mapy map:

{F1: {a:1, b:2, c:3}, F2: {b:1, c:2, a:3}}

Hmm de facto tak, mapa map.

Oryginalna decyzja jednej dziedziny na wszystko była chyba na zasadzie, że jeśli jedna cecha ma wartość "foo" i druga cecha ma wartość "foo", to żeby po konwersji też miały te same wartości numeryczne, choć chyba chodziło bardziej o to, by człowiek był w stanie przeczytać, że to ta sama wartość, mimo, że numeryczna, niż o cokolwiek innego.

Myślę, że dałoby się coś sprytnego w tym temacie wymyśleć, aby wilk był syty i owca cała (tzn. aby dziedziny różnych cech były oddzielne, ale jeśli się częściowo pokrywają, by była zachowana pewna spójność)... Ale wydaje mi się, że to może być więcej zachodu niż pożytku, a trzymanie dziedziny i udostępnienie jej narzędziom złagodzi oryginalny problem braku możliwości zrozumienia, które wartości numeryczne czego się tyczą.

Dla ludzi: do tej pory było to tak rozwiązane, że wszystko było numeryczne, ale była zachowana konwersja (pole attributes) dla tych grup kolumn (grupa kolumn = ekstaktor, pole boundaries), dla których było to wymagane. Gdy człowiek chciał się dowiedzieć się co oznaczają poszczególne wartości, to albo mógł zajrzeć do attributes, albo wywołać metodę explain_row, która dla danego wiersza macierzy zwracała listę z typami oryginalnymi.