Anonymous | Login | 01-16-2021 15:06 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0006719 | [Squeak] Kernel | minor | always | 10-10-07 20:32 | 04-18-10 22:04 | ||||
Reporter | nicolas cellier | View Status | public | ||||||
Assigned To | nicolas cellier | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.10 | ||||||
Summary | 0006719: Float nan comparison is broken | ||||||||
Description |
IEEE 754 state that NaN cannot be compared (ordered) Thus every comparison message involving a NaN SHOULD return false. This is not the case for example of: Float nan >= 2 Which is true, and should be false... |
||||||||
Additional Information |
In old versions when NaN were not in the image, Float used to be a fully ordered set and as such were a good subclass of Magnitude. With NaN inside, this is not the case anymore. This is breaking original st80 logic. I would prefer converting Float nan to some NaN instance. A class that would of course not even be a kindOf: Number as the name tells (Not A Number). |
||||||||
Attached Files |
![]() ![]() ![]() |
||||||||
|
![]() |
||||||
|
![]() |
|
(0011290 - 147 - 159 - 159 - 159 - 159 - 159) nicolas cellier 10-10-07 22:07 |
Mea culpa: one comparison operator should return true. This is the ~= test. So please forget FloatNan-Compare-M6719-Test.1.cs and load version 2. |
(0012889 - 125 - 131 - 131 - 241 - 241 - 241) nicolas cellier 01-04-09 20:11 |
I have some in-image correction to propose, but that will not fully solve the problem... The VM must also be corrected 0007260 |
(0012897 - 695 - 794 - 794 - 1164 - 1164 - 1164) nicolas cellier 01-04-09 23:20 |
A) Magnitude assumes subclass are fully ordered sets B) Number is a partially ordered set due to nan Thus Number is not a well behaved Magnitude... Either we relax Magnitude assumption, by changing definition of <= and >=, Or we implement > >= <= in Number or its subclasses to avoid the nan mess. I propose to adopt second solution, based on 0003374, that is based on exact number comparison. If you don't like 0003374 , simply replace adpatToXXX:andCompare: with adpatToXXX:andSend: Note that VW does encounter the problem with Point comparison. In Squeak too, but we should better forbid such comparison see 0007259 And please, don't forget that a new VM is also needed ( 0007260 ) |
(0012898 - 209 - 269 - 269 - 269 - 269 - 269) nicolas cellier 01-04-09 23:21 |
"fix begin" Installer mantis ensureFix: 3374. Installer mantis bug: 6719 fix:'M6719-FloatNaNCompare-Patch-nice.1.cs'. "fix test" Installer mantis bug: 6719 fix:'FloatNaNCompare-M6719-Test.2.cs'. "fix end" |
(0012901 - 140 - 196 - 196 - 196 - 196 - 196) nicolas cellier 01-04-09 23:33 |
Note that another solution would be to test argument isNumber ifFalse: [^false] for every comparison (< <= > >=), a l'instar de #= |
(0013352 - 179 - 191 - 341 - 432 - 432 - 432) nicolas cellier 10-05-09 19:25 |
Fixed in http://source.squeak.org/trunk/Kernel-nice.250.mcz [^] Note: the fix does not include 0003374 by now. This will be an independent decision (I will strongly support of course) |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
81 total queries executed. 49 unique queries executed. |