Re: Singles to Doubles

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"dpb" <none@xxxxxxx> wrote in message news:f7l5rp$iqn$1@xxxxxxxxxxx
The part about assuming whether the number came from base 10 or was
possibly from somewhere else I don't understand at all. In the context of
VB, all external representations are base 10 unless explicitly coded as
Hex$ or Oct$ in which case the base is also known and explicit. There is
no assumption of base ever required, the only "assumptions" in what I was
trying to describe had to do with what one is to assume trailing digits
are for added precision when there isn't any information
providing them.

The number could have come from anywhere. It could have been passed to VB by
some external hardware, from a database, from a file or from a webpage. When
we have a single or double stored by VB we can't assume that number was
originally base 10. Hence we can't apply optimisations on the conversions
from single to double based on the assumption that the number is a base 10
number. Base 10 is simply the method VB usually (but not always) choses to
display the number. Karls method of converting to a string and back to a
double is what I would consider an optimisation based on the assumption the
binary number represents a base 10 number.

To see what is going on internally, find Tony's post and paste his code in
and look at the actual bit patterns and it will probably become much more
clear. Or, google on "floating point conversion" or similar and amongst
the zillion of hits pretty early on there will be sites that have floating
point calculators that you can type numbers into and see their internal
representations.

I know what's going on internally, I wrote something in dot net so I could
remind myself (having uint and ulongs it was much easier). I've written my
own 32bit maths routines in assembly language for the 8051 which is an 8 bit
processor so I know this stuff well enough. I didn't write floating point
routines but writing integer maths routines gave me a good idea of what's
going on.

Again, I heartily recommend at least reading through Goldberg's paper even
if you don't study it in depth...

http://docs.sun.com/source/806-3568/ncg_goldberg.html

I'll have a look when I get a chance.

Michael


.

Relevant Pages

  • Re: Floating Point Rounding Mode
    ... I think the differences may arise due to co-processor differences Brian, ... rather than rounding modes. ... > type conversions done by C and FORTRAN use the chop rounding mode, ... > sure what happens during general floating point math operations using VB ...
    (microsoft.public.vb.general.discussion)
  • Re: question on conversion
    ... floating point number is usually larger than the largest integer. ... and the semantics of assigning a "too-large value" ... to an unsigned integer are well defined, ... It's true for integer-to-unsigned conversions, ...
    (comp.lang.c)
  • Re: VC++7.1 to 8.0 change, casting NaN or infinity to integer differs
    ... type to that integral type has undefined behaviour according to the C++ ... numeric conversions in a configurable manner. ... would only happen due to floating point inaccuracies, ... AND, these floating point ...
    (microsoft.public.vc.language)
  • Re: very confused....hex to decimal
    ... the conversions that you observe indicate) than your "expected" result. ... You must be attempting to convert the binary representation of a floating ... point number to a floating point decimal representation -- This cannot be ... Dick ...
    (microsoft.public.dotnet.languages.vb)