Division durch normierte Polynome
Dividiere ganzzahlige Polynome mit höchstens 21 Koeffizienten durch einen normierten Divisor.
def divide_monic(dividend, divisor):
for row in (dividend, divisor):
if type(row) not in (list, tuple) or len(row) > 21:
raise ValueError("at most 21 coefficients")
if any(type(x) is not int for x in row): raise ValueError("integers")
def trim(row):
row = list(row)
while row and row[0] == 0: row.pop(0)
return row
a, b = trim(dividend), trim(divisor)
if not b or b[0] != 1: raise ValueError("monic divisor")
quotient = [0] * max(0, len(a) - len(b) + 1)
while a and len(a) >= len(b):
degree, factor = len(a) - len(b), a[0]
quotient[len(quotient)-1-degree] = factor
a = trim([x-factor*y for x,y in zip(a,b)] + a[len(b):])
return trim(quotient), aVor dem Anwenden prüfen
Vergleichen Sie das tatsächliche Verhalten mit dem erwarteten Ergebnis. Klären Sie fehlgeschlagene Prüfungen vor weiteren Änderungen.
Modelle
Richten Sie einen OpenAI-kompatiblen oder Anthropic-Endpunkt mit Basis-URL und gegebenenfalls API-Schlüssel ein. Testen Sie die Verbindung. Ein lokaler Modellserver muss laufen; entfernte Werkzeuge können Daten separat übertragen.
Projekt
Prüfe Nullpolynome und einen konstanten Divisor, lehne nichtganzzahlige Koeffizienten oder einen nichtnormierten Divisor ab und kontrolliere die Quotient-Rest-Identität.
def divide_monic(dividend, divisor):
for row in (dividend, divisor):
if type(row) not in (list, tuple) or len(row) > 21:
raise ValueError("at most 21 coefficients")
if any(type(x) is not int for x in row): raise ValueError("integers")
def trim(row):
row = list(row)
while row and row[0] == 0: row.pop(0)
return row
a, b = trim(dividend), trim(divisor)
if not b or b[0] != 1: raise ValueError("monic divisor")
quotient = [0] * max(0, len(a) - len(b) + 1)
while a and len(a) >= len(b):
degree, factor = len(a) - len(b), a[0]
quotient[len(quotient)-1-degree] = factor
a = trim([x-factor*y for x,y in zip(a,b)] + a[len(b):])
return trim(quotient), aMathematische Annahmen bei Codeänderungen sichtbar halten
MonicVale ist ein Programmierarbeitsbereich für Windows, um mathematische Hilfsfunktionen im Kontext der verwendenden Anwendung zu besprechen. Beginnen Sie mit dem Projektordner und bestimmen Sie die Annahmen, auf denen die Hilfsfunktion beruht. Lassen Sie den Assistenten diese Annahmen im Code untersuchen, bevor Sie ein Refactoring anfordern. Ein hilfreicher Vorschlag erklärt, welches Verhalten unverändert bleibt und welche Eingaben weiterhin außerhalb des unterstützten Vertrags liegen.
Eine Aufgabe zu polynomial.py könnte eine Division untersuchen, deren Divisor normiert sein muss. Liefern Sie Beispiele für die Koeffizientenreihenfolge, führende Nullen sowie den erwarteten Quotienten und Rest. Fragen Sie, wie die aktuelle Implementierung diese Ergebnisse darstellt, und prüfen Sie jede vorgeschlagene Vereinfachung anhand dieser Darstellung. So bleibt das Gespräch am Softwareverhalten orientiert, statt eine allgemeine mathematische Erklärung an die Stelle einer Implementierungsprüfung treten zu lassen.
Führen Sie nach der Bearbeitung Ihre Projektprüfungen aus und vergleichen Sie die Ausgaben mit unabhängig durchgerechneten Beispielen. Prüfen Sie auch das Zurückweisungsverhalten, insbesondere wenn aufrufender Code einen nicht unterstützten Divisor liefern könnte. MonicVale verbindet sich bei Bedarf mit Zugangsdaten mit unterstützten OpenAI-kompatiblen oder Anthropic-Endpunkten. Uneingeschränkte Modelle stehen nur zur Wahl, wenn Ihr gewählter Endpunkt sie anbietet; Einschränkungen, Kontextkapazität und Werkzeuge hängen weiterhin von diesem Dienst ab. Nutzen Sie den Arbeitsbereich, um Annahmen und beobachtete Ergebnisse zusammenzuhalten, während Sie entscheiden, ob die Änderung bereit ist.
Annahmen hinter einer mathematischen Hilfsfunktion
Warum vor einer Änderung die Koeffizientenreihenfolge festlegen?
Dieselbe Liste kann je nach Konvention unterschiedliche Polynome beschreiben. Geben Sie an, wie Ihr Projekt Koeffizienten anordnet und die Null darstellt. Prüfen Sie aufrufenden Code und Rückgabewerte anhand dieser Konvention, bevor Sie ein vom Modell vorgeschlagenes Refactoring übernehmen.
Soll eine Hilfsfunktion nicht unterstützte Divisoren stillschweigend anpassen?
Nur wenn Sie ihren Vertrag bewusst ändern und die Folgen untersuchen. Eine auf normierte Divisoren beschränkte Hilfsfunktion sollte nicht unterstützte Eingaben konsistent melden; eine Verallgemeinerung kann andere arithmetische Annahmen und zusätzliche Tests im gesamten aufrufenden Code erfordern.
Was sollte ich beim Rest prüfen?
Prüfen Sie die vom aufrufenden Code erwartete Darstellung und den mathematischen Zusammenhang für unterstützte Beispiele. Berücksichtigen Sie Fälle ohne Rest und mit einem Rest ungleich null, damit der Vorschlag nicht allein durch das Bewältigen einer einfachen Division besteht.
Ist eine kürzere mathematische Funktion vertrauenswürdiger?
Nicht unbedingt. Prüfen Sie, ob die kürzere Fassung Validierung, Ausgabekonventionen und Verhalten in Grenzfällen bewahrt. Fragen Sie nach der Begründung jeder Vereinfachung und testen Sie den Vertrag; Kürze belegt nicht, dass eine mathematische Annahme gültig bleibt.
MonicVale · Aktualisiert 2026-10-25