Add exact and inexact to cptypes

[gus-massa]

And a few related changes ...

---

Add exact and inexact to cptypes

This is the main part, it has a few subparts inside the same commit:

• Add inexact to cptypes: The old implementation of real->flonum calls inexact and this goes in the "wrong" direction of detail level, and it cause a problem when I add inexact to cptypes (or perhaps when I add inexact to cpprim). So I added a new function $real->flonum to 5_3.ss

• Add exact to cptypes: The problem is that exact is not total, and the domain is unusual, so it can't be converted to the unsafe version automatically, so I added a special case. An alternative is to add a new type complex-rational to primvars.ms and then change the signature to (exact? [sig [(complex-rational) -> (boolean)]] ...). (Side note: Also, the handle has a special case to collaborate with zero? that is where I notice the problem of moving stuff from the tail position to non-tail.)

• Replace $value with fl+: This is an experimental idea. I'd like to add in the future a few fl+ here and there so later np-unbox-fp-vars! can unbox more flonums. I'm not sure when it's a good idea to add new fl+, but replacing some $value with fl+ looks like a win.

---

Reverse arguments of $real->flonum

Rename in library real-flonum to $real-flonum because it has two arguments like the primitive with the same name.

Also, in all (most?) of the other cases, who is the first argument. I'm not sure if it's necessary to keep backward compatibility at with the system functions.

Both changes are just cosmetic, but they make the code more consistent.

---

Add exact and inexact to cpprim

I'm not very happy with this third part. There is too little work to do and it may increase the executable file size without increasing speed. Perhaps inexact is interesting but exact has too few possible improvements unless I add a lot of code to cpprim.

(The boot files have probably only a stub for the increase of items in the library, without the implementation.)

[mflatt]

The first two commits look good as far as I can tell. I have some suggestions for the third commit.

[mflatt]

This seems like too much code duplication. Add a build-exact->inexact parameterized over the library entry to call?

[gus-massa]

The (small) problem is that build-libcall is a macro that expect an not-quoted version of the name of the library call. So build-exact->inexact must be a macro too.

[mflatt]

Or pass in a function like(lambda (e-x) (build-libcall #t src sexpr inexact e-x)). I'd say the goal isn't to avoid every bit of duplication, but to get most of it.

[mflatt]

I share your reluctance about these. Maybe if they included conversion from integer flonums that are small enough to fit into a fixnum? Otherwise, I'd be inclined to leave them out until motivated by a use.

[gus-massa]

Something like (copiying from #2%flonum->fixnum)

,(build-and
                            (build-fl< e-x `(quote ,(constant too-positive-flonum-for-fixnum)))
                            (build-fl< `(quote ,(constant too-negative-flonum-for-fixnum)) e-x))

I'll try tomorrow, because I prefer to see the code to think about it, but I'm still not sure.

[gus-massa]

The code should check that it's an integer flonum. flonum->fixnum just truncates the value. To check that one possibility is to look if the exponent is big enough, but that will detect only very big flonums, bigger than ~2^54 that are not very interesting (and I'm missing 0.0 and inf.0). It looks too hard to do something interesting with fast code.

I'll try to add the most interesting cases to cptypes instead.

[gus-massa]

By the way, in primdata.ss there is a primitive

($flonum->fixnum [flags single-valued])

that is unused.