GNU Octave未分配数值字面量最接近double值：可复现？是否为Bug？

在GNU Octave 10.2.0中，直接赋值x = 1.000444时，未得到与实数1.000444最接近的double值，且并非平局场景：

>> format long
>> x =              1.000444
x = 1.000444000000000
>> x1 =    str2num('1.000444')
x1 = 1.000444000000000
>> x2 = str2double('1.000444')
x2 = 1.000444000000000
>> % 表面上三者相同，但：
>> x == x1
ans = 1
>> x == x2
ans = 0
>> % 即x == x1 ≠ x2。
>> % 查看x1和x2哪个更接近精确值1.000444：
>> % 通过sprintf展开字符串，即使17位后的数字是1.000444的“伪影”，也应是机器数的“精确”表示：
>> x1str = sprintf('%.25g', x1)
x1str = 1.00044399999999988892796
>> x2str = sprintf('%.25g', x2)
x2str = 1.000444000000000110972564
>> % 手动或用vpa减法：
>> error1 = anm_vpaminus('1.000444', x1str)  % vpa减法（自定义函数）
error1 =  0.00000000000000011107204
>> error2 = anm_vpaminus('1.000444', x2str)  % vpa减法（自定义函数）
error2 = -0.000000000000000110972564
>> % 可见x2比x（或x1）更接近1.000444，并非平局。
>> % 这是否违反了IEEE 754的就近舍入规则？

疑问 #

• 能否在自己的GNU Octave环境中复现该问题？
• 即使仅在数千个数字中出现少数此类情况，这是否属于Bug？从应用场景来看，这可能是严重的基础问题。

内容的提问来源于stack exchange，提问作者Felipe Jiménez