Opened 4 years ago

Last modified 4 years ago

#24490 new defect

Do not allow QQbar(1) ^ anything

Reported by: jdemeyer Owned by:
Priority: major Milestone: sage-8.2
Component: basic arithmetic Keywords:
Cc: cheuberg, dkrenn Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #5574 Stopgaps:

Status badges

Description (last modified by jdemeyer)

Powering a QQbar number by a QQbar number makes no sense mathematically. It goes against the philosophy of the coercion model. QQbar should only support powering by QQ. See also #5574.

This ticket is meant to revert #22120 which allows QQbar(1) ^ QQbar(anything).

Change History (18)

comment:1 Changed 4 years ago by jdemeyer

  • Summary changed from Revert #22120 to Do not allow QQbar^QQbar powering

comment:2 Changed 4 years ago by jdemeyer

  • Description modified (diff)

comment:3 Changed 4 years ago by jdemeyer

  • Description modified (diff)

comment:4 Changed 4 years ago by jdemeyer

  • Branch set to u/jdemeyer/do_not_allow_qqbar_qqbar_powering

comment:5 Changed 4 years ago by git

  • Commit set to bd408ab8657c08cba5c5a1d74800aa65a3b65c13

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

bd408abDo not allow QQbar(1) ^ anything

comment:6 Changed 4 years ago by jdemeyer

  • Status changed from new to needs_review
  • Summary changed from Do not allow QQbar^QQbar powering to Do not allow QQbar(1) ^ anything

comment:7 follow-up: Changed 4 years ago by vdelecroix

And what about

sage: 2^(1/2)
sqrt(2)

Should integers/rationals only be powered by respectively positive integers/relative integers?

comment:8 in reply to: ↑ 7 Changed 4 years ago by jdemeyer

Replying to vdelecroix:

And what about

sage: 2^(1/2)
sqrt(2)

Should integers/rationals only be powered by respectively positive integers/relative integers?

That is not relevant to this ticket. There are many issues with powering for specific parents, but we should not mix up unrelated things. In any case, if you want to change 2^(1/2), that will certainly require a discussion on sage-devel.

comment:9 follow-ups: Changed 4 years ago by vdelecroix

You can define a^b for a nonzero complex and b complex to be exp(b log(a)) where log(a) is the principal determination of the logarithm. This is very natural and it breaks the coercion model in the very same way as ZZ^QQ from comment:7 does. Don't you think that the discussion about powering and coercion should be going on with a global viewpoint on sage-devel?

comment:10 in reply to: ↑ 9 Changed 4 years ago by jdemeyer

Replying to vdelecroix:

it breaks the coercion model in the very same way as ZZ^QQ from comment:7 does.

The fact that X is broken should never be used as an excuse to break Y too.

comment:11 in reply to: ↑ 9 Changed 4 years ago by jdemeyer

Replying to vdelecroix:

You can define a^b for a nonzero complex and b complex to be exp(b log(a)) where log(a) is the principal determination of the logarithm. This is very natural

It does indeed make mathematical sense for all subrings of CC. However, if you do that, the answer should lie in SR and not in QQbar. However, I don't think it would be very useful since SR doesn't really understand elements of QQbar:

sage: a = QQbar(1); b = QQbar(2).sqrt(); exp(b * log(a))
e^(1.414213562373095?*log(1))

comment:12 Changed 4 years ago by jdemeyer

From a pragmatic point of view, the main issue is that defining QQbar(1) ^ x (and only that) is pointless. I cannot think of any natural scenario where QQbar ^ QQbar powering would come up where the base is always QQbar(1). This is shown by the fact that the only doctests which break are the ones specifically added by #22120. That ticket also gives no motivation at all for why QQbar(1) ^ x should be allowed.

comment:13 Changed 4 years ago by jdemeyer

Note: as an alternative to this ticket, I could live with allowing QQbar × QQbar → SR powering in general. But I'm not convinced that this would be useful.

comment:14 Changed 4 years ago by vdelecroix

It would also make sense with QQbar x QQbar → CLF... but that is broken (somehow another story #24492).

comment:15 Changed 4 years ago by cheuberg

IIRC, the change in #22120 was motivated by the necessity of performing the operation in the asymptotic ring documented in that doctest there.

So if you want to revert this operation in QQbar, a deprecation is required IMHO and the asymptotic ring must be fixed to have the special case of a coefficient 1 such that the doctest there still works.

Some code accompanying a paper relying on that behaviour will be broken otherwise.

comment:16 Changed 4 years ago by jdemeyer

  • Authors Jeroen Demeyer deleted
  • Branch u/jdemeyer/do_not_allow_qqbar_qqbar_powering deleted
  • Commit bd408ab8657c08cba5c5a1d74800aa65a3b65c13 deleted
  • Milestone changed from sage-8.2 to sage-duplicate/invalid/wontfix
  • Resolution set to duplicate
  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_review to closed

Allright, let's fix this by implementing QQbar × QQbar → SR powering in general, which is at least a sensible thing to do (as opposed to only allowing powers of 1).

comment:17 Changed 4 years ago by jdemeyer

  • Milestone changed from sage-duplicate/invalid/wontfix to sage-8.2
  • Resolution duplicate deleted
  • Reviewers Jeroen Demeyer deleted
  • Status changed from closed to new

Hmm, both powering to SR and CLF have issues, it's not as easy as I thought. So I'm just going to stay away from this.

But I'll leave this ticket open because I still think that there is an issue to be fixed here.

comment:18 Changed 4 years ago by jdemeyer

  • Dependencies set to #5574
  • Description modified (diff)
Note: See TracTickets for help on using tickets.