On Wed, Aug 14, 2024 at 6:10 AM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
I'm observing the following behavior on a German system, but running
gretl without the local dec sep setting, i.e. not using the comma.
<gretl-console>
? = 1.6
1.6
? set force_decpoint off
? = 1.6
1,6
</gretl-console>
The first thing is OK, gretl showing in response that it's using the
point (period) for display. After setting force_decpoint to off, gretl
is then using the comma. The background is that this is screwing up some
code.
I'm having a deja-vu about this: But I believe that our conclusion in a
previous discussion was that if I don't want to _force_ the decimal
point any longer, then I want to revert to the current setting as
governed by the user preferences, _not_ to use the default language
setting. In my case, continue to use the point.
So, has this behavior crept back in? This is with the snapshot from Aug
5th (standard, GTK2) on Windows.
Oh, and here's another interesting printout, coming from gretlcli.exe:
<gretlcli>
? =1.6
1.6
? set force_decpoint off
? = 1.6
1
</gretlcli>
I can confirm this (bad, unintended) behavior, but it's limited to the
combination of Windows + you're operating in a locale that specifies
the decimal comma by default, but choose to use the decimal dot. On
Linux it works as intended: both "set force_decpoint on" and "set
force_decpoint off" do nothing if the decimal dot is already selected,
either because it's native to the locale or the user has registered a
preference for the dot. Locale issues are difficult in Windows due to
their non-standard legacy specification. However it ought to be
possible to fix this (I hope).
Allin