# Referencing Chapel's Generic Types

**URL:** <https://chapel.discourse.group/t/referencing-chapels-generic-types/42682>\
**Category:** Users\
**Created:** [May 9, 2025, 2:54am UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682 "2025-05-09T02:54:31Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![damianmoz](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/damianmoz/32/319_2.png) [@damianmoz](https://chapel.discourse.group/u/damianmoz)\
**Post date:** [May 9, 2025, 2:54am UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682/1 "2025-05-09T02:54:32Z")

</div>

In some documentation, I want to talk about a generic **complex** (w) and say

```chapel
w in (32, 64, 128, ...)

```

where the contentious issue is those 3 dots. I have said 32 because of the newly minted (or about to be) **complex** (32) which uses **real** (16) types. I use those three dots in anticipation of **real** (128) which I assume Chapel will be pressured into implementing in the not too distant future.

How contentious is that in a footnote or elsewhere in a (say) published paper or even a book?

I will use a reverse Greek epsilon instead of **in** to mean _is an element of the set_ in the publication.

---

<div class="post-metadata">

**Author:** ![lydia](https://avatars.discourse-cdn.com/v4/letter/l/34f0e0/32.png) [@lydia](https://chapel.discourse.group/u/lydia)\
**Post date:** [May 9, 2025, 8:24pm UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682/2 "2025-05-09T20:24:37Z")

</div>

I'd probably be specific about which parts were anticipated versus  
currently supported, just because the timeline for these things is not  
set in stone. But I tend towards the more cautious side anyways. It  
doesn't seem contentious that we will support them, I just worry about a  
scenario where the published words predate the support by a large amount  
of time.

Lydia

---

<div class="post-metadata">

**Author:** ![damianmoz](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/damianmoz/32/319_2.png) [@damianmoz](https://chapel.discourse.group/u/damianmoz)\
**Post date:** [May 9, 2025, 8:38pm UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682/3 "2025-05-09T20:38:30Z")

</div>

I will put a disclaimer at the end of the document. I do not have room to put extra words in the footnote. I must admit that I am amazed that 128-bit floating point numbers have not materialized in hardware much. I think the Power10 is the only commonly available CPU which does to date.

Thanks

---

<div class="post-metadata">

**Author:** ![damianmoz](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/damianmoz/32/319_2.png) [@damianmoz](https://chapel.discourse.group/u/damianmoz)\
**Post date:** [May 10, 2025, 9:01am UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682/4 "2025-05-10T09:01:03Z")

</div>

A generic w-bit (@) Chapel **complex** (w) number _z_ is comprised of a real component and an imaginary component, both real(_v = w/2_) ...

are the words in the Introduction where the (@) footnote (with no more room) says:

```
w is an element of {32, 64, 128, ...}

```

while the wrap up at the end contain words like:

Whenever Chapel supports 128-bit (or quadruple precision) floating-point arithmetic and the authors can access hardware that supports those **real** (128) and hence **complex** (256) floating-point numbers, the function will be tested with arguments of the latter. But no challenges are expected to arise.

Does that sound adequate?

I also mention the use of the newly minted **real** (16) numbers in a **complex** (32) number.

---

<div class="post-metadata">

**Author:** ![lydia](https://avatars.discourse-cdn.com/v4/letter/l/34f0e0/32.png) [@lydia](https://chapel.discourse.group/u/lydia)\
**Post date:** [May 12, 2025, 3:37pm UTC](https://chapel.discourse.group/t/referencing-chapels-generic-types/42682/5 "2025-05-12T15:37:41Z")

</div>

That sounds good to me 🙂

Lydia