quad_float arch and design

[ckormanyos]

This conversation is intended to discuss architecture and design of the upcoming BSL licensed quad_float class.

• Should it be a separate template?
• Should it be based on an instantiation of the double_float class iteself?
• Thoughts?

[sinandredemption]

Although we still have a lot of work to do on double_float before getting started with quad_float, I have one idea regarding quad_float in mind that I would like to share.

A possibility would be to construct quad_float as a cpp_double_float< cpp_double_float<native_float> > (option two in Chris' list), but specialize some of the functions (esp. multiplication) so as to increase efficiency. Although I haven't worked it out, it seems to me this method would be the quickest way to get a quad_float class up and running with minimal code.

[ckormanyos]

See also this post

[ckormanyos]

construct quad_float as a cpp_double_float< cpp_double_float<native_float> >

This idea definitely moves forward. I think this would amount to a kind of template specialization of a template type. If, or when, doing this, the underlying double_float class can no longer static_assert on the characteristics of std::numeric_limits<>::is_iec559. But this is already the case for GCC/clang quadmath.

I think this idea will also require both the same amount of non-member binary arithmetic and comparison operators (to be found by ADL) as well as its own separate implementation of syntactic code for the number backend requirements. But this is sort of expected anyway.

There might be some significant savings on I/O streaming code, and keeping that non-redundant. But that will mean the underlying class needs to implement this and such things quite generically.

[sinandredemption]

the underlying double_float class can no longer static_assert on the characteristics of std::numeric_limits<>::is_iec559.

The only place cpp_double_float<> currently does this in function split(), which shoudn't be too hard to specialize.

There might be some significant savings on I/O streaming code, and keeping that non-redundant.

Also, there might be significant savings on division and other math functions (most of which aren't coded yet, e.g. trig, exponential etc) as well.

But that will mean the underlying class needs to implement this and such things quite generically.

So far I have coded things keeping a non-native FloatingPointType in mind. So this shouldn't be a problem after a little bit of refactoring here and there.

[ckormanyos]

... savings on division and other math functions (most of which aren't coded yet, e.g. trig, exponential etc) as well.

Absolutely.

We have not yet thouroughly discussed power/trigonometric/hypertrigonometric elementary special functions yet. Some of my personla favorite implementation methods include Pade approximations combined with argument scaling, power series or Newton-Raphson iteration. In the latter two, these can be programmed generically and in a type-non-specific way.

[sinandredemption]

Due to the failing cascade construction issue, it has been decided to work on quad_float as a separate class with it's own arithmetic methods. Meanwhile, @cosurgi is also investigating an ingenious way of working around the precision loss in the double-float construct.

[ckormanyos]

decided to work on quad_float as a separate class

Excellent! Some refinements on the double-float construct in my recent PR #40 add specializations of eval_exp() and eval_log() for the cpp_double_float<T> class. So that class is inching closer and closer to usability/testability on the path to becoming a Multiprecision backend. I believe cpp_quad_float<T> can have similar design aspect(s).

[ckormanyos]

The architecture and design is now clear.

• Use the common exact_arithmetic struct and its static algorithmic members for both double/quad-float.
• Decide to make fully separate entities for double/quad-float other than those and a few other amounts of shared code, but the classes are independent from each other.
• Separate testing and CI.
• Follow cpp_double_float<T> model regarding multiprecision backend reqs also for quad float.

I'll close this issue now, as it seems complete. Implementation steps to be handle in follow-up issue(s).