<p>I will assume the question is as follows: We are given a number specified as a sequence of decimal digits that possibly includes a decimal fraction, and possibly makes use of scientific notation. How do we correctly convert this number into one of the binary floating-point formats specified by the <a href="https://en.wikipedia.org/wiki/IEEE_floating_point#IEEE_754-2008" rel="nofollow">IEEE 754</a> floating-point standard, i.e. <code>binary16</code> (half precision), <code>binary32</code> (single precision), <code>binary64</code> (double precision), or <code>binary128</code> (quadruple precision)?</p>

<p>As you noted, most decimal numbers cannot be represented exactly in a binary floating-point format. That means we need to chose one of the IEEE-754 rounding mode that should be used to determine the final result: Round towards positive infinity ("up"), round towards negative infinity ("down"), round towards zero (truncate), or round towards-nearest-or-even ("nearest"). Decimal-to-binary conversion typically uses the last mode listed, round towards-nearest-or-even, as this minimizes overall error in the conversion.</p>

<p>Conceptually, our task is simple. Carry out the conversion process until we have generated enough bits to make a correct rounding decision. Clearly, we will often need more bits than provided by the target format. However, we cannot tell a-priory exactly how many bits we will need, as some hard to round cases will generate results very close to a tie-case. The take-home message is that some parts of our algorithm will require the use of some sort of extended precision (or multi-precision) arithmetic, and we need to develop a criterion for determining when we have generated enough bits for correct rounding.</p>

<p>The fundamental algorithms for correct conversions were developed over a couple of decades in the past century, and are described in the following publications:</p>

<p>David W. Matula, "In-and-out conversions". <em>Communications of the ACM</em>, Vol. 11, No. 1 (Jan. 1968), pp. 47-50<br></p>

<p>David W. Matula,  "A Formalization of Floating-Point Numeric Base Conversion". <em>IEEE Transactions on Computers</em>, Vol 10, No. 8 (Aug. 1970), pp. 681-692 (<a href="http://www.acsel-lab.com/arithmetic/arith1/papers/ARITH1_Matula.pdf" rel="nofollow">online</a>)</p>

<p>William D. Clinger, "How to Read Floating Point Numbers Accurately". <em>SIGPLAN Notices</em>, Vol. 25, No. 6 (June 1990), pp. 92-101 (<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&amp;rep=rep1&amp;type=pdf" rel="nofollow">online</a>)</p>

<p>David M. Gay, "Correctly rounded binary-decimal and decimal-binary conversions". Technical Report 90--10, AT&amp;T Bell Laboraties, November 1990. (<a href="http://ampl.com/REFS/rounding.pdf" rel="nofollow">online</a>)</p>

<p>A fresh look at this research area is provided by the following publications:</p>

<p>Michel Hack, "On Intermediate Precision Required for Correctly-Rounding Decimal-to-Binary Floating-Point Conversion." In <em>Proceedings of Real Numbers and Computers (RNC'6)</em>, Nov. 2004, pp. 113-133 (<a href="https://www.researchgate.net/profile/Jean-Michel_Muller/publication/253481041_A_proven_correctly_rounded_logarithm_in_double-precision/links/54db2cc50cf2ba88a68f5354.pdf#page=114" rel="nofollow">online</a>)</p>

<p>Aubrey Jaffer, "Easy Accurate Reading and Writing of Floating-Point Numbers". arXiv:1310.8121, draft v6 (Jan. 2015), (<a href="https://arxiv.org/abs/1310.8121" rel="nofollow">online</a>)</p>

<p>Although the fundamental algorithms have been around for twenty-five years, they are of considerable complexity, and the "devil is in the details". <em>Correct</em> implementations of decimal-to-brinary conversions continue to prove elusive. Over the past 5 years, Rick Regan's blog <a href="http://www.exploringbinary.com/" rel="nofollow">"Exploring Binary"</a> has chronicled a number of defects in the decimal-to-binary conversion functionality of widely used software, such as 
<a href="http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/" rel="nofollow">Microsoft Visual C/C++</a>, 
<a href="http://www.exploringbinary.com/glibc-strtod-incorrectly-converts-2-to-the-negative-1075/" rel="nofollow">glibc</a>, 
and <a href="http://www.exploringbinary.com/a-better-fix-for-the-php-2-2250738585072011e-308-bug/" rel="nofollow">PHP</a>, 
where the last item would cause an infinite loop that might be exploited for denial-of-service attacks.</p>

<p>A paper by Vern Paxson and William Kahan addresses the issue of hard-to-round cases in decimal-to-binary conversion, and gives some examples that demonstrate how many additional bits beyond target precision may be required for correct rounding:</p>

<p>V. Paxson and W. Kahan, "A Program for Testing IEEE Decimal–Binary Conversion". Manuscript, May 1991 (<a href="http://www.icir.org/vern/papers/testbase-report.pdf" rel="nofollow">online</a>)</p>

<p>Additional hard-to-round cases for IEEE-754 <code>binary64</code> were listed in a 1996 <a href="https://groups.google.com/forum/#!original/comp.arch.arithmetic/uDGiskofu4I/stg9JR8vXE0J" rel="nofollow">posting</a> to the newsgroup <code>comp.arch.arithmetic</code> by Fred Tydeman.</p>

<p>The following paper describes a test framework for testing conversions, however the files containing the test vectors were no longer accessible online the last time I checked:</p>

<p>Brigitte Verdonk, Annie Cuyt, and Dennis Verschaeren. "A precision-and range-independent tool for testing floating-point arithmetic II: conversions." <em>ACM Transactions on Mathematical Software</em>, Vol. 27, No. 1 (Mar. 2001), pp. 119-140. (<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7408&amp;rep=rep1&amp;type=pdf" rel="nofollow">draft online</a>)</p>
How do you convert from binary to IEEE754 when the last decimal isn't 5?
<p>Everything I can find on this says to simply multiply by 2 until the decimal resolves to zero, but this only works if the last decimal is 5. </p>

<p>In my particular case the number to convert is 98765.4321, how would I convert this (or any other decimal that doesn't resolve) to IEEE754?</p>