{"action":"created","issue":{"url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/50","repository_url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound","labels_url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/50/labels{/name}","comments_url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/50/comments","events_url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/50/events","html_url":"https://github.com/km-git-acc/dbn_upper_bound/issues/50","id":302460183,"number":50,"title":"Potential divide and conquer strategy?","user":{"login":"km-git-acc","id":35831522,"avatar_url":"https://avatars1.githubusercontent.com/u/35831522?v=4","gravatar_id":"","url":"https://api.github.com/users/km-git-acc","html_url":"https://github.com/km-git-acc","followers_url":"https://api.github.com/users/km-git-acc/followers","following_url":"https://api.github.com/users/km-git-acc/following{/other_user}","gists_url":"https://api.github.com/users/km-git-acc/gists{/gist_id}","starred_url":"https://api.github.com/users/km-git-acc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/km-git-acc/subscriptions","organizations_url":"https://api.github.com/users/km-git-acc/orgs","repos_url":"https://api.github.com/users/km-git-acc/repos","events_url":"https://api.github.com/users/km-git-acc/events{/privacy}","received_events_url":"https://api.github.com/users/km-git-acc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":116,"created_at":"2018-03-05T20:58:43Z","updated_at":"2018-03-18T15:09:28Z","closed_at":null,"author_association":"OWNER","body":"@rudolph-git-acc and @mariotrevi\r\n\r\nFew days back, I had noticed in the fourth thread at Prof. Tao's blog you were focused on the Ceff term, and improving Ht precision at smaller values of x, while I have been working more on the medium values of x.\r\n\r\nThis could be a good divide and conquer strategy in light of the fifth thread. Do let me know if there are any thoughts on this, and if we can help each other more."},"comment":{"url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/comments/374006669","html_url":"https://github.com/km-git-acc/dbn_upper_bound/issues/50#issuecomment-374006669","issue_url":"https://api.github.com/repos/km-git-acc/dbn_upper_bound/issues/50","id":374006669,"user":{"login":"km-git-acc","id":35831522,"avatar_url":"https://avatars1.githubusercontent.com/u/35831522?v=4","gravatar_id":"","url":"https://api.github.com/users/km-git-acc","html_url":"https://github.com/km-git-acc","followers_url":"https://api.github.com/users/km-git-acc/followers","following_url":"https://api.github.com/users/km-git-acc/following{/other_user}","gists_url":"https://api.github.com/users/km-git-acc/gists{/gist_id}","starred_url":"https://api.github.com/users/km-git-acc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/km-git-acc/subscriptions","organizations_url":"https://api.github.com/users/km-git-acc/orgs","repos_url":"https://api.github.com/users/km-git-acc/repos","events_url":"https://api.github.com/users/km-git-acc/events{/privacy}","received_events_url":"https://api.github.com/users/km-git-acc/received_events","type":"User","site_admin":false},"created_at":"2018-03-18T15:09:28Z","updated_at":"2018-03-18T15:09:28Z","author_association":"OWNER","body":"@mariotrevi @rudolph-git-acc \r\n\r\nAttaching my updated script which can now run on an adaptive mesh. \r\n\r\n[Ht_adaptive_mesh_v2.txt](https://github.com/km-git-acc/dbn_upper_bound/files/1822765/Ht_adaptive_mesh_v2.txt)\r\n\r\nAlso attaching a sample run I ran between x = 500 and 520 (stopped around 511) to test the script.\r\n\r\n[Ht_adaptive_mesh_sample_run.txt](https://github.com/km-git-acc/dbn_upper_bound/files/1822767/Ht_adaptive_mesh_sample_run.txt)\r\n\r\nActually a csv file. The structure of the file is\r\n\r\nx\ttheta_c\tD\tH/B0\t|H/B0|\t|(A+B-C)/B0|\t|(NQ_[A+B-C])/B0|\t|H_tail/B0|\t|ddx_Ht_tail/B0|\r\n\r\nThere are several changes in the script.\r\n1) The (th+u) factor in the J integral bound has been changed to sqrt(th^2+u^2) which results in around a 1.33 improvement in the ddx_Ht_bound (close to the sqrt(2) expectation)\r\n2) n0 has been set to max(1,floor(sqrt(x/Pi)). I noticed that keeping this keeps the tails at a relative error between 10^-15 and 10^-12. Capping n0 to 16 for x>1000 was resulting in a relative error of around 10^-7, so I removed the cap. Also, this means passing the n0 parameter to the functions is redundant for now and that it has no default value, but haven't removed n0 from the passed parameters list at the top of the functions. \r\n3) Functions for the old integral Ht_int_old and ddx_Ht_int_old have been added, which would be useful at very small x, where the I and J integral explode.\r\n\r\nAlso, right now the script just outputs to the calculator screen. Will update my script so it can write to a file.\r\n\r\nIn terms of the output, I was earlier planning to compute the exact ddx_Ht_integral but then felt why not just use a proxy newton_quotient_(A+B-C), which shows a good match. We are not using the exact ddx_integral to decide the next mesh point, only the derivative upper bound, so it does not affect the exercise. Removing it doubles our overall speed, since now there is only the I integral which is being evaluated. There is also the J bound integral but it is much faster. I was wondering why the J bound integral gives correct results even with lower precision and mstep=1. All it requires is the correct n0. Maybe because the result values are fairly large, and the oscillation in the integrand has been killed while calculating the bound.\r\n\r\nRunning the mesh between 500 and 511 took around 56 minutes, so overall this is still a long exercise. I am planning to keep it running it till 600.\r\n\r\nOne idea I am wondering about. Anonymous had some time back posted Ht evaluations between 1000 to 1600.\r\nhttps://pastebin.com/NkFKs3pB\r\nhttps://pastebin.com/k7vC6e7n\r\n\r\nWe can randomly check a few values to see how many digits are accurate. If it is fairly accurate, then we could use it to skip some computations while running the mesh. As a hypothetical example, suppose we generated data for 1200.07 and the next mesh point to be evaluated is 1200.11, then we can instead use the mesh point of 1200.1, generate the required data, and generate the next mesh point from 1200.1. \r\nSomewhat complicated, but if done properly, it could reduce our overall time required by maybe 30-40% if not more, given that the average mesh gap right now is almost 0.05.  \r\n\r\n\r\n"}}
{"actor":{"display_login":"km-git-acc"}}