-
Notifications
You must be signed in to change notification settings - Fork 111
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
Big Variable Precision update. #318
Conversation
Update precision guards to account for the precision of *this.
Not such a big update yet, just baby steps so far. This will eventually fix #308 |
With choice of preserving source or target precision on assignment.
I just tried compiling my tests using this branch at commit 10be269. I got to the linking stage, and received an error from the linker:
I'm on MacOS 11.3, with the following for my clang version:
So, the thread local storage is an issue on my current development platform. |
Oh, that just sucks :( Are you building a shared library by any chance? Googling around, I did find plenty of references to this error message, but only when using More big updates on this soon BTW, just not (yet) for this issue... |
Improve testing further.
…pression template options.
To account for the actual type that the backend sees.
…elsewhere, [CI SKIP]
@ofloveandhate: this should be worth a serious look now. I still haven't sorted out the MacOS threading issue (not sure how to proceed on that yet), and I need to investigate setting the options at compile time. Documentation will read as follows: There are a number of types in this library whose precision can be changed at runtime, the purpose of this section is to explain how these types interoperate with each other when two variables of the same type can have different precisions. The main variable precision types being discussed here are:
Functions for setting the current working precision are as follows, with
type
We must now consider what happens in an expression such as:
There are basically 2 options here when the precision of variable and some_expression differ:
In addition we must consider what happens if some_expression contains types other than N. The behaviour of the library is controlled by the following enumerated values:
The enumerated values have the following meanings, with preserve_related_precision being the default:
As with working precision, the above options can be set or queried on either a global or thread-local level, note that these options can not be set on a per-variable basis since they control whole expressions, not individual variables:
|
This is a great step, John. Thanks for working on this! I haven't yet solved the thread local problem on macOS, so I'd really appreciate help on that one. |
I have some constructive criticism regarding the documentation. I'm writing this with my college professor hat on, seeking to make the documentation as self-contained as possible, and increase accessibility. I think a big improvement would be the addition of examples. Perhaps a table of variables at various precisions, and a column indicating how the precision policy affects the precision of an assignment after arithmetic. I think that kind of visual comparison would help make the policies make more sense to a newcomer (and me, too!). Also, if they have examples, then they don't have to write that starter code themselves. A great gift would be a small amount of copy-pastable code that should run and give some expected results in terms of precisions of variables. There're a few places that use the phrase "as above" is used; I found those confusing, because there were multiple things above and I didn't know which one was being referred to at that moment. I think that this documentation would benefit from making references within the documentation more explicit. Once I get to a state where I can compile this branch on my Mac, I can play around with the code and maybe even try to contribute to that documentation... |
for threading, is there a linker option I'm supposed to use? I use the autotools at the moment, and use the m4 macros for finding boost libraries. Since Multiprecision is a header-only library, there's no provided script for finding boost. So, I wrote my own (probably terrible) version. Is this m4 script the right place to detect and set the option I'm supposed to use so that thread local works correctly? |
Definitely, I just haven't got that far yet ;)
Will do.
I wouldn't think so.
Hmmm, how about you run the tests locally and see what command line options are used, like so:
Meanwhile, I note that there is still a thread-safety issue somewhere in the Boost.Math Bernoulli number code that I just can't track down at present.... |
Also add missing doc file. [CI SKIP]
OK, I hope I'm about done here, fleshed out docs attached. variable _precision.pdf I still don't have a way to reproduce your OS X linking issue, that may have to be dealt with as a separate |
Great thanks!!! I'm just getting back to my keyboard after a much-needed break. In the intervening time since your suggestion, and in trying to solve an issue with a different piece of software, I started over with XCode's command line tools on this computer. Now my executables are linking correctly when compiled against this branch of Multiprecision -- I added no new linker options. 🤷🏻♀️ So if it resurfaces, we'll tackle it in a separate issue. |
I have a bit more feedback on the documentation:
|
I'm following along with your tutorial, and I have the following code:
This test is "failing". I'm confused -- since the precision option is APPoS, shouldn't |
Also, in your tutorial, I think the line |
Apologies for the delay in getting back to you - and many thanks for the comments!
OK, so there is a bug somewhere with some compiler options probably that we don't know what it is !
Done.
Done.
Hmmm, I only see it used as a type, but it is used as a precision elsewhere, so changed to "Num" to be clearer.
Good spot! Fixed. Updated docs: |
The aim of a coped object is to manage a change: here you're "changing" to it's existing default value - ie doing nothing. It does no harm of course.
In order to capture the full precision of an integer - a completely unrelated type - you need preserve_all_precision, preserve_source_precision only considers types the same as the result. |
Fixed Conflicts: include/boost/multiprecision/complex_adaptor.hpp include/boost/multiprecision/debug_adaptor.hpp include/boost/multiprecision/logged_adaptor.hpp include/boost/multiprecision/mpfr.hpp
Update precision guards to account for the precision of *this.