(* n 1.0) works as an exact->inexact for all integer n:s except for 0, is that intended?
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*.*
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.
participants (4)
-
Bakul Shah -
Bradley Lucier -
Mikael -
Pierpaolo Bernardi