Je travaille actuellement sur un générateur de scanner. Le générateur fonctionne déjà correctement. Mais lorsque vous utilisez des classes de caractères, l'algorithme devient très lent.Algorithme efficace pour la conversion d'un jeu de caractères en nfa/dfa
Le générateur de scanner produit un scanner pour les fichiers codés en UTF8. La plage complète de caractères (0x000000 à 0x10ffff) doit être prise en charge.
Si j'utilise de grands jeux de caractères, comme n'importe quel opérateur '.' ou la propriété unicode {L}, le nfa (et aussi le dfa) contient beaucoup d'états (> 10000). Donc, la conversion de nfa en dfa et la création de la dfa minimale prennent beaucoup de temps (même si la sortie minimale dfa ne contient que quelques états).
Voici mon implémentation actuelle de la création d'une partie de jeu de caractères de la NFA.
void CreateNfaPart(int startStateIndex, int endStateIndex, Set<int> characters)
{
transitions[startStateIndex] = CreateEmptyTransitionsArray();
foreach (int character in characters) {
// get the utf8 encoded bytes for the character
byte[] encoded = EncodingHelper.EncodeCharacter(character);
int tStartStateIndex = startStateIndex;
for (int i = 0; i < encoded.Length - 1; i++) {
int tEndStateIndex = transitions[tStartStateIndex][encoded[i]];
if (tEndStateIndex == -1) {
tEndStateIndex = CreateState();
transitions[tEndStateIndex] = CreateEmptyTransitionsArray();
}
transitions[tStartStateIndex][encoded[i]] = tEndStateIndex;
tStartStateIndex = tEndStateIndex;
}
transitions[tStartStateIndex][encoded[encoded.Length - 1]] = endStateIndex;
}
Est-ce que quelqu'un sait comment implémenter la fonction beaucoup plus efficacement pour créer uniquement les états nécessaires?
EDIT:
Pour être plus précis, je besoin d'une fonction comme:
List<Set<byte>[]> Convert(Set<int> characters)
{
???????
}
Une fonction d'aide pour convertir un caractère (int) à un octet UTF8 [] est défini comme:
byte[] EncodeCharacter(int character)
{ ... }
Vous construisez un xFA pour l'entrée _byte_? Ne serait-il pas beaucoup plus facile (et plus fiable) de fonctionner sur des caractères (Utf16)? –
Je ne pense pas, la taille de la table de recherche (s) augmenterait lors de l'utilisation de caractères 16 bits. De plus, le fichier d'entrée typique serait plus grand si on utilisait utf16 (en comparaison avec utf8). – raisyn
Je suis désolé, j'ai mal compris! Accepter tout encodage serait une bonne option pour la future version. Mais pour rester simple, je pense qu'il est plus facile d'implémenter un seul encodage, et UTF-8 ressemble à la bonne joice pour moi. – raisyn