They still don't add up to something near the original input value - but nor should they. ... if we want to add in base 10, we need to first convert those hex values to *106* bit precision decimal values.

Okay. That makes no sense to me at all.

Given this comes from you, and is math, I pretty much know I'm wrong here. But ...

And now I'm wondering if your hardware double-double implementation is the same thing as the double-double I was referring to.

Which in summary, uses pairs of doubles, to achieve greater precision by splitting the values into two parts and storing the hi part and the lo part in the pair. Thus, when the two parts are added together, they form the complete value.

Now, the two parts cannot have more than 53-bits of precision each; so the idea that "if we want to add in base 10, we need to first convert those hex values to *106* bit precision decimal values." doesn't make sense to me.

Where does the extra precision for each of the two values, before combining them, come from?

Half of my brain is saying: this is the classic binary representation of decimal values thing; but in reverse.

Not so sure that splitting the values on the basis of the Math::BigFloat values can provide correct 106-bit values

And the other half is saying: M::BF may not be the fastest thing in the arbitrary precision world; but it is arbitrary precision, so surely when it gets there, the results are accurate?

By now you're probably slapping your forehead saying: "Why doesn't he just install Math::MPFR!"

And the answer is, I don't want an arbitrary precision or multi-precision library. I'm only using M::BF because it was on my machine and a convenient (I thought) way to test a couple of things to do with my own implementation of the double-double thing (per the paper I linked).

One of which is to write my own routines for outputting in hex-float format (done) and converting to decimal. I was working on the latter when I need to generate the binary decimal constants and here I am.

So why not just use someone else's library?

1. My aversion to incorporating the kitchen sink when all I need is the plug.

   MFPR probably requires half dozen other libraries, all of which are probably monolithic monsters in their own right; and almost certainly won't compile using MSVC.

   I know you probably provide a PPM at your repository; but will it work with the version of MSVC I using. Probably not.

   So why not upgrade to a later version? Because the only version now available from MS won't install on Vista. So why not upgrade from Vista? Because it costs money. I probably will when I upgrade my motherboard and cpu sometime next year.

   So why not just use MingW? Because my clients don't use that; and because I don't like it.

2. Ultimately, the intent is to convert the add, subtract and multiply routines that I need to assembler.

   Using, if and where possible, whatever MMX or SIMD instructions lend themselves to the purpose.

   The routines will be called from (Inline) C as the current double implementation is.

   The desire is to first get more precision (hence double-double), then more speed, by attempting to apply SIMD multiply-add to whole scan-lines of the mandelbrot set that are the background to all of this.

   So, ultimately, I don't need a Perl library (Math::MPFR); don't want the agony of trying build OSS libraries using MSVC; and won't achieve my goal by adding some huge pile of (clever) but (if typical of the breed) macro-hell, unintelligible code to my project.

3. Finally, I'm obviously not understanding the subtleties of the way the restrictions of the machine representations are affecting the math.

   I mean; how hard can it be to add two numbers together, right. And yet; here I am struggling to understand how to add two numbers together.

   And that is all the reason -- and possibly the best reason -- for persisting in my goal of writing my own implementation of the double-double representation.

Oooh! I feel so much better for having got that off my chest :) I realise that I've probably lost your patronage for my endeavour in the process; but so be it.