Clarification: "long double" and "long double complex" support

[Former user]

Originally reported on Google Code with ID 27

This informative note is responsive to issues 23 and 24.

23. Is "long double" defined in the UPC language?
24. Is "long double complex" defined in the UPC language?

The "long double" types are defined in C99 inclusive of complex number support.

The "long double" type is also defined in the required UPC "collectives" library. 
However, there is currently no support for the complex/real/imaginary equivalents.

Given the nature of HPC applications written in UPC, it is recommended that "long double"
in its various forms also be supported by a UPC compiler as long as the native C compiler
also supports them.

For completeness, the UPC collectives library API should be extended to also include
long double complex types.

Reported by gary.funck on 2012-05-21 23:19:21

[Former user]

``` I agree w/ Gary on the basic facts: 1) "long double" is part of C99 2) "float complex", "double complex" and "long double complex" are part of C99 3) UPC should support all of C99's arithmetic types.

So, I also agree w/ the conclusion that the collectives need to be expanded to include the 3 complex types. To be concrete, I would suggest "FC", "DC" and "LDC" as the type codes that are most consistent with the "principle of least surprise".

```

Reported by `[e-mail]` on 2012-05-21 23:35:43

[Former user]

Reported by `[e-mail]` on 2012-06-01 03:53:43 - Labels added: Spec-1.3

[Former user]

Reported by `[e-mail]` on 2012-06-01 06:07:38 - Labels added: Milestone-Spec-1.3 - Labels removed: Spec-1.3

[Former user]

Reported by `gary.funck` on 2012-07-03 15:10:26 - Labels added: Type-Clarification - Labels removed: Type-Defect

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` Change Status to New: Requires review. ```

Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`

[Former user]

``` Regarding implementation, it's worth noting that C99 fully permits an implementation where "long double" is equivalent to "double" (for that matter, both are also permitted to be equivalent to "float"). Obviously in the interests of interoperability the UPC compiler should probably use the same floating point types as the system C compiler. I agree that long double should appear in the list of types for any library supporting double, eg collectives.

C11 makes language support for complex types completely optional. My impression is this is because these types are incompatible with those provided in other languages (notably C++) and largely underutilized, notably by scientific libraries. How important is the C99 _Complex type to our UPC app programmers?

```

Reported by `danbonachea` on 2012-09-14 19:11:21

[Former user]

``` I'll handle this one. ```

Reported by `prmerkey` on 2012-09-17 15:30:48

[Former user]

``` There seems to be a fair amount of consensus that a UPC compiler should not choke on long double or long double complex. But there are issues with the library support, eg. the collectives.

The UPC compiler should use the same floating point types as the system C compiler.

The difficult is that there is no precise definition of long, long long, long double, long double complex. This has ramifications for allocation and libraries, eg the collectives.

To make progress, we have split the issue so that we can revisit the library aspects when we talk about the collective spec.

```

Reported by `prmerkey` on 2012-10-04 15:45:23 - Labels added: Consensus-Medium - Labels removed: Consensus-Low

[Former user]

``` "there is no precise definition of long, long long, long double, long double complex."

This is not quite accurate - there ARE precise definitions of these types in the C99 spec, and ample query operations that describe their exact size, range and precision. It's just that C99 does not require these characteristics to be identical on all implementations. This property is true of all the types defined by C99, not just the ones mentioned. A C99 or UPC program that cares about the exact range and precision of a type should use the query functions to ensure portability.

It's also worth noting that most C99 compilers in an HPC setting probably define STDC_IEC_559, which activates C99 Annex F and restricts the float and double types to exactly match the IEC 60559 binary format. In this case long double is still left somewhat "loose", allowing the variety of extended-precision formats that exist on current architectures.

Regarding the new purpose of this issue (language support for long double and complex), I don't think any spec wording is necessary to state that the UPC language includes these C99 types. This is automatic by UPC Section 1.

A related but separate discussion is the current state of UPC implementations and their support for long double and complex. Last time I checked BUPC's frontend lacked support for the complex built-in type as do several of our target backend C compilers. Given that it becomes optional in C11, it doesn't seem like a high development priority to implement the complex built-in, unless some users can motivate this as really important?

```

Reported by `danbonachea` on 2012-10-04 17:18:23

[Former user]

deferred to 1.4 on 11/29 telecon, possibly to be resolved along with C11 support

unlikely that complex types will be added to the UPC collectives, as they seem to have
poor support in C compilers and limited utilization in practice.

Reported by danbonachea on 2012-11-29 19:29:36 - Labels added: Milestone-Spec-1.4 - Labels removed: Milestone-Spec-1.3

[Former user]

Complex numbers are used extensively in scientific computing and many algorithms involve
collectives.  Is it our intent to require everyone doing reductions on complex to do
a gather+local_reduce(+bcast) implementation?

Reported by jeff.science on 2012-12-01 19:23:17

[Former user]

To clarify comment 11, complex *numbers* are used extensively in scientific computing,
but the C99 complex *type* seems to be poorly implemented/utilized, and that's the
topic of this issue. 

It seems to be common practice for C/UPC users to just define their own complex type
with something like: struct { double real; double imag; } 
or possibly store the real and imaginary components in two corresponding arrays.

The current UPC collectives do not support reductions over user-defined types, although
I believe this was one of the features under consideration for collectives 2.0.

Reported by danbonachea on 2012-12-02 13:46:24