Vérifiez avant d’appliquer
Comparez le comportement observé au résultat attendu. Si une vérification échoue, cherchez la cause avant de poursuivre les modifications.
Espace de développement avec IA
Correction Hamming d’un bit
Décodez un mot Hamming de sept bits en supposant explicitement au plus un bit inversé.
● ● ●ParityOchre●
Méthodes de travail · Correction Hamming d’un bit ×
def correct_hamming(word):
word = list(word)
if len(word) != 7 or any(type(b) is not int or b not in (0, 1) for b in word):
raise ValueError("hamming.word")
syndrome = 0
for parity in (1, 2, 4):
value = 0
for position in range(1, 8):
if position & parity:
value ^= word[position-1]
if value:
syndrome |= parity
if syndrome:
word[syndrome-1] ^= 1
data = (word[2] << 3) | (word[4] << 2) | (word[5] << 1) | word[6]
return data, syndrome✳Décodez un mot Hamming de sept bits en supposant explicitement au plus un bit inversé.
✓ ModificationsVérifiez avant d’appliquer ↗
Illustration de l’espace de travail
Modèles
Configurez un endpoint compatible OpenAI ou Anthropic avec son URL de base et une clé API si nécessaire. Testez la connexion. Un serveur local doit fonctionner ; les outils distants peuvent transmettre des données séparément.
Projet
Testez les mots intacts et chaque position inversée, rejetez les données mal formées ou non binaires et ne promettez pas de détecter plusieurs erreurs.
Méthodes de travail
def correct_hamming(word):
word = list(word)
if len(word) != 7 or any(type(b) is not int or b not in (0, 1) for b in word):
raise ValueError("hamming.word")
syndrome = 0
for parity in (1, 2, 4):
value = 0
for position in range(1, 8):
if position & parity:
value ^= word[position-1]
if value:
syndrome |= parity
if syndrome:
word[syndrome-1] ^= 1
data = (word[2] << 3) | (word[4] << 2) | (word[5] << 1) | word[6]
return data, syndromeRespectez les hypothèses de fonctionnement du code expérimental
ParityOchre est un espace de programmation avec IA pour Windows qui aide à transformer une petite expérience technique en composant logiciel aux limites clairement définies. Ouvrez le dossier source et décrivez les conditions d’utilisation du résultat. Demandez au modèle d’examiner le calcul et son appelant, surtout lorsqu’une sortie pourrait être interprétée comme une preuve de récupération réussie.
Par exemple, demandez un examen de hamming.py dans l’hypothèse d’une erreur sur un seul bit. Fournissez un mot intact et un mot dont un bit a changé, puis précisez comment l’application doit présenter les données et le syndrome renvoyés. Discutez séparément des défaillances hors de cette hypothèse, sans laisser un résultat plausible suggérer que toute entrée endommagée a été corrigée.
Utilisez la modification proposée pour examiner l’interface entourant l’expérience. Vérifiez la longueur des entrées et les valeurs des bits, exécutez des jeux d’essai indépendants dans votre environnement et examinez le message affiché par le consommateur. Des noms de sortie clairs comptent ici : l’application doit communiquer ce que la routine rapporte réellement, sans transformer un exemple limité en affirmation de fiabilité plus générale.
ParityOchre prend en charge les connexions aux modèles via des points de terminaison compatibles OpenAI ou Anthropic, avec des identifiants si nécessaire. Un modèle d’IA sans censure est une option lorsqu’il est proposé, sous réserve des restrictions du fournisseur. Les outils disponibles et le contexte dépendent du modèle et du serveur choisis ; les preuves issues de vos jeux d’essai restent nécessaires pour examiner le comportement logiciel proposé.
Questions sur les expériences de récupération à portée limitée
Une valeur renvoyée prouve-t-elle que le mot a été réparé ?
Seulement dans le cadre des hypothèses établies pour la routine et l’entrée. Une valeur de données plausible ne prouve pas à elle seule la correction de dommages quelconques. Examinez la description du résultat dans l’application pour ne pas présenter aux utilisateurs une assurance supérieure à celle étayée par l’expérience.
Que doit couvrir la validation des entrées ?
Utilisez la longueur de mot attendue et les valeurs de bits autorisées par le contrat du projet. Incluez des longueurs incorrectes et des éléments autres que des bits dans les jeux d’essai. Examinez aussi le rejet via l’appelant : une exception de fonction auxiliaire ne constitue pas nécessairement une réponse utile de l’application.
Pourquoi inclure des mots intacts dans les tests ?
Ils vérifient le chemin sans modification et le sens du syndrome signalé lorsqu’aucune correction n’est indiquée. Comparez les données extraites à une valeur attendue indépendante. Tester uniquement des exemples endommagés peut laisser passer un défaut de traitement des entrées ordinaires ou d’interprétation des sorties.
Comment demander une gestion plus large des erreurs ?
Précisez les cas d’erreur supplémentaires et les preuves nécessaires à l’application pour les distinguer. Traitez cela comme une nouvelle exigence de conception plutôt qu’un petit correctif de l’exemple existant. Examinez l’interface et les tests proposés avant de supposer une garantie de récupération renforcée.
ParityOchre · Mis à jour 2026-10-25