Adding Big-Float constructors for variable prec constants

[Izaakwltn]

This addresses issue #1013

I've renamed the existing sb-mpfr compatible Big-Float type to MPFR-Float type, and added a new Big-Float type with two constructors: (BFValue MPFR-Float) and (BFConst (:a -> MPFR-Float)).

This allows for constants to readjust to current precision.

[stylewarning]

This seems a little repetitive. How about something like

(define (mpfr-of bf)
  (match bf
    ((BFValue v) v)
    ((BFConst f) (f))))

With this, something like == would be:

(define (== a b)
  (== (mpfr-of a) (mpfr-of b)))

without all of the case analysis. Unary functions are easier:

(define (lift f x)
  (nest BFValue f mpfr-of x))

so you have

(define (sin x) (lift sin x))

Note that this approach does lead to some nonintuitive behavior. Some values are "privileged" while others are not. So something like

(define pi-1 (* 4 (atan 1))
(define pi-2  pi)

(set precision)

(== pi pi-2) ==> false

happens. I'm not sure if this is ok or not.

[eliaslfox]

I don't agree with this solution. It adds additional overhead to all bigfloat computations. Pi and E should be made methods so that they alone incur the overhead.

[Izaakwltn]

Would that be as simple as changing the class definitions from (:a) to (unit -> :a) and making sure it works for each type?

If so I can throw together that alternative.

[stylewarning]

the only "problem" with this, which may be minor, is that idk any programming language where something that looks like a constant is a function.

(* (* 4/3 (pi)) (^ r 3))

is just non-intuitive, since nobody would imagine pi to be a function or method, and there's no visual indication as such.

FWIW, I don't think big float speed will be dominated by the cost of a few extra pattern matches. With that said, there's definitely a more fundamental problem here.

[Izaakwltn]

Another option:

Have both pi & ee values and c-pi & c-ee compute methods.

This would allow big-floats to use c-pi & c-ee to recompute $\pi$ each time without disturbing the existing syntax. In addition, there may be future types that would benefit from having method constants.

[Izaakwltn]

I updated Big-Float according to the initial review