Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!jarthur!nntp-server.caltech.edu!nijinsky.ipac.caltech.edu!tim
From: tim@nijinsky.ipac.caltech.edu (Tim Conrow)
Newsgroups: comp.sys.handhelds
Subject: DEC2FRAC problem
Message-ID: <1991Apr3.011209.2203@nntp-server.caltech.edu>
Date: 3 Apr 91 01:12:09 GMT
Sender: news@nntp-server.caltech.edu
Organization: California Institute of Technology
Lines: 46


Joseph K. Horn's recent posting of DEC2FRAC was modified to more
closely emulate the capabilities of the \->Q function on the keyboard,
i.e. to operate on any (reasonable) object type (apologies for not
saving the modifier's name, I excitedly copied the code to my calculator
without saving references). I found one incompatability:

When fractions (quotients) and decimals are represented in the same
algebraic repeated calling of DO\->Q swaps the two representations,
but there is never a time when all are in quotient form. I.e.

2: '1/2 + .25'   produces    1: '.5 + 1/4'
1: 10
DO\->Q

Calling DO\->Q again reproduces the original input. \->Q on the otherhand
will produce quotients from decimals without evaluating already extant
quotients to decimals. I.e., the above example produces

1: '1/2 + 1/4'

The problem seems to be the code fragment "oper EVAL" after the START loop.
EVAL is not the inverse of OBJ\-> in this case:

1: '1/2'  produces    4: 1
OBJ\->                3: 2
                      2: 2
                      1: /
But

3: 1      produces    1: .5
2: 2
1: /
EVAL

So I guess the question is, what is the "correct" way to invert this 
operation of OBJ\->? How does one re-assemble an algebraic from the stack
without evaluating quotients to real numbers?

Surely there's a SYSEVAL for this, there always is :-) ???

Despite this tiny bug, the algorithm is wonderful. And the process is quite
educational. Thanks for the routines, guys!!

-- Tim Conrow
tim@ipac.caltech.edu