Yeah. Speed probably goes the other way. Accuracy is another issue.
On 1/6/09, Luc Maisonobe wrote:
> Phil Steitz a écrit :
>
>> Committed in r731822. I noticed one more thing that I just commented
>> for now in the code. It might be faster and/or more accurate to use a
>> solver to compute the
Phil Steitz a écrit :
> Committed in r731822. I noticed one more thing that I just commented
> for now in the code. It might be faster and/or more accurate to use a
> solver to compute the nth root of the modulus. Should we consider doing
> this and exposing the associated real function in Math
Phil Steitz wrote:
Luc Maisonobe wrote:
Phil Steitz a écrit :
Ted Dunning wrote:
I just check on how sbcl handles this. The result was mixed, but
instructive as predicted.
Positive and negative infinity behave as expected.
** (/ 1 0.0)
#.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
* (/ -1
Luc Maisonobe wrote:
Phil Steitz a écrit :
Ted Dunning wrote:
I just check on how sbcl handles this. The result was mixed, but
instructive as predicted.
Positive and negative infinity behave as expected.
** (/ 1 0.0)
#.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
* (/ -1 0.0)
*
***#.SB-EXT
Phil Steitz a écrit :
> Ted Dunning wrote:
>> I just check on how sbcl handles this. The result was mixed, but
>> instructive as predicted.
>>
>> Positive and negative infinity behave as expected.
>>
>> ** (/ 1 0.0)
>> #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
>>
>> * (/ -1 0.0)
>> *
>> ***#.SB-EXT:
Ted Dunning wrote:
I just check on how sbcl handles this. The result was mixed, but
instructive as predicted.
Positive and negative infinity behave as expected.
** (/ 1 0.0)
#.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
* (/ -1 0.0)
*
***#.SB-EXT:SINGLE-FLOAT-NEGATIVE-INFINITY
*
Square roots of ne
I just check on how sbcl handles this. The result was mixed, but
instructive as predicted.
Positive and negative infinity behave as expected.
** (/ 1 0.0)
#.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
* (/ -1 0.0)
*
***#.SB-EXT:SINGLE-FLOAT-NEGATIVE-INFINITY
*
Square roots of negative infinity work
I think that (2) is the easiest for a user to understand. Obviously, the
documentation aspect of (1) should be brought along.
The behavior of Common Lisp is always instructive in these regards. The
complex arithmetic was generally very well thought out.
On Fri, Jan 2, 2009 at 7:14 PM, Phil Stei
Phil Steitz wrote:
Phil Steitz wrote:
Thanks, Bernhard for the contribution in MATH-236. I would like to
suggest a couple of improvements.
First, I think the return type should be List, not Collection, as
there is an order to the elements in the returned collection (as
stated in the API doc
Phil Steitz wrote:
Thanks, Bernhard for the contribution in MATH-236. I would like to
suggest a couple of improvements.
First, I think the return type should be List, not Collection, as
there is an order to the elements in the returned collection (as
stated in the API doc, the order is by in
+1 sounds good :)
Phil Steitz schrieb:
> Thanks, Bernhard for the contribution in MATH-236. I would like to
> suggest a couple of improvements.
>
> First, I think the return type should be List, not Collection, as there
> is an order to the elements in the returned collection (as stated in the
Thanks, Bernhard for the contribution in MATH-236. I would like to
suggest a couple of improvements.
First, I think the return type should be List, not Collection, as there
is an order to the elements in the returned collection (as stated in the
API doc, the order is by increasing argument).
12 matches
Mail list logo