.NET некоторые значения, умноженные на большой коэффициент на некоторых машинах, а не другие - PullRequest
0 голосов
/ 12 марта 2011

У меня довольно странная проблема. У меня есть очень простое приложение, которое читает некоторые данные из файла в формате csv и рисует полярную «бабочку» в форме. Однако некоторые люди в европейских странах получают очень странную кривую, и когда я изменил программу для вывода некоторых значений выборки, чтобы попытаться выяснить, что происходит, это только дало мне больше вопросов!

Вот пример ожидаемых значений и того, что вместо этого получает один конкретный пользователь:

EXPECTED -> SEEN   
0.00 0.00  -> 0,00 0,00  
5.00 1.35  -> 5,00 1346431626488,41  
10.00 2.69 -> 10,00 2690532522738,65  

Таким образом, все значения справа (которые вычисляются в моей программе) умножаются на коэффициент 10 ^ 12 !! Как же это может произойти в CLR? первые числа - 0, 5, 10 - просто создаются простым циклом, который записывает вывод, используя: value += 5.

Код, производящий эти вычисления, использует интерполяцию с использованием библиотеки alglib.net, но проблема также возникает с 2 другими значениями, которые извлекаются из xml, возвращаемого из http get, а затем преобразуются из радиан в градусы.

Также не совсем проблема, но почему десятичные значения печатаются с запятыми вместо десятичных точек? Выходной код представляет собой простой string.Format("{0:F}", value), где значение является двойным?

Так с какой стати некоторые значения будут сдвинуты на 12 десятичных знаков, но не другие, и только в некоторых странах? Да, другие запустили приложение без проблем ... Не уверен, есть ли какое-либо отношение, но этот вывод пришел из Нидерландов.

Ответы [ 4 ]

5 голосов
/ 12 марта 2011

В разных культурах используются разные тысячи и десятичные разделителиen-US (американский английский) использует "," и "."но de-DE (немецкий немецкий) использует "."а также ",".Это означает, что при чтении или записи в строки необходимо использовать правильную культуру.При сохранении информации для последующего поиска это обычно означает CultureInfo.InvariantCulture.При отображении информации пользователю это обычно означает CultureInfo.CurrentCulture.

. Вы не предоставили код, который читает из файла CSV, но я предполагаю, что вы делаете что-то вроде double.Parse(field) для каждого поля.Если поле имеет значение «5.0», и вы анализируете его, когда текущая культура де-DE «.»будет считаться разделителем тысяч, а значение будет считаться как 50.0 в терминах en-US.То, что вы должны сделать, это double.Parse(field, CultureInfo.InvariantCulture).

Все Parse, TryParse, Format, и многие ToString методы принимают IFormatProvider.Привыкайте всегда предоставлять поставщика соответствующего формата, и вас не укусят проблемы интернационализации.

3 голосов
/ 12 марта 2011

Мое личное предположение было бы, что у вас есть строка -> преобразование чисел где-то, что вообще не учитывается культурой.

Почему бы просто запустить этот код:

var nl = System.Globalization.CultureInfo.GetCultureInfo("nl-NL");
var numberString = "1.000000000000000";
Console.WriteLine(float.Parse(numberString, nl));

Результат1E+15 теперь вам просто нужно найти места, где вам нужно указать CultureInfo.InvariantCulture (упрощенный английский, эквивалентный культуре "C" в C) до Parse вместе со строкой.

0 голосов
/ 12 марта 2011

Следует отметить одну интересную вещь: если бы 1346431626488 было разделено на 1 000 000 000 000, то вы получили бы 1,35 с округлением до двух десятичных знаков.А если 2,69 поделить на 1 000 000 000 000, то получится округление 2,69 до двух десятичных знаков.Просто наблюдение.

0 голосов
/ 12 марта 2011

В некоторых языках вместо десятичной запятой используется десятичная запятая . Это зависит от культуры. Вы можете навязать свою собственную культуру, если для вас важно, чтобы использовались только очки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...