Re: pi seems not to be a constant

On 21/10/15 21:16, Don Cohen wrote:
>       
> But this argument is the one that requires us to fill RAM with that
> one best approximation.
> Clearly we have to give up compliance on the point of pi being the
> best approximation the implementation can provide.

Not necessarily. I gave you a way to do it without losing compliance.
>
>     I don't know what YOU want either.
>     Introducing variable precision long-float as it's done is clearly
>     bringing a lot of non-conformities, and having (not (constantp
>     'pi)) is the most benign of them.
>
> - I want the special variable *long-float-digits* to control the
>    precision of long floats created by READ.
>    (BTW (let ((*long-float-digits* n))(read-from-string "1l0"))
>    would now be the way to get constants of precision n)
or as you suggested, (coerce 1l0 `(long-float ,n)).
> - I want (pi &optional precision) and similar functions for other
>    constants to compute values of the given precision, with the
>    default value of precision being *long-float-digits*
agreed.
> - I want to remove (long-float-digits) and its setf
We may keep it for legacy compatibility.
> - I want pi and the other similar constants to be defconstant
>    keeping their initial values.
Then you need an abstract value ext:π that provides a different 
precision depending on *long-float-digits*
It's not a symbol macro, because:

    (defconstant cl:pi #S(ext:π))
    cl:pi --> #S(ext:π)
    (+ 0 cl:pi) --> 3.141592l0

Actually, #S(ext:π) might print as #S(ext:π) only when *print-readably* 
is true, and could print as the current approximation of π when 
*print-readably* is false.  (then we can't use ext:π since that's the 
syntax for a symbol, or #<ext:π> since that's an unreadable syntax, 
hence #S(ext:π)).

> - I'd now add to my wish list the type spec (long-float precision)
>    with type-of returning those types for long floats and subtypep
>    recognizing those types as subtype of long-float.
yes.

> I think my proposal makes it much more practical to use different
> precisions in different pieces of code, including in different
> threads.
> (BTW I consider this much more valuable than (constantp 'pi).)
> I think my proposal reduces non-conformance without introducing
> any more non-conformance.
> In fact the only remaining non-conformance I see is that
> - pi is not (and never was!) the best available approximation
> - most-positive-long-float is not (and never was) the most positive
>    long float
> etc. for other defconstants.
We could introduce similarly #S(ext:most-positive-long-float) etc, ie. 
symbolic numbers.
> However all of this non-conformance at least appears only in
> programs that change *long-float-digits*.
>
> I admit this will be incompatible with some existing code.
> Perhaps some accomodation can be made to support such code.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com/


------------------------------------------------------------------------------
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list