Saltar al contenido principal
LibreTexts Español

6.2: Probar siempre una función

  • Page ID
    87604
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    Las funciones tienen serias implicaciones en cuanto a la exactitud de los resultados y al control de errores. Desde el lado positivo, el hecho de que el programa sea reutilizado muchas veces, y desarrollado una vez intencionalmente para su reutilización, significa que normalmente la mayoría de los errores habrán sido identificados y corregidos. Desde el lado negativo, la encapsulación significa que el usuario normalmente no sabrá lo que hay dentro, y por lo tanto no puede dar fe personalmente de la corrección. Este último es, afortunadamente, bastante fácil de abordar de una manera razonable, si no rigurosa: ante cualquier nueva función, siempre vale la pena considerar varios casos de prueba -para los que conoce la respuesta- para confirmar el comportamiento correcto; cuanto más autoritaria es la fuente, más se ha utilizado la función, cuanto más simple sea la tarea, tal vez menos pruebas requeridas. Pero recuerda que no solo estás probando el código, también estás probando tu comprensión de las entradas y salidas.

    Tenga en cuenta que muchas veces es difícil encontrar un caso de prueba en el que sepamos la respuesta. En particular en el contexto numérico existe un artificio por el cual se puede apartar esta cuestión. En particular, a menudo es posible postular la respuesta y luego determinar fácilmente la pregunta (lo que arroja esta respuesta). Por ejemplo, si queremos probar un código que encuentre las raíces de un polinomio de cuarto orden, para cualquier polinomio de cuarto orden en particular no es fácil deducir la respuesta correcta (o no necesitaríamos el código en primer lugar). No obstante, es fácil postular las cuatro raíces -la respuesta- y multiplicarse para obtener el polinomio con estas raíces -la pregunta-. Luego probamos el código yendo hacia atrás (de hecho hacia adelante), y verificando que la pregunta lleva a la respuesta. Tenga en cuenta que dicha prueba no confirma que el código funcione en todos los casos; de hecho, solo hemos confirmado un caso. El enfoque numérico (o incluso la lógica del código) podría, por lo tanto, ser defectuoso en ciertos o incluso en muchos casos. No obstante, hemos confirmado que estamos usando el código correctamente, que entendemos lo que en principio debería suceder, y que en al menos uno (o varios) casos no triviales que lo que debería suceder efectivamente sucede. Siempre debes probar una nueva función de esta manera.

    Hacemos hincapié en que nuestra discusión aquí se aplica tanto a las muchas funciones “incorporadas” de MATLAB, funciones agrupadas con el núcleo de MATLAB, como a cualquier otra función definida por el usuario. También en el resto de este capítulo muchos de los detalles son relevantes tanto para las funciones integradas como para las de usuario; por ejemplo, cómo llamar a una función multi-salida, multi-entrada; sin embargo, algunos detalles, como cómo crear una función, obviamente solo son importantes para las funciones definidas por el usuario.


    This page titled 6.2: Probar siempre una función is shared under a CC BY-NC-SA 4.0 license and was authored, remixed, and/or curated by Masayuki Yano, James Douglass Penn, George Konidaris, & Anthony T Patera (MIT OpenCourseWare) via source content that was edited to the style and standards of the LibreTexts platform; a detailed edit history is available upon request.