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

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by gary.funck on 21 May 2012 at 11:19

[GoogleCodeExporter]

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".

Original comment by phhargr...@lbl.gov on 21 May 2012 at 11:35

[GoogleCodeExporter]

Original comment by phhargr...@lbl.gov on 1 Jun 2012 at 3:53

• Added labels: Spec-1.3

[GoogleCodeExporter]

Original comment by phhargr...@lbl.gov on 1 Jun 2012 at 6:07

• Added labels: Milestone-Spec-1.3
• Removed labels: Spec-1.3

[GoogleCodeExporter]

Original comment by gary.funck on 3 Jul 2012 at 3:10

• Added labels: Type-Clarification
• Removed labels: Type-Defect

[GoogleCodeExporter]

Set default Consensus to "Low".

Original comment by gary.funck on 19 Aug 2012 at 11:26

• Added labels: Consensus-Low

[GoogleCodeExporter]

Change Status to New: Requires review.

Original comment by gary.funck on 19 Aug 2012 at 11:37

• Changed state: New

[GoogleCodeExporter]

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?

Original comment by danbonachea on 14 Sep 2012 at 7:11

[GoogleCodeExporter]

I'll handle this one.

Original comment by prmer...@gmail.com on 17 Sep 2012 at 3:30

[GoogleCodeExporter]

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.

Original comment by prmer...@gmail.com on 4 Oct 2012 at 3:45

• Added labels: Consensus-Medium
• Removed labels: Consensus-Low

[GoogleCodeExporter]

"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?

Original comment by danbonachea on 4 Oct 2012 at 5:18

[GoogleCodeExporter]

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.

Original comment by danbonachea on 29 Nov 2012 at 7:29

• Added labels: Milestone-Spec-1.4
• Removed labels: Milestone-Spec-1.3

[GoogleCodeExporter]

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?

Original comment by jeff.science@gmail.com on 1 Dec 2012 at 7:23

[GoogleCodeExporter]

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.

Original comment by danbonachea on 2 Dec 2012 at 1:46