Could you add some new features in future releases?

[bdf1]

Could you add some new features below in future releases?
1.compute the EulerGamma in custom formulas which log(2) is provided.
2.compute a common SeriesHyperdescent,SeriesHypergeometric or SeriesBinaryBBP that the number of terms are provided by user
3.BBP digit extractor for Log(2) or Log(10)
4.a scope which can return more than one values

[bdf1]

It seemes that you will may able to include the exp(x) formula in v0.7.8.
Could you able to publish the first public release of v0.7.8 before June 7th?This date is that I will attend the gaokao(The National College Entrance Examination).

[Mysticial]

Could you add some new features below in future releases?
1.compute the EulerGamma in custom formulas which log(2) is provided.
2.compute a common SeriesHyperdescent,SeriesHypergeometric or SeriesBinaryBBP that the number of terms are provided by user
3.BBP digit extractor for Log(2) or Log(10)
4.a scope which can return more than one values

1. Will consider. This isn't difficult to do. But it's not important given how expensive EulerGamma is relative to log(2).
2. Rejected. Serves no purpose.
3. Rejected. These serve little purpose and will require a non-trivial amount of work.
4. Rejected. Not possible to do with the current internal interface. No obvious and suitable syntax to express it. Can try again in a few years to see if anything has changed.

I'm being extra careful with the custom formula feature since it's so new and open-ended. So I'd like it to soak for at least a year before I decide on any non-trivial expansions to it.

---

It seemes that you will may able to include the exp(x) formula in v0.7.8.

It may or may not happen. More research is needed and that's going to take a while.

Based on your email, I know you're thinking, "What's so hard about inverting log(x) with Newton's Method?" It's not as simple as you think it is. And there's more dimensions to the problem that I want to explore.

The project is far too big for quick-and-dirty solutions that come with technical debt. So I'm going to take the time to do it right the first time - even if that means dragging it out for many months.

Could you able to publish the first public release of v0.7.8 before June 7th?This date is that I will attend the gaokao(The National College Entrance Examination).

I don't want to sound harsh, but your personal deadlines are of no concern to me. So I will do things at my own pace.

[bdf1]

So could you add some another new features below in future releases?
1.Using much more memory than original so that the computation may go faster.(like using 10 GiB or 30 GiB to compute the Pi to 1b digits)
2.The hash number for each checkpoint files(.sf).Which can prevent manually modifying.
e - 20190323-162022.txt
This is the validation file computing e,but the last digits are same as zeta(3).
3.Recovery record in each .sf files(like the rr5% formula in winrar)
4.Creating checkpoint files when invsqrting,powering and base converting.(I think that in a large computation the base converting may cost several days or several weeks)

[Mysticial]

1.Using much more memory than original so that the computation may go faster.(like using 10 GiB or 30 GiB to compute the Pi to 1b digits)

I have experimented with this in the past. The speedup is not large enough to be worth the development and maintenance costs.

2.The hash number for each checkpoint files(.sf).Which can prevent manually modifying.

This isn't possible to do without a large performance hit. It will require reading all the checkpoint files at creation and reading them again when resuming. Given that checkpoints can be very dense together, this is not viable.

e - 20190323-162022.txt
This is the validation file computing e,but the last digits are same as zeta(3).

This is a known vulnerability. But as mentioned, there is no obvious and acceptable countermeasure. This is one of several reasons why checkpoint-restart is disallowed for competitive benchmarking. Large computations are manually examined.

3.Recovery record in each .sf files(like the rr5% formula in winrar)

I don't understand what you are saying. Can you clarify?

4.Creating checkpoint files when invsqrting,powering and base converting.(I think that in a large computation the base converting may cost several days or several weeks)

Checkpointing for square roots and powering isn't necessary since they are reasonably short operations. So they're not worth the effort at the time.

Checkpointing for the base conversion is indeed needed and has been on the radar for years. But it cannot be implemented at this time due to technical debt.

[bdf1]

The third point is that in each .sf file the size is 5% larger than the original mode,the extra 5% part is called as recovery record.This part could recover the data damage in .sf files.

[Mysticial]

Oh I see what you mean. That's called forward error-correction. It's something that's been on the radar for years, but hasn't been done yet. It's for a different purpose though - to catch hardware errors as opposed to intentional tampering to defeat the validation.

Unfortunately, it's not possible to implement it without performance overhead. So if and when it's done, it will be a separate framework. There's no timeline for it at the moment and there's research that needs to be done.