Odd circle diameter

[CVH]

Continued from this topic:
viewtopic.php?f=33&t=7818

@ Andrew,

What double value in a dxf file (textual) results in:
-2147483648' 8988465674311578476003883458326967976270757867609612092806662678859711890369052157063584584531181568"
= plain copy off the Radius in the Property Editor, handle 0x904

Can't find any circle entry in the dxf-file that comes even close.

• 8.988465674311578E+99 (= CIRCLE 904)
  1.25
  1.75
  0.1250000000000001
  0.1250000000000001
  0.1249999999999997
  0.1249999999999997
  0.0750000000000002
  0.075
  0.0750000000000002
  0.075
  2.025

Regards,
CVH

[andrew]

QCAD cannot handle that value correctly (overflow).

[CVH]

So, instead of NAN or Infinite or Undefined:
- It displays 110 fictive digits.
- With a wrong sign
- While Number.MAX_VALUE is known.
=1.7976931348623157e+308

Please direct me to that piece of code ... so I can utterly avoid it.

Regards,
CVH

[andrew]

The value is neither NaN (not a number), Infinite nor Undefined. The digits are not fictive. It's the closest value a computer can represent in memory. But I guess you know all that...

[CVH]

No, sorry,
I am not aware of that
-214748364' 89884656...."
is the closest value to
+8.988465674311578e+99 inch

nextUp = +8.98846567431158e+99 inch
nextDown = +8.988465674311577e+99 inch
Both are positive numbers !

Reversed we get twice the input back:
+8.988465674311578e+99 inch
+8.988465674311578e+99 inch
Both are still positive numbers !

This stores in memory as: 01010100 10110000 01110000 00011011 11010101 00100111 10110100 10010111
And is nowhere near the binary limit.
The first bit = 0 => positive !
The most accurate decimal notation without exponent:
+8988465674311578476003883458326967976270757867609612092806662678859711890369052157063584584531181568
Also positive and equal to the inch fraction that the Property Editor showed us.

Converting inches to feet one divides by 12.
I don't expect to get an 'overflow' from such division.
A positive number divided by 12 remains positive : +7.490388061926315e+98 feet
Again positive !
Code in a script doesn't has any problem with that. It is nowhere near the binary limit.
The most accurate decimal notation without exponent:
+749038806192631539666990288193913998022563155634134341067221889904975990864087679755298715377598464

Substracting full feets times 12 in inches from the +8.988e99 inches we get zero
Simply because 1ULP = 1.942668892225729e+84 and the remaining inches would be less as 12e0
In other words, the remainder is smaller than the accuracy.

So, yes:
Minus 214748364' 89884656...." is fully fictional, the number should start with 7.49038....
Certainly not negative.

And no, I don not know that all, I am just guessing.

CVH

[andrew]

The conversion to feet / inches goes wrong (overflow when converting to inch for the feet part). The value behind the conversion is correct. Negative values are typical for overflows. There's not an awful lot a software can do when these kinds of limits are reached. The value in the file is clearly not intended. I'll have to leave it at that.

[CVH]

There's not an awful lot a software can do when these kinds of limits are reached.

Catch them of before they even occur.
Math core of T2H is at least 6 months unchanged.
Catching off math errors is busy and very hard. Over 80 parameters.
Testing it for, and passed, reasonably limits is only half ready.

If I ever get that far, live is catching up on me.
Already dropped the endeavors for entity documentation, macro's, pocket milling, V-carving under QCAD.

The value in the file is clearly not intended.

I know, the questions were:
What value results in ...
And
Where does this flaw occur in the code.

A bit similar as: Why doesn't QCAD format proper numbers with LZ, TZs or better as 1e-12.
Found out all that myself by trial and error. Solved those.
I am hitting the 1ULP every day.

As Administrator, you may delete all these post.
I have a bad time and I can't handle to be attacked on simple, and straightforward things.

Regards,
CVH