Это странно .... Я установил решение с 4 проектами
- a. NET Framework 4.7.2 project
- a. NET Core 2.0 проект
- a. NET проект Core 3.1
- a. NET проект Core 3.1 для запуска всех 3 проектов одновременно.
В каждом проекте I использовал константу Math.PI, чтобы увидеть, если что-то изменится, и это действительно произошло, но не так, как я ожидал.
Если я запускаю четвертый проект, тот, который вызывает все 3, я получаю этот результат
Значения всех трех проектов одинаковы. Но если я запускаю их отдельно, я получаю следующие результаты:
. NET Framework
. NET Core 2
. NET Core 3
Так что для некоторых причина, по которой я получаю разные результаты от вашего. NET Core использует Math.PI константы, и они одинаковы для версии 2 и 3.1. Однако я получаю тот же результат, что и у вас с. NET Framework, который отличается от двух. NET Core. Но, как мы видели выше, если вы запустите все 3 проекта из другого проекта, сделанного в. NET Core, вы получите те же результаты, то есть, возможно, это вызывающий проект, который определяет, какое округление следует использовать. К сожалению, я не могу найти точную причину, почему это происходит, но если я правильно помню, есть некоторые незначительные различия в том, как округление работает в Windows по сравнению с Unix системами. Поскольку. NET Core является кроссплатформенным, я думаю, что используется округление Unix, а не Windows, которое, вероятно, используется. NET Framework, что приводит к этим различиям.
РЕДАКТИРОВАТЬ: Это выходит за рамки науки сейчас ... Я использовал постоянное значение 3.14159265358979 вместо Math.PI, что в теории то же самое (в соответствии с Документация Microsoft ). Но при использовании этого значения результаты снова меняются! Если вы запустите тест, в котором запущены все 3 проекта, вы все равно получите те же результаты для всех 3, но они отличаются от предыдущего запуска
39,2975164552063
31,438013450643936
3,5725015284376096
При запуске. NET Framework Framework вы Получите те же результаты, что и раньше, при запуске. NET Core, вы получите вышеуказанные результаты. Таким образом, использование постоянного значения вместо Math.PI изменяет результаты еще раз. Но это на самом деле бессмысленно, поскольку под капотом Math.PI - это просто двойная константа со значением 3.14159265358979
РЕДАКТИРОВАТЬ 2: Я написал ту же программу с Python
def main():
x = 123.4567890 / 3.14159265358979
print(x)
y = 98.76543210 / 3.14159265358979
print(y)
z = 11.2233445566778899 / 3.14159265358979
print(z)
if __name__ == "__main__":
main()
и результаты идентичны. NET Core
39.2975164552063
31.438013450643936
3.5725015284376096
Затем я попытался сделать то же самое, используя Go
package main
import "fmt"
func main() {
x := 123.4567890 / 3.14159265358979
fmt.Println(x)
y := 98.76543210 / 3.14159265358979
fmt.Println(y)
z := 11.2233445566778899 / 3.14159265358979
fmt.Println(z)
}
И в этом случае результаты
39.2975164552063
31.43801345064394
3.5725015284376096
y округлено до ..94, тогда как x и z совпадают с python и. NET Core.
В качестве финального теста я попытался сделать это с Javascript / Node.JS
let x = 123.456789 / 3.14159265358979;
console.log(x);
let y = 98.7654321 / 3.14159265358979;
console.log(y);
let z = 11.2233445566778899 / 3.14159265358979;
console.log(z);
Но здесь также результаты такие же, как python и. Net Core
39.2975164552063
31.438013450643936
3.5725015284376096
Поскольку Python, JS,. NET Core и GO (если вы не учитываете округление y), являются кроссплатформенными, я предполагаю, что что-то связано с Windows экосистема, на которую опирается. NET framework. Было бы интересно попробовать другие фреймворки / языки, связанные с Windows, но я не знаю ничего, кроме. NET Framework (может быть, Visual Basi c?)