Polyglot 1.4.50b

[Michel]

Here is an attempt to unify the two polyglots that are currently shipped with WB.

I have disabled persistence in favor of an explicit save button. In the future persistence may be
reenabled if WB wants to communicate in some way the state of its SaveSettingsOnExit setting to PG.

According to HGM the current standard ways of invoking PG will not change for the time being.
Recall that these are

xboard -fcp EngineCommand -fUCI

and for people using the same engine with multiple personalities

xboard -fcp "polyglot config.ini"

This version of PG handles both mechanisms. In the first case a special config file
is automatically created whose name is derived from the engine name. Its default
location is $HOME/.polyglot/ on Linux and ./_PG/ on Windows.

On HGM's suggestion I have also severely restricted the number of options that PG exports.
This is for people that have small screens. To export all options one may set OnlyWbOptions to false in the config file
or invoke PG with the comand line option "-wb false" (in the future PG will be invoked by a template command so this last method
would work for every PG invocation).

Download link:

http://alpha.uhasselt.be/Research/Algeb ... t-release/

[H.G.Muller]

Not that I am all in favor of shielding the user (and especially the novice user) from the fact that Polyglot is involved. But in the case of an engine co-existing in multiple versions differing in settings through use of diffeent polyglot.ini files, I cannot see a way to do that. (Of course I am open to suggestions.)

To hide the fact that Polyglot is involved, polyglot+UCI engine should behave the same way as a native WinBoard engine. (With the only exeption of the precense of a -fUCI or -sUCI flag.) If a solution would work for UCI engines, but not with WB engines when you leave out the -fUCI, it would create more confusion than the hiding of Polyglot involvement would be worth, IMO.

The only way to run WinBoard engines with multiple settings is to install them several times, in different folders. (Assuming the WB engines control their settings by ini files in their own folder.) This could be made to work transparently with Polyglot+UCI, if polyglot.ini files were stored in the engine folder (or would be given default file names that included the folder name). I think in future WinBoard versions, which will support an "adapterCommand" in stead of a "polyglotDirectory", this can still be acheived by making the adapterCommand

polyglot %<fd>/polyglot.ini -ec %<fcp> -ed %<fd>

In that case several versions of the UCI engine could coexist and all be called through -fcp enfine.exe -fd engineDir -fUCI with different engine directories. But the need to make copies of the engine and its support files would be ugly compared to just having different settings file in the default Polyglot folder.

Having an option in the ini file to control "verbose" nature of the options seems a good idea. Note that future implementation of the -reset option type in WinBoard would allow you define a button to change this option interactively. The small set could have a "More..." button, which would clear the option to create a full display. That full display could then contain a "Less..." button to set the option again.

I will put implementation of the adapterCommand-based invoking of Polyglot and the -reset option high on the to-do list, so that versions will become available in which we could test such schemes.

[Michel]

Do you have an opinion on how tournament managers should ensure that an engine is invoked with default settings?
Since now xboard engines are supposed to have way to remember their settings it would be easy to mistakenly run
an engine with non default settings (like Rybka with its Elo set to 1200).

The only thing I see is to mandate the existence of a -reset button "_Defaults" (say) which would make the engine use
default settings.

An alternative solution would be to add a prefix or suffix to the engine name to indicate that the engine is using non default settings. But even then you would still need a _Defaults button to restore the default settings.

[H.G.Muller]

I don't think this problem has grown any worse than it has always been. UCI engines have always remembered their settings. If someone had edited the polyglot.ini file to limit Rybka strength to 1200, and had forgotten about it, his next tournament would have Rybka play at 1200... But I think a non-defaults suffix in the myname feature would be a very useful asset.

I am not sure it is the task of tournament managers to enforce default settings. The problem that people would inadvertantly play an engine with other settings than they intended always exists, also for specially tailored settings. So taking special provisions for default settings at best solves only part of the problem. People that care very much about default settings should simply not set persistence, and never press a "Save now" button. Which is easy enough if they only play automated tournaments; they likely would not ever open the dialog to see that button.

Another way to enforce default settings is to play al engines with the same .ini file or even without one (which is possible now the engine name and path no longer have to come from there) by using an adapterCommand that fixes this such. Engines that do need an option set (e.g. a Polyglot work-around) could get it set through the WB interface, by installing the engine in the TM with WB command-line option /firstOptions="OptionName=VALUE". This would make WinBoard set the mentioned option whenever the engine was loaded.

[Michel]

I don't think this problem has grown any worse than it has always been. UCI engines have always remembered their settings.

This is not true for Arena or ChessBase. In those cases the GUI remembers the settings. And one engine can have many sets of settings. So you can just create an engine with default settings which you never touch. You can still experiment with other settings.

In principle a WB engine has only one set of settings associated to it. Using the engine settings dialog is easy to change these and then you would not even know what the original settings were. So the engine author must provide a way to return to default settings. Since it is necessary anyway it seems reasonable to mandate a standard way of doing so.

The problem that people would inadvertantly play an engine with other settings than they intended always exists, also for specially tailored settings. So taking special provisions for default settings at best solves only part of the problem.

After the engine is in a known state the tournament manager can of course set options as it sees fit (e.g. using -firstOptions/-secondOptions).

But I think a non-defaults suffix in the myname feature would be a very useful asset.

Yes but then you still need a way to enable default settings...

[H.G.Muller]

In principle a WB engine has only one set of settings associated to it. Using the engine settings dialog is easy to change these and then you would not even know what the original settings were. So the engine author must provide a way to return to default settings. Since it is necessary anyway it seems reasonable to mandate a standard way of doing so.

OK, sorry. I had not realized that you were primarily talking about WB engines. I am not sure how many WB engines do have settings that can be changed, and how many then would allow these settings to be remembered. It seems logical, though, that when authros allow engine settings to be saved, they would also allow them to be restored.

I am not sure a standard way to do this is needed, however. All such options are unique to the engine, so why not restoring the defaults? A standard way would only be needed when you wanted to provide something like a global GUI setting, comparable to hash size, that you could set to temporarily overrule all customization. When you want to run an individual engine with default settings, you should just make sure those settings are in force before you start the tourney, like you would have to check any non-default settings as well. (E.g. by opening the settings dialog, and press whatever restores the defaults.) I see no great need to have this automatically applied to all enines, because I suspect it would be almost never what one wants. If I would ever change settings of an engine, it would most likely be for a reason. Undoing all such changes because one of the engines might accidentally have wrong settings does not seem the answer.

After the engine is in a known state the tournament manager can of course set options as it sees fit (e.g. using -firstOptions/-secondOptions).

True. If they really cared to be 100% sure to run the engine with known settings, they can simply put all its options in the list. They would not even be dependent on the existence of a restore-defaults option then.

My feeling is still that we are chasing ghosts here. In the end people using tournament managers will not want to have to deal with cumbersome -firstOptions lists that have to be edited either. If the desire is to control this from the tournament manager, it means that in the end the TM would get a dialog just as the one WB has now (which PolyglotGUI already does as part of Alex Guerrero's WinMan). And then you would not have to worry that someone accidentally changed the settings from the WinBoard dialog, but that he accidentally changed the settings from the TM dialog. It would only displace the problem.

Yes but then you still need a way to enable default settings...

I think we should leave it up to the engine author how he wants to solve that. Personally, I would never allow users to alter settings of my engine permanently. So there would not even be a way to save them. If they want to alter settings they can do it through the -firstOptions WB option, and that this is cumbersome hopefully discourages them from doing so. But other authors might have a completely different view, and not even have strictly default settings but allow anything within a certain range still to count as "their engine".

[Michel]

True. If they really cared to be 100% sure to run the engine with known settings, they can simply put all its options in the list. They would not even be dependent on the existence of a restore-defaults option then.

No since the TM would not know what the default settings are. So it can not restore the engine to its factory state by itself...

A standard way would only be needed when you wanted to provide something like a global GUI setting, comparable to hash size, that you could set to temporarily overrule all customization.

I was indeed thinking of such a thing.

I think we should leave it up to the engine author how he wants to solve that. Personally, I would never allow users to alter settings of my engine permanently. So there would not even be a way to save them.

Hmm. I was hoping that fmax would give an example of how the whole -save/-reset etc... framework should be implemented for WB engines.

[H.G.Muller]

However one does it, it will have to be controlled from some place what the settings will be the engine plays with. And if you err in that place, the engine will play with wrong settings. That seems logically unavoidable. Some people will want to play the engine with default settings, other will want to customize them. And it is not at all unlikely that customized and factory-default engines will have to participate together in a single tournament.

I still don't see a real disadvantage from making the one place from which to control the engine settings the GUI Engine-Settings dialog. If you want to play it with factory defaults, just open that dialog and do whatever is needed for that engine to make it play with factory defaults. (Could be ticking a check option "use defaults" that does not disturb the settings of any customization of other options, it could be a "restore defaults" button.) If you take your tourney seriously you would have to check the engine settings anyway, wherever their ultimate source of control was. Someone could have changed the settings, but that holds just as much for customized settings as for default settings. Default settings are already more easy to restore if there are things like "restore" buttons. I am not sure at all why it would be any advantage to move the ultimate source of control to the TM.

[mikeleany]

I'm not entirely following how you're dealing with engine options (and I have not yet used the new xboard/winboard) but it sounds like it's the wrong way.

Here's what I see as the ideal:
When you call xboard, you should have the option to specify an engine configuration file (for UCI engines, you can use a polyglot ini file, for xboard engines you can do something similar).
If no file is specified, there are two possibilities, both of which should be supported (ideally with a command line argument as well as a menu/dialog box option).
1) use the default settings, or
2) use the same settings as last time the user manually changed the settings.
But if you do specify a configuration file, the settings should differ from the defaults ONLY in the ways specified by the configuration file (unless and until the user changes them through the GUI, and then only for that instance, unless the user chooses to save them). So an empty configuration file would always use the defaults.
Also, no program (whether xboard or polyglot) should modify a user specified configuration file (or a default, like polyglot.ini, found in the working directory) without the user's explicit permission. I noticed there was previously some debate on this matter.

The important points are that
1) The user should NOT be required to manually change or verify the settings each time he/she/it(as in a program) wants to use a specific set of settings. Note that if the user is a program, it cannot open up xboard's Engine Settings dialog.
2) The user should be able to play an engine against itself with different settings.
3) Between runs, the engine should not be remembering settings specified through the xboard or UCI protocols. If this is happening, things are being done in completely the wrong way.

Now perhaps I'm misunderstanding and all those points are being met, but it doesn't sound like it.

[H.G.Muller]

I don't see how (1) could be logically avoided. If you work in an environment where the settings of the engines are changed often, they might be wrong, and if you won't check they will stay wrong. If you never touch the settings other than at install, there is no need to check and you simply won't do it, of course.

It is a decision of the engine author if he wants to support (3), and if it does, it is up to the user if he wants to make use of that. If the engine supports a "Save Settings" button you don't have to press it.

As far as I am concerned, this whole thing is just a facility to configure the engine at install in a user-friendly way. Editing settings files is not of this time. If authors feel that their engines need settings files that must be changed by the user, we now offer them a way to do that editing through a user-friendly interface. (The real nerds, which know how to use a text editor, can still make the changes that way if they prefer so.)

If authors feel their engine does not need a configuration file, but does need some settings that can be interactively changed, those that want to play the engine automatically from a tournament manager can do so by passing the settings to the GUI as command-line option. That is the TM's equivalent of "opening the settings dialog". Any TM obviously would have to maintain data on each engine, if only to know how it is to be invoked. The setting of interactive options is part of this process.

When two engines have to play each other with different interactive settings, they can be installed in PSWBTM twice, with different options, but can make use of the same executable in the same folder. (Unless there is a clash of, say, log files, which prevents an engine to run twice in the same folder.) I already do the same for engines that I want to run with different GUI options (e.g. time-odds). If you want to play several versions of an engine simultaneously with different settings that they consider permanent, you would have no choice than to make copies of it, in different folders. But also this can be done. So I think this satisfies your requirement (2).

I guess the main point is that I cannot control what engines do remember from one run to the next. The only one in control of that is the engine author, and he can do as he pleases. If the author feels his engine should have settings that are permanent, we should respect that. But if you use the Engine Settings dialog to change such settings, they will of course be remembered the next run. If that is inconveient, it just means you are using the engine in a way different from what the author intended.

[Michel]

Any TM obviously would have to maintain data on each engine

I guess in your point of view it would need to know which particular button(s?) would have to be pressed to return the engine to a known state.

I maintain that it would be much easier to provide a button with a standard name so that the engine configuration in the TM could just have a check box "Start from default settings" instead of forcing the tournament director to include some obscure button options that would have to be figured out separately for each engine.

You can compare this to the annoyance arising from the fact that there is no standard option for setting the number of threads in UCI.

But I guess only people that actually organize tournaments could give a well-founded opinion on this issue... If they think the current protocol is sufficient then there is nothing to argue.

[H.G.Muller]

I guess in your point of view it would need to know which particular button(s?) would have to be pressed to return the engine to a known state.

Either that, or it should trust that the engine is in the correct state. In fact I strongly dislike the idea of the TM to meddle with the state of the engine at all. I am the one to decide about the state of the engine, and I will do so when I install it. If that involves permanent settings that deviate from their default values, that is my decision. The TM should respect that decision, and just run a tourney with the engine as I hand it over, as far as permanent settings are concerned. If I want to test various settings against each other, I will explicitly specify the value of the parameters in which I want them to differ in the TM, but otherwise the TM should not mess with any of the settings I have chosen.

I maintain that it would be much easier to provide a button with a standard name so that the engine configuration in the TM could just have a check box "Start from default settings" instead of forcing the tournament director to include some obscure button options that would have to be figured out separately for each engine.

You can compare this to the annoyance arising from the fact that there is no standard option for setting the number of threads in UCI.

I agree the latter is an annoyance. But I do see a large difference between the two cases. Any engine will need a limit on the number of CPUs it uses, and there would hardly ever be a reason to set it different for different engines. It is therefore something that you want to control globally. For default settings I think this is very different. For one, they would not control a single setting, but many settings. So the likelihood that you do not want to use it on a particular engine, because you prefer one of the settings to be different from the default, is multiplying. E.g. engines could have an option that has white POV vs Own POV sign convention for its score, and they could actually have different default value for it. This would immediately preclude me from using a check option that forces defaults on the engine that does not have the defaults I would like.

I think defaults are getting way to much attention. For many options the defaults will just be abitrary choices. Should engines make a log file by default or not? Do I care what default name they use for the log file or not? Is their default value for the EGTB cache size suitable for my system, or is it chosen conservatively for all those users that seem to be running win98?

But I guess only people that actually organize tournaments could give a well-founded opinion on this issue... If they think the current protocol is sufficient then there is nothing to argue.

[mikeleany]

I don't see how (1) could be logically avoided. If you work in an environment where the settings of the engines are changed often, they might be wrong, and if you won't check they will stay wrong. If you never touch the settings other than at install, there is no need to check and you simply won't do it, of course.

As long as there are no problems with (3), then (1) could be taken care of if xboard had configuration files similar to polyglot's ini files.

It is a decision of the engine author if he wants to support (3), and if it does, it is up to the user if he wants to make use of that. If the engine supports a "Save Settings" button you don't have to press it.

Of course I know that this is ultimately up to the engine author. I just meant that the way xboard does things should discourage it. However, if engines only remember the settings if a "Save Settings" button is pressed, that's not quite as bad. But I would prefer that xboard rather than the engine were responsible for saving settings, and that it was done with standardized config files.

As far as I am concerned, this whole thing is just a facility to configure the engine at install in a user-friendly way. Editing settings files is not of this time. If authors feel that their engines need settings files that must be changed by the user, we now offer them a way to do that editing through a user-friendly interface. (The real nerds, which know how to use a text editor, can still make the changes that way if they prefer so.)

If authors feel their engine does not need a configuration file, but does need some settings that can be interactively changed, those that want to play the engine automatically from a tournament manager can do so by passing the settings to the GUI as command-line option. That is the TM's equivalent of "opening the settings dialog". Any TM obviously would have to maintain data on each engine, if only to know how it is to be invoked. The setting of interactive options is part of this process.

For clarification, are the command line options you're talking about xboard's command line options or the engine's command line options?
If they are xboard's command line options, that sounds a little messy, but still workable.
If they are the engine's then I suppose this part remains unchanged from previous versions of xboard. But unfortunately, engine authors may begin to abandon command line options because the options can be set through the GUI, and that brings us back to the problem of computer programs that call xboard being unable to set the options.

When two engines have to play each other with different interactive settings, they can be installed in PSWBTM twice, with different options, but can make use of the same executable in the same folder. (Unless there is a clash of, say, log files, which prevents an engine to run twice in the same folder.) I already do the same for engines that I want to run with different GUI options (e.g. time-odds). If you want to play several versions of an engine simultaneously with different settings that they consider permanent, you would have no choice than to make copies of it, in different folders. But also this can be done. So I think this satisfies your requirement (2).

I would hope that making multiple copies of the same executable in different folders would never be necessary. xboard (not just the engine) should provide a way for the calling program to specify any and all engine options available through the GUI. If you do, then I see no reason for multiple copies of the same executable. If you don't, that's a problem.

I guess the main point is that I cannot control what engines do remember from one run to the next. The only one in control of that is the engine author, and he can do as he pleases. If the author feels his engine should have settings that are permanent, we should respect that. But if you use the Engine Settings dialog to change such settings, they will of course be remembered the next run. If that is inconveient, it just means you are using the engine in a way different from what the author intended.

[H.G.Muller]

As long as there are no problems with (3), then (1) could be taken care of if xboard had configuration files similar to polyglot's ini files.

I don't see how that would help. What was in the configuration files could be wrong, if it is is the place were settings are stored and when settings are often changed. So they would have to be checked. It really does not solve anything at all.

Of course I know that this is ultimately up to the engine author. I just meant that the way xboard does things should discourage it. However, if engines only remember the settings if a "Save Settings" button is pressed, that's not quite as bad. But I would prefer that xboard rather than the engine were responsible for saving settings, and that it was done with standardized config files.

Well, WinBoard does not keep a database of engines, let alone information on their settings. It would be larely wasted effort to maintain such a database in WinBoard, as the information could then still not be used to select engines for a tournament, and would have to be duplicated in the tournament manager.

I share your dislike for "Save Settings on Exit" type of persistence, and even more persistence types where a change would be committed to file automatically immediately.

For clarification, are the command line options you're talking about xboard's command line options or the engine's command line options?
If they are xboard's command line options, that sounds a little messy, but still workable.
If they are the engine's then I suppose this part remains unchanged from previous versions of xboard. But unfortunately, engine authors may begin to abandon command line options because the options can be set through the GUI, and that brings us back to the problem of computer programs that call xboard being unable to set the options.

They are indeed GUI command-line options. The option features reported by the first engine are matched by XBoard with the string given in the -firstOptions argument, and if there is a match, the value specified in the -firstOptions s immediatey sent to the engine.

I would hope that making multiple copies of the same executable in different folders would never be necessary. xboard (not just the engine) should provide a way for the calling program to specify any and all engine options available through the GUI. If you do, then I see no reason for multiple copies of the same executable. If you don't, that's a problem.

Well, some engines cannot even run twice in the same folder even with the same settings (e.g. for a time-odds match). For engines that have configurable options in an ini file of a fixed name in its own folder, I don't see any way to run two versions without making a copy. For engines that can be configured through the xboard interface it would be possible to run two versions of a single executable by passing the value of options that you want to differ from TM via GUI to engine. The engine would have to occur twice in the TM database, with different GUI arguments. An advanced TM might have its own graphical interface to enter the settings for the installed engines in its database, a less advanced one might require you to explicitly write out the GUI options for configuring the engine. But there is nothing that the GUI could do here to help. Fortuately installing multiple copies of the same engine with different settings is not something a typical user would do.

[Michel]

I share your dislike for "Save Settings on Exit" type of persistence, and even more persistence types where a change would be committed to file automatically immediately.

Well engine options in Arena are persistent. I think I am not alone in finding this the expected behaviour.

[H.G.Muller]

Well, in general editors do not save changes without at least prompting you.

[Michel]

Well, in general editors do not save changes without at least prompting you.

Yes but on the other hand most programs remember settings without being asked explicitly to do so.
Look for example at the preference window in Firefox. Or gconf-editor.

Personally I hate it when a program forgets its settings after restart.

To be clear my latest version of PG has persistence disabled.

[mikeleany]

Well, in general editors do not save changes without at least prompting you.

Yes but on the other hand most programs remember settings without being asked explicitly to do so.
Look for example at the preference window in Firefox. Or gconf-editor.

Personally I hate it when a program forgets its settings after restart.

To be clear my latest version of PG has persistence disabled.

I view engine settings as being between browser settings and your typical text file in terms of what I expect when editing them. Wanting different browser settings for the same user is rare. Wanting different engine settings for the same user is not. But more importantly, wanting to change your browser settings for only one use is much more rare than wanting to change your engine settings for only one use. I can deal with the way Arena handles settings because it allows for copy and then modify where the save is expected (due to the layout of the dialog), but then you have to manually discard temporary settings. I would prefer to modify, and then decide later (perhaps after playing a few games) if I want to discard the changes, keep the changes in the same settings file, or save the settings to a new file. But I guess that's really a matter of personal preference. What I detest though, is if engine settings are automatically overwritten with no warning, especially if there's no option to copy the settings before modifying them.

[mikeleany]

As long as there are no problems with (3), then (1) could be taken care of if xboard had configuration files similar to polyglot's ini files.

I don't see how that would help. What was in the configuration files could be wrong, if it is is the place were settings are stored and when settings are often changed. So they would have to be checked. It really does not solve anything at all.

But if the settings are in a configuration file that is NOT autosaved, the user can make it once and never touch it again. Problem solved. The command line options you mention below should also solve this problem, but sound a bit more cumbersome. I guess I can live with that, though.

Of course I know that this is ultimately up to the engine author. I just meant that the way xboard does things should discourage it. However, if engines only remember the settings if a "Save Settings" button is pressed, that's not quite as bad. But I would prefer that xboard rather than the engine were responsible for saving settings, and that it was done with standardized config files.

Well, WinBoard does not keep a database of engines, let alone information on their settings. It would be larely wasted effort to maintain such a database in WinBoard, as the information could then still not be used to select engines for a tournament, and would have to be duplicated in the tournament manager.

No database needed, only individual configuration files (located wherever the user wants them) for each set of settings in a standard format which the tournament manager can also read and write to if it wants. Personally, I don't even care if xboard can write them, only that it can read and make use of them, but I expect other users would appreciate having the ability to write them using xboard.

I share your dislike for "Save Settings on Exit" type of persistence, and even more persistence types where a change would be committed to file automatically immediately.

For clarification, are the command line options you're talking about xboard's command line options or the engine's command line options?
If they are xboard's command line options, that sounds a little messy, but still workable.
If they are the engine's then I suppose this part remains unchanged from previous versions of xboard. But unfortunately, engine authors may begin to abandon command line options because the options can be set through the GUI, and that brings us back to the problem of computer programs that call xboard being unable to set the options.

They are indeed GUI command-line options. The option features reported by the first engine are matched by XBoard with the string given in the -firstOptions argument, and if there is a match, the value specified in the -firstOptions s immediatey sent to the engine.

Ok. Sounds workable.

I would hope that making multiple copies of the same executable in different folders would never be necessary. xboard (not just the engine) should provide a way for the calling program to specify any and all engine options available through the GUI. If you do, then I see no reason for multiple copies of the same executable. If you don't, that's a problem.

Well, some engines cannot even run twice in the same folder even with the same settings (e.g. for a time-odds match). For engines that have configurable options in an ini file of a fixed name in its own folder, I don't see any way to run two versions without making a copy.

You are right. I was not considering this possibility, as I seldom run an engine that's not my own against itself. But in this case, it's the engine's fault, not xboard's.

For engines that can be configured through the xboard interface it would be possible to run two versions of a single executable by passing the value of options that you want to differ from TM via GUI to engine. The engine would have to occur twice in the TM database, with different GUI arguments. An advanced TM might have its own graphical interface to enter the settings for the installed engines in its database, a less advanced one might require you to explicitly write out the GUI options for configuring the engine. But there is nothing that the GUI could do here to help. Fortuately installing multiple copies of the same engine with different settings is not something a typical user would do.

So to sum up our conversation: I did indeed misunderstand the way settings are being handled. They're not handled the way I think would be ideal, but everything sounds workable (so long as engine authors cooperate), so I'm sorry I doubted.

[Michel]

What I detest though, is if engine settings are automatically overwritten with no warning, especially if there's no option to copy the settings before modifying them.

I agree. I would prefer that WB would evolve to a Arena style of setting settings where you can copy before write (and undo changes by returning to default settings). But since it will remain exactly one set of settings per engine with no standard way of returning to defaults, persistence is really dangerous. That's why I turned it off again in PG.

Also: if WB would one day allow more sets of settings per engine then it would be more logical for WB to maintain them. There would be no need for PG or any other WB engine to do any saving by itself.