Hi guys,
It’s a trivial but completely unnecessary error that is causing me trouble with data tips after tight crop
Also shows up on 2024.0.0
Helllo,
This is not a math error, this is just reality of finite 52 bits mantissa coding of IEEE754 numbers.
Welcome to the real world (cit. Morpheus)…
S.
1 Like
Look at the last 52 bits of the binary representation of numbers above
--> bitstring([15.025; 13.375])
ans = [2x1 string]
"0100000000101110000011001100110011001100110011001100110011001101"
"0100000000101010110000000000000000000000000000000000000000000000"
15.025 has a periodical truncated development, whereas 13.375 is exactly encoded.
The substraction of the two above encoded numbers yields a different number than encoded 1.65:
--> bitstring([15.025-13.375; 1.65])
ans = [2x1 string]
"0011111111111010011001100110011001100110011001100110011001101000"
"0011111111111010011001100110011001100110011001100110011001100110"
you clearly see that the difference of the mantissa is exactly 10, which is the encoding of
--> 2^-51
ans =
4.441D-16
S.
1 Like
Thanks Mottelet,
Yes, that is about what I figured.
Here is the problem:
first it was negative 13.375-15.025. I put it in positive form to simplify what was happening.
That error ended up in an xpoly dimension. Still ok.
Then later I read the xpoly data and placed a data tip in that location. Still ok.
Then I used that poly data to tight crop the drawing at that location, which was y min by putting it in ax.data_bounds
Not ok. The data tip was off the edge (not visible)
When I subtracted an addition 1e-15 from the data_bounds (for example) it showed up fine.
You have made clear why this is normal. Your explanation makes perfect sense, but it is still an error. That error is not a problem in itself, but the working together as I described above is an actual use problem.
data_bounds accepts and stores the number, but apparently does not use the -4.44089210D-16 error to set the actual bounds of the drawing.
In the following demo I used the lower left x number:
Setting bounds with a1.data_bounds(1,1)=13.375-15.025;
Setting bounds with a1.data_bounds(1,1)=13.375-15.025-1e-15;
So, the error is normal but I think the problem it creates is unexpected. There are various ways of solving it with code, but I think it is not normal, so not something that would be designed into the code in advance.
(BTW, I have no idea why my text is bold. I set it to bold, then removed it, but it stuck)
Hello
Please post a simple/minimal piece of code exhibiting the problem.
S.
1 Like
Mottelet,
I can reproduce on the original program with no problem, but I have not been able to duplicate with a simplified version.
Obviously it is too simple. I’ve left the thing off that is exposing this. That could mean that it is an avoidable code choice.
I’ll dig into this further and get back to you
Here it is. My original premise, that it was due to the math error, may be incorrect. The top two data tips don’t show up. Afterwards enter this command: a.data_bounds(1,2)=-1.65-1e-15;
And they show up. Also changing the numbers around, like changing out to make ymax 17 instead of 16, makes the problem go away. Likewise changing ymin by ± 1e-15.
I still believe its an actual problem, but I’m a little baffled about the root cause.
close
clear;
clc;
out.xy = [-2, -1.65;
2, -1.65;
2, 16;
-2, 16]
xpoly(out.xy(:,1), out.xy(:,2), 'lines', 1);
o = gce();
a = o.parent;
f = a.parent;
for idt = 1:4
d(idt) = datatipCreate(o, idt);
end
a.tight_limits = 'on';
1 Like
I just opened and issue #17273
2 Likes