# [racket-dev] What are single flonums good for?

 From: Neil Toronto (neil.toronto at gmail.com) Date: Mon Sep 17 11:11:10 EDT 2012 Previous message: [racket-dev] What are single flonums good for? Next message: [racket-dev] What are single flonums good for? Messages sorted by: [date] [thread] [subject] [author]

```On 09/16/2012 04:10 PM, Matthias Felleisen wrote:
>
> Suppose we had started Racket long ago and maintained it until now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may need 128. (Actually there were machines in the past that did, but never mind.)
>
> Could we separate precision and type into separate dimensions so that we could state types like this:
>
>    ∀ p : precision. FP[p] -> FP[p]
>
> where we see FP as a type constructor that consumes a precision value to generate the right kind of type. This might be a dependent type but it could be a useful one. Of course, it isn't really a parametric form of polymorphism as Neil's functions show (and better still Vincent's rewrites).

80-bit, and then 128-bit flonums are inevitable.

After TR has type classes or something like them, this would work really
well. The C++ Boost libraries use templates to achieve something
similar. Functions with an FPU implementation (sin, exp, etc.) just
dispatch to the proper bare-metal function. Functions without an FPU
implementation (gamma, erf, etc.) also dispatch depending on precision,
but can share implementation details when the algorithms are similar.
(Example: the gamma function uses a different Lanczos polynomial for
each precision, but always uses it in the same way.) Compositions of
either kind are fully polymorphic.

Neil ⊥

```

 Posted on the dev mailing list. Previous message: [racket-dev] What are single flonums good for? Next message: [racket-dev] What are single flonums good for? Messages sorted by: [date] [thread] [subject] [author]