In some documentation, I want to talk about a generic complex(w) and say
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.
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.
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.
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.
