On Wed, 2 Jul 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
Anyway, I propose we put thing of this sort on a WISH-LIST, w priorities, so we'd don't forget about it and propose it again.
Many items on the to-do list are "wishes", and the mentioned `SELECTED_REAL_KIND' is already there. (Though it may refer to a feature to choose between the available standard real types according to some parameters -- as I said, I don't know it exactly.)
But while we're at it, we might as well think about if, how, and how far something can/should be implemented at all before we put it on the list, so the wish list remains (or perhaps gets ;-) a little more realistic.
IMHO strivings should be 100x of what we can achieve, and what is planned only 10x that much ;-)
IMHO this parametrized reals might be a good idea, yet GPC should worry only about loads from/stores into Reals with this new precision, all arithmetic would inevitably have to be done in standard single/double/long double floats,
This would simplify things quite a bit, but it would leave it somewhat unclear (to the programmer) how much of the declared precision is actually used. (Naively, when declaring a real with a precision of 256 bits, I'd expect it to have that precision, not artihmetic done with 64 or so bits of precision.)
Certainly, if so is defined, yet of course one should be aware of the performance penalty for extra precision. Even if not, it could be defined that parametrized Real's precision will not be allowed to be greater than what hardware supports {just like Word attribute (Size = 1..64), even though cardinals of 128 or more bits are very imaginable and could easily find application - i.e. in astronomy}.
Also, I more and more tend to "do it in Pascal code" whenever it has no big disadvantages. So my questions are:
- Do you really see the need for such *parametrized* types? (As opposed to a few particular types for specific needs, such as your GSM example. Those could be implemented individually, though with a bit of code duplication, but also probably more efficiently, since dealing with fixed sizes of exponent and mantissa should make for faster code than variable sizes.)
At the time programmers were using FORTRAN just because it had reals with greater precision and few mathematical libraries written in it -- in fact, it may still be so ...
But I understand the *legitimate* concern not to over-burden the compiler that already isn't what you'd want it to be with extra heavy stuff.
In fact, in ideal world all the hassle over standard arithmetic with modifications of standard types would have been taken care of by the back-end. IRW, front-end should do much more of the total work.
I don't knwo what ar the experiences with the implementation of Cardinal, Word and Integer bitfields; before telling anything specific on implementation of similar functionality with Reals.
Sadly, I've had to convince myself that back-end is an untamed beast (with RotateLeft/RotateRight implementation e.g.), and how it doesn't always do the right thing -- and how it's not very educated about bitfields.
At the level of definition, parametrized Reals arithmetic doesn't seem to complex to write, as long as we stick to modification of IEEE floats. Add, mul, and sqrt are rather trivial; and everything else can be derived from it.
Of course, it would be very clumsy to instantiate all the arithmetic separatelly for each new manitissa or exponent size, now matter how standard the calculation routines may be. And worse, the resulting arithmetic could be slower than that generated by promotion to nearest higher precision standard IEEE float.
- How big are the disadvantages of a Pascal-based solution really? As I said in my previous mail, it might not be more than explicit conversions in assignments. If that's really all, I'm not convinced that the extra effort in the compiler is worth it.
With clever tricks and using some hacks it could be done in rather efficient manner, probably. The only issue is *elegance*, the same way as I declare
var mybitfield : Integer attribute (Size = 2);
and later have almost no worry, i use it as the normal Integer type, and I enjoy the benefit of all automatic conversions Integer type already has, all the functions defined on Integer etc. If I had mybitfield as unit, I'd probably have to call conversion routines myself, but I'm not this familiar with GNU Pascal.
In fact, I might rather consider such "type-cast" operators as mentioned. They would be a more general concept, and perhaps even easier to implement (since the actual conversions can be kept to Pascal code this way).
Interesting.
If we agree on this, I'd rather only put the more general solution on the to-do list (which happens to be there already), so perhaps future contributors who read the list won't waste their time on a feature that was already rejected.
I'd be very encouraged if it's not rejected that easily, and for good. Perhaps in 5 years it would be 50 lines in the front-end to implement it, at little cost of programming and debugging.
So in fact I suggest you try to write a Pascal unit for such a type that you see a need for, with all those operators etc., and find out what can't be done currently.
OK; then I'll add it to my TODO list. It appears at first glance that authomatic promotions are the first thing that is missing -- compiler might never know that new defined type is even a numeric, let alone real ...
Mirsad