Re: pi seems not to be a constant

On 19/10/15 08:33, Don Cohen wrote:
> Pascal J. Bourguignon writes:
>
>   > It seems to me that (typep cl:pi 'long-float)
>   > is more important to maintain than (constantp 'cl:pi).
>
> If you leave pi with its original value this remains true:
> (defconstant pi2 pi)
> (setf (ext:long-float-digits) 128)
> (typep pi2 'long-float) => T

Yes, and this is what I mean; the opposite option being 
ext:variable-precision-long-float as subtype of float distinct from the 
other subtypes, and (typep cl:pi 'ext:variable-precision-long-float)
and therefore (not (typep cl:pi 'long-float)).  This would be bad.


>
>   > a conforming library would work correctly when
>   > processing an expression containing cl:pi with constantp returning NIL
>   > (and therefore, not "inlining" cl:pi,
> That's not the only use of constantp.
Sure, this is what it means. Read clhs constantp.
> Don't you think a conforming library might count on constantp to tell
> it what symbols not to accept as variables to be bound?  And if pi
> were allowed to be bound, say, to some non-number, don't you think
> some sort of non-conforming behavior might result?

Nope, constantp applies on a form, not a symbol denoting a variable.  It 
is useless to call it before a let, because let is source code that 
would detect the error at compilation time, while constantp is a 
run-time function.

   (if (constantp 'cl:pi)
     (let ((mypi 3))
       (f mypi))
     (let ((cl:pi 3))
       (f cl:pi)))

is dumb. (And using #. wouldn't make it less dumb).

>
>   > Therefore in my opinion, it's better to have constantp return nil for a
>   > non-constant cl:pi, since while it's nominaly non-conforming, allows
>   > more conforming programs to continue working correctly, and since it's
>   > much less complex than adding a fifth float subtype.
>
> I don't see why any such additional subtype is needed.

Because that would allow us to leave cl:pi alone, binding it as a 
defconstant to a value that wouldn't change.

> Perhaps I'm missing something.  Other than recomputing a lot of
> constants that I don't think should be changed, what does setting
> ext:long-float-digits do?  My impression was that it affected the
> result of READing a long float.  Once the value is read, its precision
> is fixed, right?  Changing long-float-digits doesn't affect it.
Yes. But you could re-read it.

>
> So continuing my previous example, now that we have 64 bit pi2 and
> 128 bit pi, I get
>   (+ 1 pi) => 4.14159265358979323846264338327950288418L0
>   (+ 1 pi2) => 4.1415926535897932383L0
> You might view these as values of two different subtypes of
> long-float, namely 64-bit and 128-bit long floats, but type-of
> returns long-float in both cases.
>
>
That's a good way to see them, but it doesn't help with the constant 
long-float pi problem.
But this gives me an idea for another solution:

   cl:pi --> #.ext:π
   (typep ext:π) --> long-float
   ext:π --> #.ext:π


That is, bind cl:pi to a symbolic object of type long-float, which, when 
*used* in arithmetic operations would evaluate to the value of π in the 
current subtype of long-float.

   cl:pi --> #.ext:π
ext:π --> #.ext:π
   (+ 1 pi) --> 4.1415926535897932383L0

   (setf (ext:long-float-digits) 128)
   (+ 1 pi) --> 4.14159265358979323846264338327950288418L0



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


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