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 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.)
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.)
- 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.
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).
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.
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.
Frank