Racines quadratiques stables
Calculez les racines réelles d'un polynôme quadratique avec des coefficients mis à l'échelle et une formule limitant l'annulation numérique.
from math import isfinite, sqrt, copysign
def real_roots(a, b, c):
original = (a, b, c)
if not all(type(v) in (int, float) and isfinite(v) for v in original) or a == 0:
raise ValueError("finite quadratic coefficients")
if c == 0:
other = -b / a
if not isfinite(other) or (b != 0 and other == 0):
raise ValueError("unrepresentable root")
return [0.0] if b == 0 else sorted((0.0, other))
scale = max(map(abs, original))
a, b, c = (v / scale for v in original)
if any(v != 0 and s == 0 for v, s in zip(original, (a,b,c))):
raise ValueError("coefficient underflow")
d = b*b - 4*a*c
if d < 0: return []
if d == 0: roots = [-b / (2*a)]
else:
q = -0.5 * (b + copysign(sqrt(d), b))
if q == 0: raise ValueError("root underflow")
roots = sorted((q/a, c/q))
if not all(map(isfinite, roots)) or (original[2] != 0 and 0 in roots):
raise ValueError("unrepresentable roots")
return rootsModè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 une racine double et des racines éloignées, en rejetant un coefficient dominant nul ou des résultats non représentables et en ne renvoyant aucune racine si le discriminant est négatif.
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.
from math import isfinite, sqrt, copysign
def real_roots(a, b, c):
original = (a, b, c)
if not all(type(v) in (int, float) and isfinite(v) for v in original) or a == 0:
raise ValueError("finite quadratic coefficients")
if c == 0:
other = -b / a
if not isfinite(other) or (b != 0 and other == 0):
raise ValueError("unrepresentable root")
return [0.0] if b == 0 else sorted((0.0, other))
scale = max(map(abs, original))
a, b, c = (v / scale for v in original)
if any(v != 0 and s == 0 for v, s in zip(original, (a,b,c))):
raise ValueError("coefficient underflow")
d = b*b - 4*a*c
if d < 0: return []
if d == 0: roots = [-b / (2*a)]
else:
q = -0.5 * (b + copysign(sqrt(d), b))
if q == 0: raise ValueError("root underflow")
roots = sorted((q/a, c/q))
if not all(map(isfinite, roots)) or (original[2] != 0 and 0 in roots):
raise ValueError("unrepresentable roots")
return rootsExaminer le comportement numérique au-delà des cas ordinaires
RootEquinox est un espace de programmation avec IA pour Windows destiné aux développeurs qui doivent examiner le comportement d’un calcul hors des exemples faciles. Commencez par les fichiers du projet et décrivez la plage d’entrées attendue par l’application. Demandez au modèle connecté d’inspecter le calcul et la réponse de l’appelant quand un résultat ne peut pas être représenté comme prévu.
Une routine de racines quadratiques fournit une tâche concrète. Des coefficients d’échelles très différentes peuvent révéler un comportement absent d’un petit exemple scolaire ; apportez donc des cas représentatifs à la conversation avant de demander une modification. Discutez des racines multiples, des coefficients dominants rejetés et du signalement d’un résultat non pris en charge. Ces questions relient le changement de formule proposé au contrat logiciel environnant.
Inspectez le code obtenu et exécutez les contrôles du projet avec les cas initiaux, y compris des vérifications des résidus si approprié. Ne considérez pas un nombre affiché plausible comme une preuve suffisante que le code respecte ses bornes. RootEquinox fonctionne avec les points de terminaison compatibles OpenAI ou Anthropic pris en charge, avec des identifiants si nécessaire. Un modèle sans restrictions est possible si le service configuré en fournit un, tandis que les outils et limites de contexte dépendent du serveur. L’objectif est un changement numérique évaluable sur des cas explicites, avec un comportement de rejet examiné aussi soigneusement que les sorties réussies.
Évaluer un correctif numérique
Que joindre au signalement d’un résultat inexact ?
Fournissez les coefficients d’entrée, le comportement attendu et assez de détails pour reproduire l’écart. Incluez l’utilisation du résultat par l’appelant. L’assistant dispose ainsi d’un problème logiciel concret plutôt que d’une invitation à remplacer la formule sans preuve.
Pourquoi inspecter les circuits de rejet du code numérique ?
Les appelants ont besoin d’une réponse définie si l’entrée est invalide ou si un résultat utile ne peut pas être représenté. Examinez ces circuits avec le calcul pour qu’un correctif ne remplace pas un échec clair par une sortie trompeuse ou une exception inattendue.
Une vérification des résidus prouve-t-elle la précision de chaque racine ?
Elle apporte des éléments sur les valeurs renvoyées, mais ne constitue pas une preuve universelle. Utilisez-la avec des cas de référence et des vérifications aux bornes d’entrée, et examinez les hypothèses de tolérance plutôt que de prendre un seul petit résidu pour une validation complète.
Dois-je accepter une réécriture qui réussit les exemples ordinaires ?
Seulement après avoir vérifié les cas difficiles à l’origine de la tâche. Conservez dans les tests du projet les échelles très différentes, les racines multiples et les entrées invalides spécifiées. Examinez tout changement du comportement d’échec avant d’accepter le remplacement.
RootEquinox · Mis à jour 2026-10-25