Skip to content

Conversation

@dpiparo
Copy link
Member

@dpiparo dpiparo commented Dec 20, 2024

Fixes #17225

Copy link
Member

@lmoneta lmoneta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, if it passes the tests should be fine.
Thank you Danilo for the fix

TString value = TString::Format("%lf", (*constIt).second);
// #17225: we take into account LC_LOCALE settings for which the decimal separator
// is , instead of ., e.g. de_AT.UTF-8
TString value = TString::Format("%lf", (*constIt).second).ReplaceAll(",", ".");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be dependent on the value of LC_LOCALE? (in some local we might have 1,200.00 for one thousand two hundreds).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a good observation. But how can we adapt to all possible locale?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually it seems that there are only 3 decimal separators: comma, period and arabic decimal separator (https://randombits.dev/articles/number-localization/locale-list)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking more about it... If we have an arabic decimal separator, it means that we also have arabic digits. At that point, I am unsure whether the decimal separator would be the first problem we hit...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I think we need a larger conversation about local and how to handle them. It seems odds/confusion to all support local for this single functions. Until we have this conversation, I recommend we issue an explicit error when encountering a comma here.

@github-actions
Copy link

github-actions bot commented Dec 20, 2024

Test Results

    18 files      18 suites   4d 4h 24m 48s ⏱️
 2 681 tests  2 680 ✅ 0 💤 1 ❌
46 536 runs  46 535 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit c7a2716.

♻️ This comment has been updated with latest results.

guitargeek added a commit to guitargeek/root that referenced this pull request Aug 24, 2025
In root-project#18194, an optional parameter to `TFormula::GetExpFormula()` was
introduced, which can be used to customize the precision when putting
parameters into the jitted code.

However, I don't see the reason why wouldn't like to always print the
floating point numbers with maximum precision, which is suggested in
this commit.

This is achieved using modern C++ functions, which are also not
respecting the users locale setting, but instead use the classic C
locale by default, which is what we need when generating code.

Follows up on root-project#18194 (and its partial revert root-project#18216).

Closes root-project#17225.

Replaces root-project#17327.
@dpiparo
Copy link
Member Author

dpiparo commented Aug 26, 2025

Superseded by #19734.

@dpiparo dpiparo closed this Aug 26, 2025
@dpiparo dpiparo deleted the fix_17225 branch August 26, 2025 06:19
guitargeek added a commit that referenced this pull request Aug 26, 2025
In #18194, an optional parameter to `TFormula::GetExpFormula()` was
introduced, which can be used to customize the precision when putting
parameters into the jitted code.

However, I don't see the reason why wouldn't like to always print the
floating point numbers with maximum precision, which is suggested in
this commit.

This is achieved using modern C++ functions, which are also not
respecting the users locale setting, but instead use the classic C
locale by default, which is what we need when generating code.

Follows up on #18194 (and its partial revert #18216).

Closes #17225.

Replaces #17327.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TFormula: Possibility of failure during dynamic compilation of predefined functions "gausn" and "landau"

3 participants