{"action":"created","issue":{"url":"https://api.github.com/repos/boostorg/multiprecision/issues/75","repository_url":"https://api.github.com/repos/boostorg/multiprecision","labels_url":"https://api.github.com/repos/boostorg/multiprecision/issues/75/labels{/name}","comments_url":"https://api.github.com/repos/boostorg/multiprecision/issues/75/comments","events_url":"https://api.github.com/repos/boostorg/multiprecision/issues/75/events","html_url":"https://github.com/boostorg/multiprecision/issues/75","id":351847905,"node_id":"MDU6SXNzdWUzNTE4NDc5MDU=","number":75,"title":"precision-semantics policy","user":{"login":"ofloveandhate","id":1388063,"node_id":"MDQ6VXNlcjEzODgwNjM=","avatar_url":"https://avatars0.githubusercontent.com/u/1388063?v=4","gravatar_id":"","url":"https://api.github.com/users/ofloveandhate","html_url":"https://github.com/ofloveandhate","followers_url":"https://api.github.com/users/ofloveandhate/followers","following_url":"https://api.github.com/users/ofloveandhate/following{/other_user}","gists_url":"https://api.github.com/users/ofloveandhate/gists{/gist_id}","starred_url":"https://api.github.com/users/ofloveandhate/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ofloveandhate/subscriptions","organizations_url":"https://api.github.com/users/ofloveandhate/orgs","repos_url":"https://api.github.com/users/ofloveandhate/repos","events_url":"https://api.github.com/users/ofloveandhate/events{/privacy}","received_events_url":"https://api.github.com/users/ofloveandhate/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":23,"created_at":"2018-08-18T20:11:41Z","updated_at":"2018-08-31T19:02:34Z","closed_at":null,"author_association":"NONE","body":"*edit:* i changed the title of this issue from \"writing a complex class using `mpfr_float` that is precision-semantically equivalent to the new `mpc` type\".\r\n\r\nwithin the Boost.Multiprecision library, there are some precision rules:\r\n\r\n- Copying or move-assignment copies the precision of the source.\r\n- Assignment keeps the precision of the target.\r\n\r\nfor legacy purposes, i have to keep supporting users of my library with Boost versions that do not contain the new `mpc` implementation of complex numbers.  i want my type to be precision-semantically identical with `mpc`.  i am struggling with one thing, and, while i know this isn't a Boost.Mutiprecision issue *per se*, since it is a use of bmp, i am hoping for some help.  \r\n\r\nif this is too off-topic, please **politely** decline -- i'm feeling anxious about asking this already, admitting that i am ignorant about this; i'm a mathematician first and a programmer second.\r\n\r\n---\r\n\r\nmy class is the \"obvious\" implementation of complex numbers with a `bmp::mpfr_float` as the real and imaginary fields, and all the typical operator overloading, etc.  it's not elegant but it works.\r\n\r\nmy one and only family of failing tests relate to mixed precision arithmetic.  when i take complex's `a` and `b`, at different precisions, and say add them, stuffing them into a previously existing `z` at some other precision, the `mpc` policy is that `z` should be at its same precision after the arithmetic.  however, with RVO and move assignment in the mix, **my** `z` ends up at whatever precision the result is at.  i can fix this by making the move assignment operator preserve precision, but this breaks moving.  no good.  i feel like i need to distinguish between moving and these cases coming from arithmetic, but that it's an impossible problem without re-writing the whole thing using ET's and basically replicating Boost.Multiprecision, a non starter.\r\n\r\nhere's the test that fails **for my naive implementation**, whereas this test passes for the glorious new `mpc` implementation:\r\n```\r\nBOOST_AUTO_TEST_CASE(complex_precision_predictable_add)\r\n{\r\n\tDefaultPrecision(30);\r\n\tbertini::mpfr_complex a(1,2);\r\n\r\n\tDefaultPrecision(50);\r\n\tbertini::mpfr_complex b(3,4);\r\n\r\n\tDefaultPrecision(70);\r\n\tbertini::mpfr_complex c(5,6);\r\n\r\n\ta = b+c;\r\n\tBOOST_CHECK_EQUAL(Precision(a),30);\r\n\r\n\tDefaultPrecision(90);\r\n\ta = b+c;\r\n\tBOOST_CHECK_EQUAL(Precision(a),30);\r\n}\r\n```\r\n\r\nmy obvious overload for `+`:\r\n```\r\ninline custom_complex operator+(custom_complex const& lhs, const custom_complex & rhs){\r\n\t\treturn custom_complex(lhs.real()+rhs.real(), lhs.imag()+rhs.imag());\r\n\t}\r\n```\r\n\r\nshould i give up and just accept that because of RVO and move assignment that, without expression templating my type and basically recreating Boost.Multiprecision itself at some level, this is an impossible problem to solve?\r\n\r\nmy genuine thanks for any consideration.   🙇‍♀️ "},"comment":{"url":"https://api.github.com/repos/boostorg/multiprecision/issues/comments/417761282","html_url":"https://github.com/boostorg/multiprecision/issues/75#issuecomment-417761282","issue_url":"https://api.github.com/repos/boostorg/multiprecision/issues/75","id":417761282,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNzc2MTI4Mg==","user":{"login":"ofloveandhate","id":1388063,"node_id":"MDQ6VXNlcjEzODgwNjM=","avatar_url":"https://avatars0.githubusercontent.com/u/1388063?v=4","gravatar_id":"","url":"https://api.github.com/users/ofloveandhate","html_url":"https://github.com/ofloveandhate","followers_url":"https://api.github.com/users/ofloveandhate/followers","following_url":"https://api.github.com/users/ofloveandhate/following{/other_user}","gists_url":"https://api.github.com/users/ofloveandhate/gists{/gist_id}","starred_url":"https://api.github.com/users/ofloveandhate/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ofloveandhate/subscriptions","organizations_url":"https://api.github.com/users/ofloveandhate/orgs","repos_url":"https://api.github.com/users/ofloveandhate/repos","events_url":"https://api.github.com/users/ofloveandhate/events{/privacy}","received_events_url":"https://api.github.com/users/ofloveandhate/received_events","type":"User","site_admin":false},"created_at":"2018-08-31T19:02:34Z","updated_at":"2018-08-31T19:02:34Z","author_association":"NONE","body":"that's fine!  all are welcome!"}}
{"actor":{"display_login":"ofloveandhate"}}