Number: 1290

Date:  1-Jun-84 12':57':03

Submitter: Sannella.PA

Source: Farrell.pa

Subject: Arithmetic should not bomb on negative zeros 

Assigned To: JonL

Attn: Release

Status: Fixed

In/By: 

Problem Type: Bug

Impact: Serious

Difficulty: Easy

Frequency: Everytime

Priority: Hopefully

System: Language Support

Subsystem: Arithmetic

Machine: 1132

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["JonL.pa" "23-Sep-84 21':36':11" Subject': Assigned% To': Attn': Status':(Open->Fixed)]'
["JonL.pa" "23-Sep-84 22':11':43" Source': Description':]'
["JonL.pa" "24-Sep-84 04':19':57" Description':]'
["JonL.pa" "24-Sep-84 04':28':08" Disposition': Description': Edit-Date':]

Description: '
Date': 15 May 84 19':18 PDT'
Sender': Farrell.pa'
Subject': Lisp': death under elt specific to Dorado.'
To': Jonl'
From':Nuyens'
cc': Farrell.pa'
Lisp-System-Date':  9-Apr-84 18':28':19'
Machine-Type': Dorado'
'
Hi,'
  ELT is blowing up under \convert.floating.number on an analysis that Joyce is doing.  It only dies on the Dorado though.  The function that will blow is GAUSS in <farrell>lisp>filter.  Right now I am running it interpreted but Joyce says it blew up compiled as well.  I have to go.  Is there any chance you could look at this for her?  I don''t know if it is our bug or hers, but the recovery isn''t spectacular in any case.  '
'
Greg'
'
Date': 18 May 84 01':21 PDT'
From': JonL.pa'
Subject': Arithmetic SHOWSTOPPER!!'
To': Sannella, Raim.pasa'
cc': Sheil,JonL, vanMelle, LispSupport'
'
Three horrible bugs have come to my attention in the past two days, whose combined weight almost force a new loadup for Carol.  Focus is in LLFLOAT and AARITH files.'
'
Summary, with more explanation postscripted':'
'
1) FEQP''s shortsightedness causes fatal lossage to some users.  Emended FEQP in new version of LLFLOAT.'
'
...'
1) Some code, in particular \CONVERT.FLOATING.NUMBER, dies because FEQP fails to reply "yes" to negative zeros; thus thinking that the mantissa isn''t zero, it extracts these bits and ELT''s and QUOTIENT''s away, leading to a lossage that''s "hard to look at", since an attempt to print negative zero never succeeds.  These oddballs are legit IEEE-format items, but we haven''t seen many of them yet; apparently this has been around forever, but its symptoms were not diagnosed before.  It''s primarily of importance to the Dorado, since Taft''s ucode for floating multiply generates these oddballs more liberally than Bill and I would have supposed necessary.   Yet it caused a *fatal* death to Joyce Farrell yesterday. '
'
'
Date': 16 May 84 16':26 PDT'
From': JonL.pa'
Subject': IEEE "negative zeros" and infinities '
To': vanMelle'
cc': LispCore↑'
'
It turns out that Taft''s ucode for floating multiplication will ocasionally produce a "negative zero" (I''ve submitted an AR on a certain bug this causes).  I think this is an acceptable IEEE format, and it does have its purposes.  Some discussion on "negative zero" took place in the Cmomon Lisp community recently -- mostly about the hardware treatment of them and the programming levels at which one wants to distinguish them.'
'
Could we support them -- i.e., both "negative zeros" and the two infinities?   I''d imagine that we would initially generate a negative zero only in the floating-point underflow case, where the \UNDERFLOW flg could specify to produce a signed zero rather than error out or returning a mantissa-correct answer.  The sign of the zero would reflect the intended sign if the underflow hadn''t happened (of course, a negative zero would be produced when dividing any normal positive number by negative infinity, and vice versa for signs).'
'
Similar remarks apply about generating negative and positive infinities, although it looks as though the \OVERFLOW flg is being used for both floating-point overflow cases and integer overflow. '
'
Although negative zeros and infinities will propogate [i.e., (TIMES 3.4 <negative zero>) should yield <negative zero>],  many operations squelch these oddballs.  E.g. (PLUS <reasonablenumber> <signedZero>) should return <reasonablenumber>'
'
I''d propose to change FEQP and to check the various ucodes and UFNs for the 4 rational operations and for the GREATERP/LESSP comparisons, to be sure of the correct "propogations".  Additionally, functions like \MAKEFLOAT would have to be extended so as not to ignore the sign on zeros.   Since the generic ZEROP would wind up calling an FEQP equivalent, then this catches the common case of EQP testing.'
'
'
'
From': JonL'
Date': 23-Sep-84'
See also the now-defunct AR 1127'
'
'


Workaround: 

Test Case: 

Edit-By: JonL.pa

Edit-Date: 24-Sep-84 04':28':09