I wrote:
> Having looked more closely, I see now that our 'string->number' is also
> less precise than it should be.
Sorry, I was mistaken about this. Our 'string->number' is fine.
Mark
I wrote:
> Sorry, this is due to an inadequate 'number->string' implementation in
> Guile.
Having looked more closely, I see now that our 'string->number' is also
less precise than it should be. I'll fix these issues soon.
Mark
Hengqing Hu writes:
> The following behavior is observed on both guile 1.8 and guile 2.0.
> Is it correct?
> Can somebody elaborate why it happens?
>
> guile> (atan 0 -1)
> 3.14159265358979
> guile> (= 3.14159265358979 3.14159265358979)
> #t
> guile> (= (atan 0 -1) 3.14159265358979)
> #f
Sorry, t
On Thu, Jan 31, 2013 at 9:50 AM, John Darrington <
j...@darrington.wattle.id.au> wrote:
>
> pi is an irrational number. You would need an infinite number of digits
> wouldn't you?
>
Good point :-). All I meant was enough digits that it parsed as the same
floating-point number that (atan 0 -1) re
On Thu, Jan 31, 2013 at 08:32:53AM -0500, Noah Lavine wrote:
What you have here is a precision problem.
scheme@(guile-user)> (= 3.14159265358979 (atan 0 -1))
$8 = #f
scheme@(guile-user)> (= $7 (atan 0 -1))
$9 = #t
It might be possible to have Guile print mo
What you have here is a precision problem.
When a floating-point number like pi is printed, I don't think you can
guarantee that the string representation will be read in the same way it
was read out. So when guile reads "3.14159265358979", it gives you some
floating point number that is *close to
Dear list,
The following behavior is observed on both guile 1.8 and guile 2.0.
Is it correct?
Can somebody elaborate why it happens?
guile> (atan 0 -1)
3.14159265358979
guile> (= 3.14159265358979 3.14159265358979)
#t
guile> (= (atan 0 -1) 3.14159265358979)
#f
--
Best Regards, Hengqing Hu
