그리고 제 생각에는 결과 측면에서 첫 번째와 두 번째가 동일 합니다. 변수와 b에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다. Renat는 다른 것에 대해 썼습니다. 그 예에서 정규화된 값을 뺀 결과가 정규화 되지 않았기 때문입니다. 연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산 을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다.
어떤 경우에는 실제로 작동하지만 항상 그런 것은 아닙니다. 이 "항상 그런 것은 아님"은 컴퓨터 메모리에 값을 저장하는 독특한 방법에 의해 결정됩니다. 사실.
변수와 b에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다. 그것은 불가능 합니다. 저것들. 무엇이든 할 수 있지만 보장된 결과를 얻으려면 비교 연산자가 포함된 표현식에서 직접 NormalizeDouble ()을 사용해야 합니다.
Renat는 다른 것에 대해 썼습니다. 그 예에서 정규화된 값을 뺀 결과가 정규화 되지 않았기 때문입니다. 네. 그러나 이것이 귀하의 이전 진술이 정확하다는 것을 의미하지는 않습니다.
연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다. 사용된 특정 컴퓨터 기술로 인해 마지막 숫자의 값이 변경될 수 있습니다. 이것은 사용자가 눈치채지 못하는 사이에 발생할 수 있으며 실제로 발생합니다. 사실. 어떤 경우에는 (예를 들어, 프로그램 디버깅 중에) 작동할 것이고, 이 프로그램을 사용할 때 종종 불행한 프로그래머가 예상한 대로 작동할 것이고 때로는 작동하지 않을 것입니다.
조건이 충족되지 않습니다. 이퀄라이징 안됨? 그럼에도 불구하고 메모리에서 이중 변수를 저장하거나 읽는 데 오류가 있다고 생각하는 이유는 무엇입니까? 산술 연산 에 오류가 있습니까?
이 경우 오류가 있을 수 있다고 생각하십니까?
double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
gravity001 писал (а): На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял. У меня были ошибки при сравнении, когда я использовал такую конструкцию:
gravity001 : 조건이 충족되지 않습니다. 이퀄라이징 안됨? 그럼에도 불구하고 메모리에서 이중 변수를 저장하거나 읽는 데 오류가 있다고 생각하는 이유는 무엇입니까? 산술 연산에 오류가 있습니까?
이 경우 오류가 있을 수 있다고 생각하십니까?
double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
나눗셈 자체가 제대로 실행되고 있다고 생각합니다.
논의 중인 문제는 일부 변수의 값을 얻는 방법(변수의 계산 또는 초기화의 결과로 얻은 값인지 여부)에 관한 것이 아니라 프로그램 실행 중 이 변수 값의 운명에 관한 것입니다. 그리고 심지어 컴퓨터의 작동. 그리고 그녀의 운명은 예측할 수 없습니다. 따라서 논리 연산을 프로그래밍할 때 빨간색 배너 함수인 NormalizeDouble ()을 사용해야 합니다.
SK. писал (а): 어떤 경우에는 실제로 작동하지만 항상 그런 것은 아닙니다. 이 "항상 그런 것은 아님"은 컴퓨터 메모리에 값을 저장하는 독특한 방법에 의해 결정됩니다. 사실. 컴퓨터 메모리에 값을 저장하는 방법을 알고 있습니다. :) 프로그래밍 경력은 약 20년입니다. 과거 대학에서 학생들에게 프로그래밍을 가르친 적도 있습니다.
변수와 b에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다. 그것은 불가능 합니다. 저것들. 무엇이든 할 수 있지만 보장된 결과를 얻으려면 비교 연산자가 포함된 표현식에서 직접 NormalizeDouble ()을 사용해야 합니다.
당연히 어떤 식으로 계산한 결과를 비교하기 전에 이 결과를 정규화해야 합니다! 누가 이것으로 논쟁을 벌이는 겁니까?! 그러나 이것은 우리의 논의와 아무 관련이 없습니다. 나는 코드 아이덴티티에 대해 이야기하고 있었다. 그리고 그것의 전체 차이점은 두 번째 경우 정규화 결과가 변수에 저장된다는 것입니다. 그리고 모든 것!
저것들. NormalizeDouble 함수의 비트 너비가 두 배보다 큰 결과가 있다고 주장합니다(함수의 결과는 최소 1비트만큼 더 많은 메모리 비트를 차지함). 이것에 대해서만 함수의 결과를 변수에 저장할 때 손실(또는 변경)을 설명할 수 있습니다. 또는 할당할 때 한 메모리 셀에서 다른 메모리 셀로 데이터를 바이트 단위로 복제하는 것이 아니라 일부 까다로운 작업이 수행됩니다.
다시 한 번 말씀드리지만, 비교 연산의 오른쪽과 왼쪽 피연산자의 개별 정규화의 정확성 등을 논의하는 것이 아닙니다. 질문은 위의 두 코드 조각의 결과 ID에 관한 것입니다.
연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다. 사용된 특정 컴퓨터 기술로 인해 마지막 숫자의 값이 변경될 수 있습니다. 이것은 사용자가 눈치채지 못하는 사이에 발생할 수 있으며 실제로 발생합니다. 사실. 어떤 경우에는 (예를 들어, 프로그램 디버깅 중에) 작동할 것이고, 이 프로그램을 사용할 때 종종 불행한 프로그래머가 예상한 대로 작동할 것이고 때로는 작동하지 않을 것입니다.
와! 그리고 어떤 종류의 "특정 컴퓨터 기술"을 의미합니까? 일반적으로 사용자 의 경우 많은 일이 "눈에 띄지 않게 발생"하지만 결국 우리는 프로그래머 입니다. :) 우리에게는 눈에 띄지 않게 아무 일도 일어나지 않아야 합니다 . 그렇지 않으면 더 이상 컴퓨터가 아니라 예측할 수 없는 결과의 생성기가 될 것입니다. :) 아니면 이미 컴퓨터에 떠도는 비트가 있습니까? 때로는 그렇게 읽고 때로는 그렇게... 다시 한 번! 실수로 산술 연산을 수행할 때 결과는 실제로 절대적으로 정확하지 않습니다 (실수가 표현되는 방식으로 인해). 그러나 할당 작업에는 적용되지 않습니다. NormalizeDouble 함수가 완료되어 double 유형의 결과를 반환한 후 이 결과는 단순히 값을 복사하여 변수에 배치됩니다(모든 바이트가 일치함). 미래에는 변수의 값이 변경되지 않는 동안(즉, 읽기만 하고 아무 것도 기록되지 않음), 원래 형식으로 저장되고 어떤 범주에도 표시되지 않습니다. 읽어도 똑같은 내용이 나옵니다. 그러나 적어도 1을 곱하고 결과를 다시 쓰는 것으로 충분합니다. 여기에는 아무 것도 보장되지 않습니다.
double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
이 경우 작업 결과는대략 2.0 이 됩니다. 매우 먼 숫자의 오류는 실수가 표현되는 방식으로 인해 발생할 수 있습니다.
나는 이것을 말하면서 더 많은 것을 비교하는 것을 의미합니다.
형식의 구성이 항상 작동하는 것은 아니라는 점을 염두에 두십시오.
변수와 b 에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다.
Renat는 다른 것에 대해 썼습니다. 그 예에서 정규화된 값을 뺀 결과가 정규화 되지 않았기 때문입니다.
연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산 을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다.
이 구성을 다소 확인하지는 않았지만 평등을 확인했습니다.
이 구성을 사용할 때 비교 오류가 발생했습니다.
왜 몰라?
어떤 실수?
그리고 제 생각에는 결과 측면에서 첫 번째와 두 번째는 동일 합니다.
어떤 경우에는 실제로 작동하지만 항상 그런 것은 아닙니다. 이 "항상 그런 것은 아님"은 컴퓨터 메모리에 값을 저장하는 독특한 방법에 의해 결정됩니다. 사실.
변수와 b 에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다.
그것은 불가능 합니다. 저것들. 무엇이든 할 수 있지만 보장된 결과를 얻으려면 비교 연산자가 포함된 표현식에서 직접 NormalizeDouble ()을 사용해야 합니다.
Renat는 다른 것에 대해 썼습니다. 그 예에서 정규화된 값을 뺀 결과가 정규화 되지 않았기 때문입니다.
네. 그러나 이것이 귀하의 이전 진술이 정확하다는 것을 의미하지는 않습니다.
연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다.
사용된 특정 컴퓨터 기술로 인해 마지막 숫자의 값이 변경될 수 있습니다. 이것은 사용자가 눈치채지 못하는 사이에 발생할 수 있으며 실제로 발생합니다. 사실. 어떤 경우에는 (예를 들어, 프로그램 디버깅 중에) 작동할 것이고, 이 프로그램을 사용할 때 종종 불행한 프로그래머가 예상한 대로 작동할 것이고 때로는 작동하지 않을 것입니다.
신규유저들에게 똑같은걸 1000번씩 설명해줘야 하는 개발자분들께 심심한 위로의 말씀을 드립니다..
이 구성을 다소 확인하지는 않았지만 평등을 확인했습니다.
이 구성을 사용할 때 비교 오류가 발생했습니다.
왜 몰라?
어떤 실수?
그럼에도 불구하고 메모리에서 이중 변수를 저장하거나 읽는 데 오류가 있다고 생각하는 이유는 무엇입니까? 산술 연산 에 오류가 있습니까?
이 경우 오류가 있을 수 있다고 생각하십니까?
На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял.
У меня были ошибки при сравнении, когда я использовал такую конструкцию:
Почему, не знаете?
조건이 충족되지 않습니다. 이퀄라이징 안됨?
그럼에도 불구하고 메모리에서 이중 변수를 저장하거나 읽는 데 오류가 있다고 생각하는 이유는 무엇입니까? 산술 연산에 오류가 있습니까?
이 경우 오류가 있을 수 있다고 생각하십니까?
나눗셈 자체가 제대로 실행되고 있다고 생각합니다.
논의 중인 문제는 일부 변수의 값을 얻는 방법(변수의 계산 또는 초기화의 결과로 얻은 값인지 여부)에 관한 것이 아니라 프로그램 실행 중 이 변수 값의 운명에 관한 것입니다. 그리고 심지어 컴퓨터의 작동. 그리고 그녀의 운명은 예측할 수 없습니다. 따라서 논리 연산을 프로그래밍할 때 빨간색 배너 함수인 NormalizeDouble ()을 사용해야 합니다.
적용이 좋습니다. 올바른 사용은 매우 좋습니다.
적용하지 마십시오. 잘못된 사용은 나쁜 것입니다.
---
휴가가고싶다..
어떤 경우에는 실제로 작동하지만 항상 그런 것은 아닙니다. 이 "항상 그런 것은 아님"은 컴퓨터 메모리에 값을 저장하는 독특한 방법에 의해 결정됩니다. 사실.
컴퓨터 메모리에 값을 저장하는 방법을 알고 있습니다. :) 프로그래밍 경력은 약 20년입니다. 과거 대학에서 학생들에게 프로그래밍을 가르친 적도 있습니다.
변수와 b 에 할당된 결과는 정규화되어 비교할 수 있으며 아무 일도 일어나지 않습니다.
그것은 불가능 합니다. 저것들. 무엇이든 할 수 있지만 보장된 결과를 얻으려면 비교 연산자가 포함된 표현식에서 직접 NormalizeDouble ()을 사용해야 합니다.
당연히 어떤 식으로 계산한 결과를 비교하기 전에 이 결과를 정규화해야 합니다! 누가 이것으로 논쟁을 벌이는 겁니까?! 그러나 이것은 우리의 논의와 아무 관련이 없습니다. 나는 코드 아이덴티티에 대해 이야기하고 있었다. 그리고 그것의 전체 차이점은 두 번째 경우 정규화 결과가 변수에 저장된다는 것입니다. 그리고 모든 것!
저것들. NormalizeDouble 함수의 비트 너비가 두 배보다 큰 결과가 있다고 주장합니다(함수의 결과는 최소 1비트만큼 더 많은 메모리 비트를 차지함). 이것에 대해서만 함수의 결과를 변수에 저장할 때 손실(또는 변경)을 설명할 수 있습니다. 또는 할당할 때 한 메모리 셀에서 다른 메모리 셀로 데이터를 바이트 단위로 복제하는 것이 아니라 일부 까다로운 작업이 수행됩니다.
다시 한 번 말씀드리지만, 비교 연산의 오른쪽과 왼쪽 피연산자의 개별 정규화의 정확성 등을 논의하는 것이 아닙니다. 질문은 위의 두 코드 조각의 결과 ID에 관한 것입니다.
연산의 최종 결과를 정규화하면 변수에 할당한 다음 연산을 수행할 수 있습니다. 가장 중요한 것은 변수 자체가 미래에 값을 변경하지 않는다는 것입니다.
사용된 특정 컴퓨터 기술로 인해 마지막 숫자의 값이 변경될 수 있습니다. 이것은 사용자가 눈치채지 못하는 사이에 발생할 수 있으며 실제로 발생합니다. 사실. 어떤 경우에는 (예를 들어, 프로그램 디버깅 중에) 작동할 것이고, 이 프로그램을 사용할 때 종종 불행한 프로그래머가 예상한 대로 작동할 것이고 때로는 작동하지 않을 것입니다.
와! 그리고 어떤 종류의 "특정 컴퓨터 기술"을 의미합니까? 일반적으로 사용자 의 경우 많은 일이 "눈에 띄지 않게 발생"하지만 결국 우리는 프로그래머 입니다. :) 우리에게는 눈에 띄지 않게 아무 일도 일어나지 않아야 합니다 . 그렇지 않으면 더 이상 컴퓨터가 아니라 예측할 수 없는 결과의 생성기가 될 것입니다. :) 아니면 이미 컴퓨터에 떠도는 비트가 있습니까? 때로는 그렇게 읽고 때로는 그렇게... 다시 한 번! 실수로 산술 연산을 수행할 때 결과는 실제로 절대적으로 정확하지 않습니다 (실수가 표현되는 방식으로 인해). 그러나 할당 작업에는 적용되지 않습니다. NormalizeDouble 함수가 완료되어 double 유형의 결과를 반환한 후 이 결과는 단순히 값을 복사하여 변수에 배치됩니다(모든 바이트가 일치함). 미래에는 변수의 값이 변경되지 않는 동안(즉, 읽기만 하고 아무 것도 기록되지 않음), 원래 형식으로 저장되고 어떤 범주에도 표시되지 않습니다. 읽어도 똑같은 내용이 나옵니다. 그러나 적어도 1을 곱하고 결과를 다시 쓰는 것으로 충분합니다. 여기에는 아무 것도 보장되지 않습니다.
신규유저 들 에게 똑같은걸 1000번씩 설명 해줘야 하는 개발자분들께 심심한 위로의 말씀을 전합니다..
이 경우 오류가 있을 수 있다고 생각하십니까?
매우 먼 숫자의 오류는 실수가 표현되는 방식으로 인해 발생할 수 있습니다.