Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

negative powers of BigInt without DomainErrors? #50498

Closed
PallHaraldsson opened this issue Jul 10, 2023 · 2 comments
Closed

negative powers of BigInt without DomainErrors? #50498

PallHaraldsson opened this issue Jul 10, 2023 · 2 comments
Labels
bignums BigInt and BigFloat speculative Whether the change will be implemented is speculative

Comments

@PallHaraldsson
Copy link
Contributor

PallHaraldsson commented Jul 10, 2023

@nhz2 from #50486 (comment)

BigInt should be better supported. Almost every math function that works with Int inputs should work with BigInt inputs.

You are only asking for the special case a ^ b where b = -1. It's currently handled by:

function bigint_pow(x::BigInt, y::Integer)
    if y<0; throw(DomainError(y, "`y` cannot be negative.")); end

[for b < -1 the only result could be returning BigFloat, i.e. having BigInt power type-unstable, not under consideration here.] It's plausible to do extend this function for b = -1 only to and keep it type-stable, and looking at the code I think it can be done without slowing the other cases down. [I'm just not sure it's very valuable, and since such an extreme edge case, I'm ok with this issue just closed. I was basically answering @nhz2, here to not derail the other conversation.]

What needs to be done then is similar to:

@assume_effects :terminates_locally function power_by_squaring(x_, p::Integer)
 [..]
    elseif p < 0
        isone(x) && return copy(x)
        isone(-x) && return iseven(p) ? one(x) : copy(x)
        throw_domerr_powbysq(x, p)

[Myself, I would prefer a ^ b to return Float64 (for all numbers, but not all types), i.e. a breaking change for 2.0 and then returning BigFloat for BigInt would seem sensible for compatibility, but since there's no Unsigned BigInt, unlike for other Integers we would have a dilemma.]

@stevengj stevengj added the bignums BigInt and BigFloat label Jul 11, 2023
@stevengj
Copy link
Member

stevengj commented Jul 11, 2023

This seems to be #3024 all over again. a ^ b can't return a BigFloat for b = big(-1) if we want it to be typestable, unless all BigInt powers are BigFloats (which would be inconvenient for a lot of number theory, I think), or unless we treat "literals" like big(-1) specially — though I don't see much point to this since for the case of a -1 literal you might as well do a literal power a^-1 (which already produces a BigFloat for a::BigInt).

@stevengj stevengj changed the title Better support for power of BigInt needed? negative powers of BigInt without DomainError Jul 11, 2023
@stevengj stevengj changed the title negative powers of BigInt without DomainError negative powers of BigInt without DomainErrors? Jul 11, 2023
@stevengj stevengj added the speculative Whether the change will be implemented is speculative label Jul 11, 2023
@PallHaraldsson
Copy link
Contributor Author

This doesn't seems worth it so I'm closing. I don't want BigFloat result in general, because we have that, and want some way of getting BigInt. I was only addressing the question from @nhz2, and to match non-BigInt, it only addresses -1 ^ -1 and 1 ^ -1 as extra cases. Feel free to add the code for that, but it's such edge cases that I do not care. The issue you point to is for arbitrary a for a ^ b where b is negative. I still want that to return Float64 for non-BigInt, but see now it would lead to an inconsistency with BigInt power.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bignums BigInt and BigFloat speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

2 participants