Boost logo

Boost :

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-04 17:24:40


>> When you do something like "get_constant_pi()", I see you >> are "warm-caching" the result from the first computation. Great. >> >> Just to double-check... >> I see the static bool flag, right? It's warm-cached, right? Yes. OK. >> Please confirm: >The constants are initialized prior to the start of main - so they're thread safe as long as only one thread executes prior to main. I have struggled with this issue before. Maybe you help me out. The bool "is_initialized" flags are local statics in template subroutines. A subroutine local static will be initialized once, but not prior to main(), rather the first time the subroutine is executed, i.e., the first time it's called by a user. Is this even right, or are templates somehow special? So if thread1 starts initializing the warm-cached representation of pi and thread2 of higher priority interrupts this halfway through, then thread2 will complete the initialization fully and return. Thread1 subsequently continues its initialization of the, well, already initialized representation of pi. I think it's harmless, though highly confusing. But when push comes to shove, I think I have historically made a subtle mistake in this matter. The is_initialized flag (which is actually a kind of manual "guard-variable") should be set to true *after* initializing the representartion of pi. Am I just plain wrong here, or is it really this confusing/subtle, etc.? I don't want to introduce <atomic> or <mutex>. Thanks, Chris. >> Would you like to "seed" common constants such as pi, e, sqrt2, ln2, etc. >> with a known string representation of, say, a few hundred digits? >> Or is reading the string slower than computing the value? > Ah, good point, oversight on my part.  I've just committed an update that uses your 1100 digit values to initialize when possible. > John. Excellent! Thanks.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk