Debugger gives wrong value for long double

[Gord P 14]

Using C++Builder 11.3, 32 bits, VCL.  Problem is same for classic or clang compiler.

 

Some simple code shows the issue:

void __fastcall TForm1::FormShow(TObject *Sender)
{
    long double ld1, ld2, ld3;
    _TCHAR bufStrg[128];

    ld1 = 1.0;
    ld2 = 7.0;
    ld3 = ld1 / ld2;

    swprintf(bufStrg, L"Long Double = %.20LG", ld3);  // better than FormatFloat for displaying long doubles
    Label1->Caption = String(bufStrg);
}

The true value of 1/7 is 0.142857142857142857..., where 142857 repeats itself forever.

 

If you set a break somewhere after ld3 is calculated, and look at either the Inspect tool or the Watch window, it shows the value of ld3 as 0.142857142857142864.

 

But if you let the program run, it displays the value on the form as

Which is as good as you will get for a long double.

 

After putting the variable through a few calculations and inspecting the results, I concluded that the value displayed on the form is indeed what the variable is holding and not what the debugger says it is holding.

 

I will put this into QP unless shows me something that I am doing wrong here.

 

I noticed this issue a fair number of years ago but didn't pursue it because I didn't need to use long doubles.  Now I want to use them and was surprised this issue still persists in a much later version.  I would have thought there would be lots of people using long doubles that would not be happy about this.  There was report on QP about this for the 64 bit compiler but it is closed and says it was fixed in v 10.1.

 

[Gord P 14]

I fooled around a little bit with TExtended80Rec and found that the value held in the double (ld3) equates to: 

0.14285714285714285712736854039306422........

I have bolded the part before it goes off the rails.  So sprintf() presents it well.  I don't have Delphi to see if their corresponding function is part of the problem (I think they write Rad Studio in Delphi but I could be wrong about that).

 

Anyway after having said and done all that I think the bigger issue for using long doubles is the fact that in Win64 they are not supported.  To be more accurate, they are just the same as doubles (8 bytes).  Kind of pointless. At some point I will be migrating over to 64 bits so I would lose the precision then.  

Edited January 7 by Gord P

[David Heffernan 2353]

On 1/2/2024 at 8:24 PM, Gord P said:

The true value of 1/7 is 0.142857142857142857..., where 142857 repeats itself forever.

Not in IEEE 754 floating point data types that you are using.

 

Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger? 

 

As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now. Is double insufficient for your needs? 

[Gord P 14]

22 hours ago, David Heffernan said:

Not in IEEE 754 floating point data types that you are using.

The number I quoted is the actual (true) value for 1/7.  But yes, in a binary system you don't get that.  Which is why I used TExtended80Rec to see what the value in the long double variable equated to.

 

22 hours ago, David Heffernan said:

Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger?

The debugger does not display the value that the variable actually contains to the precision it should be able to (and could if it used something akin to sprintf()) - as per my first post.

 

22 hours ago, David Heffernan said:

As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now.

Yes, that is unfortunate and is what I was referring to in my second post.

 

22 hours ago, David Heffernan said:

Is double insufficient for your needs? 

That is a good question, and one I was trying to sort out.  It is not a matter so much of whether it is insufficient, but whether things could be improved with additional precision.  I have been using doubles forever and it has been fine. But there are cases where there is numerical instability and I wonder if more precision would help.  But, there are always ways to get around it and because of the previous point, those will have to suffice.

[DelphiUdIT 187]

Have you tried the math package RudysBigNumbers  https://github.com/TurboPack/RudysBigNumbers  ? It's in Getit too.

 

[Gord P 14]

1 hour ago, DelphiUdIT said:

Have you tried the math package RudysBigNumbers  https://github.com/TurboPack/RudysBigNumbers  ? It's in Getit too.

Thanks no I haven't.  There also the Neslib.Multiprecision Library that I haven't checked into either.  

[David Heffernan 2353]

Those libraries will be appallingly slow. In terms of the calculation side of it, it doesn't sound like you have a problem. Use double. 

 

As far as the IDE goes its not surprising that a program written using the Delphi rtl doesn't convert floats to decimal text correctly because the rtl doesn't. Or vice versa. Never has done and in spite of Emba being told more than a decade ago they haven't shown any inclination to address it. 

 

In my code I use dtoa and dragon4 to do these things so I can get correct values. 

[Mark- 29]

15 hours ago, David Heffernan said:

In my code I use dtoa and dragon4 to do these things so I can get correct values. 

What is "dragon4"?

 

 

[Cristian Peța 107]

1 hour ago, Mark- said:

What is "dragon4"?

I suppose is about the algorithm (google for "Dragon4 algorithms").

[David Heffernan 2353]

1 hour ago, Mark- said:

What is "dragon4"?

 

 

Floating-point arithmetic - Wikipedia

[Mark- 29]

55 minutes ago, David Heffernan said:

Floating-point arithmetic - Wikipedia

Thanks.

 

Edited January 9 by Mark-

[Mark- 29]

1 hour ago, Cristian Peța said:

I suppose is about the algorithm (google for "Dragon4 algorithms").

Thanks

[Gord P 14]

19 hours ago, David Heffernan said:

Those libraries will be appallingly slow.

I suspected that.  That was nice about using the 80 bit doubles.  From what I understood, there wasn't a huge performance hit.  I was about test all that out, but now I think I will stick with the doubles for now.

[David Heffernan 2353]

5 hours ago, Gord P said:

I suspected that.  That was nice about using the 80 bit doubles.  From what I understood, there wasn't a huge performance hit.  I was about test all that out, but now I think I will stick with the doubles for now.

Massive performance hit compared to double on 64 bit