Fix float printing

[cbmarini]

This fixes the float printing issue

#StartFloat 50
Local F = 1/3;
ToFloat;
Print;
.end

that resulted in

   F =
      3.3e-01;

The correct result is now

   F =
      3.333333333333333e-01;

Furthermore set the default MZV weight MAXWEIGHT to 0 instead of 40.

[jodavies]

Does SetupMZVTables need the same change? In that function there is some weight dependence on the precision that is used; I wonder if it is not easier to just allocate everything at the same, maximally-required precision? Then the logic to set the precision can all move to DoStartFloat and the multiple calls to SetFloatPrecision could all be removed?

[vermaseren]

I have been thinking that the second parameter in #StartFloat should be not just a number, but MZV=number. This for when the future needs other parameters as well. It also makes things more readable. What do you think?

…

On 20 Jun 2025, at 16:22, jodavies ***@***.***> wrote: jodavies left a comment (form-dev/form#676) <#676 (comment)> Does SetupMZVTables need the same change? In that function there is some weight dependence on the precision that is used; I wonder if it is not easier to just allocate everything at the same, maximally-required precision? Then the logic to set the precision can all move to DoStartFloat and the multiple calls to SetFloatPrecision could all be removed? — Reply to this email directly, view it on GitHub <#676 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCESVHPNQX3GF2N25X333EQKJDAVCNFSM6AAAAAB7YM3LGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJRHAYTINBYGQ>. You are receiving this because you are subscribed to this thread.

[jodavies]

That sounds reasonable. Also a way to specify precision in digits rather than bits?

#startfloat 50b,MZV=0
#startfloat 50d,MZV=0

for example. Or do b and d look too similar there?

I also wonder: why can the regular mpf_init function not be used to set up the aux floats? Then everything should "just work" at the precision that is requested?

[cbmarini]

@jodavies, this can indeed use some cleaning up, see the following example:

#StartFloat 64,2
L F = mzv_(2);
Evaluate;
Print;
.end
   F =
      1.64493406684822643645e+00;

vs

#StartFloat 67,2
L F = mzv_(2);
Evaluate;
Print;
.end
   F =
      1.64493406684822643647e+00;

The last digit changed if we added a few more bits of precision.
Let me see if changing SetupMZVTables similarly resolves this problem.

@vermaseren, I also like the idea to be specific that the weights are for the MZVs. Maybe indeed also go with @jodavies suggestion to specify the precision in either bits or digits.

[vermaseren]

I don’t think the b and d are a problem. Concerning the aux floats, my attitude was to do this myself, to allow me to understand what is happening. Of course, now we know what works, we can make variations, because now it means changing one thing at a time.

…

On 20 Jun 2025, at 16:39, jodavies ***@***.***> wrote: jodavies left a comment (form-dev/form#676) <#676 (comment)> That sounds reasonable. Also a way to specify precision in digits rather than bits? #startfloat 50b,MZV=0 #startfloat 50d,MZV=0 for example. Or do b and d look too similar there? I also wonder: why can the regular mpf_init function not be used to set up the aux floats? Then everything should "just work" at the precision that is requested? — Reply to this email directly, view it on GitHub <#676 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEUAJMIPRTWELQSSSSD3EQMJRAVCNFSM6AAAAAB7YM3LGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJRHA3DKNRYGQ>. You are receiving this because you commented.

[cbmarini]

I see that the tests that printed some of the constants like pi_ now also need to be updated.

[cbmarini]

I changed SetupMPFTables such that it uses GMP's mpf_init. At the moment, the MZV tables are set with variable precision (see the comment at the beginning of SetupMZVTables). Do we still want this, or is it better to set the tables also with the highest precision using mpf_init?

[coveralls]

coverage: 50.848% (+0.2%) from 50.603%
when pulling e622d40 on cbmarini:PrintFloat
into 21f29a8 on form-dev:master.

[jodavies]

Does it make sense that there is a digit less here?

[cbmarini]

Do you mean for EM1 specific or for all of them?

[jodavies]

For EM1 specifically: the rest all have the same number of digits. The next would be a 1, from rounding 07, or? Does the conversion truncate rather than round (and then FORM cuts the trailing 0)?

[cbmarini]

If you look at the next digits, one has 5.77215664901532860606e-01. So it looks like it got truncated: 60606 becomes 6060 by gmp_snprintf in PrintFloat. Then the parsing of FORM drops the last 0. So in total, one gets one digit less compared to the other examples in the test.

[cbmarini]

One more observation: running this test with one more bit (so #StartFloat 65), EE1 and EM1 change (the rest is unchanged), that is

   EE1 =
      2.7182818284590452353e+00;
   EM1 =
      5.7721566490153286061e-01;

The rounding for EM1 seems now more logical to me, whereas for EE1 the previous rounding (with 64 bits) seemed more logical.

[jodavies]

OK, I think this is the expected behaviour of MPFR_RNDN.

[cbmarini]

For the new test that evaluates all MZVs up to weight 6, we could consider increasing the weight. On my laptop, evaluating up to weight 10 only takes about 0.25 seconds.