design - solve - Enhebrado de ecuaciones: ¿por qué el comportamiento predeterminado?
solve wolfram mathematica (2)
Hace poco redescubrí un pequeño paquete de Roman Maeder que le dice a Mathematica que enrute automáticamente funciones aritméticas y similares sobre expresiones como x == y. Enlace al paquete de Maeder.
Primero, para demostrar, he aquí un ejemplo dado por Maeder:
In[1]:= Needs["EqualThread`"]
Ahora proceda a usar el comportamiento de enhebrado para resolver la siguiente ecuación para x ''a mano'':
In[7]:= a == b Log[2 x]
In[8]:= %/b
Out[8]:= a/b == Log[2 x]
Ahora exponencial:
In[9]:= Exp[%]
Out[9]= E^(a/b) == 2 x
Y dividir por 2:
In[10]:= %/2
Out[10]= (E^(a/b))/2 == x
P: Desde una perspectiva de diseño, ¿alguien puede explicar por qué Mathematica se comporta de esta manera por defecto? Enhebrar automáticamente parece ser el tipo de comportamiento que un principiante de Mathematica esperaría, al menos para mí, quizás alguien pueda ofrecer un ejemplo o dos que causarían problemas con el sistema como un todo. (Y siéntete libre de señalar cualquier ignorancia matemática ...)
Parece natural cuando se piensa en operaciones aritméticas. Pero ese no es siempre el caso.
Cuando yo escribo
Boole[a==b]
Yo no quiero
Boole[a] == Boole[b]
Y eso es lo que hace el paquete de Maeder.
Editar
Respondiendo tu comentario a continuación:
Noté que Boole [] se agregó en v.5.2, mientras que el paquete de Maeder fue creado para v.3. Supongo que el núcleo de mi pregunta todavía gira en torno al problema del ''diseño''. Quiero decir, ¿cómo resolver el problema que señaló? Para mí, el camino más claro sería declarar algo sobre las variables con las que estás trabajando, ¿no? - Lo que me desconcierta es la manera en que generalmente solo puedes hacer esto con Suposiciones (globalmente o como una opción para Simplificar, etc.). ¿Alguien más piensa que sería más natural tener un conjunto completo de Atributos numéricos? (en este sentido, el atributo constante es una burla)
Mi respuesta no es de ninguna manera una crítica al paquete de Maeder, lo cual es agradable, sino una afirmación de que no debería ser la forma principal de tratar a Equal [] en Mma.
Igual [] es una función, y no es particularmente fácil de entender al principio:
- devuelve True si lhs y rhs son idénticos
- devuelve False si se determina que lhs y rhs son desiguales mediante comparaciones entre números u otros datos sin procesar, como cadenas.
- permanece sin evaluar cuando lhs o rhs contienen objetos como Indeterminate y Overflow.
- se usa para representar una ecuación simbólica, para ser manipulada usando funciones como Solve.
La intención del paquete de Maeder, que entiendo está bien alineado con el tuyo, es darle a la expresión lhs == rhs el mismo significado y las mismas reglas de manipulación que los humanos usan cuando hacen matemáticas.
En matemáticas, la igualdad es una relación de equivalencia, que impone un orden parcial en un conjunto, y una ecuación es una afirmación de que las expresiones están relacionadas por esta relación particular.
Compare estas diferencias con otras "funciones" Mma. Sin [x] está en Mma, y en las matemáticas habituales es lo mismo (bueno, casi), y lo mismo se puede decir de la mayoría de las bestias Mma. Sin embargo, hay algunos constructos de Mma que no tienen ese isomorfismo exacto para los conceptos matemáticos: Igual, SameQ, Equivalente, etc. Son el puente del mundo de las matemáticas al mundo de la programación. No son conceptos matemáticos estrictos, sino conceptos de programación modificados para mantenerlos.
Lo siento si tengo un poco en el lado filosófico.
HTH!
Supongo que se debe en parte a que el comportamiento no se puede extender a las desigualdades. Y también porque el comportamiento debe tener sentido tanto cuando se evalúan las igualdades:
Sería bueno:
In[85]:= Thread[Power[a == b, 2], Equal]
Out[85]= a^2 == b^2
In[86]:= Thread[Power[a == b, c == d], Equal]
Out[86]= a^c == b^d
pero:
In[87]:= Thread[Power[a == b, c == d] /. {c -> 2, d -> 2}, Equal]
Out[87]= a^True == b^True