This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.
Source for ticket #313
cc
changetime
2012-02-26 19:47:05
component
WG1 - Core
description
We allow "an implementation violation" for inexact non-real to exact,
since implementations may not support ratios, but require implementations
to support both exact and inexact complex. This may be too strong a
requirement.
id
313
keywords
milestone
owner
alexshinn
priority
major
reporter
alexshinn
resolution
invalid
severity
status
closed
summary
inexact->exact and exact->inexact on complex numbers
time
2011-12-17 11:54:21
type
defect
Changes
Change at time 2012-02-26 19:47:05
author
alexshinn
field
comment
newvalue
On re-reading the text, I think it can be inferred that the disclaimer
{{{
If an exact argument has no reasonably close inexact equivalent, then a violation of an implementation restriction may be reported.
}}}
also applies to complex numbers, despite the preceding statement
{{{
For exact complex numbers, the result is a complex number whose real and imaginary parts are the result of applying exact-> inexact to the real and imaginary parts of the argument, respectively.
}}}
so there doesn't seem to be anything to change here, except
potentially as an editorial clarification if someone comes up
with better wording.
oldvalue
2
raw-time
1330256825315075
ticket
313
time
2012-02-26 19:47:05
Change at time 2012-02-26 19:47:05
author
alexshinn
field
resolution
newvalue
invalid
oldvalue
raw-time
1330256825315075
ticket
313
time
2012-02-26 19:47:05
Change at time 2012-02-26 19:47:05
author
alexshinn
field
status
newvalue
closed
oldvalue
new
raw-time
1330256825315075
ticket
313
time
2012-02-26 19:47:05
Change at time 2011-12-18 01:19:40
author
cowan
field
comment
newvalue
I agree; we should allow an implementation to support not having exact complex numbers.
oldvalue
1
raw-time
1324142380672687
ticket
313
time
2011-12-18 01:19:40