SIGN bug?
Rafael Millán
stack is a question mark. If the argument is a real zero, however, the
result is 0 (real), as it should be.
I found this using a program by Joe Horn for computing egiptian
fractions (in www.hpcalc.org) which worked ok in my original calculator
with 1.10 ROM. Then, I updated to 1.16 and the question mark appeared;
yesterday, I updated to 1.17.2 and the problem persists.
I have found that the YUser emulator, which has ROM 1.10 also, has the
same problem, and this upsets me because I am fairly sure that in my
original ROM the egiptian fractions program worked in all cases. Or
perhaps there is some unknown (for me) flag with subtle effects over
implicit conversions, or...
Is this a known bug? If so, I apologize.
RaM.
Joėl Bourquard
> stack is a question mark. If the argument is a real zero, however, the
> result is 0 (real), as it should be.
>
> I found this using a program by Joe Horn for computing egiptian
> fractions (in www.hpcalc.org) which worked ok in my original calculator
> with 1.10 ROM. Then, I updated to 1.16 and the question mark appeared;
> yesterday, I updated to 1.17.2 and the problem persists.
I have no idea whether it's a bug or not, but I noticed that too.. I had to
change the egyptian fraction prog. to make it work above.. 1.14-2 I think.
--
Best Regards,
Joėl
____________________________
Numlock from XLR8 Digital Labs
http://fly.to/numlock icq#24242846
Steen S. Schmidt
It's not a bug. SIGN(0) _is_ undefined. SIGN(0.)=0. is kept for
compatibility with the HP48.
Regards
Steen
Rafael Millán
Steen S. Schmidt escribió:
>It's not a bug. SIGN(0) _is_ undefined. SIGN(0.)=0. is kept for
>compatibility with the HP48.
Defining the SIGN(x) function as being 0 when x is 0 seems to me a very
good and logical definition, and so has been in every calculator and
programming language I have used.
RaM.
Joseph K. Horn
> When I apply the SIGN command to an integer zero, the result in the
> stack is a question mark. If the argument is a real zero, however, the
> result is 0 (real), as it should be.
The reason SIGN(0)=? is that Derive (and other CAS packages) consider
the sign of 0 to be "indeterminate". Some return NaN (Not-a-Number),
and others return +/-1 (which, I guess, means that the answer could be
either +1 or -1 depending on which direction you came from to get to the
0, perhaps?). This is because SIGN(x) is defined as x/ABS(x), and 0/0
is of course indeterminate.
> I found this using a program by Joe Horn for computing egiptian
> fractions (in www.hpcalc.org) which worked ok in my original
> calculator with 1.10 ROM. Then, I updated to 1.16 and the question
> mark appeared; yesterday, I updated to 1.17.2 and the problem
> persists.
Replace SIGN in 'EGYPT' with NOT NOT and the program will work in all
ROM versions.
-Joe-
Sent via Deja.com http://www.deja.com/
Before you buy.
John H Meyers
> Defining the SIGN(x) function as being 0 when x is 0
> seems to me a very good and logical definition,
> and so has been in every calculator and
> programming language I have used.
Does I\->R SIGN take care of "defining" SIGN(0) = 0
[for those who desire it] ?
If so, then to generalize:
\<< \-> x \<< x DUP TYPE 28. == { I\->R } IFT SIGN \>> \>>
'Sign' STO
----------
BTW, I only just noticed that I->R also accepts any *real* argument
( even 0.52, say ) while R->I also accepts any integer-type argument,
but R->I won't accept 0.52 ( R->B will accept it, however, although
R->B won't accept #1 as an argument, etc.)
File this in your "math has consistent, simple rules" notebook ;)
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Homer Simpson
>>It's not a bug. SIGN(0) _is_ undefined. SIGN(0.)=0. is kept for
>>compatibility with the HP48.
>good and logical definition, and so has been in every calculator and
>programming language I have used.
Yeah - but the HP49 does math. If something is undefined, it says undefined,
it doesn't give a default value.
As always, the choice of zero for
sign(zero) could be discussed, and I'm sure different people would have
different excellent reasons to choose another value than zero in this
case... For example, Maple thinks that sign(0) is 1 [comment: I'm not sure
this is the right function to use, there is also a signum(0) function that
returns an unspecified result by default.], and the TIs evaluate
sign(0) to itself (not undef).
Homer Simpson
http://zap.to/hsimpson
Keith J. Farmer
Rafael Millán <.> wrote in message news:841d8c$j2l...@SGI3651ef0.iddeo.es...
> You surely mean my "HP49 consistency notebook". I don't think this is a
> big problem, and it is understandable with so much functions and data
> types, but I'm sure that the designers themselves would not defend these
> inconsistencies, and would prefer to fix them.
The problem is in trying to keep backward compatibility with the 48. As a
step toward the next calculator, that's excusable in the 49. I agree,
though, that the 48 should be given less thought when designing the next
calc.
As regards Sign(0)=0, that seems a valid choice, since you could test for 0
and raise an exception if needed. Perhaps this case could be added to the
rigorous setting (the one that keeps abs(x) from going to x).
Rafael Millán
Joseph K. Horn escribió:
>The reason SIGN(0)=? is that Derive (and other CAS packages) consider
>the sign of 0 to be "indeterminate". Some return NaN (Not-a-Number),
>and others return +/-1 (which, I guess, means that the answer could be
>either +1 or -1 depending on which direction you came from to get to
the
>0, perhaps?). This is because SIGN(x) is defined as x/ABS(x), and 0/0
>is of course indeterminate.
But we could define SIGN(x) as "x/ABS(x) for x!=0, and 0 for x==0". I
can imagine no bad consequence (mathematical or computational) derived
from using this definition. In any case, the definition ought to be the
same for reals and integers.
>Replace SIGN in 'EGYPT' with NOT NOT and the program will work in all
>ROM versions.
I replaced SIGN with 0 \=/ several days ago. While they decide what kind
of thing is SIGN(0), I wanted to play with these fractions
(fascinating!)
Rafael Millán
John H Meyers escribió:
>File this in your "math has consistent, simple rules" notebook ;)
You surely mean my "HP49 consistency notebook". I don't think this is a
big problem, and it is understandable with so much functions and data
types, but I'm sure that the designers themselves would not defend these
inconsistencies, and would prefer to fix them.
RaM.
Rafael Millán
>Yeah - but the HP49 does math. If something is undefined, it says
undefined,
>it doesn't give a default value.
The HP49 does math with integers but does not with reals? Hmm.
I don't think 0 is a default value in this case; it is the logical
choice for SIGN(0) _if_ you want the function defined over the whole
real domain.
>As always, the choice of zero for
>sign(zero) could be discussed, and I'm sure different people would have
>different excellent reasons to choose another value than zero in this
>case... For example, Maple thinks that sign(0) is 1 [comment: I'm not
sure
>this is the right function to use, there is also a signum(0) function
that
>returns an unspecified result by default.], and the TIs evaluate
>sign(0) to itself (not undef).
I fully agree. Reasons could be invoked for backing any choice. But the
49 takes two choices simultaneously: one for reals, another for
integers; this is, at least, confusing.
RaM.
Richard Helps
definition of signum (SIGN) as found on the HP48 with SIGN(neg) = -1,
SIGN(0) = 0, SIGN(pos) = +1. This three way test is very useful in
programming and exists is many User RPL programs. using an (arguably) better
definition of signum will make all those programs buggy. One goal of the
HP49 was to bring with it the legacy of thousands of existing HP48 programs.
If I had to vote I would choose to keep SIGN(0) = 0 for both real and
integer for programming convenience, but this is not an issue of democracy,
rather it is an issue of matyhematical correctness and I am sure that many
who are more profoundly mathematically educated would argue SIGN(0) = ? is
the only correct definition.
The HP49 does seem to have become much more of a mathematician's
calculator rather than an engineer's calculator. I hope the mathematics
market is big enough (or perhaps bigger) than the engineering market.
Rafael Millán wrote:
> But we could define SIGN(x) as "x/ABS(x) for x!=0, and 0 for x==0". I
> can imagine no bad consequence (mathematical or computational) derived
> from using this definition. In any case, the definition ought to be the
> same for reals and integers.
>
> >Replace SIGN in 'EGYPT' with NOT NOT and the program will work in all
> >ROM versions.
>
> I replaced SIGN with 0 \=/ several days ago. While they decide what kind
> of thing is SIGN(0), I wanted to play with these fractions
> (fascinating!)
Richard Helps
Tom Sears
> Yes, Keith !
> I think we need a CASPAR ....
Hi,
Having not seen a post from you by Sunday, I almost
suggested this myself ;-)
Happy Year 2000!
Tom
Keith J. Farmer
news:848smu$m71$1...@tron.sci.fi...
> I think we need a CASPAR (I getting tired myself)
The problem I've always seen with CASPAR is speed and memory cost. We only
need to check/set 1 bit -- with the 49's ROM we could, I imagine, set aside
a few dedicated nibbles to expand the flag list, rather than 5 times (at
least) that amount to have an object stored in a list, which may or may not
exist somewhere in PATH. This also preserves the way you access flags,
rather than creating a special case (as the current EXTPRG setup has mutated
to, with the Games menu being a special case, even if it is more efficient
than the other menus). In fact, the only possible benefit I can see is in
being able to set different CAS parameters for different directories.
Veli-Pekka Nousiainen
I think we need a CASPAR (I getting tired myself)
Noooooo...(voice slowly fading away, like falling to a bottomless pit)
--
Regards, VPN
_________________________________________________________
Veli-Pekka Nousiainen ; e-mail= v...@fcsolutions.com
Sokinsuontie 3 A 1, FIN-02760 Espoo, Finland
TEL, WORK= +358 (9) 859 2025 ; (WORK2= +358 (3) 4728 300)
Future Computing Solutions Oy ; URL= http://www.eiffel.fi
_________________________________________________________
HP25,HP28S,HP41CX,HP48SX,HP48GX,HP49G,HP71B,HP75C & TI89
Vote for the "82484A Curve Fit for HP71B" => HP49G !!!
Keith J. Farmer <far...@pacbell.net> wrote in message
news:s68gr2...@corp.supernews.com...
>
> Rafael Millán <.> wrote in message
news:841d8c$j2l...@SGI3651ef0.iddeo.es...
> > You surely mean my "HP49 consistency notebook". I don't think this is a
> > big problem, and it is understandable with so much functions and data
> > types, but I'm sure that the designers themselves would not defend these
> > inconsistencies, and would prefer to fix them.
>
Pete M. Wilson
context where having SIGN(0) = 0 causes a problem?
Perhaps inside a program where it leads to an incorrect result?
As a programmer, having SIGN(0) = 0 is much more useful than SIGN(0) =
? .
Richard Helps <richar...@byu.edu> wrote:
>The problem is that many programs have already been written using the
>definition of signum (SIGN) as found on the HP48 with SIGN(neg) = -1,
>SIGN(0) = 0, SIGN(pos) = +1. This three way test is very useful in
>programming and exists is many User RPL programs. using an (arguably) better
>definition of signum will make all those programs buggy. One goal of the
>HP49 was to bring with it the legacy of thousands of existing HP48 programs.
>
> If I had to vote I would choose to keep SIGN(0) = 0 for both real and
>integer for programming convenience, but this is not an issue of democracy,
>rather it is an issue of matyhematical correctness and I am sure that many
>who are more profoundly mathematically educated would argue SIGN(0) = ? is
>the only correct definition.
> The HP49 does seem to have become much more of a mathematician's
>calculator rather than an engineer's calculator. I hope the mathematics
>market is big enough (or perhaps bigger) than the engineering market.
>
Pete M. Wilson
Gamewood Data Systems Internet Service
wils...@gamewood.net
Joseph K. Horn
> Can a mathemetician give an example of using the SIGN function in a
> context where having SIGN(0) = 0 causes a problem?
No, but here's some mathematical background, FWIW.
Every number has an ABS (distance from the origin) and an ARG (angle
counterclockwise from the positive X axis), which you can obtain either
by using these two separate commands, or all at once by putting your
calculator into polar mode and looking at the resulting (ABS,ARG)
ordered pair. (Add (0,0) if necessary).
The SIGN command modifies its input in such a way that its ABS becomes
1, while its ARG stays the same. In other words, it shrinks (or
lengthens) the input to the "unit vector" with the same polar angle.
Example: (3,4) ABS --> 5.
(3,4) SIGN ABS --> 1.
But what unit vector should be associated with (0,0)? There is no unit
vector which makes any sense whatsoever. The HP48 and HP49 therefore
yield these default results in lieu of anything better being possible:
(0,0) SIGN --> (0,0) [not a unit vector]
0. SIGN --> 0. [not a unit vector]
0 SIGN --> ? [HP49 only]
BTW, the objection that SIGN(0) should yield 0 so that it can be used
for branching is a valid objection, but it can be easily worked around
by testing before the SIGN instead of afterwards.
-Joe-
aven...@epita.fr
Back a few ROM versions ago, there were some bug reports about some
limits incorrectly calculated by the HP49.
All these limits involved internally the SIGN command. We had to
restrict this function to return ? (undefined) in order to return a
correct results for these limits... While SIGN(0.) still return 0. for
backward compatibility reason and because most of the developpers are
engineers :)
Back to your engineering problem, set your calculator in approx mode,
and you won't be bother with mathematical answers anymore :)
Jean-Yves
In article <3868186c...@news.gamewood.net>,
wils...@drop.gamewood.net (Pete M. Wilson) wrote:
> Can a mathemetician give an example of using the SIGN function in a
> context where having SIGN(0) = 0 causes a problem?
>
Richard Helps
disagree with is your last BTW paragraph.
"Joseph K. Horn" wrote:
> BTW, the objection that SIGN(0) should yield 0 so that it can be used
> for branching is a valid objection, but it can be easily worked around
> by testing before the SIGN instead of afterwards.
The point that I was making is that SIGN _is_ the test. It is a three way
test which yields -1, 0, 1 to be used in later processing. Perhaps we can
code around this with two tests, one for zero and one for SIGN, and perhaps
our final code won't end up any bigger/slower than before but the SIGN
three-way test has certainly been useful in the past.
On the question of consistency which started this thread I guess we can
live SIGN(0)=? and SIGN(0.)=0. since we have other integer/real functions
which produce different results. For example 0/0 = ? but 0./0. = '/
Error'
Richard Helps, Brigham Young University
Pete M. Wilson
With I-R SIGN on integer: 0.0311_s
With I-R SIGN on real: 0.0297_s
With SIGN on integer: 0.0449_s
With SIGN on real: 0.0288_s
So, adding I-R takes 0.0009_s in the real case, which is probably more
comparable to the old 48 SIGN function.
So having the inconsistency could actually be the second best choice
since it only requires minor changes to programs.
(First choice, I would have made SIGN do I-R internally and added a
SIGNUM function that does SIGNUM(0.) = ? and SIGNUM(0) = ? -
compatibility with a large installed base is more important than
correctness or improvements (ask IBM)).
Richard Helps <richar...@byu.edu> wrote:
Veli-Pekka Nousiainen
ACO:
Give us SIGNUM, please!
--
Regards, VPN
_________________________________________________________
Veli-Pekka Nousiainen ; e-mail= v...@fcsolutions.com
Sokinsuontie 3 A 1, FIN-02760 Espoo, Finland
TEL, WORK= +358 (9) 859 2025 ; (WORK2= +358 (3) 4728 300)
Future Computing Solutions Oy ; URL= http://www.eiffel.fi
_________________________________________________________
HP25,HP28S,HP41CX,HP48SX,HP48GX,HP49G,HP71B,HP75C & TI89
Vote for the "82484A Curve Fit for HP71B" => HP49G !!!
Pete M. Wilson <wils...@drop.gamewood.net> wrote in message
news:3869063f...@news.gamewood.net...
!> So how much time does it take to do I-R SIGN instead of SIGN?
!>
!> With I-R SIGN on integer: 0.0311_s
!> With I-R SIGN on real: 0.0297_s
!> With SIGN on integer: 0.0449_s
!> With SIGN on real: 0.0288_s
!>
!> So, adding I-R takes 0.0009_s in the real case, which is probably more
!> comparable to the old 48 SIGN function.
!>
!> So having the inconsistency could actually be the second best choice
!> since it only requires minor changes to programs.
!>
!> (First choice, I would have made SIGN do I-R internally and added a
!> SIGNUM function that does SIGNUM(0.) = ? and SIGNUM(0) = ? -
!> compatibility with a large installed base is more important than
!> correctness or improvements (ask IBM)).
!>
!> Richard Helps <richar...@byu.edu> wrote:
!>
!> >Thanks for the clear mathematical explanation Joe. The only part I
mildly
!> >disagree with is your last BTW paragraph.
!> >
!> >"Joseph K. Horn" wrote:
!> >
!> >> BTW, the objection that SIGN(0) should yield 0 so that it can be used
!> >> for branching is a valid objection, but it can be easily worked around
!> >> by testing before the SIGN instead of afterwards.
!> >
!> >The point that I was making is that SIGN _is_ the test. It is a three
way
!> >test which yields -1, 0, 1 to be used in later processing. Perhaps we
can
!> >code around this with two tests, one for zero and one for SIGN, and
perhaps
!> >our final code won't end up any bigger/slower than before but the SIGN
!> >three-way test has certainly been useful in the past.
!> >
!> >On the question of consistency which started this thread I guess we can
!> >live SIGN(0)=? and SIGN(0.)=0. since we have other integer/real
functions
!> >which produce different results. For example 0/0 = ? but 0./0. = '/
!> >Error'
!> >
!> >Richard Helps, Brigham Young University
!> >
!> >
!>
!>
!> Pete M. Wilson
!> Gamewood Data Systems Internet Service
!> wils...@gamewood.net
Keith Farmer
> the system would parse the list into internal form.
The reason PPAR, etc, are the way they are is because the information
they contain is not of the form 0/1. PPAR holds equations, for example.
Having a parsing interface wouldn't be all that convenient in the end,
any more than writing ":: xHEX ; <cr>@" is a convenient way to tell the
HP to set the flags for HEX.
For the simple options you wish, which are very easily represented by a
simple Yes/No question, just expanding the flag list would be the
quickest, most coherent solution.
Veli-Pekka Nousiainen
You're quite right !
Let me rephase:
We have STOF and RCLF, which access bits in SysRAM.
The result can be manipulated by the user.
We have STOKEYS and RCLKEYS.
The user has no reserved variable for them at Home, either.
We have Alarms and a Browser for them plus a handfull
of commands handling them and the system takes
efficiently care about the Alarms.
OK
How about RCLCASPAR and STOCASPAR, then?
The result would be a list with keywords and parameters,
quite similar to PLOTPAR, but after STOCASPAR
the system would parse the list into internal form.
The PLOTPAR was nicely enhanced form 48S to 48G
when new plotting commands were introduced.
Opinions?
--
Regards, VPN
_________________________________________________________
Veli-Pekka Nousiainen ; e-mail= v...@fcsolutions.com
Sokinsuontie 3 A 1, FIN-02760 Espoo, Finland
TEL, WORK= +358 (9) 859 2025 ; (WORK2= +358 (3) 4728 300)
Future Computing Solutions Oy ; URL= http://www.eiffel.fi
_________________________________________________________
HP25,HP28S,HP41CX,HP48SX,HP48GX,HP49G,HP71B,HP75C & TI89
Vote for the "82484A Curve Fit for HP71B" => HP49G !!!
Keith J. Farmer <far...@pacbell.net> wrote in message
news:s6gcf44...@corp.supernews.com...
> Veli-Pekka Nousiainen <v...@fcs.fi> wrote in message
> news:848smu$m71$1...@tron.sci.fi...
> > I think we need a CASPAR (I getting tired myself)
>
Veli-Pekka Nousiainen
How about introducing the SIGNUM function?
SIGNUM(0)
?
SIGNUM(0.)
?
SIGN(0)
0
SIGN(0.)
0.
--
Regards, VPN
_________________________________________________________
Veli-Pekka Nousiainen ; e-mail= v...@fcsolutions.com
Sokinsuontie 3 A 1, FIN-02760 Espoo, Finland
TEL, WORK= +358 (9) 859 2025 ; (WORK2= +358 (3) 4728 300)
Future Computing Solutions Oy ; URL= http://www.eiffel.fi
_________________________________________________________
HP25,HP28S,HP41CX,HP48SX,HP48GX,HP49G,HP71B,HP75C & TI89
Vote for the "82484A Curve Fit for HP71B" => HP49G !!!
<aven...@epita.fr> wrote in message news:849su3$iq7$1...@nnrp1.deja.com...
!> Hello
!>
!> Back a few ROM versions ago, there were some bug reports about some
!> limits incorrectly calculated by the HP49.
!>
!> All these limits involved internally the SIGN command. We had to
!> restrict this function to return ? (undefined) in order to return a
!> correct results for these limits... While SIGN(0.) still return 0. for
!> backward compatibility reason and because most of the developpers are
!> engineers :)
!>
!> Back to your engineering problem, set your calculator in approx mode,
!> and you won't be bother with mathematical answers anymore :)
!>
!> Jean-Yves
!>
!>
!>
!>
!> In article <3868186c...@news.gamewood.net>,
!> wils...@drop.gamewood.net (Pete M. Wilson) wrote:
!> > Can a mathemetician give an example of using the SIGN function in a
!> > context where having SIGN(0) = 0 causes a problem?
!> >
!> > Perhaps inside a program where it leads to an incorrect result?
!> >
!> > As a programmer, having SIGN(0) = 0 is much more useful than SIGN(0) =
!> > ? .
!> >
!> > Richard Helps <richar...@byu.edu> wrote:
!> >
!> > >The problem is that many programs have already been written using the
!> > >definition of signum (SIGN) as found on the HP48 with SIGN(neg) = -1,
!> > >SIGN(0) = 0, SIGN(pos) = +1. This three way test is very useful in
!> > >programming and exists is many User RPL programs. using an
!> (arguably) better
!> > >definition of signum will make all those programs buggy. One goal of
!> the
!> > >HP49 was to bring with it the legacy of thousands of existing HP48
!> programs.
!> > >
!> > > If I had to vote I would choose to keep SIGN(0) = 0 for both real
!> and
!> > >integer for programming convenience, but this is not an issue of
!> democracy,
!> > >rather it is an issue of matyhematical correctness and I am sure
!> that many
!> > >who are more profoundly mathematically educated would argue SIGN(0)
!> = ? is
!> > >the only correct definition.
!> > > The HP49 does seem to have become much more of a mathematician's
!> > >calculator rather than an engineer's calculator. I hope the
!> mathematics
!> > >market is big enough (or perhaps bigger) than the engineering market.
!> > >
!> >
!> > Pete M. Wilson
!> > Gamewood Data Systems Internet Service
!> > wils...@gamewood.net
!> >
!>
!>
!> Sent via Deja.com http://www.deja.com/
!> Before you buy.
Tom Gutman
news:840n7q$6km$3...@front1.grolier.fr...
> >Steen S. Schmidt escribió:
> >>It's not a bug. SIGN(0) _is_ undefined. SIGN(0.)=0. is kept for
> >>compatibility with the HP48.
> >Defining the SIGN(x) function as being 0 when x is 0 seems to me a very
> >good and logical definition, and so has been in every calculator and
> >programming language I have used.
>
>
undefined,
> it doesn't give a default value.
Does so. There is even a long discussion somewhere about why they chose to
make 0^0 result in 1.
>
> As always, the choice of zero for
> sign(zero) could be discussed, and I'm sure different people would have
> different excellent reasons to choose another value than zero in this
> case... For example, Maple thinks that sign(0) is 1 [comment: I'm not sure
> this is the right function to use, there is also a signum(0) function that
> returns an unspecified result by default.], and the TIs evaluate
> sign(0) to itself (not undef).
>
> Homer Simpson
> http://zap.to/hsimpson
>
>
>
>
For real numbers, sign(x) is typically defined as -1, 0, or +1, depending on
whether the number is negative, zero, or positive (corresponding to the
three subsets defined for ordering). For complex numbers (which are not
ordered) is is commonly defined as x/|x|, which is undefined at zero. Even
for this case, I expect that the case for making sign(0)=0 is at least as
strong as the case for 0^0=1 (which I personally find unconvincing).
>
>
--
Tom Gutman
Tom Gutman
"Rafael Millán" <.> wrote in message
news:841d8c$j2l...@SGI3651ef0.iddeo.es...
>
> >The reason SIGN(0)=? is that Derive (and other CAS packages) consider
> >the sign of 0 to be "indeterminate". Some return NaN (Not-a-Number),
> >and others return +/-1 (which, I guess, means that the answer could be
> >either +1 or -1 depending on which direction you came from to get to
> the
> >0, perhaps?). This is because SIGN(x) is defined as x/ABS(x), and 0/0
> >is of course indeterminate.
>
> can imagine no bad consequence (mathematical or computational) derived
> from using this definition. In any case, the definition ought to be the
> same for reals and integers.
In the case of real numbers, that is commonly done. But with complex
numbers the sign function effectively a direction, and that is undefined for
0 (ARG(0)). There is actually a discontinuity at zero, so the use of a zero
value is less clear.
>
>
>
> >Replace SIGN in 'EGYPT' with NOT NOT and the program will work in all
> >ROM versions.
>
> I replaced SIGN with 0 \=/ several days ago. While they decide what kind
> of thing is SIGN(0), I wanted to play with these fractions
> (fascinating!)
>
>
>
--
Tom Gutman