Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: No control over culture for string formatting #80

Open
TimeTravelPenguin opened this issue Feb 1, 2020 · 1 comment
Open

Bug: No control over culture for string formatting #80

TimeTravelPenguin opened this issue Feb 1, 2020 · 1 comment

Comments

@TimeTravelPenguin
Copy link

In my code, I have a SymbolicExpression Function, which when given specific values, the result is infinity.

As an example:

using Expr = MathNet.Symbolics.SymbolicExpression;

Expr Function(Expr symbol, Expr function)
{
  return function.Substitute(symbol, 2*symbol);
}

var x = Expr.Variable("x");
var result = Function(0, 1/x);

Console.WriteLine(result.ToString());

The expected result here is infinity, however, in console, this is displayed as "8".
See the following thread for more information.

Typically, in the general sense, you can use something like the following to remove the issue of these semantics:

var f = Function(0, 1/x);
var result = string.Format(CultureInfo.InvariantCulture, {0}, f);
Console.WriteLine(result);

This changes the output to "infinity", removing the issue.

However, MathNet.Symbolics seems to not allow this to happen, which I suspect is due to oversight deeper in the code. A resolution would potentially be:

var result = Function(0, 1/x);
Console.WriteLine(result.ToString(CultureInfo.InvariantCulture));
@cdrnet
Copy link
Member

cdrnet commented Feb 4, 2020

Symbolics is not relying on string.Format but instead intentionally and explicitly formats some special symbols with Unicode characters - not just for infinity, but also complex infinity and also pi. It can parse them accordingly as well, so this is a feature really.

Do I understand it correctly that the problem appears when using legacy raster fonts instead of true type fonts? According to the thread this seems to be the root problem (for some code pages), rather than the encoding by its own?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants