Difficulty achieving deterministic results

Started by ptrdtznr, March 09, 2026, 07:34:25 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Liviu Lalescu

Hello, ptrdtznr,

Thank you for your code! Yes, I received it on my email. Here on the forum zip's are allowed, but the maximum size is 512 kb.

The auto-reset feature is interesting - I did not think of this.

However, as I already told you, I am very circumspect about this feature. I'll think of this.

Also, there are many possible code improvements in FET, but me and Volker we prefer to keep our work to the strictly necessary.

ptrdtznr

I completely understand the desire to keep the codebase lean and focus only on what is strictly necessary. However, my main "fear" is exactly what you hinted at: FET is evolving quickly, and version 7.8.3 already feels noticeably faster in its calculations. I'd love to stay on the main release path to benefit from your future improvements rather than being stuck on a custom build that I have to manually merge every time a new version drops.

Regarding the "necessity" of the feature, here is why I think the current implementation respects your cautious approach:

- Zero Impact by Default: Since it automatically disables on restart, it doesn't change the standard FET experience for 99% of users.
- Safety First: The per-generation warning ensures that even the person who turned it on doesn't get "stuck" with a fixed seed by mistake.
- Maintenance: I've kept the changes localized to a single GroupBox in the Settings and the Generate logic to keep the footprint as small as possible.

I'd love for you to consider it—even if just as an "experimental" addition—so that those of us needing reproducible results for specific testing can stay aligned with your latest performance boosts!

Liviu Lalescu

#17
Hello, ptrdtznr,

The speed is not really improved in the recent updates. Maybe luck. Only the two new exam constraints are improved.

Regarding the safety of your feature, indeed, it is very safe, and I like the reset-at-start idea.

Regarding the necessity, unfortunately, I don't really see a need for it. Why duplicate the results in the same FET session? If we want the same solution, we need to generate on the locked data_and_timetable.fet file, very fast. If we want to generate twice with the same seed, we simply enter the random seed dialog and input the same seed at start, inputting a very simple seed, like 1,0,0, 1,0,0, or manually input the more complex seed with copy/paste, which is not so difficult.

A few users might consider it is a good thing to keep the same seed in general, which is of course incorrect.