Quad double: Add initial/tentative support for libqd.

[jzmaddock]

See #184.

[ckormanyos]

See #184.

Awesome ! I was thinking you might start moving forward on this. Looks like a promising start...

[ckormanyos]

I would like to refresh interest in this project (and can mentor some additional potential progress on it) for Boost Google Summer of Code 2021

[jzmaddock]

SOC is a good thought, the code that's here works, needs more testing (there's one unresolved issue I think), and if possible it would be great to move this to C++ only (ie without the external library).

[ckormanyos]

SOC is a good thought, the code that's here works, needs more testing (there's one unresolved issue I think), and if possible it would be great to move this to C++ only (ie without the external library).

Agreed... on all points. I will comply in that order.

[ckormanyos]

I tried a big merge operation of today's develop onto this relatively old branch.

[ckormanyos]

Develop has been successfully merged into this branch. This is good and partially prepares the road for further work on this topic. If (or when) I personally do something on QD, I think we should simply use (re-use, continue to use) this PR.

Is that OK to keep going on QD on this PR, at least at first for a while?

[jzmaddock]

Good question, I guess if it's a GSOC project then it might be easier to fork this off into the student's own repro?

[AuroraDysis]

I tried to use qd in my program several times, but according to my experience, it has a lot of bugs. I dare say that I am not alone and there are others who experienced a similar situation. For example

ddmarshall/Code-Eli#27 (comment)

[ckormanyos]

tried to use qd in my program several times, but according to my experience, it has a lot of bugs.

Thank you for the heads up.

The intent of integrating this QD thing is to either use it (if it's good enough out of the box) or replacing entirely its algorithms under Boost licensing if it's not. At the moment, we have not fully or exhaustively estimated the work/effort in these activities, but the potential GSoC is expected to move this endeavor forward.

[anilmuthigi]

I was going through this function :

inline void eval_divide(quad_double_backend& result, const quad_double_backend& a, const quad_double_backend& b)
{
bool i1 = (boost::math::isinf)(a.data()[0]);
bool i2 = (boost::math::isinf)(b.data()[0]);
if (i1 && !i2)
result.data() = a.data();
else if (i2 && !i1)
result.data() = 0.0;
else
result.data() = a.data() / b.data();
}

Don't you think that b.data()=0.0 should be handled separately?

[jzmaddock]

Don't you think that b.data()=0.0 should be handled separately?

I guess only if the division doesn't generate an infinity anyway - and I'm assuming it does?

[ckormanyos]

going through this function

Yes. Thanks for looking.

There are a whole bunch of functions in this kind of multiprecision adaption. As this project moves on, we will be looking into this function and numerous others, re-writing some, adaptimg others, all with the common goal of getting an efficient, portable, reliable, tested QD running.

I think we wil luncover a bunch of little nuances like this one...

[jzmaddock]

I think we wil luncover a bunch of little nuances like this one...

Indeed, what I should have said was: if the special case is already handled by the hardware, then we should leave it to it on the grounds that it will be way more efficient than any code we can write.

[ckormanyos]

if the special case is already handled by the hardware

Yes John. Agreed. That's actually a detail that I'll be asking you about/discussing with you, regarding your advice and best way to/or not to do it, later in the project.