From Newsgroup: comp.lang.tcl

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

Regards
Alex
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 13:22 , meshparts wrote:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

And what about this one:

% tclsh9.0
% set tcl_patchLevel
9.0.2
% expr {(-8)**(1/3)}
1

Regards,
Erik Leunissen
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 13:31 , erikl wrote:

And what about this one:

% tclsh9.0
% set tcl_patchLevel
9.0.2
% expr {(-8)**(1/3)}
1

And compared these two:

% expr {8**1/3}
2
% expr {8**(1/3)}
1

So: parentheses have a "special" effect.

Erik.
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 07:56, erikl wrote:

On 12/1/25 13:31 , erikl wrote:

And what about this one:

% tclsh9.0
% set tcl_patchLevel
9.0.2
% expr {(-8)**(1/3)}
1

And compared these two:

% expr {8**1/3}
2
% expr {8**(1/3)}
1

Take note of the difference between integer division and floating point division.

% expr 1/3
0
% expr 1.0/3
0.3333333333333333
--
| Don Porter Applied and Computational Mathematics Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 13:56 schrieb erikl:

And compared these two:

% expr {8**1/3}
2
% expr {8**(1/3)}
1

So: parentheses have a "special" effect.

Erik.

I don't think your last 2 examples have anything to do with my original question.

First of all: The two exaples yield correct results, because division by integers results to an integer.

Secondly: Of course paranthesis has an effect on how operations are handled. --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 14:14 schrieb Don Porter:

Take note of the difference between integer division and floating point division.

Don, happy I see my post.
This must be a bug, right?
On the other side, Tcl 8 and 9 have this same bug.
How can this be?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 07:22, meshparts wrote:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

When both operands are doubles, the ** operator is implemented as a
call to the pow() function from the math library, and it has this
behavior.
--
| Don Porter Applied and Computational Mathematics Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 13:22 schrieb meshparts:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

Regards
Alex

The man page of pow() states:

Computes the value of x raised to the power y. If x is negative, y must
be an integer value.

This is apparently a limitation of the pow (and **) function in TCL.

Harald

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 14:31 schrieb Don Porter:

On 12/1/25 07:22, meshparts wrote:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

When both operands are doubles, the ** operator is implemented as a
call to the pow() function from the math library, and it has this
behavior.

Still a bug from a mathematical point of view.
I mean, even my windows calculator gives me the right result.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 08:34, meshparts wrote:

Am 01.12.2025 um 14:31 schrieb Don Porter:

On 12/1/25 07:22, meshparts wrote:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

When both operands are doubles, the ** operator is implemented as a
call to the pow() function from the math library, and it has this
behavior.

Still a bug from a mathematical point of view.
I mean, even my windows calculator gives me the right result.

The ** operator was introduced in Tcl 8.5, via TIPs 123 & 274.
Reproducing pow() was the explicit proposal.

My mind is not closed to a compatible revision with a larger domain, but I'm not signing up to do it.
--
| Don Porter Applied and Computational Mathematics Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 15:04 schrieb Don Porter:

The ** operator was introduced in Tcl 8.5, via TIPs 123 & 274.
Reproducing pow() was the explicit proposal.

So there is no stadard function in Tcl to compute the power of a
negative base to a real exponent?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 15:16 schrieb meshparts:

Am 01.12.2025 um 15:04 schrieb Don Porter:

The ** operator was introduced in Tcl 8.5, via TIPs 123 & 274.
Reproducing pow() was the explicit proposal.

So there is no stadard function in Tcl to compute the power of a
negative base to a real exponent?

You may consider to author a bug report on tcl.

Even if it is documented behaviour, it might not be true any more for
current libraries.

Take care,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 14:14, Don Porter wrote:

Take note of the difference between integer division and floating point division.

Right.

I wasn't quite lucid.
Sorry for the noise.

Erik.
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/25 05:34, meshparts wrote:

Am 01.12.2025 um 14:31 schrieb Don Porter:

On 12/1/25 07:22, meshparts wrote:

For example

expr (-8.0)**(1.0/3.0)

leads to domain range error, not -2 as expected.

Why?

When both operands are doubles, the ** operator is implemented as a
call to the pow() function from the math library, and it has this
behavior.

Still a bug from a mathematical point of view.
I mean, even my windows calculator gives me the right result.

From a "mathematical point of view", the power of a negative base in
the real domain can be defined only if the exponent is either a positive integer or a *rational number*, but is undefined for irrational exponents.

If using computer algebra (i.e. symbolic computation), it is indeed
possible to know that 1/3 is a rational number and -2 could be
calculated. A calculator application knows the history of operations,
hence can perform some level of symbolic computation. Or such
application may decide to check if the inverse of the exponent is "close enough" from being an integer. Those approximative heuristics may make
sense at high level for an application.

But at system level, since calculating pow(-8.0,1.0/3.0) operates on
floating point numbers, the exponent is not known anymore to be a
rational number when pow() is calculated. That's why Posix explicitly
states that pow() returns NaN with invalid domain error for any
exponentiation of a negative base with a non-integer exponent.

This is definitely not a Tcl specific behavior. Some languages (e.g.
Python) may return a complex number by default (though maybe not the one
you expect):

pow(-8.0, 1.0/3.0)

(1.0000000000000002+1.7320508075688772j)

and you can see why rounding errors makes the pow() undefined in real
domain:

pow(pow(-8.0, 1.0/3.0),3)

(-8+3.1086244689504383e-15j)

But on any system and language (Tcl being one among many, if not all) operating on real numbers, the result can only be NaN.

Eric
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Eric Hassold, Wizard from Evolane and e-TCL.
Welcome back !
I followed a bit your journey on LinkedIn through the US big tech
companies. My appreciation !
Au très grand plaisir,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

In article <10gkad1$1dori$1@dont-email.me>,
Eric Hassold <hassold@evopulse.com> wrote:
...

But on any system and language (Tcl being one among many, if not all) >operating on real numbers, the result can only be NaN.

All that you wrote makes sense, but, interestingly enough, both Perl and
AWK (GAWK) get this right:

% iPerl
:-) -8 ** (1/3)
-2
:-) ^C
% gawk4 'BEGIN { print -8 ** (1/3) }'
-2
%

I haven't dug into it, but (unless I'm assuming something I should not be assuming), I would expect both of them to be using pow() to do the work.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/IceCream
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 03.12.2025 um 23:19 schrieb Kenny McCormack:

All that you wrote makes sense, but, interestingly enough, both Perl and
AWK (GAWK) get this right:

Nice!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

At Wed, 3 Dec 2025 22:19:06 -0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

In article <10gkad1$1dori$1@dont-email.me>,
Eric Hassold <hassold@evopulse.com> wrote:
...

But on any system and language (Tcl being one among many, if not all) >operating on real numbers, the result can only be NaN.

All that you wrote makes sense, but, interestingly enough, both Perl and
AWK (GAWK) get this right:

% iPerl
:-) -8 ** (1/3)
-2
:-) ^C
% gawk4 'BEGIN { print -8 ** (1/3) }'
-2
%

I haven't dug into it, but (unless I'm assuming something I should not be assuming), I would expect both of them to be using pow() to do the work.

Also Common Lisp:
sbcl
This is SBCL 1.4.2, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (expt -8 1/3)
#C(1.0 1.7320508)
*
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 01/12/2025 14:57, Eric Hassold wrote:

... at system level, since calculating pow(-8.0,1.0/3.0) operates on
floating point numbers, the exponent is not known anymore to be a
rational number when pow() is calculated.

Are there irrational floating-point numbers? I thought every
floating-point number (obviously not NaNs and infs) was a rational.

In your example the exponent is a rational number even if it's:

3333333333333333/10000000000000000

as it appears to be on my local Tcl version:

expr {1.0/3.0}
0.3333333333333333
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 03.12.25 um 23:19 schrieb Kenny McCormack:

In article <10gkad1$1dori$1@dont-email.me>,
Eric Hassold <hassold@evopulse.com> wrote:
...

But on any system and language (Tcl being one among many, if not all)
operating on real numbers, the result can only be NaN.

All that you wrote makes sense, but, interestingly enough, both Perl and
AWK (GAWK) get this right:

% iPerl
:-) -8 ** (1/3)
-2
:-) ^C
% gawk4 'BEGIN { print -8 ** (1/3) }'
-2
%

I think this is a misunderstanding. They compute -(8**(1/3)) instead of (-8)**(1/3)

chris@linux:~> gawk 'BEGIN {print (-8)**(1.0/3)}'
-nan
chris@linux:~>

Whereas in Tcl, the - sign binds stronger than the exponent operator **
- I think, this is a bug (or misdesign).

I haven't dug into it, but (unless I'm assuming something I should not be assuming), I would expect both of them to be using pow() to do the work.

The problem is that even if you go to the complex domain, the principle
root is a different one:

https://www.wolframalpha.com/input?i=%28-8%29%5E%281%2F3%29

says 1+sqrt(3)*i


The pow operator cannot see anymore that teh exponent is a fraction with
an odd denominator (unless it would try to rewrite the floating point
value into a fraction) - therefore the only reliable way to do this
would be a nthroot function like this:

proc nthroot {x n} {
if {![string is entier $n]} {
return -code error "ONly integer exponents"
}
if {$x >= 0} {
return [expr {$x**(1.0/$n)}]
}
if {$n % 2 == 0} { return -code error "Even root from negative number" }

return [expr {-(abs($x)**(1.0/$n))}]
}

Christian
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 04.12.2025 um 07:15 schrieb Christian Gollwitzer:

therefore the only reliable way to do this would be a nthroot function
like this:

Well, if this is the only solution, then Tcl needs such a function.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/3/25 19:10, Tristan Wibberley wrote:

On 01/12/2025 14:57, Eric Hassold wrote:

... at system level, since calculating pow(-8.0,1.0/3.0) operates on
floating point numbers, the exponent is not known anymore to be a
rational number when pow() is calculated.

Are there irrational floating-point numbers? I thought every
floating-point number (obviously not NaNs and infs) was a rational.

In your example the exponent is a rational number even if it's:

3333333333333333/10000000000000000

as it appears to be on my local Tcl version:

expr {1.0/3.0}
0.3333333333333333

Sure, every IEEE754 number is de facto a rational number:

value = (Signbit ? -1 : 1) * (1 + Mantissa) * 2^(Exponent - 1023)

But that rational number is not (necessarily) equal to the initial
rational number, and the parity of its numerator/denominator is not
preserved.

Let's take this 1.0/3.0. The calculated IEEE754 number is:
(0, 01111111101, 0101010101010101010101010101010101010101010101010101)
that is:
(1 + (0x5555555555555 / 2**52)) * 2^(1021 - 1023)
or, in pure fractional form:
0x15555555555555 / (2**54)
and, if converted back to decimal, is exactly:
0.333333333333333314829616256247390992939472198486328125

What about 1.0/6.0? well, very similar, we end up with:
0x15555555555555 / (2**55)
i.e., in decimal:
0.1666666666666666574148081281236954964697360992431640625

Then the issue is clear. Those two numbers have same parity (odd
numerator, even denominator), not correlated with the parity of their
original fractional form (odd for 1/3, even for 1/6). So if trying to
evaluate say pow(-8.0, 1.0/3.0) and pow(-64, 1.0/6.0), it is impossible
to determine, from the IEEE754-encoded "fractional form", that the
former may return -2 but the latter should fail.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

In article <10gr8tj$10ea$1@dont-email.me>,
Christian Gollwitzer <auriocus@gmx.de> wrote:
...

I think this is a misunderstanding. They compute -(8**(1/3)) instead of >(-8)**(1/3)

chris@linux:~> gawk 'BEGIN {print (-8)**(1.0/3)}'
-nan
chris@linux:~>

Oops. You are right. My mistake.

When you parenthesize (-8), both AWK and Perl report "nan".

It really had not occurred to me that - would bind less tightly than **.

As they say, Never Mind...

Though, having said all this, it makes one wonder what OP's actual use case was. I don't think that was ever explained. I mean, what I am saying is
that the simplest solution to OP's problem is just to re-parenthesize his expression:

expect 1.2> expr -8 ** (1.0/3)
Error: domain error: argument not in valid range
expect 1.3> expr -(8 ** (1.0/3))
Result: -2.0
expect 1.4>

Voila! Problem solved.

(Yes, this is intended as a satire of the tendency (*) on support forums (including Usenet) of focusing on providing a workaround instead of
addressing the actual question...)

(*) Though not seen in this thread. In general, I find the TCL group significantly *less* persnickety than is usual... That's a Good Thing.
--
b w r w g y b r y b
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 04.12.2025 um 13:37 schrieb Kenny McCormack:

Though, having said all this, it makes one wonder what OP's actual use case was. I don't think that was ever explained. I mean, what I am saying is that the simplest solution to OP's problem is just to re-parenthesize his expression:

expect 1.2> expr -8 ** (1.0/3)
Error: domain error: argument not in valid range
expect 1.3> expr -(8 ** (1.0/3))
Result: -2.0
expect 1.4>

Voila! Problem solved.

As you already imagined, this will not solve my problem.
I fixed this in my code by if/else and asking about the sign of the base.
In general Tcl has no standard function to correctly compute $a**(1.0/$b).
I think this needs to be solved.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

In article <10gs0f8$14a4k$1@tota-refugium.de>,
meshparts <alexandru.dadalau@meshparts.de> wrote:

Am 04.12.2025 um 13:37 schrieb Kenny McCormack:

Though, having said all this, it makes one wonder what OP's actual use case >> was. I don't think that was ever explained. I mean, what I am saying is
that the simplest solution to OP's problem is just to re-parenthesize his
expression:

expect 1.2> expr -8 ** (1.0/3)
Error: domain error: argument not in valid range
expect 1.3> expr -(8 ** (1.0/3))
Result: -2.0
expect 1.4>

Voila! Problem solved.

As you already imagined, this will not solve my problem.
I fixed this in my code by if/else and asking about the sign of the base.

Note: I don't know enough TCL to know the actual names/syntax for what I am proposing, but it seems you could do something like:

sgn(x)*(abs(x) ** (1.0/n))

Editorial comment: IMHO, sgn() is an often useful function that should be present in our toolkits. It is sad that most such toolkits omit it.

In general Tcl has no standard function to correctly compute $a**(1.0/$b).
I think this needs to be solved.

Agreed.
--
Elect a clown, expect a circus.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 04.12.2025 um 14:05 schrieb Kenny McCormack:

Note: I don't know enough TCL to know the actual names/syntax for what I am proposing, but it seems you could do something like:

sgn(x)*(abs(x) ** (1.0/n))

Hm, I guess not. Only true if n is odd.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 04.12.2025 um 14:05 schrieb Kenny McCormack:

In article <10gs0f8$14a4k$1@tota-refugium.de>,
meshparts <alexandru.dadalau@meshparts.de> wrote:

Am 04.12.2025 um 13:37 schrieb Kenny McCormack:

Though, having said all this, it makes one wonder what OP's actual use case >>> was. I don't think that was ever explained. I mean, what I am saying is >>> that the simplest solution to OP's problem is just to re-parenthesize his >>> expression:

expect 1.2> expr -8 ** (1.0/3)
Error: domain error: argument not in valid range
expect 1.3> expr -(8 ** (1.0/3))
Result: -2.0
expect 1.4>

Voila! Problem solved.

As you already imagined, this will not solve my problem.
I fixed this in my code by if/else and asking about the sign of the base.

Note: I don't know enough TCL to know the actual names/syntax for what I am proposing, but it seems you could do something like:

sgn(x)*(abs(x) ** (1.0/n))

Editorial comment: IMHO, sgn() is an often useful function that should be present in our toolkits. It is sad that most such toolkits omit it.

In general Tcl has no standard function to correctly compute $a**(1.0/$b). >> I think this needs to be solved.

Agreed.

Christian Gollwitzer already proposed a user defined function to solve
this: nthroot
But this function should be standard in Tcl.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 04.12.2025 um 16:59 schrieb meshparts:

Am 04.12.2025 um 14:05 schrieb Kenny McCormack:

In article <10gs0f8$14a4k$1@tota-refugium.de>,
meshparts  <alexandru.dadalau@meshparts.de> wrote:

Am 04.12.2025 um 13:37 schrieb Kenny McCormack:

Though, having said all this, it makes one wonder what OP's actual
use case
was.  I don't think that was ever explained.  I mean, what I am
saying is
that the simplest solution to OP's problem is just to re-
parenthesize his
expression:

expect 1.2> expr -8 ** (1.0/3)
Error: domain error: argument not in valid range
expect 1.3> expr -(8 ** (1.0/3))
Result: -2.0
expect 1.4>

Voila!  Problem solved.

As you already imagined, this will not solve my problem.
I fixed this in my code by if/else and asking about the sign of the
base.

Note: I don't know enough TCL to know the actual names/syntax for what
I am
proposing, but it seems you could do something like:

     sgn(x)*(abs(x) ** (1.0/n))

Editorial comment: IMHO, sgn() is an often useful function that should be
present in our toolkits.  It is sad that most such toolkits omit it.

In general Tcl has no standard function to correctly compute
$a**(1.0/$b).
I think this needs to be solved.

Agreed.

Christian Gollwitzer already proposed a user defined function to solve
this: nthroot
But this function should be standard in Tcl.

We need a TCL ticket for this.

Any voluntears ?

Thanks,
Harald

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 05.12.2025 um 10:57 schrieb Harald Oehlmann:

We need a TCL ticket for this.

Any voluntears ?

I could write an email to tcl-core, would that suffice?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 04/12/2025 08:43, Eric Hassold wrote:

On 12/3/25 19:10, Tristan Wibberley wrote:

On 01/12/2025 14:57, Eric Hassold wrote:

... at system level, since calculating pow(-8.0,1.0/3.0) operates on
floating point numbers, the exponent is not known anymore to be a
rational number when pow() is calculated.

Are there irrational floating-point numbers? I thought every
floating-point number (obviously not NaNs and infs) was a rational.

In your example the exponent is a rational number even if it's:

   3333333333333333/10000000000000000

as it appears to be on my local Tcl version:

   expr {1.0/3.0}
   0.3333333333333333

Sure

So the exponent is still known to be a rational number. Did you start by
saying "exponent" instead of whatever term refers to the result of an exponentiation? I think that would then have been correct.

every IEEE754 number is de facto a rational number:

Is IEEE754 relevant? Does Tcl use IEEE754 or just whatever system of floating-point calculation is fast on the hardware?


I won't bother commenting on your very detailed text below because I
don't have fully toned mental machinery to recognise everything quickly
the way it's written but I appreciate it for later.

   value = (Signbit ? -1 : 1) * (1 + Mantissa) * 2^(Exponent - 1023)

But that rational number is not (necessarily) equal to the initial
rational number, and the parity of its numerator/denominator is not preserved.

Let's take this 1.0/3.0. The calculated IEEE754 number is:
  (0, 01111111101, 0101010101010101010101010101010101010101010101010101) that is:
  (1 + (0x5555555555555 / 2**52)) * 2^(1021 - 1023)
or, in pure fractional form:
  0x15555555555555 / (2**54)
and, if converted back to decimal, is exactly:
  0.333333333333333314829616256247390992939472198486328125

What about 1.0/6.0? well, very similar, we end up with:
  0x15555555555555 / (2**55)
i.e., in decimal:
  0.1666666666666666574148081281236954964697360992431640625

Then the issue is clear. Those two numbers have same parity (odd
numerator, even denominator), not correlated with the parity of their original fractional form (odd for 1/3, even for 1/6). So if trying to evaluate say pow(-8.0, 1.0/3.0) and pow(-64, 1.0/6.0), it is impossible
to determine, from the IEEE754-encoded "fractional form", that the
former may return -2 but the latter should fail.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2