Transformée entière de Walsh–Hadamard
Appliquez la transformée de Walsh–Hadamard non normalisée à une suite non vide d’entiers bornés dont la longueur est une puissance de deux au plus égale à 256.
def walsh_transform(values):
out = list(values)
n = len(out)
if not 1 <= n <= 256 or n & (n - 1):
raise ValueError("length.power_two")
if any(type(v) is not int or abs(v) > 1000000 for v in out):
raise ValueError("value.range")
step = 1
while step < n:
for start in range(0, n, 2 * step):
for j in range(start, start + step):
a, b = out[j], out[j + step]
out[j], out[j + step] = a + b, a - b
step *= 2
return out| Projet | Rejetez les longueurs incorrectes et les booléens, puis vérifiez que deux applications multiplient la suite initiale par sa longueur. |
|---|---|
| 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. |
| 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. |
def walsh_transform(values):
out = list(values)
n = len(out)
if not 1 <= n <= 256 or n & (n - 1):
raise ValueError("length.power_two")
if any(type(v) is not int or abs(v) > 1000000 for v in out):
raise ValueError("value.range")
step = 1
while step < n:
for start in range(0, n, 2 * step):
for j in range(start, start + step):
a, b = out[j], out[j + step]
out[j], out[j + step] = a + b, a - b
step *= 2
return outGardez les conventions de transformation visibles pendant la refactorisation
WalshAster est un espace de programmation sous Windows pour examiner les modifications du code source avec un modèle d’IA connecté. Les refactorisations de calcul sont plus faciles à évaluer si la convention d’origine est d’abord explicitée. Décrivez les entrées acceptées, la forme de sortie attendue et la règle de mise à l’échelle avant de demander une réorganisation des boucles ou une autre implémentation.
L’exemple de transformation entière de Walsh–Hadamard fournit une tâche concrète pour cette conversation. Demandez au modèle d’examiner les paires mises à jour et la limite de longueur d’entrée dans le contexte de votre module. Explicitez la convention de l’exemple pour qu’un nom familier ne conduise pas l’assistant à supposer une variante normalisée ou un autre ordre des résultats.
Pendant la revue, comparez le code proposé à de petites sorties connues et aux propriétés que le projet doit conserver. Dans cet exemple, appliquer deux fois la transformation fournit un contrôle utile du facteur d’échelle, en plus des cas d’entrées rejetées. Exécutez vous-même les vérifications et examinez les appelants qui interprètent la sortie ; une refactorisation interne ne doit pas changer silencieusement la convention de données exposée.
Ne choisissez un modèle d’IA sans restrictions que via un point de terminaison compatible OpenAI ou Anthropic pris en charge qui le propose. Configurez les identifiants requis et vérifiez la capacité de contexte et les outils. Les restrictions du modèle connecté dépendent toujours du fournisseur, et sa simplification proposée doit encore être étayée par votre implémentation réelle et vos tests.
Questions pour la maintenance d’une transformation
- Quelle convention documenter avant une refactorisation ?
Précisez l’ordre des sorties, le facteur d’échelle et les longueurs d’entrée acceptées, ainsi que les types d’éléments traités par le module. Incluez une petite entrée et une sortie connues. Cela évite de substituer une autre convention de transformation sous le même nom.
- Un contrôle par double transformation suffit-il seul ?
Il est utile pour la convention illustrée, mais doit accompagner des sorties connues et des tests aux limites des entrées. Vérifiez aussi l’interprétation de l’appelant. Une propriété algébrique préservée ne prouve pas nécessairement que l’ordre et l’interface restent conformes aux attentes de l’application.
- Comment examiner une modification qui altère l’entrée ?
Déterminez d’abord si le contrat existant autorise cette mutation. Incluez les appelants qui réutilisent les valeurs originales et testez explicitement cette réutilisation. Une proposition économisant de la mémoire change le comportement observable si ces appelants attendent une séquence inchangée.
- Changer de modèle modifie-t-il les vérifications nécessaires ?
Non. Conservez les mêmes entrées acceptées, résultats connus et contrôles d’échelle lorsque vous évaluez la proposition d’un autre modèle. Le choix du modèle peut changer l’explication ou le code suggéré, mais n’établit pas la correction et ne remplace pas la vérification du projet.
WalshAster · Mis à jour 2026-10-25