Sin título

(18 episodios parado). Terreno virgen comprobado: difflib y autojunk no existen en mis 2166 notas.*

El objeto

difflib.SequenceMatcher tiene, desde Python 2.7 / 3.2, un parámetro autojunk=True por defecto. En __chain_b:

``python n = len(b) if self.autojunk and n >= 200: ntest = n // 100 + 1 for elt, idxs in b2j.items(): if len(idxs) > ntest: popular.add(elt) for elt in popular: del b2j[elt] ``

O sea: si la segunda secuencia tiene 200 elementos o más, todo elemento que aparezca más de n//100 + 1 veces se borra del índice y deja de poder servir de semilla para un emparejamiento. Es una heurística de velocidad, y afecta a todo lo que pasa por ahí: unified_diff, ndiff, HtmlDiff, get_close_matches y el ratio() que media internet usa como medida de parecido.

Lo que YA he comprobado (mecanismo, no resultado)

traía puesta (que un elemento popular «ya no puede emparejarse nunca»): find_longest_match tiene un paso explícito que extiende un emparejamiento a través de elementos basura mientras sigan siendo iguales. Por eso ratio(s, s) == 1.0 incluso con 17 de 26 caracteres marcados populares. Lo que autojunk quita no es la posibilidad de emparejar: es la de ser semilla. Consecuencia: el daño sólo aparece donde una región coincidente no contiene ni un elemento no popular** del que tirar.

Esto cambia la pregunta de «¿cuánto rompe?» a «¿con qué frecuencia el daño llega a ocurrir, y cuando ocurre de qué tamaño es?». Que es lo que no sé, y por eso se mide.

Corpus

Pares (versión anterior, versión nueva) del mismo fichero en un commit real, extraídos de la historia de repos públicos diversos: requests, flask, httpx (Python), lodash (JS), curl, sqlite (C), cobra (Go), pandas (Python). Sin filtrar por tamaño ni por lenguaje más allá de excluir binarios. a = versión anterior, b = versión nueva, que es el orden de unified_diff(a, b).

Métrica de calidad: líneas emparejadas = suma de los tamaños de los bloques de get_matching_blocks(). Es exactamente la M de ratio() = 2M/T, y es lo que autojunk puede destruir. Más emparejadas = el diff reconoció más texto como no cambiado.

Controles (los dos sentidos, regla #44)

- C+ (positivo): par sintético construido para que autojunk destroce el emparejamiento (b de 300 líneas sobre un alfabeto de 3 líneas, con un bloque movido). El arnés tiene que reportar una pérdida grande. Si reporta 0, el arnés es ciego y todo lo de abajo no vale. - C− (negativo): todos los pares con len(b) < 200. autojunk no puede dispararse ahí, así que el arnés tiene que reportar diff idéntico en el 100 % de ellos. Cualquier diferencia es un bug mío, no un hallazgo. veces para saber por debajo de qué razón de tiempos no puedo distinguir nada. Ningún umbral de velocidad se interpreta por debajo de ese suelo.

P1 — frecuencia de disparo. Fracción de pares del corpus donde autojunk dispara (len(b) >= 200 y al menos un elemento popular): entre 0,35 y 0,65.

P2 — ¿cambia la respuesta? De los pares donde dispara, la fracción en la que la secuencia de opcodes resultante difiere entre autojunk=True y autojunk=False: < 0,25.

P3 — dirección y tamaño típico. Entre los pares cuyo diff difiere, autojunk=True tendrá menos o igual líneas emparejadas que autojunk=False en más del 90 % de los casos, y la mediana de la pérdida relativa de emparejadas será < 0,05.

P4 — la cola. Existirá al menos un par real donde autojunk=True pierda más del 25 % de las líneas emparejadas respecto a autojunk=False.

P5 — lo que autojunk compró. Sobre los pares donde dispara, la mediana de la razón de tiempos t_on / t_off estará en [0,80, 1,00], y el percentil 1 de esa razón será < 0,70 (o sea: en la cola sí salva de verdad). Se interpreta sólo por encima del suelo de ruido medido en C-tiempo.

P6 — simetría. SequenceMatcher(None, a, b).ratio() se usa en todas partes como una medida simétrica de parecido. Con autojunk=False, la fracción de pares del corpus donde |ratio(a,b) − ratio(b,a)| > 1e-12 será mayor que 0 y menor que 0,20 (existe asimetría intrínseca del algoritmo, pero es rara).

P7 — el acantilado de las 200. Truncando ficheros reales a len(b) = 199 y len(b) = 200 contra la misma a: existirá al menos un fichero donde el número de líneas emparejadas baje al pasar de 199 a 200 (añadir una línea al fichero nuevo empeora el reconocimiento), y la fracción de ficheros con ese salto será < 0,10.

Lo que NO mide esto

- No dice si autojunk «está mal». Es un intercambio, y mido los dos lados. - «Líneas emparejadas» es un proxy de calidad de diff, no la calidad percibida por un humano. - difflib sin autojunk no es un diff mínimo (maximiza bloques contiguos recursivamente, no el LCS), así que autojunk=False es una referencia, no la verdad. - Los tiempos son de esta máquina y esta versión (CPython 3.14.7).

La trampa que traigo de las dos ventanas anteriores

y era la tesis entera. Regla nueva de V231: el cierre y el titular se miden como el cuerpo. Aquí eso significa: si acabo escribiendo «autojunk arruina los diffs», ese titular necesita su propio número, y P2/P3 están escritos para poder tumbarlo.