Hello Juergen, Elias,
I think there are still three flies in the "complex number display"
ointment. Please see the attached tar file containing a APL test file
and a log file generated from it using GnuAPL svn 279. Only one of the
4 complex numbers entered in polar form and that have a zero real part
is displayed with a 0 for the real part. The remaining 3 numbers
display with a real part having a E¯16 scale factor. For these 3
numbers, the real part magnitude is definitely 10 orders of magnitude
less than the imaginary part magnitude and should display with a 0 for
the real part.Regards, Fred On Tue, 2014-05-20 at 18:09 +0200, Juergen Sauermann wrote: > Hi Fred, Elias, > > fixed in SVN 279. > > I dared to print the (non-zero) imaginary part even if the standard > tells otherwise. > > /// Jürgen > > > On 05/20/2014 07:35 AM, Frederick H. Pitts wrote: > > Elias, > > > > The part before the "Then:" states the obvious. Numeric output > > conversion converts numbers in internal format (implementation-defined)) > > to external literal decimal format. > > > > The part after the "Then:" is totally bogus. What is the point of > > performing complex number calculations and then summarily throwing away > > the imaginary part? The imaginary part could be the part the user is > > interested in. > > > > Sincerely, I do not see anything here that legitimately contradicts the > > descriptions cited in the IBM APL2 Language Reference. The IBM document > > says 1) display the real part as 0 if the real part magnitude is ⎕PP > > orders of magnitude less than the imaginary part magnitude and 2) > > suppress the display imaginary part if its magnitude is ⎕PP orders of > > magnitude less than the real part. The exception is when ⎕PP is at > > maximum; then both parts are displayed at full precision. > > > > Regards, > > > > Fred > > > > On Tue, 2014-05-20 at 12:47 +0800, Elias Mårtenson wrote: > >> ISO/IEC 13751:2000 seems to give an implementation lots of flexibility > >> here. > >> > >> > >> I'm honestly not sure how to interpret this. Section 15.2.2 says: > >> > >> > >> Informal Description: Numeric output conversion converts > >> numeric values represented as numbers—numeric quantities whose > >> format is implementation-defined—into the same numeric > >> quantities represented in decimal notation as lists of > >> characters. > >> > >> > >> Then: > >> > >> > >> Note: Any imaginary-part of the numeric input to > >> Numeric-Output-Conversion is simply ignored; only the > >> real-part of a complex-number is used. > >> > >> > >> Regards, > >> Elias > >> > >> > >> On 20 May 2014 12:24, Frederick H. Pitts <fred.pi...@comcast.net> > >> wrote: > >> Juergen, > >> > >> Under "Display of Complex Numbers:" on page 13 of the > >> "APL2 > >> Programming: Language reference", the document says: > >> > >> "In J notation, the real or imaginary part is not > >> displayed if it is > >> less than the other by more than ⎕PP orders of magnitude > >> (unless ⎕PP is > >> at its maximum)". > >> > >> In SVN 268, neither of the presented examples work. > >> The smaller > >> magnitude part is not zeroed if its the real part or > >> suppressed if its > >> the imaginary part. > >> > >> In addition, complex numbers entered in polar notation > >> as described at > >> the top page 12 do not display correctly per the description > >> on page 13. > >> 1D90 and 1R1.5707963267948965 should display as 0J1 assuming > >> ⎕PP is less > >> than maximum. Currently the real part is displayed as some > >> number times > >> 10 to the -16 power, i.e. zero for all intents and purposes. > >> > >> Regards, > >> > >> Fred > >> Retired Chemical Engineer > >> > >> > >> > >> > > > > > > >
COMPLEX.tar.gz
Description: application/compressed-tar
