Anterior Siguiente Indice

10. Apendice C: Detalle de Fallas

10.1 Falla del Escritor de Ecuaciones

Texto original de Joe Horn

Comportamiento Revisión E

Primero baja la bandera -53 (la bandera de procedimiento).

En una Rev E, pon '((1+2)/(3+4))^5' en la pila y presiona flecha hacia abajo. Veras:


       5

/ 1+2 \

| --- |                         (A)

\ 3+4 /
como debiera ser. Pero ahora presiona shift-naranjo +; ves el mensaje "Implicit () off" momentáneamente; presiona flecha-izquierda (no borrar), después presiona la softkey EXIT. La expresión queda mutilada en esto:

    1+2

-----------                       (B)

      (5)

 (3+4)
que no es la misma expresión (A) de arriba! Falla, si? Presiona ON para abortar el proceso.

Ahora sube la bandera -53, y repite el procedimiento de arriba. Primero veras:


       5

/ 1+2 \

| --- |                         (C)

\ 3+4 /
que es lo mismo que (A) arriba; pero continuando igual que antes, veras:

         (5)

/  1+2  \

| ----- |                       (D)

\ (3+4) /
que es igual al original. Por eso la falla puede ser evitada manteniendo la bandera -53 arriba (una solución no agradable).

Comportamiento Rev J

Mayor diferencia: después de presionar la flecha hacia abajo, la Rev J va directamente al modo gráfico, así que debes presionar ON y después EXIT para llegar el editor de ecuaciones (la Rev E llegaba directamente). Pero eso es insignificante comparado el siguiente gran cambio.

La misma secuencia de operaciones, primero con la bandera -53 abajo, después arriba, exactamente como se detallo arriba, se producen estas cuatro pantallas en una Rev J:


         5

/ (1+2) \

| ----- |                       (A')

\  3+4  /
(notas los paréntesis extras?) y después:

         5

/ (1+2) \

| ----- |                       (B')

\ (3+4) /
que es igual a (A'); nada como la expresión (B) de arriba! y después:

         5

/ (1+2) \

| ----- |                       (C')

\  3+4  /
que es lo mismo que (A') arriba; y despues:

         5

/ (1+2) \

| ----- |                       (D')

\ (3+4) /
que es igual a (A'). No hay falla en la Rev J.

SUMARIO: Rev A-E tienen una falla en el EquationWriter que puede mutilar expresiones si la bandera -53 esta abajo (por defecto) y el modo de "Paréntesis Explícitos" esta puesto. Esta falla ha sido arreglada en la Rev J.

Desafortunadamente (como lo pudiste ver arriba) la Rev J siempre pone paréntesis al rededor de los numeradores de polinomios. Por eso es imposible usar el comando ->GROB en una Rev J para crear un GROB que se vea como la expresión (A) de arriba; la expresión mas simple que se puede tener es la (A').

Otro cambio menor: Rev A-E no cambian el menú cuando presiones REPL; Rev J cambia automáticamente al menú apropiado RULES.

10.2 Falla en la Conversión de Velocidad de Rotación a Frecuencia Angular

Sobre la Falla:

Texto original de Wlodek Mier-Jedrzejowicz <wacm@doc.ic.ac.uk>

Hay una falla en la conversión de velocidad de rotación en la HP48 G/GX que no he visto aquí antes, así que después de una discusión con las personas en Corvallis estoy publicando esta descripción. Advertencia: tiene 159 líneas!

Primero - un ejemplo. Pon el objeto de unidad 60_rpm en el nivel 2 y el objeto de unidad 1_r/s en el nivel 1, después ejecuta el comando CONVERT. Le estas pidiendo a la HP48 que convierta una velocidad de rotación de 60 revoluciones por minuto a una frecuencia angular en radianes por segundo. 60 rpm es una revolución por segundo, o 2pi radianes por segundo. Ninguna HP48 G/GX dará este resultado! No todos usan rpm o están al tanto de la existencia de esta unidad - es una de las unidades extra en el menú UTILS de la Librería de Ecuaciones - así que aquí hay un segundo ejemplo - suma 2pi radianes por segundo a un Hertz. Pon 6.2832_r/s en el nivel 2, 1_Hz en el nivel 1, y suma. Estas sumando una frecuencia angular de dos pi (un ciclo) por segundo a una velocidad de rotación de uno por segundo, así que el resultado debería ser una frecuencia de dos Hertz. En una HP48 S/SX esa es la respuesta. En una HP48 G/GX no lo es.

Cuando las unidades son convertidas, por CONVERT, o durante aritmética de objetos de unidades, el objeto en el nivel 2 es cambiado primero a "unidades de base", y después el resultado es convertido en las unidades del objeto del nivel 1. En la HP48 S/SX, la "unidad base" de ángulos es una rotación ( o una "unidad de circulo" o una revolución o un ciclo). Así la unidad de ángulo de rpm (una revolución) o de Hz (un ciclo si Hz es tratado como velocidad de rotación) ya están en unidades de base - conversiones a ángulos que envuelven rpm y Hz funcionan automáticamente en forma correcta. En la HP48 G/GX, la "unidad de base" de los ángulos es el modo actual de ángulo (DEG, RAD, o GRAD)- así que cualquier conversión desde rpm o Hz (o cualquier formula que trabaje en ciclos, rotaciones, revoluciones, unidad de circulo) a ángulos debería ser precedida por una conversión desde la unidad de circulo al ángulo actual. Aparentemente nadie noto que esto fuera necesario, ya que todo funcionaba automáticamente en la HP48 S/SX.

Así que cuando convertía 60_rpm a unidades de r/s, una HP48 G/GX no convertía 60 rotaciones sino 60 "unidades de base angular" por minuto a radianes/segundos. En modo RAD, obtienes 1 radian por segundo. En modo Deg obtienes 1 grado por segundo, y en modo GRAD obtienes 1 gradian por segundo (en cada caso expresado en radianes). Esas tres diferentes repuestas, de las cuales ninguna es correcta! Pasa exactamente lo mismo si conviertes 1_Hz a ángulos por segundo, y el error inverso es cometido si conviertes ángulos por tiempo a ciclos o rotaciones divididas por tiempo.

La primera vez que escuche de esta falla fue gracias a un miembro de HPCC (club ingles de usuarios de handhelds HP), Peter Embrey. El describe sus problemas en los artículos de las dos primeros números de 1994 de la revista de su club, DATAFILE (en el Volumen 13 numero 1 paginas 12 a 14 y V13n2p6). El estaba calculando la energía acumulada por una "flywheel" - dada por la formula (1/2)*I*omega^2 y después de un tiempo el decidió que las respuestas eran demasiado grandes cuando las convertía desde kg*m^2*(r/s)^2 a W*h en una HP48 GX. Se ve que (r/s) son las unidades correctas para obtener la respuesta correcta, pero la GX estaba convirtiendo a grados por segundo como si estuviera en modo DEG, así que su respuesta era demasiado grande por un factor de (360)/2pi)^2- un factor cercano a 3,300. En este caso, su HP48 SX no daba mejores resultados, ya que desde radianes a unidad de círculos. El camino para obtener la repuesta correcta es usar una HP48 G o GX en modo RAD - o dividir para eliminar los radianes de la formula antes de usar CONVERT. Esto no es una falla, pero necesita mucho cuidado así como el uso de unidades de temperatura en la HP48. Pero cuando Peter trato de resolver el problema usando rpm, el llego a la falla descrita mas arriba. Mis agradecimientos a Peter por encaminarme correctamente!

Aparentemente esta falla no ha sido reportada anteriormente - a lo menos mis amigos en HP me dijeron que no estaba en su lista de problemas conocidos hasta que yo se los dije. (Esto quiere decir que no esta reparado en la nueva revisión R). Porque nadie sabia de esto o trabajo con esto sin querer contarle a nadie mas? O nadie usa su HP48 para hacer cálculos de cuerpos en rotación - o la mayoría de las personas hacen cálculos con cuerpos en rotación de tal forma que no encontraron este problema? Podrían haber cientos de estudiantes e ingenieros all afuera calculando y diseñando cosas en sus HP48 G/GX y obteniendo resultados demasiado imprecisos? Alguien habrá fabricado una disquetera o un motor jet que rota demasiado rápido y que se desintegrara a causa de esto? no, por supuesto que no, todos los ingenieros sabemos que cualquier calculo de diseño debe ser repetido absolutamente en dos calculadoras o programas computacionales totalmente separados! :-| Talves algunos estudiantes han perdido notas en exámenes a causa de esto - pero por favor, esto no lo digo para recomenzar la discusión si las calculadoras deberían ser permitidas en los exámenes!

Quiero destacar nuevamente que aparentemente nadie ha reportado esto antes - lo que significa que muy pocas personas han sido afectadas por esto. Por lo tanto, no es una buena razón para botar tu HP48 G/GX al la basura o contratar un abogado para demandar que HP reemplace tu HP48 G/GX - pero pienso que es importante que las personas están prevenidas para que tomen las precauciones del caso. El resto de este mensaje se ahonda mas en el tema - si nuca te has preocupado acerca de cálculos de rotaciones, entonces puedes ignorar el resto sin peligro - aunque lo vas a encontrar interesante, así que no pares aun de leer :-)

Una manera de evitar esto es agregando una nueva unidad en la HP48 - llámala como quieras - "ciclo" o "rotación" o "revolución" o "unidad de circulo". Como escribí arriba, esta ya esta implícita en la HP48 S/SX; para ver esto en una HP48 S/SX, pon 360 grados en el nivel 1 y ejecuta UBASE - el resultado es 1, significa que 360 grados son equivalentes a una unidad de base de medida angular, pero no hay una unidad HP48 con nombre que corresponda a esta. En contraste, UBASE en una G/GX considera la unidad de base de la medida angular a el radian, aun cuando CONVERT se comporta como si la unidad de base sea el modo angular. Aparentemente hay dos normas diferentes para la unidad de base angular en la HP48 G/GX!

Este asunto es mencionado brevemente en los manuales de HP. En el manual original de la HP48 SX (dos volúmenes, lomo espiral), la sección "Unidades Adimensionales de ángulos" en el capitulo 13, en la pagina 198, advierte al lector sobre el peligro de usar unidades a dimensionales y explica como las unidades angular y los escalares son tratados. En los manuales posteriores de la HP48 SX (un volumen), la misma advertencia es dada en "Conversión de Unidades Adimensionales de Ángulos", en la pagina 13-12. El Manual del Usuario de la Serie HP48 G, en "Conversión de Unidades Angulares", en la pagina 10-7, dice que la conversión interpretara un escalar de acuerdo al actual modo angular. (Un escalar es un numero puro sin unidades).

Para una descripción detalla, ve en la edición de la HP48 S/SX del "HP48 Insights Vol II", sección 21.4.3. Este libro fue escrito por Dr Bill Wickes, quien fuera el líder del equipo de desarrollo de la HP48 SX, y quien escribiera los libros "Insights" (interiores), principalmente para proveer una suerte de explicaciones y detalles que fueron dejados afuera de los manuales. Una buena de las unidades angulares es exactamente el tipo de cosa que uno puede encontrar ahí! El explica las trampas y las contradicciones inevitables de trabajar con ángulos en el sistema de unidades de la HP48 y dice que la HP48 S/SX hace alguna elección arbitraria de usar 2pi como la unidad de base angular, por esto que las conversiones entre ángulos por tiempo y Hertz trabajen correctamente.

Tal vez nadie en el equipo de diseño de la HP48 G/GX leyó esto mientras hacían cambios en la HP48 S/SX! Porque cambiaron la unidad de base? Aparentemente porque estaban tratando de manejar otra contradicción: las unidades de sistema te dejaban agregar números puros a ángulos, ya que ambos eran adimencionales. Si tu agregas el numero 1 en el nivel 2 al objeto unidad 0_r en el nivel 1 de una HP48 S/SX, el numero 1 es tratado como 1 unidad base, o 2 pi radianes, y el resultado es 6.2832_r - pero si tomas el SIN del numero 1, no es tratado como 2pi, sino como 1 unidad del modo angular actual. EL cambio efectuado en la HP48 G/GX resuelva esta contradicción, pero al costo de introducir la falla antes mencionada.

Como mencione, una forma de resolver el problema es agregar la unidad "ciclo" explícitamente al sistema de unidades de la HP48. Hz entonces seria tratado como ciclos por segundo cuando fuera usado en cálculos relacionados con rotaciones - rpm serian tratados como ciclos por minuto, y las conversiones irían desde ciclos a las unidades apropiadas de ángulos. Esta sugerencia fue hecha por Peter Embrey en sus artículos, y las personas en HP aceptaron que era una buena solución - pero ellos no la han implementado aun. Mientras tanto, se muy, pero muy cuidadoso cuando conviertas unidades entre velocidad de rotación y unidades de frecuencia angular. Yo recomendaría a todo el que no tiene una copia de Insights II que lo compre y lea la sección relevante - tal vez eso alentara a Bill Wickes a que publique la tan esperada versión HP48 G/GX de ese libro!

No he mencionado ángulos sólidos. En un principio no deberían haber problemas - an la HP48 S/SX y en la HP48 G/GX la unidad base de ángulos sólidos es una "unidad esférica", o 4pi steradianes. En la HP48 S/SX puedes agregar el numero puro 1 a 0_sr y obtener 12.5664_sr (4pi steradianes). Los manuales de la HP48 G/GX dan a entender que pasaría exactamente lo mismo, pero en my HP48 GX (versión L) esto da el mensaje de error "Inconsistent Units". Este es otra diferencia no documentada entre la serie S y la serie G, pero al menos no es una falla!

Disculpas por hacer esta descripción tan larga, espero que mucha gente este de acuerdo que un asunto como este merece una descripción detallada! Para mi nueva maña - algunos detalles del Generador de Números Aleatorios en la HP48.

Adición:

Texto original de Eric Haas <EHaas@ix.netcom.com>

Nota: El símbolo < representa al carácter ángulo.

La falla de la conversión angular esta en la definición de la unidad rpm. Si pones 1_rpm en la pila, y tipeas UBASE, obtendrás 1.66666666667E-2_1/s. Nota que no hay una unidad angular en la definición. Si la unidad rpm es definida como 6_</s, todas las conversiones de y hacia rpm funcionaran bien. Como un parche, define la unidad RPM como 6_< y úsala en vez de la unidad incorporada.

Si lo deseas, también puedes definir la unidad HZ como 60_RPM o 360_</s. Sin embargo, algunas veces Hz es usado para describir cosas que no son velocidades de rotación, entonces una definición como esta no seria apropiada para todas las circunstancias.


Anterior Siguiente Indice