Re: Subplot frustration

Paul Mennen wrote:
Actually, while I've not pursued it, on reflection I
suspect that they are floating point numbers is only
an artifice of ML's representation of the internal handle as a default Double...

I've often been curious why they didn't stick to integers
despite the fact that they use a 64 bit double as the
handle. There are many many billions of integers that
can be represented as a 64 bit double, far more handles
than any practical program could ever use. So I don't
see the drawback to sticking with integers.

Occasionally I have found it useful to be able to assign
a unique string to graphic objects. The logical way to do
that would be "s=num2str(h)" where h is the object's handle.
While this does generate a unique string it has the drawback
that you can't use it to get the original handle back. If
you try "h=str2num(s)" you will find that h is not a handle.
That is because of the loss of precision that happens when
converting to decimal representations of floating point numbers.

I have found a trick that gets around this problem.
Use "s = num2str(h*8192)". Then one can get the original
handle back via "h = str2num(s)/8192". The reason this
trick works is that Matlab always uses handles that are
an exact multiple of 1/8192. So when you multiply the
handle by 8192 you get an integer, which can be converted
to a decimal string with no loss of precision. I haven't
seen anywhere that TMW guarantees that this will always
be true, so perhaps someday my programs will break because
of this assumption. However this assumption has so far
proved valid for the first version using handle graphics
and every subsequent release up to and including the
current version.

Interesting observation...I hadn't ever delved into the actual numerics sufficiently to notice the precise limit of precision, but it would obviously be desirable that the last bit of precision not be a problem if they were, indeed, processed somehow internally as floats.

My supposition is that they _are_ fundamentally integers but the storage in fp makes them _appear_ to be fractions. As I say, I've not investigated that thoroughly either but to me at least, it makes sense why that would be so as noted above.

My other supposition is that the "handle graphics" package was a product not developed inside TMW, but that again is an assumption.

--
.

Relevant Pages

  • Re: Rounding of the double
    ... John von Neumann suggested that only fixed-point integers should be used because floating ... If you choose your representation as double, then you have to live with the consequences. ... you can never get precision in any computation on a computer than involves ... MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text - ...
    (microsoft.public.vc.mfc)
  • Re: Will too many paradigms addle my brain.
    ... i.e. that a subclass should define a subtype. ... it's represented as an integer or as a floating point object. ... Most of the time I don't want to specify the precision explicitly, ... representation, and exact infinities are primarily used to provide ...
    (comp.lang.functional)
  • Re: Rounding of the double
    ... When in doubt, trust the representation. ... digits precision", the first rule is that only the binary bits matter. ... The formal specification of floating point precision is usually expressed as ±1 LSB (Least ...
    (microsoft.public.vc.mfc)
  • Re: What I can to do with old PL/1 code?
    ... >> I have IBM Visual Age PL/1 compiler, ... > issues related to limitations on precision and representation of real ... > the same binary precision for all floating point numbers. ...
    (comp.lang.pl1)
  • Re: Precision
    ... Whether one does the subsequent calculations in internal ie integer format ... I have always used external format with Precision 4 since my ... floating point calcs which are done in binary have around 3% error albeit at ... positions it is IMPOSIBLE to have a result of 4 decimals with the 2 ...
    (comp.databases.pick)