Ticket #0001717

Summary	Method of handling infinity
Description	Good -- it is possible to create a valid decimal! of +/-INF using a trick with pair! a: as-pair 1e300 -1e300 == 1.#INFx-1.#INF type? a/1 == decimal! Good -- -INF and +INF will compare correctly: a/1 = a/1 == true a/2 = a/2 == true Bad -- INF pairs are not comparable: a = a == false ;; normal equals b: array/initial 100 a length? unique b == 100 ;; UNIQUE equals Bad -- no obvious way to serialise and reload an INF do mold first a Syntax error: invalid "integer" -- "1.#INF" Where: to case load -apply- do Near: (line 1) 1.#INF Bad -- no other obvious way of creating an INF: 1e99999 Math error: math or number overflow
Example code

Assigned to	n/a	Fixed in	-	Last Update	10-Nov-2010 10:58

Comments
(0002660) meijeru 26-Oct-2010 12:46	Ticket #1029 addresses the same subject (via 32 bit vectors). It also contains a comment on the molding of infinite (do we like "1.#INF" ?) and on the absence of "not a number" or NaN.
(0002676) BrianH 27-Oct-2010 00:51	I like the trigger-an-error method of dealing with Inf and NaN.
(0002683) Carl 27-Oct-2010 07:54	We should get this figured out. I'm a bit surprised anything worked on it above.
(0002819) Sunanda 10-Nov-2010 10:58	Another reason to normalise the behaviour of #INF random 1e30x1e30 == 0x0

Date	User	Field	Action	Change
10-Nov-2010 10:58	sunanda	Comment : 0002819	Added	-
27-Oct-2010 07:54	carl	Comment : 0002683	Added	-
27-Oct-2010 00:51	BrianH	Comment : 0002676	Added	-
26-Oct-2010 20:04	carl	Summary	Modified	Infinity handling is inconsisent => Method of handling infinity
26-Oct-2010 20:03	carl	Description	Modified	-
26-Oct-2010 20:03	carl	Status	Modified	submitted => reviewed
26-Oct-2010 12:46	meijeru	Comment : 0002660	Added	-
26-Oct-2010 11:04	sunanda	Ticket	Added	-