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).

Since we can have both, we don't have to argue about that.


  > > 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.

I've read clhs.  I don't see where it says this is the only use.

  > 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.
A symbol denoting a variable IS a form.

  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.
First, let is not the only binding form - how about progv.
Second, you can view what I'm doing as compile time.
I'm planning to tell the user I don't understand his input
cause I don't recognize pi as a variable.
And finally, there won't be an error at run time unless 'pi 
is constantp.

  > > 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.

But no subtype is needed in order to do that.
Just declare pi as defconstant as it is.
It will always be the same long float.  When you want a different
precision pi you can use (ext:pi) for the current long-float-digits
or (ext:pi ndigits) for some other precision.

  > 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.

Right, (read-from-string "2.1l0") would not be constantp.
However pi would be.

  > 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.

What exactly is this problem?
I see no problem if pi is a defconstant with the value
that it would have before long-float-digits ever changes.

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