Re: pi seems not to be a constant

     [8]> (type-of *one-def*)
     LONG-FLOAT
     [9]> (type-of *one-100*)
     LONG-FLOAT
     [10]>
     This is another non-conformity. clhs eql:
     The value of eql is true of two objects, x and y, in the folowing cases:
     1. If x and y are eq.
     2. If x and y are both numbers of the same type and the same value.
     3. If they are both characters that represent the same character.
     Otherwise the value of eql is false.

It seems the best solution to this problem would be to
add to clisp the typespec (long-float precision) which would be a
recognizable subtype of long-float, and have type-of return that.
I suspect this is not very difficult.
This is independent of all other discussions in this thread.
It's purely a fix of current clisp which increases conformity and also
is useful for more accurately finding the type of a value.
(You agree?)

    > I don't understand why you think pi should be the best approximation
    > available with long-float-digits digits.
    > The spec says the best long approximation.
    > This is only satisfied by whatever is the maximum allowed value of
    > long-float-digits and nobody (in his right mind) wants to use that.

   But you cannot guess in advance what will be the maximum used by a

I don't see what the maximum used by a program has to do with this.

   program!  The maximum allowed propably fills the RAM.

That's why nobody would want to use it.

    > Given that the image contains values of aribtrarily many different
    > precisions, why should pi contain this one rather than any of the
    > others?  I think it should contain the original one and that should
    > simply be the local clisp definition of pi.

   Because CL:PI is meant to represent <pi> and any value with less
   precision than the maximum allowed will be a DIFFERENT value, not
   representing <pi>

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.
Once that is recognized, why would you consider one non-compliant
approximation to be better than any other ?
If we just leave it at the initial value and make that defconstant
then at least one point of compliance is restored, without introducing
any others.

   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)
- 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*
- I want to remove (long-float-digits) and its setf
- I want pi and the other similar constants to be defconstant
  keeping their initial values.
- 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.

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.

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.

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