Re: Singles to Doubles


"dpb" <none@xxxxxxx> wrote in message news:f7l5rp$iqn$1@xxxxxxxxxxx
Michael C wrote:
"dpb" <none@xxxxxxx> wrote in message news:f7k4fe$vv8$1@xxxxxxxxxxx
If, after all this you still want more, do a google on "What Every
Computer Scientist...Floating Point" and you'll be led quickly to a
very
fine paper on all the details of floating point. I thought I had a
bookmark, but can't seem to find it at present and I'm plumb tuckered
out,
sorry... :)

What you say makes sense although I'm still trying to get my head fully
around it. A binary number such as 1.11 should be converted to 1.1100 as
these 2 values are equal. *If* we assume the number came from a base 10
number then we could provide some optimisation to the binary conversion
to
make some sort of guess as to what information was lost converting it to
binary. But what we have is a binary number which could have been
obtained
from any source and might not have been a base 10 number at some stage.
Therefore to assume base 10 could be faulty.

I'm confused by your nomenclature but let me see if I can paraphrase and
add and get us closer...

A "binary number 1.11 should be converted to 1.1100 as they are equal".

If you're saying an internal representation of 1.11 (decimal) should be
displayed as 1.1100 externally under all circumstances, that can't be
unless it is one of the set of reals than can be represented exactly
(and I didn't check for sure). In that case it _will_ be preserved both
in i/o and in promotion.

If otoh it can't be represented exactly as a Single, then the likelihood
that it can in Double isn't zero, but the problem of translation to/from
the external representation arises, as does that of promotion. The VB
i/o rtl is in a way a culprit in masking these problems because Print
(and friends) _do_ incorporate logic in them to try their darnedest to
make "ugly" values "pretty" because, just as in Karl's case, that's what
is often wanted. Consequently, when the "problem" does appear, as this
thread has amply demonstrated, it is more confusing than it might
otherwise be in a more rigorous (in some sense) language such as C or
Fortran where "what you see is what you get" makes the internal
representations a little more visible.

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.

I'm repeating myself, but that's the situation w/ promotion or
translation. In both cases the course of action that is followed is to
extend w/ zeros, but that leads to two different results, depending on
whether one is extending zeros in the external or internal representation.

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.

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

--

This thread highlights the importance, for any program of consequence, of
defining business rules for scope and precision whenever one deals with
floating point math and storage. For example, had the app defined stored
values as significant to 5 places, Karl would have home free a long time
ago.

In the absence of any definitions the exisiting routine that calculates a
value becomes the de facto "Business Rule". Any modification of that routine
is thus a change to the BRs - and as such requires testing and sign-offs
beyond a simple programming decision or technical fix-up.

Programmers intuitively grasp the idea that converting a double to a single
will likely lead to a loss of information. The fact that performing a
conversion in the oppostite direction will also lose information is less
obvious but just as real.

-ralph


.

Relevant Pages

  • Re: Singles to Doubles
    ... If you're saying an internal representation of 1.11 should be displayed as 1.1100 externally under all circumstances, that can't be unless it is one of the set of reals than can be represented exactly. ... If otoh it can't be represented exactly as a Single, then the likelihood that it can in Double isn't zero, but the problem of translation to/from the external representation arises, as does that of promotion. ... 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. ...
    (microsoft.public.vb.general.discussion)
  • Re: Singles to Doubles
    ... conversion in some form to translate it to internal representation. ...
    (microsoft.public.vb.general.discussion)
  • Re: Adding Older Versions of GCC To The Tool Chain ... safely?!?!
    ... There is by definition no such thing as 'an unsigned overflow', ... the bits of the object representation ... for conversion to an unsigned type to be performed on mathematical ... If an exceptional condition occurs during the evaluation of an ...
    (comp.os.linux.development.apps)
  • Re: Question re. integral promotion, signed->unsigned
    ... >>Why is it OK to reinterpret a signed integral type as ... > but such a conversion isn't well defined if the value of the unsigned ... regardless of the representation of negative values. ... > While this conversion is well defined and yields the same result, ...
    (comp.lang.c)
  • Re: [LogoForum] Re: item & setItem bitwise?
    ... representation should be encoded in the "visual representation" of the ... At least in Logo. ... So in this cases there should be another way to make the conversion ... compiled by Lhogho => users will start to use more advanced technology ...
    (comp.lang.logo)