# Disabling DomainError (in sqrt())?

**URL:** https://discourse.julialang.org/t/disabling-domainerror-in-sqrt/88755
**Category:** General Usage
**Tags:** error, math, inbounds
**Created:** [October 14, 2022, 9:14pm UTC](https://discourse.julialang.org/t/disabling-domainerror-in-sqrt/88755 "2022-10-14T21:14:41Z")
**Posts on this page:** 2
**Page:** 2

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 17, 2022, 8:36pm UTC](https://discourse.julialang.org/t/disabling-domainerror-in-sqrt/88755/21 "2022-10-17T20:36:11Z")

</div>

[https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/SLprSJzpgCQ/m/WdvNwTd0DAAJ](https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/SLprSJzpgCQ/m/WdvNwTd0DAAJ)

> The operation implemented by frsqrt.\* is a correctly-rounded implementation of the IEEE 754-2008 rSqrt operation  
> […]  
> The instruction can be considerably faster if it’s required to be within 1-ulp than if it’s required to be correctly rounded.

At least there seems to be “the IEEE 754-2008 rSqrt operation” (just not sure if it’s only a recommendation).

Would it be allowed to convert 1/sqrt(x) to use the more accurate `@fastmath` method (which seems to be a win-win, also faster), by default? I’m not sure the standard would require it rather in function form, but I do see at least at least one libm has it (are they standardized, I mean the number of functions)?)

[https://www.ibm.com/docs/en/aix/7.2?topic=r-rsqrt-subroutine](https://www.ibm.com/docs/en/aix/7.2?topic=r-rsqrt-subroutine)

We’re about to get rid of libm in Julia, but I’m not sure it has rsqrt, or we were ok with dropping it since not used since not required.

There’s of course no requirement to include less accurate versions in Julia Base, I just thought easily possible. But more accurate should be welcome? [Though I don’t just want to get rid of LinuearAlgebra from the sysimage, I kind of want all floating-point gone too, since not required by Julia iseelf/the compiler…]

If you have a series of ops, here sqrt, then /, I believe each must be correctly rounded, meaning to one ULP, does that mean both to 2 ULPs? I’m not sure it applies always, but in this case?

rsqrt is important enough to be in standards and in hardware, but I suppose sqrt(1/x) isn’t too common. I guess it could however also be made more accurate (and faster?). I’m just trying to learn from the conversation.

Of some interest:

> <https://stackoverflow.com/questions/66752842/ieee-754-conformant-sqrtf-implementation-taking-into-account-hardware-restrict>

---

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 17, 2022, 9:20pm UTC](https://discourse.julialang.org/t/disabling-domainerror-in-sqrt/88755/22 "2022-10-17T21:20:30Z")

</div>

rsqrt is a recommendation in older IEEE, and one of the functions we “need” to implement in Julia and “should define”:

> <https://github.com/JuliaLang/julia/issues/32877>
>
> from IEEE 754-2019: sec 9.2 Additional mathematical operations
> 
> "Language stan…dards should define, to be implemented according to this subclause, as many of the operations in Table 9.1 as is appropriate to the language. As with other operations of this standard, the names of the operations in Table 9.1 do not necessarily correspond to the names that any particular programming language would use. In this subclause the domain of an operation is that subset of the affinely extended reals for which the corresponding mathematical function is well defined. A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain."
> 
> 
> \_these functions include\_
> \`\`\`
> rsqrt(x) ≝ 1 / sqrt(x)
> compound(x, n) ≝ (1 + x)^n
> 
> rootn(x, n) ≝ x^(1/n)
> pown(x,n) ≝ x^n
> pow(x, y) ≝ x^y \[-Inf, +Inf\] x \[-Inf, +Inf\] 
> powr(x,y) ≝ x^y \[0,+Inf\] x \[-Inf, +Inf\]
> 
> exp2m1(x) ≝ 2^x - 1
> exp10m1(x) ≝ 10^x - 1
> 
> log2p1(x) ≝ llog2(1+x)
> log10p1(x) ≝ log10(1+x)
> 
> 
> sinpi(x) ≝ sin(π \* x)
> cospi(x) ≝ cos(π \* x)
> tanpi(x) ≝ tan(π \* x)
> 
> asinpi(x) ≝ asin(x) / π
> acospi(x) ≝ acos(x) / π
> atanpi(x) ≝ atan(x) / π
> 
> atan2pi(y, x) is the angle subtended at the origin by the point (x, y)
> and the positive x-axis. The range of atan2pi is \[−1, +1\].
> \`\`\`
> there are short tables of required \`y = f(x) where x in {±0, ±∞}\`
> for many of these functions
> 
> \`\`\`
> getpayload(x)
> if the source operand is a NaN, the result is the payload
> as a non-negative floating-point integer.
> if the source operand is not a NaN, the result is −1.
> 
> setpayload(x)
> If the source operand is a non-negative floating-point integer whose value
> is one of an implementation-defined set of admissible payloads for
> the operation, the result is a quiet NaN with that payload. 
> Otherwise, the result is +0, with a preferred exponent of 0.
> 
> setpayloadsignaling(x)
> like setpayload, the result is a signaling NaN
> \`\`\`

In addition to Base.sqrt\_llvm there’s Base.sqrt\_llvm\_fast, and we “should” implement rootn(x, n) not just sqrt, so I’m not sure we should add at least the more accurate versions to your package, though maybe the less accurate and faster versions.

[Previous page](https://discourse.julialang.org/t/disabling-domainerror-in-sqrt/88755.md?page=1)
