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

Embeddings vs places #491

Open
1 of 3 tasks
thofma opened this issue Dec 18, 2021 · 0 comments
Open
1 of 3 tasks

Embeddings vs places #491

thofma opened this issue Dec 18, 2021 · 0 comments

Comments

@thofma
Copy link
Owner

thofma commented Dec 18, 2021

We are a bit sloppy and not really distinguishing embeddings and infinite places. So far this has been fine. For CM types one needs to work with complex embeddings and one needs to distinguish between conjugated ones. In #490 I do this by using an infinite place and storing a flag isconjugated::Bool. But this is awkward. It is also a bit sneaky/questionable that we allow evaluate(a, P) for an infinite place P and for it to mean the image under (one of the) embedding(s) and not the image of the absolute valuation (which I believe would be the correct thing).

It really feels strange to now put the embeddings on top of the places. It should be the other way around. We should have embeddings and build the places on top of that.

It could also be that we never actually needed places in the first? It seems that the complex places are not actually used anywhere.

What are your thoughts @fieker?

Here is a proposal if we want to keep places and introduce embeddings properly:

Here is a proposal:

  1. Implement embeddings "from scratch". By "from scratch" I mean not using the infrastructure for places.
  2. Swap the implementation of the places to use embeddings.
  3. If P is an infinite place, P(a) will denote |v(a)| where v is an embedding defining P. If v is an embedding, v(a) will just be the embedding (what is now evaluate).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant