6
votes

Une question d'entrevue - Split texte en sous-chaînes selon les règles

Split texte en sous-chaînes selon les règles ci-dessous:

  • a) La longueur de chaque sous-chaîne doit être inférieure ou égale à M
  • b) la longueur de la sous-chaîne doit être inférieure ou égale à N (n
  • c) le nombre total de sous-chaînes doit être aussi petit que possible

    Je n'ai aucune idée de la façon de résoudre cette question, je suppose que cela est lié à la "programmation dynamique". Quelqu'un peut-il m'aider à la mettre en œuvre en utilisant C # ou Java? Merci beaucoup.


3 commentaires

Pouvez-vous créer un lien vers l'endroit où vous avez la question, s'il s'agissait d'une source en ligne?


@IVLAD - Il s'agit d'une question de codage que j'ai obtenue de Microsoft il y a deux ans.


Ne leur dis pas la réponse! Microsoft essaie toujours d'obtenir une personne interrogée non rémunérée pour corriger leur performance sur l'hyphénation en mot! ;)


3 Réponses :


0
votes

Le résultat de votre calcul sera un partitionnement du texte donné en sous-chaînes courtes contenant des numériques et de longues substrings ne contenant pas de numérics. (Cela vous connaissait déjà).

Vous ferez essentiellement partitionnement des sous-marins autour des numériques, puis rompre tout ce qui est souvent possible dans de longs sous-marins aussi souvent que nécessaire pour remplir les critères de longueur.

Votre liberté, c'est-à-dire ce que vous pouvez manipuler pour améliorer votre résultat, consiste à sélectionner les caractères à inclure avec un numérique. Si n = 3, alors pour chaque numérique, vous obtenez le choix de xxn , xnx ou nxx . Si m a 5 ans et que vous avez 6 caractères avant votre premier numérique, vous voudrez inclure au moins un de ces caractères dans votre courte substance afin de ne pas vous retrouver avec deux "longues" chaînes à gauche de votre "courte "Un quand tu pourrais avoir un seul à la place.

En tant que première approximation, j'irais avoir l'extension de vos "courtes" cordes de gauche suffisamment loin pour éviter les chaînes "longues" redondantes. Il s'agit d'une approche typique «gourmande» et d'approches gourmandes produisent souvent des résultats optimaux ou presque optimaux. Faire encore mieux que cela ne serait pas facile, et je ne vais pas essayer de comprendre comment y aller.


2 commentaires

Les approximations gourmandes sont assez triviales pour venir avec je pense. Avez-vous des conseils sur la manière de créer une solution optimale à l'aide de DP?


Je pense qu'une solution optimale garantie serait une chose plutôt injuste de demander dans une interview. Sur le dessus de ma tête, je construirais un arbre des configurations résultant de chaque décision possible de chaque emplacement numérique et de déterminer les moyens de pruneaux des sujets produisant des solutions non pertinentes ou pires que d'autres. Compte tenu de temps pour se préparer, j'avais d'abord frappé «l'intelligence artificielle - une approche moderne» de Russell et Norvig »ou d'un autre livre qui explique ce truc. Avec la chance, il peut y avoir un exemple de problème similaire.



11
votes

idée

Une approche gourmande est la voie à suivre: p>

  • Si le texte actuel est vide, vous avez terminé. LI>
  • Prenez les premiers n personnages. Si l'un d'entre eux est un chiffre, il s'agit d'une nouvelle sous-chaîne. Coupez-le et allez à commencer. Li>
  • Sinon, étendez le segment sans chiffres à la plupart des caractères M. Ceci est une nouvelle sous-chaîne. Coupez-le et allez à commencer. Li> ul>

    Preuve H2>

    Voici une preuve de réductio-ad-absurdum que ce qui précède génère une solution optimale. Supposons qu'il y a une meilleure scission que la scission gourmande. Passons au point où les deux divisions commencent à differser et à supprimer tout avant ce point. P>

    cas 1) un chiffre parmi les premiers caractères. Strong> P>

    Supposons qu'il y a une entrée pour laquelle la coupant les premiers caractères ne peut pas donner une solution optimale. P> xxx pré>

    Cependant, le deuxième segment de la solution de mieux placée peut être toujours raccourci du côté gauche, et le premier étendu à n caractères, sans modifier le nombre de segments. Par conséquent, une contradiction: cette scission n'est pas meilleure que la scission gourmande. P>

    Cas 2) Pas de chiffre parmi les premiers caractères K (N p>

    suppose qu'il y a une entrée pour laquelle couper les premiers caractères K ne peut pas donner une solution optimale. p> xxx pré>

    à nouveau, la division "meilleure" peut être transformé, sans modifier le nombre de segments, à la scission gourmande, qui contredit l'hypothèse initiale selon laquelle il y a une scission meilleure que la scission gourmande. P>

    Par conséquent, la scission gourmande est optimale. Q.e.d. P>

    Mise en œuvre (Python) H2>
    public class SO {
       public List<String> go(int m, int n, String text) {
          if (text == null)
             return Collections.emptyList();
          List<String> chunks = new ArrayList<String>();
    
          int i = 0;
          int j = 0;
          while (j < text.length()) {
             i = j;         
             j = Math.min(text.length(), j + n);
             boolean ok = true;
             for (int k = i; k < j; k++) 
                if (Character.isDigit(text.charAt(k))) {
                   ok = false;              
                   break;                   
                }                   
             if (ok)        
                while (j < text.length() && j - i < m && !Character.isDigit(text.charAt(j)))
                   j++;                     
             chunks.add(text.substring(i, j));
          }         
          return chunks;
       }    
    
       @Test
       public void testIt() {
          Assert.assertEquals(
             Arrays.asList("asdas", "d332", "4asd", "fsdxf", "23"),
             go(5, 4, "asdasd3324asdfsdxf23"));
       }    
    }
    


4 commentaires

C'est une solution absolument correcte. (n'a pas vérifié le code, seulement une idée)


Ok, j'ai aussi posté une preuve maintenant :) et +1 pour trouver vous-même une solution correcte vous-même, BTW.


Une question hors sujet ici: Que dit la So Etiquette sur les améliorations progressives d'une réponse? Mon entrée était initialement une question de savoir s'il existe un contre-exemple d'un algorithme fourni (avec une mise en œuvre de travail en python). Plus tard, j'ai ajouté la preuve, la mise en œuvre de Java et supprima la question. Mes modifications ont invalidé certaines des commentaires et potentiellement quelques votes en haut. Sont des édits incrémentiels ok? Sinon, quel est le meilleur plan d'action.


Personnellement, cela ne me dérange pas d'amélioration progressive. Si des commentaires sont invalidés, je m'attends à ce qu'ils soient supprimés (j'ai supprimé la mine), et je m'attends également aux bowvotes de vérifier les améliorations sur les questions / réponses qu'ils ont bientôt évoluée. Je ne sais pas s'il y a une "étiquette officielle" cependant.



4
votes

bolo a fourni un algorithme gourmand dans sa réponse et a demandé un contre-exemple. Eh bien, il n'y a pas de contre-exemple parce que c'est une approche parfaitement correcte. Voici la preuve. Bien que ce soit un peu verbeux, il arrive souvent que la preuve soit plus longue que l'algorithme lui-même :)

Imaginons que nous avons une entrée de longueur l et construit une réponse A avec notre algorithme. Maintenant, supposons qu'il y ait une meilleure réponse B . I.e., B a moins de segments que A .

disons, premier segment dans A a la longueur la et dans b - lb . la > = lb car nous avons choisi le premier segment dans A pour avoir une longueur maximale possible. Et si lb < la , nous pouvons augmenter la longueur du premier segment dans B sans augmenter le nombre total de segments dans B . Cela nous donnerait une autre solution optimale B ', ayant le même premier segment que a .

maintenant, supprimez ce premier segment de A et B ' et répétez le fonctionnement de la longueur l' < l . Faites-le jusqu'à ce qu'il ne reste plus de segments. Cela signifie que la réponse A est égale à une solution optimale.


0 commentaires