Why this result of (haxor-exact->inexact 0), just curious, does the RNRS dictate this?
(define (haxor-exact->inexact n) (* n 1.0))
(haxor-exact->inexact -1) => -1*.* (haxor-exact->inexact 0) => 0 (haxor-exact->inexact 1) => 1*.*
Afficher les réponses par date
On 03/07/2014 10:11 AM, Mikael wrote:
Why this result of (haxor-exact->inexact 0), just curious, does the RNRS dictate this?
No. But it allows it.
The explanation starts with: exact zero times any exact number is exact 0.
So if 1. (inexact 1) is the result of some computation X that returns a number with some uncertainty, the uncertainty doesn't matter---if X is changed to compute the result exactly, then exact 0 times that exact result will be exact 0, no matter what the result is.
Brad
On Fri, Mar 7, 2014 at 4:11 PM, Mikael mikael.rcv@gmail.com wrote:
Why this result of (haxor-exact->inexact 0), just curious, does the RNRS dictate this?
In addition to what Bradley wrote, returning exact 0 is more in the spirit of scheme.
High quality implementations will return exact answer when possible. Another example is the square root of an exact square: try (sqrt 4) in various implementations, or (sin 0), or other special angles.
This behaviour is not mandated, to allow for implementations caring more about sped than exactness.
Cheers P.
On 03/07/2014 10:53 AM, Pierpaolo Bernardi wrote:
High quality implementations will return exact answer when possible. Another example is the square root of an exact square: try (sqrt 4) in various implementations, or (sin 0), or other special angles.
Try (sqrt +2i) or (expt -1 1/3) in Gambit ;-).
Brad
On Fri, 07 Mar 2014 10:54:58 EST Bradley Lucier lucier@math.purdue.edu wrote:
On 03/07/2014 10:53 AM, Pierpaolo Bernardi wrote:
High quality implementations will return exact answer when possible. Another example is the square root of an exact square: try (sqrt 4) in various implementations, or (sin 0), or other special angles.
Try (sqrt +2i) or (expt -1 1/3) in Gambit ;-).
Shouldn't it return all the roots? :-)
Been meaning to ask:
(expt +nan.0 0)
1
(expt 1 +nan.0)
+nan.0
This seems to be at least inconsistent. Seems to me both should return 1
(expt nan 0.0)
+nan.0
(expt 1.0 nan)
+nan.0
These seem fine.
But I am not a mathematician.
Ah noted, nice point.
2014-03-07 16:53 GMT+01:00 Pierpaolo Bernardi olopierpa@gmail.com:
On Fri, Mar 7, 2014 at 4:11 PM, Mikael mikael.rcv@gmail.com wrote:
Why this result of (haxor-exact->inexact 0), just curious, does the RNRS dictate this?
In addition to what Bradley wrote, returning exact 0 is more in the spirit of scheme.
High quality implementations will return exact answer when possible. Another example is the square root of an exact square: try (sqrt 4) in various implementations, or (sin 0), or other special angles.
This behaviour is not mandated, to allow for implementations caring more about sped than exactness.
Cheers P.