Anonymous | Login | 12-13-2019 05:09 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 | |||||||
0003380 | [Squeak] Kernel | minor | always | 03-29-06 01:28 | 05-05-06 22:10 | |||||||
Reporter | nicolas cellier | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | open | |||||||||
Status | new | Product Version | 3.9 | |||||||||
Summary | 0003380: Interval hash/Equal problem | |||||||||||
Description |
The never ending story of hash equal problems: (1 to: 3) = #(1 2 3). "is true" (1 to: 3) hash = #(1 2 3) hash. "is false" This does break Set behaviour: self assert: ((Set new: 4) add: (2 to: 4 by: 2); add: #(2 4); size) = ((Set new: 5) add: (2 to: 4 by: 2); add: #(2 4); size) |
|||||||||||
Additional Information |
Efficient Interval hash should fall back to slow super hash... why ? because they have same species as Array... and thus compare to true with Array. Maybe all SequenceableCollection hash should be refactored, because they hash each and every element, which might be a slow on big collections. There is a balance between fast hash code computation / slow Set access because of hash code collision. |
|||||||||||
Attached Files | ||||||||||||
|
![]() |
|
(0004884 - 29 - 41 - 41 - 126 - 126 - 126) nicolas cellier 05-05-06 22:10 edited on: 04-30-07 19:07 |
This bug is solved at 0003488 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
40 total queries executed. 29 unique queries executed. |