to fix the failures

You meant line 95. Done. Cycling.

Should be just that line. Things seem to be running normal again.

I don't have write access to the GSoC repo

You do now. Admin rights are in your inbox.

Thanks.

I think I've always used a traits class, see for example has_poor_large_value_support in test_sin.cpp.

I think I've always used a traits class, see for example has_poor_large_value_support in test_sin.cpp.

Oh that is cool. Far out, I had not thought of that. I could activate tests or not-tests with a traits-class in association with if-constecpr or the Boost equivalent thereof.

I think this is the right way to evolve. Let me see if I can use that instead of the PP.

OK. So based on some sage and early review comments, we need to enable/disable tests of this new back end in a more refined and specific/exclusive way.

I'll get to work on that and then let this thing settle.

If any one else has some comments, please now is the time to add.

It is not often that we add a new back end to MP. So this is the time for comments. I think we did our homework. But please if you review and notice something awkward, then consider change requests. They will be noted.

Sure, this thing will evolve. But the more we catch prior to the first release, the better.

Thx so far.

I think I've always used a traits class, see for example has_poor_large_value_support in test_sin.cpp.

Thanks John. That'll work.

See also BoostGSoC21/multiprecision/issues/195, which is linked to the epic TODO list at BoostGSoC21/multiprecision/issues/160.

Cc: @sinandredemption and @cosurgi

@ckormanyos I'm not entirely sure why, but I am still blocked from pushing onto this branch. You'll want to wrap two of the numeric_limits members as so:

   // These members were deprecated in C++23, but only MSVC warns (as of June 25)
   #ifdef _MSC_VER
   #pragma warning(push)
   #pragma warning(disable:4996)
   #endif

   static constexpr float_denorm_style      has_denorm                    = denorm_absent;
   static constexpr bool                    has_denorm_loss               = true;

   #ifdef _MSC_VER
   #pragma warning(pop)
   #endif // deprecated members

wrap two of the numeric_limits members

Thanks Matt (@mborland). Good catch.

Cycling in 6cf9348

I am still blocked from pushing onto this branch.

I don't know where the blocker is. I added you as admin on the repo. See pic.

Maybe you have to be a member of the Org. But I can't do that?

But this thing will soon be in develop of Multiprecision anyway. So i'm not going to struggle any more for the moment. Sorry it didn't quite work out Matt. If we have any big, unexpected changes, we can try to dig deeper.

So folks, this thing is green all over. And I don't have anything else to add at the moment.

It is last call for comments.

Our final outstanding decision is if we try to rush for the 3-July-2025 deadline for 1.89? Or should we take it down a notch and merge rather end of July or beginning of August for 1.90?

Thoughts?

I have a (very) slight 1.89 preference since I'm certain when this thing gets into the wild, we will learn some lessons and evolve it anyway. But I'm a little concerned about the failing Inspect and hope that comes to its senses. (It's not a Multiprecision thing.)

Cc: @jzmaddock and @sinandredemption and @cosurgi and @mborland

Our final outstanding decision is if we try to rush for the 3-July-2025 deadline for 1.89? Or should we take it down a notch and merge rather end of July or beginning of August for 1.90?

Thoughts?

I vote merge it in. Get it in the hands of users and see what happens. There's enough testing and validation that it's a solid product, but there's always corners we'd never think about.

And I don't have anything else to add at the moment.

Upon review, I have come to the opinion that test_float_io.cpp was missing tests for cpp_bin_float (which is officially not within the scope of this PR).

So I have, nonetheless, taken the liberty to add these. Cycling now.

Cc: @jzmaddock and @mborland

OK so we got cpp_bin_float tested in test_float_io.cpp. I got greedy and, even though this was unrelated to this PR, I sneaked it in.

This thing is good to go.

Cc: @jzmaddock and @mborland and @sinandredemption and @cosurgi

This was a big one.

Please @sinandredemption accept my gratitude for your foudational work in GSoC 21. And also @cosurgi thank you for co-mentoring this.

I feel that we helped each other and only in team could we get this one.

@jzmaddock thank you for coaching and guiding us.

And thanks @mborland for finishing this one of with the perfect CI, coverage and quality label. Thereby making this thing good.

Out for now. Looking forward to QUAD-Double-Trouble.

Closing and deleting branch.

This is great! Thank you very much! :)

Well done everybody, and especially @ckormanyos for keeping this moving forwards!!

Well done everybody

Thank you John (@jzmaddock), for helping every step of the way.

I was really impressed with the tests we have in Multiprecison and the quality we have. You sure did a lot to get us there.

This new backend is an interesting one. It's not precise. It absolutely is fast within its modest digit range. Yet it might behave in subtle, diffferent ways than some clients expect from a FP-backend. I'm interested to see how this plays out in the client domain.