On Tue, 29 Nov 2005 lanceboyle@bluebottle.com wrote:
Now, I'm saying this:
But isn't there potentially a difference between the longest _natively_supported_ float per hardware, and the longest float, which might be partially software-implemented? For speed, it would still seem like a good idea to have a type which defaults to the longest natively supported length.
Sorry if this is beating the subject to death.
I think going to manual brings us to the fact (LongestReal:: in index):
type LongestReal = LongReal; { might get bigger than LongReal someday }
while on the Real Types page we read:
| Note that not all machines support longer floating point types, so | `LongReal' is the same as `Real' on these machines. Also, some machines | may support a longer type, but not do all arithmetic operations (e.g. | the `Sin' function, *Note Sin::) in a precision higher than that of | `Real'. If you need higher precision, you can look at the `GMP' unit | (*note GMP::) which provides rational and real numbers with arbitrary | precision, but their usage is different from normal real types. | | The following real types are guaranteed to be compatible to the real | types of GNU C. The sizes given, however, are _not_ guaranteed. They | are just typical values used on any IEEE compatible floating point | hardware, but they may be different on some machines. | | type name alternative name GNU C equivalent size in bits | (typically) | ShortReal Single float 32 | Real Double double 64 | LongReal Extended long double 80
So, essentially this means that GPC will support hardware supported types with GPC native types, while for software extended precision GMP (or other) library is required.
My $0.02
Regards, Mirsad