tim@nijinsky.ipac.caltech.edu (Tim Conrow) (04/03/91)
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.edubson@rice-chex.ai.mit.edu (Jan Brittenson) (04/03/91)
In a posting of [3 Apr 91 01:12:09 GMT] tim@nijinsky.ipac.caltech.edu (Tim Conrow) writes: > The problem seems to be the code fragment "oper EVAL" after the START > loop. EVAL is not the inverse of OBJ\-> ... Surely there's a SYSEVAL > for this, there always is :-) ??? Yeah, #546d puts together an Algebraic. Try replacing: oper EVAL with: oper n 1 + # 18CEAh SYSEVAL @ n+1 as system binary # 546Dh SYSEVAL @ join as algebraic Let's hope this works better! -- Jan Brittenson bson@ai.mit.edu