- Boost - lists.boost.org

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

Am 11.03.23 um 11:44 schrieb John Maddock via Boost: > On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: - The support for XX_v is omitted. - Additional macros BOOST_FLOATxx_C_OR_ZERO are needed. - boost::multiprecision::float128 is now constexpr if possible. > Off the top of my head I see two main correctness issues: > * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me> I am not sure if this is actually true. When testing with pi the results were identical. If this should be generally so (testing) we can save the helper macros BOOST_FLOATxx_C_OR_ZERO and use the general version. In the code the general version is available, but commented out. > * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). Instead of lexical_cast, the constructor(sting) is now used - had overlooked that. Is the accuracy sufficient? > * It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. As said boost::multiprecision::float128 works now. Are there any other cases? Exactly with boost::multiprecision::float128 it is noticed negatively that there are 3 code paths: - gcc (BOOST_MP_USE_FLOAT128) - intel (BOOST_MP_USE_QUAD) - in general This was also the reason for my other posting - quadmath as a standalone library. Then there would be only 2 code paths and the quadmath lib could be implemented more understandable. Eg there is in cstdfloat_iostream.hpp AND cstdfloat_cmath.hpp the stream operator<<. This is completely unnecessary effort. You have expressed concerns that with these measures the code would have to be adapted - which nobody likes to do. But in the train with C++23-FP types this must be done anyway - then please correctly. Gero

1 0

Re: [boost] Master branch is now open for bug fixes
by Glen Fernandes 16 Mar '23

16 Mar '23

On Thursday, March 16, 2023, John Maddock via Boost <boost(a)lists.boost.org> wrote: > > I'd like to merge two bug fixes from Multiprecision into master if > possible: > > * This one is a flat out correctness-bug that really should go in: > https://github.com/boostorg/multiprecision/pull/542 > > * This one is a more nice to have fix to the conversion operators: > https://github.com/boostorg/multiprecision/pull/543 > > > Go ahead Glen

1 0

Re: [boost] Master branch is now open for bug fixes
by John Maddock 16 Mar '23

16 Mar '23

On 16/03/2023 15:38, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I'd like to merge two bug fixes from Multiprecision into master if possible: * This one is a flat out correctness-bug that really should go in: https://github.com/boostorg/multiprecision/pull/542 * This one is a more nice to have fix to the conversion operators: https://github.com/boostorg/multiprecision/pull/543 In both cases the one CI failure, is a network timeout on the drone runner pulling Boost down. Thanks, John.

1 0

Master branch is now open for bug fixes
by Marshall Clow 16 Mar '23

16 Mar '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> The next deadline: On April 5th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

1 0

Re: [boost] [Release] Master branch is closed for beta
by Andrey Semashev 16 Mar '23

16 Mar '23

On 3/9/23 17:19, Marshall Clow via Boost wrote: > Master is closed for all changes. > > See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> Is the master branch open now?

1 0

[release] Boost 1.82.0 beta 1 released
by Marshall Clow 15 Mar '23

15 Mar '23

Boost release 1.82.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ The SHA256 checksums are: efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 Release notes (still need updates): https://www.boost.org/users/history/version_1_82_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 15 Mar '23

15 Mar '23

Robert Ramey via Boost <boost(a)lists.boost.org> writes: > On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote: > > > This implicit "if you don't include the header then you don't need to > > link the dependency" approach doesn't scale well to cases where Boost is > > split into individual packages which are managed by a package manager. > > Right. This is a built-in deficiency of the package manager approach. > Dependencies are dependent upon the actual end user application and cannot > be logically discerned a priori by any package manager. They cannot be "magically" discerned but there can be a mechanism for specifying them explicitly. I don't believe we are disagreeing about the fundamental issues, which is that there needs to be support for optional dependencies. The difference is that you seem to advocate implicit discovery (and ongoing maintenance) of optional dependencies by the end-user (based on linker errors, by carefully studying the documentation, etc) while I advocate having an explicit mechanism in the package manager for the library author to specify which functionality is optional (and that requires optional dependencies) and for the library user to request this optional functionality (and automatically get the required dependencies). We have such a mechanism in build2, in our experience it works well, and we have applied it to the Boost libraries. > Contrary to what one would hope, the package manager is not a panacia > and trying to make it into one is a hopeless quest which leads to > pointless efforts to "eliminate dependencias" and create "standalone" > libraries. That's quite a bizarre perspective, seeing that the main functionality of a package manager is to make management of dependencies easier. It also doesn't match empirical evidence. For example, in Rust it's hard to find a package that doesn't have at least a few dozens dependencies (and more often a few hundreds). If anything, the problem is actually the opposite.

1 0

Re: [boost] v1.81.0 web page: operators library links to utility
by Andrey Semashev 15 Mar '23

15 Mar '23

On 3/15/23 07:04, Gavin Lambert via Boost wrote: > On 15/03/2023 16:33, Brook Milligan wrote: >> I’m not sure who to report this to, but it seems to me that on the >> web page for Boost v1.81.0 docs, the Operators library link is to >> Utility not Operators. > Boost.Operators isn't actually a real library; it's part of > Boost.Utility. But it does have the wrong link. > > For reference: > > - Page: https://www.boost.org/doc/libs/1_81_0/ > - Link target: > https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm > - Actual page: > https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… > > It looks like this broke as of Boost 1.78. libs/utility/operators.htm exists and redirects to doc/html/utility/utilities/operators.html.

1 1

Re: [boost] v1.81.0 web page: operators library links to utility
by Gavin Lambert 15 Mar '23

15 Mar '23

On 15/03/2023 16:33, Brook Milligan wrote: > I’m not sure who to report this to, but it seems to me that on the > web page for Boost v1.81.0 docs, the Operators library link is to > Utility not Operators. Boost.Operators isn't actually a real library; it's part of Boost.Utility. But it does have the wrong link. For reference: - Page: https://www.boost.org/doc/libs/1_81_0/ - Link target: https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm - Actual page: https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… It looks like this broke as of Boost 1.78.

1 0

v1.81.0 web page: operators library links to utility
by Brook Milligan 15 Mar '23

15 Mar '23

I’m not sure who to report this to, but it seems to me that on the web page for Boost v1.81.0 docs, the Operators library link is to Utility not Operators. Cheers, Brook

1 0