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

height and canonical height for projective points and morphisms #14218

Closed
bhutz opened this issue Mar 3, 2013 · 34 comments
Closed

height and canonical height for projective points and morphisms #14218

bhutz opened this issue Mar 3, 2013 · 34 comments

Comments

@bhutz
Copy link

bhutz commented Mar 3, 2013

This patch implements height functionality from the initial dynamics functionality problems proposed at the 2012 ICERM semester in Complex and Arithmetic dynamics.

Builds on Trac #13130 and Trac #14217

Implements height functionality:

  • height of points
  • height of morphisms
  • local green's functions
  • canonical heights

Apply:

Component: algebraic geometry

Keywords: height, canonical, projective, dynamics

Author: Ben Hutz

Reviewer: Joao Alberto de Faria, Adam Towsley

Merged: sage-5.13.beta2

Issue created by migration from https://trac.sagemath.org/ticket/14218

@bhutz bhutz added this to the sage-5.11 milestone Mar 3, 2013
@bhutz bhutz self-assigned this Mar 3, 2013
@bhutz
Copy link
Author

bhutz commented Mar 3, 2013

Attachment: heights.patch.gz

@fchapoton
Copy link
Contributor

Changed dependencies from 13130, 14217 to #13130, #14217

@bhutz

This comment has been minimized.

@fchapoton
Copy link
Contributor

comment:3

apply trac_14218_heights.patch

@bhutz
Copy link
Author

bhutz commented May 16, 2013

comment:4

apply trac_14218_heights.patch

@jdemeyer jdemeyer modified the milestones: sage-5.11, sage-5.12 Aug 13, 2013
@fchapoton

This comment has been minimized.

@fchapoton

This comment has been minimized.

@fchapoton
Copy link
Contributor

comment:8

Attachment: trac_14218_remove_imports.patch.gz

new patch, changed the import of copy

@bhutz
Copy link
Author

bhutz commented Sep 4, 2013

comment:9

apply trac_14218_heights.patch trac_14218_remove_imports.patch

@sagetrac-jdefaria
Copy link
Mannequin

sagetrac-jdefaria mannequin commented Oct 2, 2013

Reviewer: Joao Alberto de Faria

@sagetrac-jdefaria
Copy link
Mannequin

sagetrac-jdefaria mannequin commented Oct 2, 2013

comment:10

Confirmed that the functions were returning the correct values. Also tested the functions would not accept undefined variables, here are the list of known issues found

projective_point.py:

  • green_function: kwd "precision"in should be "prec"
  • green_function: Joe's name is spelled wrong
  • global_height: lacking both a number field and precision example
  • global_height: description still says ZZ or QQ only
  • canonical_height: lacking a precision example

@bhutz
Copy link
Author

bhutz commented Oct 3, 2013

Changed dependencies from #13130, #14217 to none

@bhutz
Copy link
Author

bhutz commented Oct 3, 2013

comment:11

Fixed all the issues described above. The only change of note was that fixing the 'precision' keyword required more than just a rename. The use of the precision needed to be included throughout the green's function computation.

Since that patchbot seems to be trying to apply the patches from the closed dependencies #13130 and #14217, I've removed those from the dependency field. Hopefully that will allow the patchbot to test this patch.

@bhutz
Copy link
Author

bhutz commented Oct 3, 2013

comment:12

apply trac_14218_heights.patch trac_14218_remove_imports.patch

@sagetrac-atowsley
Copy link
Mannequin

sagetrac-atowsley mannequin commented Oct 3, 2013

comment:13

When computing the height of the constant 0 in a function field global_height gives and error. Every other constant seems fine.

R. = PolynomialRing(QQ)

A. = AffineSpace(QQ,1)

H=Hom(A,A)

f=H([0])

f.global_height()

returns

Traceback (most recent call last):
File "", line 1, in
File "_sage_input_100.py", line 10, in
exec compile(u'open("code.py","w").write("# -- coding: utf-8 --
n" + support.preparse_worksheet_cell(base64.b64decode("Ui48eD4gPSBQb2x5bm9taWFsUmluZyhRUSkKQS48eD4gPSBBZmZpbmVTcGFjZShRUSwxKQpIPUhvbShBLEEpCmY9SChbMF0pCmYuZ2xvYmFsX2hlaWdodCgp"),globals())+"
n"); execfile(os.path.abspath("code.py"))
File "", line 1, in

File "/tmp/tmpYiF_cn/code.py", line 7, in
exec compile(u'f.global_height()
File "", line 1, in

File "/home/atowsley/sage-5.12.rc0/local/lib/python2.7/site-packages/sage/schemes/affine/affine_morphism.py", line 542, in global_height
h=max([c.global_height(prec) for c in C])
ValueError: max() arg is an empty sequence

@bhutz
Copy link
Author

bhutz commented Oct 3, 2013

comment:14

Yes, missed that case. Actually, in any dimension if any one of the coordinate functions is 0 it has the same issue. The new patches catches those.

apply trac_14218_heights.patch trac_14218_remove_imports.patch

@sagetrac-atowsley
Copy link
Mannequin

sagetrac-atowsley mannequin commented Oct 6, 2013

comment:15

I found no more issues. It passed the long test.

@bhutz
Copy link
Author

bhutz commented Oct 7, 2013

Changed reviewer from Joao Alberto de Faria to Joao Alberto de Faria, Adam Towsley

@jdemeyer
Copy link

Merged: sage-5.13.beta1

@jdemeyer
Copy link

Changed merged from sage-5.13.beta1 to none

@jdemeyer
Copy link

comment:18

Sorry, but this needs work:

there are numerical precision issues on Solaris with green_function:

**********************************************************************
File "devel/sage/sage/schemes/projective/projective_morphism.py", line 1236, in sage.schemes.projective.projective_morphism.SchemeMorphism_polynomial_projective_space.green_function
Failed example:
    f.green_function(P.point([5,2],False),0,N=30)
Expected:
    1.7315451844777406965714211646
Got:
    1.7315451844777406965172110560
**********************************************************************
File "devel/sage/sage/schemes/projective/projective_morphism.py", line 1238, in sage.schemes.projective.projective_morphism.SchemeMorphism_polynomial_projective_space.green_function
Failed example:
    f.green_function(P.point([2,1],False),0,N=30)
Expected:
    0.86577259223181085968927265240
Got:
    0.86577259223181085966216759809
**********************************************************************
File "devel/sage/sage/schemes/projective/projective_morphism.py", line 1240, in sage.schemes.projective.projective_morphism.SchemeMorphism_polynomial_projective_space.green_function
Failed example:
    f.green_function(P.point([1,1],False),0,N=30)
Expected:
    0.43288629610862337434550672337
Got:
    0.43288629610862337433195419621
**********************************************************************
File "devel/sage/sage/schemes/projective/projective_point.py", line 727, in sage.schemes.projective.projective_point.SchemeMorphism_point_projective_ring.green_function
Failed example:
    Q.green_function(f,0,N=200,prec=200)
Expected:
    1.6460930160038721221892751679783564477424287857689424150860
Got:
    1.6460930160038721221892751679783564477424287857689424150656
**********************************************************************

This actually shows a bigger problem: it shows that some computations depend on machine floats and therefore are done only to 53 bits precision. In the code I see:

RealField(prec)(log(m))

this should be

RealField(prec)(m).log()

(the best solution to avoid this is simply removing from math import log)

Also, I recommend you to write once

R = RealField(prec)

and then use R(a) every where.

Also, comparisons to None should be done with is: a is None or a is not None.

@jdemeyer jdemeyer reopened this Oct 19, 2013
@bhutz
Copy link
Author

bhutz commented Oct 20, 2013

comment:19

apply trac_14218_heights.patch trac_14218_remove_imports.patch

Removed the math.log function and replaced with R.log() everywhere it occurred. That should fix the precision issue.

Fixed comparisons to None everywhere they occurred.

Also, added another input check to the error_bound kwd.

@fchapoton
Copy link
Contributor

Attachment: trac_14218_addon1.patch.gz

@fchapoton
Copy link
Contributor

comment:21

Hello,

I have added a patch which mainly cleans the doc a little bit.

for the patchbot:

apply trac_14218_heights.patch trac_14218_remove_imports.patch trac_14218_addon1.patch

By the way, did you know that you could run your own patchbot on your own tickets instead of waiting for the bot of someone else ?

@fchapoton

This comment has been minimized.

@jdemeyer
Copy link

comment:22

I suggest removing the added

from math import log

(the addon patch removes only 1 out of 2)

@bhutz
Copy link
Author

bhutz commented Oct 21, 2013

comment:23

Yes, thanks, I'll upload a new version that gets the missed one in affine_point.py as soon as my tests are done.

@bhutz
Copy link
Author

bhutz commented Oct 21, 2013

Attachment: trac_14218_heights.patch.gz

removed the log import from affine_point.py

@bhutz
Copy link
Author

bhutz commented Oct 21, 2013

comment:24

apply trac_14218_heights.patch trac_14218_remove_imports.patch trac_14218_addon1.patch

all I have to say is that I can't wait to switch to git instead of dealing with a stack of patches like this...

@jdemeyer
Copy link

comment:25

Replying to @bhutz:

all I have to say is that I can't wait to switch to git instead of dealing with a stack of patches like this...

It is perfectly fine to fold all patches into one patch.

@sagetrac-atowsley
Copy link
Mannequin

sagetrac-atowsley mannequin commented Oct 24, 2013

comment:26

Green's function works and is accurate on my computer.

@jdemeyer
Copy link

Merged: sage-5.13.beta2

@jdemeyer
Copy link

Changed author from Ben Hutz to Benjamin Hutz

@fchapoton
Copy link
Contributor

Changed author from Benjamin Hutz to Ben Hutz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants