The clarity provided by the use of params

Users
1

Something to consider in one's rare spare moments:

Currently, Chapel has various symbolic constants which largely map to symbolic constants defined in the C standard. One can argue they unnecessarily pollute the name space of the
Math module.

Rather than using Chapel's existing compile time constant

sqrt2

the expression

sqrt(2.0)

would be a far clearer way to reference that square root. But as we do not want any run-time overhead in this expression, we need to define a param variant of the standard sqrt() routine as in:

proc sqrt(param x : real(?w)) param where x == 2
{
    param A002193 = 1.4142135623730950488016887242096980785696718753;

    return A002193:real(w);
}

Such a zero run-time overhead routine could be called as

sqrt(2.0:real(32))
sqrt(2.0:real(64))
sqrt(2.0);

to provide the desired result, the first to 32-bits of precision, the second to 64-bits of precision, and the last, because 2.0 has the default type real(64), also to 64-bits of precision.

That A002193 is that sequence within the On-Line Encyclopedia of Integer Sequences that consists of the digits in the decimal expansion of the square root of 2.

One could exploit the long standardized and well accepted name of the inverse square root function as defined by the C (and C++) standards, i.e. rsqrt(), to provide the reciprocal of 2 as

proc rsqrt(param x : real(?w)) param where x == 2
{
    return 1 / sqrt(x);
}

which can then be evaluated with no run-time overhead as

rsqrt(2.0:real(32))
rsqrt(2.0:real(64))
rsqrt(2.0);

where the precision of each is left as an exercise for the reader.

This is just another example of the elegance and power of Chapel

One could also declare

proc exp(param x : real(?w)) param where x == 1
{
    param A001113 = 2.71828182845904523536028747135266249775724709369995;

    return A001113:T;
}

to allow a programmer zero-overhead run-time access to Napier's constant (or Euler's number or e, the 32-bit value of which would be

exp(1:real(32))

and provide future justification to drop e from the Math.chpl namespace.

But that is a whole new ball game that I leave for others to philosophically ponder

2

Good observation, thank you!

Ideally of course the implementation would provide a param value for the square root of anything that is param, like we do for multiplication, for example:

operator *(param a: real(64), param b: real(64)) param do return __primitive("*", a, b);

However, starting with just a handful of cases like sqrt(2) is also a good suggestion.

I am thinking that instead of introducing rsqrt, which is yet another name to remember, the compiler would produce a param value for normal-looking expressions like 1/sqrt(some param value).

Vass

3

I am sure that there are more important things that you have on your TODO list.

For now, it is really easy to handle the common cases based on my example

I personally never need/use any of the constants in the Math module, I have:

exp(1.0); // no need for 'e'
sqrt(2.0)
rsqrt(2.0)
pix(0.25), pix(0.5), pix(1.0), pix(2.0); // pi * (the argument)
rpix(1.0), rpix(2.0); // (the argument) / pi
Inf(real(w));
NaN(real(w));

All those other constants in the Math module, like their equivalents in the C standard, have pretty limited application.

From an IEEE 754 perspective, sqrt() is a mandatory operator like +, -, *, and / so strictly it should be on your list, but very low down in terms of priority in my opinion.

The name rsqrt() has been around for 33+ years, so I do not think it is too much of a burden. Also, I like the control I have by nominating it explicitly.

Can you fix the typo in the subject please?

4

I don't think we have the ability to adjust the title of the thread, unfortunately. But I do think this is an interesting idea and it would be nice to get rid of those Math constants in favor of it. Would you be interested in opening an issue about it? If not, I can definitely do so

Thanks,
Lydia

5

I will open an issue over the weekend.

A shame about the title. My fat fingers are on show for eternity.

6

I've fixed it.

-Brad

1 Like
7

I guess Brad has the ability, then XD

8

Done - See #26571

1 Like