MISRA-C: 2004 Rule 13.3 : Floating-point expressions shall not be tested for equality or inequality. MISRA-C: 2004 코딩규칙 13.3 : 부동소수 표현은 같음/다름을 테스트해서는 안된다. (비교연산자 == 와 != 를 사용해서는 안된다.)
@@HJ-ri9fj60년대머에 펀치카드로배웠고제일 많이 쓴것은 vax/vms fortran 이어서 경험이부족하지요 당시에는cobol이흐이던시절이라 두개를 한프로그램에서 불러흐기도 햏는데 이런 편의점들이 이식성을 많이낮추어습니다. 표준도읽은적이있지만 그 태에는posix 작업했었고 fortran 과는작별했습니다. 요약하면 평생강좌를 열 실력에 다다른적이 없어 난처한브탁입니다.
최대한 부동소수점으로는 연산하지 않는 습관을 들이세요 별생각없이 짠 decimal 1이 되어야 할 코드가 integer 0이 되어있을겁니다 (부동소수점으로 바꿔보면 0.99999...) 반도체장비였다면 그 장비안에 검사도구가 없을경우 웨이퍼 몇백장을 날려먹을수도 있습니다
@@알쓸컴잡 경솔하게 짤 경우 인티저도 백분율 계산같은거 잘못하면 "factor(100보다 작은 값) / 100 * percentage (= 항상0)" 같은 오류 공식을 쓸 확률이 높은건 마찬가지입니다. 이런경우 곱하기를 먼저 하기만 해도 해결되긴 하지만 가독성을 우선시한다면 그냥 부동소수점 쓰는게 낫겠죠. 때에 따라 합리적으로 쓰는게 맞는거지 가급적 인티저를 쓰라는 말은 좀 애매한 표현 같아요. "부동소수점 연산이 필요없을때는 가급적(혹은 무조건) 인티저를 써라"가 맞는 말이지 "가급적 부동소수점 연산을 피해라"라는 말은 틀린 말인것 같습니다. 부동소수점 연산을 피할 수 없는 게임, 물리 시뮬레이션, 트랜지션 이런거 만들때도 일부러 변태처럼 인티저로 에뮬레이션 코드 짜야될까요? 왜죠? ㅋㅋㅋ
그냥 요즘 흔한, CS 지식없이 코딩'만' 배운 사람들은 잘 빠질만한 문제네요. 4:29 그런데 수치해석 해야하는 경우에는 여기서 말하는 회피수단은 사용 못 하므로 절대값 뺀 후 오차범위 이내인가를 판단 ( |a-b| < eps ) 하는 방법에 대해도 언급했으면 더 좋았을듯 합니다. 마지막 해법인 double 로 올려본들, 소수점 이하 어딘가에서 저런 문제 생기는 건 똑같거든요.
24자리로 100시간에 0.34초 오차면, 62자리(?)로 10000000000000000000000000000000 시간에 0.34초 오차인것 아닌가요? 100시간으로 따져보면 0.00000000000000000000000000034초 오차인데 이정도는.. 미미한것아닐까 싶기도한데 몇십년동안 계속 구동된다고 해도 유의미한 오차를 관측하기 힘들지 않을까 싶기도 합니다! 똥몽청이라 계산을 잣같이 했을건데, 지적 후 계산 제대로 해주시면 감사!
@@gandaahtesla5843 수치해석 하는경우에는 연산시간과 메모리 사용량이 동시에 고려되어야 합니다. 게다가 시뮬레이션의 스케일이 매우 거대한 천문학(에서도 수치해석을 하려나?) 라던지 MEMS NEMS쪽 시뮬레이션을 할 때는 기본적인 단위가 10^nn이거나 10^-6 에서 10^-9정도로 이미 자리수를 많이 까먹고 시작하게 되죠. 그래서 오차 epsilon(eps)를 이용해서 시뮬레이션 스텝을 진행하거나 종료 조건으로 잡게됩니다. 다만 이 방법은 효율적으로 계산하기 위한 방법이지 "정확"한 해답을 내놓기 위한 방법은 아니긴 하니까 다루는 내용이 조금 다를지도 모르겠네요. 물론 영상에 나온것과 같이 미사일 궤적 계산 같은 경우는 RTOS라 해서 적절한 정확도로 정시성을 보장하는 계산도 중요한 내용이라 이런 방법을 사용해 궤적을 분석하고 미사일을 조종할 수 도 있겠습니다.
이진 기준으로 소숫점 아래 23번째 자리까지만 나타내는데 이때 소숫점 아래 24번째 자리에서 오사오입(짝수-반올림)해서 나타냅니다. 예를 들어, 십진수 0.6은 이진법 수로 0. 1001 1001 1001 1001 1001 1001 ...인데 24번째 자리에서 오사오입 해서 0. 1001 1001 1001 1001 1001 101 로 저장이 됩니다.
1:52 여기서 소숫점 앞의 1을 왜 저장 안하는지 궁금하실지 모르실텐데, 0을 제외한 거의 모든 수는 이진법으로 치환하면 저렇게 1이 꼭 하나 나옵니다. 그래서 저거를 비트도 아끼고 한자리라도 더 나타내야하니 생략하자! 가 되어버려서 그런겁니다. 이 때문에 IEEE 754 프로토콜을 가진 컴퓨터는 궁극적으로 0을 나타낼 수 없게 됩니다. 생략되는 1 하나 때문에 그냥 0에 무한히 가까운 수만 나타낼 수 있습니다.
@@tubeyou1490 0이 아닌 모든 이진수 k는 1.nnnn × 2^m 의 형태를 갖게 됩니다. 뒤에 2의 몇승을 곱하는 이유가 그렇게 나타내기 위해서에요. 경우의 수를 나눠볼까요. i) | k | >= 1: 절대값이 1보다 크거나 같은 실수라면 소수점 위는 무조건 정수 형태를 띄죠. 근데 이진수 정수의 가장 높은 자리 숫자는 항상 1입니다. 4 = 101(2) 를 4 = 0101(2) 라고 적지 않죠. 맨 앞에 값이 없는 0은 몇 개를 적던 똑같기 때문에 생략하게 되고, 따라서 k = 1.??? × 2^m 의 형태가 됩니다. 참고로 4 = 101(2) 에서 중간의 0은 자릿수를 나타내기 위해 꼭 필요한 숫자입니다. ii) 0 < | k | < 1 절대값이 1보다 작은 실수여도 마찬가지입니다. 2의 몇승만 해주면 i)과 같아집니다. 따라서 k = 1.??? × 2^m 형태가 됩니다.
0의 표현을 위해 지수부의 특정 값을 예약값으로 사용합니다. 예를 들어 지수부가 모두 0인 경우 0으로, 모두 1인 경우 무한대로 간주합니다. 0을 제외한 모든 수는 위의 다른 분들이 설명하신 대로 정규화하여 1.xxxx x 2^n 꼴로 나타낼 수 있으므로, xxxx와 n만을 저장하는 것입니다.
첨언하자면 1/3은 0.3333333... 3으로 무한으로 이어진다고 알지만 컴퓨터는 어느 순간 마지막 3을 끊고 특정값으로 설정해야 할 필요가 있습니다, (위의 0.1011로 반복되는 예시) 그렇지 않으면 1/3를 표현하기 위해 모든 메모리 공간을 쓰고도 표현을 할 수가 없기 때문입니다,. (영상에서도 이 얘기가 나왔었죠? ) 따라서 특정 시점으로 끊기는 그 수와 수 사이의 간격을 Machine Epsilon(머신 입실론)이라고 합니다. 그리고 크롬의 자바스크립트 기준으로 머신 입신론 값은 2.220446049250313e-16 가 나옵니다. 크롬 콘솔창을 열고 Number.EPSILON를 입력해보세요.
추가 설명 감사드립니다. 근데 제가 잘 이해한 것이라면 머신 입실론 값은 "컴퓨터 메모리 한계로 인해 끊긴 수의 값"과 "원래 저장하려 의도한 수의 값"의 차이잖아요? 그럼 원래 의도한 수가 어떤 수인지에 따라 모신 입실론 값이 달라지는 것 아닌가요? 크롬 js엔진 기준으로 머신 입실론 값이 특정되어 있다는 뉘앙스로 말씀하셔서 궁금해져 여쭙습니다.
@@parkypark-m7f 제가 설명이 정확하지 않았네요. 의도한 수에 따라 머신입실론값이 달라지는 것이 맞습니다. 어떤수는 3이 반복되고 어떤 수는 다른 수가 반복되기 때문입니다. 그래서 친구배님 말씀대로 "원래 의도한 수"와 "끊겨서 나온 수"의 차이는 적어도 머신 입실론 값보단 작다고 할 수 있습니다. 그리고 이 차이를 통해서 소수점의 크기 비교에 필요한 유틸함수를 만들수 있는데요. 바로 두 수의 차이가 머신입실론보다 작으면 같은 수라고 판단하는 로직입니다. function equal(n1, n2) { return Math.abs(n1 - n2) < Number.EPSILON; } equal(0.1 + 0.2, 0.3); // true 하지만 이런식으로 소수를 판단하는건 매우 귀찮으니 일반적으로 수와 관련된 라이브러리를 사용하기를 권고하고 있습니다. 또는 소수가 만들어지지 않는 방식으로 값을 관리합니다. (영상 속 예시처럼 달러-> 센트) 표시처럼이요/
ㅅㅂ 이거 보면서 어차피 내가 하는 코딩에서 이거 겪을일 없음 하고 지나갓는데 마이프리코딩캠프에서 자바스크립트로 잔돈거스름 뱉는 프로젝트할때 실제로 겪음. 계속 실패하길래 왜이러지 하면서 콘솔에 로그했더니 마지막 페니가 자꾸 빔.. 개똥이가 훔쳐갓나 하면서 거스름돈 총값 출력해보니 4페니 ($0.004) 가 아닌 $0.0039999999997) 이런식으로 나와서 마지막 페니가 안튀어나온거였음..
실수의 기본 표현 방식이 +- (1.m) × 2^(e-127)이라 그렇습니다. 여기서 e는 부호 비트 뒤의 8칸, m은 맨 뒤 23칸에 저장하게 됩니다. 여기서 101.001은 1.01001 × 2^2이므로, e에 저장해야 할 부분이 2^2가 되야합니다. 그러나 표현 방식은 e - 127로 표현하기에 원래 숫자의 127을 더하는 겁니다. 그러므로 e - 127 = 2. 즉, e가 129가 되야하므로 10000001(2)가 저장이 되는 겁니다.
부동소수점.... 본능적으로 소숫점 계산을 싫어하게 만드는 녀석이죠. 소수 계산이 있는 업무 환경에서는 보통 기존에 사용하는 숫자 계산 체계가 있을 테니 그걸 따라가시면 되고 그런게 없는데 소수 계산을 해야한다..그러면 각 언어에서 지원하는 math 관련 라이브러리를 찾아서 사용하시면 한결 안전합니다. 그냥 float 계산은 안쓴다고 생각하세요...
저거 피하는 방법으로 훨씬 쉽고 더 많이 쓰는걸 언급 안하셨는데 == 대신에 >= 요런식으로 풀어서 비교를 하게 합니다 그리고 제일 중요한게 대부분 조건문에서 저런 비교문을 만이 쓸텐데 왠만하면 실수로 비교문을 짜지 않아야 합니다 정수비교랑 속도차이가 어마어마하게 납니다 그게 아니어도 애초에 ==비교는 float자료형에서 쓰면 절대 안됩니다
쓰앵님들 궁금한 거 있습니다 부동소수점 지수부 저장할 때 127을 더하는 이유가 뭔가요? 8칸을 할당하는데 지수부가 0일 때만 01111111로 앞자리가 0이고 나머지는 1로 시작하기 때문에 이 케이스를 빠르게 구분하기 위해서인가요? 그리고 생각하다보니 컴퓨터는 각기 자료형에 따라 할당하는 비트가 달라서 애초 물리적으로 32비트 혹은 64비트마다 표지하는 건 불가능하고, 매번 가변적으로 한 데이터의 끝과 시적점을 구분해야 할 텐데 이런 과정은 어떻게 이뤄지나요? 구체적으론, 생물에서의 개시 코돈이나 종결 코돈처럼 '여기서부터 한 문단 끝났고 다음부터 새로운 맥락이다' 라는 구분이 명확히 없어보임에도 특정 주소에 저장된 1은 '아 이전 변수값은 끝났고 이건 다음 변수인 float 5.7의 부호부군' 라는 걸 어떻게 구분하나요?
포인터와 메모리 구조를 공부하시면 궁금한걸 해결하실 수 있을거에요. 메모리 0번 주소가 첫 8비트를 가르키고, 1번 주소가 두번째 8비트, 이런식으로 가르킵니다. 포인터는 시작 주소를 저장하며, 포인터의 자료형이 시작 주소로 부터 몇 바이트를 읽을지를 결정합니다. 그리고 배열 및 malloc, new 등으로 할당한 매모리 영역은 시작 주소 바로 앞 주소에 이 자료형에 메모리가 몇바이트 할당되었는지 정보를 담아둡니다. int a = 1 이렇게 써도 컴파일러가 엄격한 규칙을 바탕으로 스택 영역에 할당할 뿐이지 접근법은 포인터와 같습니다.(사용자가 선언한 포인터는 힙에 저장됨) 다만 그냥 변수로 선언하면 값복사가 일어나지만, 포인터는 복사 없이 바로 참조하여 속도가 빠르다는 차이가 있습니다.
예전에 프로젝트로 여러 방법으로 원주율을 계산하는 프로그램을 만든 적이 있는데, 이것 때문에 미칠뻔 했죠. 덕분에 vc++ 프로젝트 지우고 g++로 다시 작성했습니다. double로는 부족한데 vc++이 boost float128을 못 쓰더라고요. 많이 힘든 프로젝트 였지만 덕분에 boost 사용법도 배우고 부동소수 연산할때 Epsilon도 배웠네요. 그리고 한번 c#으로도 작성해 보았는데 매우 쉽게 되더군요. "이러면 내가 c++로 1주일 동안 노력한게 뭐가 되지?"라는 생각이 들며 그 뒤로 주로 c#을 쓰고 있습니다.
초짜일때 어떤 검사기의 측정값을 상하한 스펙에 따라 합부판정 한 뒤 db에 저장하는 프로그램을 짰었는데,,,, 그 때 상하한 스펙과 검사기 측정값이 모두 소수점 4자리의 소수 값이었어요. 딱 저 영상과 같은 케이스로 판정이 이상하게 나오는 경우가 있어 당황스러웠던 적이 있네요. 그땐 이유도 잘 모른채 더블형으로 바꾸어 볼까 하는 식으로 해결을 했었는데,, ㅋㅋㅋ
이 문제 때문이었나? 30년 전에 베이직으로 숫자를 2진법으로 소숫점 10자리인가 20자리까지인가로 바꾸는 프로그램(요즘은 코딩이라 하나?)을 짰는데 정수는 진짜 잘 되는데 소수점은 자꾸 틀리더라구 당시 다니던 학원강사한테도 보여줬는데 잘 짰다면서도 원인은 못찾더라구....
램 메모리 이진법 소수 이진법 0.125에 2를 곱합니다. 그러면 0.125 * 2 = 0.25가 됩니다. 0.25에 2를 곱합니다. 그러면 0.25 * 2 = 0.5가 됩니다. 0.5에 2를 곱합니다. 그러면 0.5 * 2 = 1.0이 됩니다. 이 과정에서 얻은 나머지를 순서대로 읽으면 0.001이 됩니다. 따라서, 0.125의 이진법 표현에서 소수 부분은 0.001이 됩니다. 저장되는목록 1번째칸:부호 2번째~9번째칸: 지수에 127을 더해서 정수 이후 23개칸 : mantissa 순환소수 최대32칸 넘김 계산은 정수,반올림,double 자료형 (64칸)
개발자가 명심해야하는 것도 있지만 엔드유저 역시 기기를 장시간 사용했을 경우 에러가 누적되기 때문에 주기적으로 재부팅해줘야 하는것도 있어요. 당장 스마트폰 사용시간 보시면 일주일 이주 삼주 넘어가는 분들 많을 겁니다. 스마트폰 정도야 큰 불편함은 없겠지만 센서류 간혹 먹통될 경우에는 재부팅은 필수!
컴퓨터로 계산하는한 무한소수 부분에서 오차가 발생할수 밖에 없죠 목표 오차 이내로 계산 되면 문제가 없습니다. 100시간이나 오차를 누적하는 방식이 잘못 된거지 그부분이 실무를 잘 모르는 분이 설명하는 느낌이 드내요. 마찬가지로 4.1달러를 센트로 보관하나 4.1달러로 보관하나 마찬가지고요.
컴퓨터에서 소수점은 공학적 표기 관점에서 고정 소수점 방식과 부동 소수점 방식이있습니다. 그리고 우리의 컴퓨터는 IEEE754 규격의 부동소수점 표기법을 쓰는데 가수부와 지수부로 나눠지며 이때 가수부가 표현하는 2진법의 데이터의 저장 방식으로 표현할 수 없는 데이터가 있으므로 실제 값과 오차가 발생 할 수 있습니다. 그렇기에 근사치를 저장하게됩니다. 그렇다면 실제로 오차로 인하여 값이 커지거나 작아질 수 있음을 의미합니다. 라고 말한다면 합격인가요?
와 너무 쉽게 설명하신다! 질문있습니다. 소수를 문자열 포맷으로 통신하는 경우도 있더라구요. 몇몇 API를 사용하다 그런 케이스를 보았습니다. 문자열로 저장했을 때 정확도가 보장되는 것 때문으로 추측했습니다. 그런데 문자열은 용량을 많이 차지 할 것인데 문자열로 보내는 이유가 있을까요? 제가 생각하기에 영상에서 말씀하신 double 형태로 보내더라도 결국 시스템 상황에 따라서 해당 자료형의 사이즈가 환경에 따라서 다르고 처리 방식 또한 다르기 때문에 값의 무결성을 지키기 위해서 용량을 차지하더라도 문자열로 보내는 걸까요?
애초에 통신 자체는 문자열로 하고, 부동소수점에 해당하는 문자열은 해석하는 과정을 거쳐 메모리에 저장을 하므로, '전송 전 문자열 변환 -> 통신 -> 수신 후 소수점 해석'의 과정을 거치는 것 보다 통으로 문자열로 다루고 '문자열 전송 -> 통신 -> 수신 후 소수점 해석'의 과정을 거치는 게 더 간결한 것도 있겠습니다.
개발자의 성향에 따라 다른걸로 이해하시면 될것같습니다. 문자열로 보낼지, ASCII로 보낼지, 4/8바이트 표현 그대로 보낼지는 자유입니다. 문자열로 보내면 수신한 데이터를 float, double 형태로 변환하는 추가적인 과정(비효율)이 생기겠지만, 수신측에서 데이터를 받고 아무 처리 없이 바로 로그를 출력했을 때 사람이 이해할 수 있는 형태로 표현되어 편의상 선호하는 개발자도 있는 것 같습니다.
영상 정말 잘봤습니다. 영상을 보고 궁금증이 생겨 실례를 무릅쓰고 질문 드리고 싶습니다. Q1. 0.125 같이 깔끔하게 2진법으로 변환되는 수들을 사용하면 오차가 발생하지 않게되나요? Q2. 이런 오차가 더 큰 값으로만 일어나는 이유가 있을까요? 예) 1.1 + 0.1 > 1.2
A1. 2진법과 10진법의 변환시에 2의 제곱을 통해서 변환을 하는데 0.125는 1/8이라서 딱 2의 -3승입니다. A2. 10진법 순환소수를 통해서 이해하면 됩니다. 순환소수는 n/9, n/99등으로 무조건 n/10^m보다 큽니다. 1/9=1.1111...을 생각해봅시다. 소수를 절삭한다면 소수점 아래 n째 단위로 끊습니다. 소수점 아래 첫째짜리에서 끊는다면 1.1이 되고 1.1(10진수의 1.1)은 1.111...(2진수의 1.1 비유)보다 작죠? 두번째 자리에서 끊어도 1.11이 되고 이는 1.1111...(2진수의 1.1 비유) 보다 작죠?
1.1은 실제 저장된 값을 보면 1.100000000X로 표현됩니다, 실제 값과 저정된 값의 차이는 머신입실론이라고 하는데 1.1의 머신입실론과 0.1의 머신입실론의 합이 1.2의 머신입실론보다 크기 때문에 그렇게 표현됩니다. 하지만 1.1 + 0.1 > 0.8 + 0.4 의 결과는 false입니다. 0.8 + 0.4의 머신입실론 값이 더 크기 때문입니다. 따라서 더 큰값으로만 일어난다고 할 수 없습니다,
1. 이러한 오차가 일어나는 이유는 '정밀도 손실' 때문입니다. 1번에서 질문하신 2진법으로 변환되는 수들을 사용하여 계산을 한다고 해도, 1.2222222 와 같은 무한소수의 값을 얻게 됩니다. 한마디로 10진법이든 2진법이든 1.2를 정확하게 계산하는 방법은 없습니다. 이유는 c, java, javascript, ruby 등이 IEEE-754로 표현되기 때문입니다. Q. 그럼 해결 못하는 건가요? 어림수를 구하면 됩니다. let sum = 1.1 + 0.1 console.log( +sum.toFixed(2) ); 무한소수를 완벽하게 잘라내는 방법은 없습니다. 단순 꼬리 잘라 어림수를 만든 편법입니다. 2. 윗분들이 자세히 설명해주셨네요. 보잘것 없지만 설명을 좀 해드리자면, 1.1 + 0.1 > 1.2 와 같은 대소비교가 되는 이유는 간단하게 1번의 내용과 같습니다 1.2222222 > 1.2 이렇게 보시면 편합니다.
귀찮아서라기보다, IEEE 표준 계산 방식이라 보면됩니다. 정규화(소수점 이동) 후에, 단일정밀도의 경우 8비트로 만들기 위해 bias 값인 127을 더해줍니다. 정밀도에 따라 할당되는 각 영역에 바이트도 다르고 지수부에 더해지는 bias 값도 달라진다고 생각하시면 됩니다.
아, 실습 시간에 전부 정수로 바꿔서 하니까, 조교가 "참 좋은 습관이다."라고 했는데...
이해가 되네요.
조교 : 교토 출신
신입때 이거 당했는데 실제로 보면 어이없어서 웃음나옴 ㅋㅋㅋㅋㅋ 수업 때 들은 것들 무슨 고대 기계 문명에서 사용했던 지식 같았는데, 실제로 내 앞에 나타나니까 원시인이 지하철 타고있는거 보는 기분이었음
4:43 교훈 = 소수쓰지말고 무조건 100 10000 곱해서 쓰다가 출력은 나누면됨.
즉 기본베이스 계산은 무조건 정수로 처리되게끔해야함
참고로 이거 프로그래밍의 기본임.
개발 초기에 통신값이 계속 미세하게 튀어서 그 당시에 엄청 머리 싸매고 있었는데 float를 사용한 것이 문제였어요.
진짜 중요한 문제입니다.
double써서 해결하셨나요?
MISRA-C: 2004 Rule 13.3 : Floating-point expressions shall not be tested for equality or inequality.
MISRA-C: 2004 코딩규칙 13.3 : 부동소수 표현은 같음/다름을 테스트해서는 안된다. (비교연산자 == 와 != 를 사용해서는 안된다.)
그렇기에 부동소수 표현 값을 Assert할 때에는 반드시 '허용 오차'를 주어야 한다.
이미 60년대에도 fortran에서 반드시 기억해야하는 규칙이었다고 합니다. 70년대에 포트란 배우며 들었던 얘기...
@@boglaejo 선생님 혹시 포트란 77과 포트란 99를, 유튜브 강좌를 올려주시면 어떨까요?
많은 사람들이 보거나 남기지 않겠지만 그래도 배우고 싶은 젊은 사람들을 위해 포트란 강좌와 컴퓨팅 역사에 관한 기록물을 남겨주시면 감사하겠습니다.
@@HJ-ri9fj60년대머에 펀치카드로배웠고제일 많이 쓴것은 vax/vms fortran 이어서 경험이부족하지요 당시에는cobol이흐이던시절이라 두개를 한프로그램에서 불러흐기도 햏는데 이런 편의점들이 이식성을 많이낮추어습니다. 표준도읽은적이있지만 그 태에는posix 작업했었고 fortran 과는작별했습니다. 요약하면 평생강좌를 열 실력에 다다른적이 없어 난처한브탁입니다.
@@HJ-ri9fj싸가지보소
A. 부동소수점 연산 과정에서 오차가 있으므로 abs(1.1 + 0.1 - 1.2) < EPSILON 등으로 처리해야 한다.
c#으로 테스트 해봤는데...
double.epsilon 이 더 작습니다. 진짜 epsilon 넣으면 안되고, 적당히 가감해야 할듯.
var b = Math.Abs((1.1 + 0.1) - 1.2) < double.Epsilon;
@@prussicblack 보통의 경우 epsilon을 말할 때 충분히 작은 수라는 의미에서 epsilon을 사용합니다. 말씀처럼 실제 코드에선 적절히 설정해야죠 :>
그냥 숫자를 2진수의 합과 차로 기억해서 하면 되지 않을까요?
가령 54는 64-8-2로 쓰는 거죠.
최대한 부동소수점으로는 연산하지 않는 습관을 들이세요
별생각없이 짠 decimal 1이 되어야 할 코드가 integer 0이 되어있을겁니다
(부동소수점으로 바꿔보면 0.99999...)
반도체장비였다면 그 장비안에 검사도구가 없을경우 웨이퍼 몇백장을 날려먹을수도 있습니다
내 잘못이 아니라 콤푸타 이놈 잘못이군요!
가끔 문제되는 경우에 피해서 쓰면 되지 최대한 그럴거 까지야 ㅋㅋㅋ
@@niceyoungmo그 가끔이 ㅈㄴ많이 일어남
@@알쓸컴잡 경솔하게 짤 경우 인티저도 백분율 계산같은거 잘못하면 "factor(100보다 작은 값) / 100 * percentage (= 항상0)" 같은 오류 공식을 쓸 확률이 높은건 마찬가지입니다. 이런경우 곱하기를 먼저 하기만 해도 해결되긴 하지만 가독성을 우선시한다면 그냥 부동소수점 쓰는게 낫겠죠. 때에 따라 합리적으로 쓰는게 맞는거지 가급적 인티저를 쓰라는 말은 좀 애매한 표현 같아요.
"부동소수점 연산이 필요없을때는 가급적(혹은 무조건) 인티저를 써라"가 맞는 말이지 "가급적 부동소수점 연산을 피해라"라는 말은 틀린 말인것 같습니다. 부동소수점 연산을 피할 수 없는 게임, 물리 시뮬레이션, 트랜지션 이런거 만들때도 일부러 변태처럼 인티저로 에뮬레이션 코드 짜야될까요? 왜죠? ㅋㅋㅋ
그냥 요즘 흔한, CS 지식없이 코딩'만' 배운 사람들은 잘 빠질만한 문제네요.
4:29 그런데 수치해석 해야하는 경우에는 여기서 말하는 회피수단은 사용 못 하므로 절대값 뺀 후 오차범위 이내인가를 판단 ( |a-b| < eps ) 하는 방법에 대해도 언급했으면 더 좋았을듯 합니다.
마지막 해법인 double 로 올려본들, 소수점 이하 어딘가에서 저런 문제 생기는 건 똑같거든요.
24자리로 100시간에 0.34초 오차면,
62자리(?)로 10000000000000000000000000000000 시간에 0.34초 오차인것 아닌가요?
100시간으로 따져보면 0.00000000000000000000000000034초 오차인데 이정도는.. 미미한것아닐까 싶기도한데 몇십년동안 계속 구동된다고 해도 유의미한 오차를 관측하기 힘들지 않을까 싶기도 합니다!
똥몽청이라 계산을 잣같이 했을건데, 지적 후 계산 제대로 해주시면 감사!
@@gandaahtesla5843 수치해석 하는경우에는 연산시간과 메모리 사용량이 동시에 고려되어야 합니다.
게다가 시뮬레이션의 스케일이 매우 거대한 천문학(에서도 수치해석을 하려나?) 라던지 MEMS NEMS쪽 시뮬레이션을 할 때는
기본적인 단위가 10^nn이거나 10^-6 에서 10^-9정도로 이미 자리수를 많이 까먹고 시작하게 되죠.
그래서 오차 epsilon(eps)를 이용해서 시뮬레이션 스텝을 진행하거나 종료 조건으로 잡게됩니다.
다만 이 방법은 효율적으로 계산하기 위한 방법이지 "정확"한 해답을 내놓기 위한 방법은 아니긴 하니까 다루는 내용이 조금 다를지도 모르겠네요.
물론 영상에 나온것과 같이 미사일 궤적 계산 같은 경우는 RTOS라 해서 적절한 정확도로 정시성을 보장하는 계산도 중요한 내용이라 이런 방법을 사용해
궤적을 분석하고 미사일을 조종할 수 도 있겠습니다.
시뮬레이션 개발의뢰를 햇던적이 있었는데 개발자분이 소수를 무지하게 싫어하시더라구요. 그때는 그냥 계산식중 하나인데 뭐가 문제인거지? 하고 넘어갔었는데 이런 오차가 발생할 수 있었군요. 무릎을 탁 치고 갑니다.!!
그 개발자가 맡을 깜냥이 아니었던거네요
무릎을 탁 치시면 무릎이 아야합니다. 사람은 살면서 많은것을 깨닫고 살죠, 그럴때 마다 무릎을 탁 치시면 무릎의 수명도 탁 하고 나갑니다! 조심하세요~
@@훵훠이 ㅇㅈ
@@훵훠이 ㅋㅋㅋ 그러겠네요
그래서 전 계란을 탁 쳐서 후라이 해먹습니다 😊
와 알수없는 유튜브의 알고리즘에 이끌려 왔는데, 딕션 쩌네요. 현직 강사신가? 동영상을 아주 꽉채워서 설명 진짜 잘하셨다.
요즘 같이 가정용 패트리어트 미사일 하나씩 필수인 세상에 이거 몰랐으면 비명횡사할 뻔 했네요 감사합니다 !
ㅇㅈ
ㅇㅈ
ㅇㅈ
ㅇㅈ
아ㅋㅋㅌㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
좋은 내용 감사합니다.
실제 개발 할때 정수로 바꿔서 (1.1*10) + (0.1*10) == (1.2*10) 이런 식으로 사용합니다.
와…. 컴알못인 저를 이렇게 이해하기쉽게 설명해주시다니 감사합니다 ㅠㅠ 엄청나요ㅠ정말 최고입니다
실수오차는 표현 자릿수를 쭉 늘려서 눈으로 확인하시면 좋습니다~
감사합니다
정말 쉽게 설명해주시네요! 0.1이 이진수로 저장되면 순환소수이고, 32칸에서 컷되는 부분으로인해 오차가 발생한다는 작동원리와 이로인한 문제사례와 해결방법(정수로 변환)까지 완전 이해하기 쉬웠네요. 좋은 영상 감사합니다^^
이게 쉬워요?
@@gun_hyeok 문제 자체는 어려운데 설명을 쉽게 해주셨다는거 같아요
@@gun_hyeok 정확히 뭔소린지는 모르겠는데 아 이래서 그렇구나~ 이정도는 알거같애요
영상안봤는데 확 이해되네
아 정수리로 변환했는데 머리가 없어졋어요
4:40 작은 오차를 보정한다는 핑계로 510센트를 5100센트로 얼렁뚱땅 부풀려 드시는 신종 횡령법!! ㅋㅋ
이 영상 안보고 개발했다가 무고한 희생자가 생길뻔 했네….. 감사합니다.
근데 궁금한게있습니다. 특정지점에서 끊어버린다면 0.1은 실제로 0.9999..어딘가쯤으로 저장이되는건데, 왜 1.1+0.1 의 결과는 1.2 보다 큰가요? 더 작아야하는거 아닌가요? 0:08 이거 이유를 여전히 모르겠습니다
더 크게 저장될 수도 있습니다.
@@오치치577 그러니까 다들 그렇게만 말을하고 구체적으로 왜 를 알려주는 사람이없어요 ㅠㅠㅠ
@@오치치577 Mantise 가 23비트니까 실제로 저장한값은 2^-24 + 2^-25 ...만큼의
차이가 “적게” 나야하는데, 이게 대체 무슨원리로 크게 저장이 될수있는겁니까....
이진 기준으로 소숫점 아래 23번째 자리까지만 나타내는데 이때 소숫점 아래 24번째 자리에서 오사오입(짝수-반올림)해서 나타냅니다. 예를 들어, 십진수 0.6은 이진법 수로 0. 1001 1001 1001 1001 1001 1001 ...인데 24번째 자리에서 오사오입 해서 0. 1001 1001 1001 1001 1001 101 로 저장이 됩니다.
@@totoistk 다른 예시로, 0.1+0.2=0.30000000000000004가 나옵니다.
유리수는 비교할 때 ==이 아니라 두 수를 빼서 오차범위와 비교하는 식으로 이용하라고 들었습니다. 1.2 - 1.1 < 0.11 이런식으로요.
1:52 여기서 소숫점 앞의 1을 왜 저장 안하는지 궁금하실지 모르실텐데, 0을 제외한 거의 모든 수는 이진법으로 치환하면 저렇게 1이 꼭 하나 나옵니다. 그래서 저거를 비트도 아끼고 한자리라도 더 나타내야하니 생략하자! 가 되어버려서 그런겁니다. 이 때문에 IEEE 754 프로토콜을 가진 컴퓨터는 궁극적으로 0을 나타낼 수 없게 됩니다. 생략되는 1 하나 때문에 그냥 0에 무한히 가까운 수만 나타낼 수 있습니다.
거의 모든 수인 이유가 있을까요? 0을 제외하면 모든 수여야 할거 같은데 거의라고 표현하셔서 써봅니다. 0으로 시작하면 소수점 자리를 1이 나올때까지 뒤로 옮길 수 있으니 말씀하신대로 맨 앞은 1로 시작하게 되겠죠. 예외상황이 있는지 궁금합니다.
@@tubeyou1490 0이 아닌 모든 이진수 k는 1.nnnn × 2^m 의 형태를 갖게 됩니다. 뒤에 2의 몇승을 곱하는 이유가 그렇게 나타내기 위해서에요. 경우의 수를 나눠볼까요.
i) | k | >= 1:
절대값이 1보다 크거나 같은 실수라면 소수점 위는 무조건 정수 형태를 띄죠. 근데 이진수 정수의 가장 높은 자리 숫자는 항상 1입니다. 4 = 101(2) 를 4 = 0101(2) 라고 적지 않죠. 맨 앞에 값이 없는 0은 몇 개를 적던 똑같기 때문에 생략하게 되고, 따라서 k = 1.??? × 2^m 의 형태가 됩니다. 참고로 4 = 101(2) 에서 중간의 0은 자릿수를 나타내기 위해 꼭 필요한 숫자입니다.
ii) 0 < | k | < 1
절대값이 1보다 작은 실수여도 마찬가지입니다. 2의 몇승만 해주면 i)과 같아집니다. 따라서 k = 1.??? × 2^m 형태가 됩니다.
@@tubeyou1490 한마디로 0 이외의 모든 수는 2의 "몇제곱" 값을 조절하면 1.xxx 형태로 나타낼수 있습니다. 예외가 없도록 표현을 그렇게 하게 돼있어요.
@@yacht-responce 제 표현을 잘 읽어주세요. 원 댓글님이 거의라고 해서 왜 모든이 아닌 거의라고 표현한건지를 물어본겁니다. 님께서는 그냥 모든이라고 해서 제 생각과 같으신건 이해했습니다.
0의 표현을 위해 지수부의 특정 값을 예약값으로 사용합니다. 예를 들어 지수부가 모두 0인 경우 0으로, 모두 1인 경우 무한대로 간주합니다.
0을 제외한 모든 수는 위의 다른 분들이 설명하신 대로 정규화하여 1.xxxx x 2^n 꼴로 나타낼 수 있으므로, xxxx와 n만을 저장하는 것입니다.
첨언하자면
1/3은 0.3333333... 3으로 무한으로 이어진다고 알지만 컴퓨터는 어느 순간 마지막 3을 끊고 특정값으로 설정해야 할 필요가 있습니다,
(위의 0.1011로 반복되는 예시)
그렇지 않으면 1/3를 표현하기 위해 모든 메모리 공간을 쓰고도 표현을 할 수가 없기 때문입니다,. (영상에서도 이 얘기가 나왔었죠? )
따라서 특정 시점으로 끊기는 그 수와 수 사이의 간격을 Machine Epsilon(머신 입실론)이라고 합니다.
그리고 크롬의 자바스크립트 기준으로 머신 입신론 값은 2.220446049250313e-16 가 나옵니다.
크롬 콘솔창을 열고 Number.EPSILON를 입력해보세요.
추가 설명 감사드립니다. 근데 제가 잘 이해한 것이라면 머신 입실론 값은 "컴퓨터 메모리 한계로 인해 끊긴 수의 값"과 "원래 저장하려 의도한 수의 값"의 차이잖아요?
그럼 원래 의도한 수가 어떤 수인지에 따라 모신 입실론 값이 달라지는 것 아닌가요?
크롬 js엔진 기준으로 머신 입실론 값이 특정되어 있다는 뉘앙스로 말씀하셔서 궁금해져 여쭙습니다.
@@parkypark-m7f 머신 입실론 값은 "특정 시점으로 끊겨서 나오는 수들의 차이"값이라 보면 되며, "원래 의도한 수"와 "끊겨서 나온 수"의 차이는 적어도 머신 입실론 값보단 작다고 할 수 있습니다.
지수부 제외하고 가수부만 계산하는 거라 동일해요. 0000....0001
@@parkypark-m7f 제가 설명이 정확하지 않았네요. 의도한 수에 따라 머신입실론값이 달라지는 것이 맞습니다.
어떤수는 3이 반복되고 어떤 수는 다른 수가 반복되기 때문입니다.
그래서 친구배님 말씀대로 "원래 의도한 수"와 "끊겨서 나온 수"의 차이는 적어도 머신 입실론 값보단 작다고 할 수 있습니다.
그리고 이 차이를 통해서 소수점의 크기 비교에 필요한 유틸함수를 만들수 있는데요.
바로 두 수의 차이가 머신입실론보다 작으면 같은 수라고 판단하는 로직입니다.
function equal(n1, n2) {
return Math.abs(n1 - n2) < Number.EPSILON;
}
equal(0.1 + 0.2, 0.3); // true
하지만 이런식으로 소수를 판단하는건 매우 귀찮으니 일반적으로 수와 관련된 라이브러리를 사용하기를 권고하고 있습니다.
또는 소수가 만들어지지 않는 방식으로 값을 관리합니다. (영상 속 예시처럼 달러-> 센트) 표시처럼이요/
머신 입실론이란 용어는 처음 알게 되었네요.. 입실론은 그냥 작은 수를 나타내는줄 알았는데
2:43 뒷부분을 컷(버림)하면 작아져야하는거 아닌가요??
float a = 0.1, b = 1.1;
a+b < 1.2
이렇게 되어야할거같은데
실제론 a+b > 1.2 가 되는데
단순히 컷(버림)이 아니라 반올림?올림?으로 처리가 되나요?
이런 오분 내외의 컴싸지식 영상 너무 좋습니다 감사합니다
아직 영상 다 안 봤지만..
컴퓨터에서 특정 소수는 정확히 표현할 수 없음. 근사값을 찾아갈 수는 있을 뿐.
그래서 == 라는 수식을 사용하는 해야 한다면 값을 직접 봐야 할 필요가 있고, 아니라면 범위 안에만 들어오면 맞도록 조건식을 작성해야 함.
정확한 숫자연산을 위해 다들 Decimal을 사용합시다~
덕분에 죽을목숨 살렸습니다
1.1 + 0.1 == 1.2
> false
왜냐면 10진법=>2진법 변환시 0.1은 순환소수. 메모리때문에 32칸에서 잘리므로 오차 발생.
1. 정확히 계산하려면 정수로 (예: 5.1달러 -> 5100센트)
2. Float 써야하는 상황이 생기면 반올림 문법 적절히 활용
precision = Math.pow(10,precision)
Math.ceil(num*precision)/precision
3. double 자료형 : 숫자 1개당 64칸 사용 - 단점: 메모리 용량 2배
정리 ㄱㅅ
ㄱㅅㄱㅅ
굿
근데 5.1달로는 5100센트가 아니긴 함
대충 저런게 있다는것만 알고있었는데 개발자 15년만에 제대로 이해하게 되었습니다.
ㅅㅂ 이거 보면서 어차피 내가 하는 코딩에서 이거 겪을일 없음 하고 지나갓는데
마이프리코딩캠프에서 자바스크립트로 잔돈거스름 뱉는 프로젝트할때 실제로 겪음.
계속 실패하길래 왜이러지 하면서 콘솔에 로그했더니 마지막 페니가 자꾸 빔.. 개똥이가 훔쳐갓나 하면서 거스름돈 총값 출력해보니 4페니 ($0.004) 가 아닌 $0.0039999999997) 이런식으로 나와서 마지막 페니가 안튀어나온거였음..
사실 프로그램에서 소수는 뒤에 찌꺼기가 남는다 정도만 알고 있었지 정확히 이유는 몰랐는데
이진법의 순환 소수 문제 때문이란건 처음 알았네요
혹시 @1:55에서 지수 부분에 127을 더해서 2진법으로 변환한다고 하시는데, 왜 127을 더하는 게 2진법으로 변환하는 건지 아시는 분 계신가요..?
저도 궁금한데 혹시 알아내셨나요?
저도 이 부분이 궁금한데
실수의 기본 표현 방식이 +- (1.m) × 2^(e-127)이라 그렇습니다. 여기서 e는 부호 비트 뒤의 8칸, m은 맨 뒤 23칸에 저장하게 됩니다.
여기서 101.001은 1.01001 × 2^2이므로, e에 저장해야 할 부분이 2^2가 되야합니다. 그러나 표현 방식은 e - 127로 표현하기에 원래 숫자의 127을 더하는 겁니다. 그러므로 e - 127 = 2. 즉, e가 129가 되야하므로 10000001(2)가 저장이 되는 겁니다.
요약: 10->2진법 변환 한계로 0.1표현이 제대로 안됨 따라서 연산 후 결과를 비트연산하게되면 다른값이 나올 수 있다
중요한건 왜 다른값이 나오는가이다
부동소수점.... 본능적으로 소숫점 계산을 싫어하게 만드는 녀석이죠.
소수 계산이 있는 업무 환경에서는 보통 기존에 사용하는 숫자 계산 체계가 있을 테니 그걸 따라가시면 되고
그런게 없는데 소수 계산을 해야한다..그러면 각 언어에서 지원하는 math 관련 라이브러리를 찾아서 사용하시면 한결 안전합니다.
그냥 float 계산은 안쓴다고 생각하세요...
수치해석 4시간동안 배우는걸 5분만에 설명해주시네요 ㄷㄷ
저래서 수치해석 할 땐 어떤 값이 반복 계산 끝에 수렴했는지를 입실론이라는 지정한 작은 숫자보다 작은지로 판단합니다,,
느낌표가 달려 있는 느낌의 억양이네요. 신기.
개발 17년하는사이에 이걸 알고하는사람 솔직히 잘 못봄.. 알아야 하는건 맞지만 너무 하나에 매몰되지말고 넓고 얕은지식을 알고난 뒤에 서서히 하나씩 쌓으면서 경력을 쌓는게 더 좋음.
영상보면 너무 답답한 부사수 빨리 이해시키려고 설명해주시는거같아서 너무 머리귀에 박히네요 너무 잘 보고 배우고있습니다 선생님 감사합니다
저거 피하는 방법으로 훨씬 쉽고 더 많이 쓰는걸 언급 안하셨는데 == 대신에 >= 요런식으로 풀어서 비교를 하게 합니다
그리고 제일 중요한게 대부분 조건문에서 저런 비교문을 만이 쓸텐데 왠만하면 실수로 비교문을 짜지 않아야 합니다 정수비교랑 속도차이가 어마어마하게 납니다
그게 아니어도 애초에 ==비교는 float자료형에서 쓰면 절대 안됩니다
왠만->웬만
쓰앵님들 궁금한 거 있습니다 부동소수점 지수부 저장할 때 127을 더하는 이유가 뭔가요? 8칸을 할당하는데 지수부가 0일 때만 01111111로 앞자리가 0이고 나머지는 1로 시작하기 때문에 이 케이스를 빠르게 구분하기 위해서인가요?
그리고 생각하다보니 컴퓨터는 각기 자료형에 따라 할당하는 비트가 달라서 애초 물리적으로 32비트 혹은 64비트마다 표지하는 건 불가능하고, 매번 가변적으로 한 데이터의 끝과 시적점을 구분해야 할 텐데 이런 과정은 어떻게 이뤄지나요? 구체적으론, 생물에서의 개시 코돈이나 종결 코돈처럼 '여기서부터 한 문단 끝났고 다음부터 새로운 맥락이다' 라는 구분이 명확히 없어보임에도 특정 주소에 저장된 1은 '아 이전 변수값은 끝났고 이건 다음 변수인 float 5.7의 부호부군' 라는 걸 어떻게 구분하나요?
지수부가 음수인 경우를 따지려고 512의 절반만큼 밀어두는거로 알고있습니다
포인터와 메모리 구조를 공부하시면 궁금한걸 해결하실 수 있을거에요.
메모리 0번 주소가 첫 8비트를 가르키고, 1번 주소가 두번째 8비트, 이런식으로 가르킵니다. 포인터는 시작 주소를 저장하며, 포인터의 자료형이 시작 주소로 부터 몇 바이트를 읽을지를 결정합니다. 그리고 배열 및 malloc, new 등으로 할당한 매모리 영역은 시작 주소 바로 앞 주소에 이 자료형에 메모리가 몇바이트 할당되었는지 정보를 담아둡니다.
int a = 1 이렇게 써도 컴파일러가 엄격한 규칙을 바탕으로 스택 영역에 할당할 뿐이지 접근법은 포인터와 같습니다.(사용자가 선언한 포인터는 힙에 저장됨) 다만 그냥 변수로 선언하면 값복사가 일어나지만, 포인터는 복사 없이 바로 참조하여 속도가 빠르다는 차이가 있습니다.
스마트팩토리 플젝할때 같은 로그 학습시켜도 언어별로 소수점 3자리를 다르게 뽑아내서 이거 뭐임 했었다가 해결을 하긴 했는데
이렇게 깊은 뜻이... 이해해 버렸다...
패트리어트는 정말 첨 들어보는 이야기네요 썰풀기 좋네요
수업료 좋댓구알 입력합니다
맨날 헷갈리던 개념이었는데 정리 깔끔하게 해주셔서 이해했습니다.
나도 조승희인데
그 외에도 뭐 라운딩을 습관화한다던가 꼭 필요할 때는 인터넷에서 좀 더 나은 comparer를 찾아본다던가 하는 방법이 있겠네요
...솔직히 평상시에는 이렇게까지 하나 싶지만 생각해보니 저도 신경쓸 필요가 있는 경우가 종종 있었네요
예전에 프로젝트로 여러 방법으로 원주율을 계산하는 프로그램을 만든 적이 있는데, 이것 때문에 미칠뻔 했죠.
덕분에 vc++ 프로젝트 지우고 g++로 다시 작성했습니다. double로는 부족한데 vc++이 boost float128을 못 쓰더라고요.
많이 힘든 프로젝트 였지만 덕분에 boost 사용법도 배우고 부동소수 연산할때 Epsilon도 배웠네요.
그리고 한번 c#으로도 작성해 보았는데 매우 쉽게 되더군요. "이러면 내가 c++로 1주일 동안 노력한게 뭐가 되지?"라는 생각이 들며 그 뒤로 주로 c#을 쓰고 있습니다.
C#이 숙달만 하면 기능도 많고 편리하긴 하죠..많이 무겁지만..
@@King_God 확실히 c++이 테스트 했을 때 몇배는 더 빠르고 cpu 자원도 덜 쓰더라고요
c++++ > c++
기승전결 c#
@@manai2683 ㅋㅋㅋㅋ 초창기때 c# 하고 자바만 했는데 추억..
3:19 사람 죽는다는게 코딩애플한테 맞아죽는다는 드립인 줄 알았는데 진짜 죽어뿌렀노.... 패트리어트 요격 실패 사건은 알았는데 그게 저런 이유 때문이었다니....
뭔가 국어 비문학 기술지문에 나올법한 신기한 이야기군요
좋은 지식 감사합니다
좋은 내용 감사합니다. 사소하게 틀린부분이 하나 있는데, 4:41에 5.1달러는 5100센트가 아니라 510센트로 고쳐야 하겠네요.
와 사이드플젝할때 왜 자꾸 가격계산할때 특정하게 무한소수값이 나오나했더니 이런원리가 있었네요;; 코드만하다보니 CS지식이 다날아가버렸군여ㅜㅜ 감사합니다..
초짜일때 어떤 검사기의 측정값을 상하한 스펙에 따라 합부판정 한 뒤 db에 저장하는 프로그램을 짰었는데,,,, 그 때 상하한 스펙과 검사기 측정값이 모두 소수점 4자리의 소수 값이었어요.
딱 저 영상과 같은 케이스로 판정이 이상하게 나오는 경우가 있어 당황스러웠던 적이 있네요.
그땐 이유도 잘 모른채 더블형으로 바꾸어 볼까 하는 식으로 해결을 했었는데,, ㅋㅋㅋ
그 때->그때
ㄷㄷ 패트리어트 100시간 넘게 켜두면 안되는군요... 좋은정보 얻고 갑니다
이 문제 때문이었나?
30년 전에 베이직으로 숫자를 2진법으로 소숫점 10자리인가 20자리까지인가로 바꾸는 프로그램(요즘은 코딩이라 하나?)을 짰는데
정수는 진짜 잘 되는데 소수점은 자꾸 틀리더라구
당시 다니던 학원강사한테도 보여줬는데
잘 짰다면서도 원인은 못찾더라구....
꿀팁 : 소수 곱셈 할 때 오차가 많이 발생하는데 이런 연산들은 log 연산으로 치환하면 오차를 많이 줄일 수 있다
이거지 ㅋㅋ
팁 : 소->팁: 소
@@d2341a 이것도 규칙이 있었어?
램
메모리
이진법
소수 이진법
0.125에 2를 곱합니다. 그러면 0.125 * 2 = 0.25가 됩니다.
0.25에 2를 곱합니다. 그러면 0.25 * 2 = 0.5가 됩니다.
0.5에 2를 곱합니다. 그러면 0.5 * 2 = 1.0이 됩니다.
이 과정에서 얻은 나머지를 순서대로 읽으면 0.001이 됩니다. 따라서, 0.125의 이진법 표현에서 소수 부분은 0.001이 됩니다.
저장되는목록
1번째칸:부호
2번째~9번째칸: 지수에 127을 더해서 정수
이후 23개칸 : mantissa
순환소수 최대32칸 넘김
계산은 정수,반올림,double 자료형 (64칸)
개발자도 아닌데 개발이라는 개념을 배우는 게 너무 재밌는듯
나중에 학생들 개발공부할 때 표본으로 써도 될거같아요
부동소수점을 표현할때 정수를 표현할때보다 부하가 많이 걸리기때문에 정확성보다는 속도를 우선시해서 표현함. 그로 인해 아주 작은 오차가 발생. 그래서 보통은 부동소수점의 같음은 라이브러리를 이용하는 경우가 많음.
개발자가 명심해야하는 것도 있지만 엔드유저 역시 기기를 장시간 사용했을 경우 에러가 누적되기 때문에 주기적으로 재부팅해줘야 하는것도 있어요. 당장 스마트폰 사용시간 보시면 일주일 이주 삼주 넘어가는 분들 많을 겁니다. 스마트폰 정도야 큰 불편함은 없겠지만 센서류 간혹 먹통될 경우에는 재부팅은 필수!
컴퓨터공학 다니는 재학생입니다. 2학년인데 IEEE는 배웠지만 저런 개념은 처음 들었습니다. 진짜 많은 도움되었습니다 감사합니다
IEEE 754 에 다 나오지만 2학년 시점에서 설명들어도 솔직히 실감은 안 갈거고, 수치해석 이런 과목 하면서 저런 문제 실제 맞딱드려야 와닿긴 하죠
컴구조하면 배워요
컴퓨터로 계산하는한 무한소수 부분에서 오차가 발생할수 밖에 없죠 목표 오차 이내로 계산 되면 문제가 없습니다. 100시간이나 오차를 누적하는 방식이 잘못 된거지
그부분이 실무를 잘 모르는 분이 설명하는 느낌이 드내요.
마찬가지로 4.1달러를 센트로 보관하나 4.1달러로 보관하나 마찬가지고요.
C++ 이나 C# , 자바, PHP 등에서는 아예, MATH 라이브러리가 있습니다.
거기에서 무한수 함수가 포함되어 있으니 그거 쓰면 진짜로 오차가 많이 줄어듭니다.
근데 메모리를 더블 형보다 더 많이 잡아먹습니다.
그래도 치명적인 연산 실수를 줄일 수 있으니 상당히 유용하네요.
컴퓨터에서 소수점은 공학적 표기 관점에서 고정 소수점 방식과 부동 소수점 방식이있습니다.
그리고 우리의 컴퓨터는 IEEE754 규격의 부동소수점 표기법을 쓰는데 가수부와 지수부로 나눠지며
이때 가수부가 표현하는 2진법의 데이터의 저장 방식으로 표현할 수 없는 데이터가 있으므로
실제 값과 오차가 발생 할 수 있습니다. 그렇기에 근사치를 저장하게됩니다.
그렇다면 실제로 오차로 인하여 값이 커지거나 작아질 수 있음을 의미합니다.
라고 말한다면 합격인가요?
Java에서는 double도 오차가 있습니다. 그래서 financial organization 현업에서는 precision을 절대 상수로 정의하고 지키시던가, 처리 속도가 엄청나게 중요한게 아니면 BigDecimal을 쓰면 편합니다. 좋은 영상 감사합니다.
모든 언어에는 double오차 있어요
영상에서도 오차의 범위가 줄어든다고 말해요
없다가 아님
@@IllIIllIlIIIlI 강의하신 분이 아니라 많은 개발자들이 잘못 코드하시는걸 두고 말씀 드린것이예요.
@@daredevone 아.. 넵 ^^
@@IllIIllIlIIIlI ㅋㅋ논리적인 대화가 불가능하다는것을 인지하고 눈웃음으로 마무리하시는 센스
@@moonan2ㅋㅋㅋ ㄹㅇ 말귀를 못알아먹어서 딴소리하네
사람 쥬거,, ㄷㄷㄷㄷ
이런 사례 들려주시니까 머리속에 꽉 박히네여 ㄷㄷㄷ
항상 감사합니다 코애님 ㅠㅠㅠ
저도 이거 좀 헷갈리던 개념이었는데 쉬운 설명 감사합니다.
부동소수점은 표현가능 범위내의 모든 수를 표현하지 못합니다.
또한 표현 가능한 수가 모두 동일한 좌표축 내의 거리만큼 떨어져 있지도 않습니다.
꼼수충입니다. 예전에 어떤문제인지는 정확히 기억나진않지만 롱인티져를 비교할때 문제가생긴적이있습니다. 그땐 단순히 actionscript3에서 버그가있다고 생각했는데 시간은없고 빠르게해결해야했기에 스트링변환후 반으로자르고 각각을 비교해처리한적이있는데 소수점기준 스플릿나눠서 정수로 비교해도되긴합니다. 이상 꼼수충이었읍니다
와 그냥 썸네일만 보고 뭐가 문제인지 생각하고 안볼라 했었는데 보길 잘했네요 대머리를 두둥탁 치고 갑니다!!
이런 영상의 강의 좋은거 같아요 많이 만들었으면 좋겠네요
이거 땜에 도형 좌표계산하는거에서 계속 오류가 나가지고, 결국 소숫점 4번째 자리부터 전부 버림처리해서 해결했습니다. 만약에 굳이 긴 소수점이 필요하다면 Big Int 계산하는 것처럼 string으로 변환하는 것도 방법일듯하네여.
10진수가 2진수로 변환될때 소수일때만 무한소수로 나타는 경우의 예시까지 깔끔한 설명 좋네요..
조만간 나올 C23에서 decimal floating point (2진수 대신 10진수를 사용)가 추가된다고는 합니다만 이게 현업에서 사용될 때까진 시간이 걸리겠지요.. 다른 언에에도 추가될지 미지수고요
난 코딩에 관심도 없는 사람인데 왜 이곳에... 여긴 어디지... 하지만 진짜 신기한거 배워갑니다
내가 인터넷에서 본 부동소수점 설명중 가장 명쾌함. 모두의 코드랑 투탑 ㅋㅋ
1줄요약 : "부동소수점 방식 자료형에서 흔히 일어나는 오차입니다."
약 : "->약: "
와 요즘같이 험난한 사회에서 이거 안봤으면 외마디 비명만 남긴 채 잿가루 될 뻔 ㄷㄷ
와 너무 쉽게 설명하신다! 질문있습니다. 소수를 문자열 포맷으로 통신하는 경우도 있더라구요. 몇몇 API를 사용하다 그런 케이스를 보았습니다. 문자열로 저장했을 때 정확도가 보장되는 것 때문으로 추측했습니다. 그런데 문자열은 용량을 많이 차지 할 것인데 문자열로 보내는 이유가 있을까요? 제가 생각하기에 영상에서 말씀하신 double 형태로 보내더라도 결국 시스템 상황에 따라서 해당 자료형의 사이즈가 환경에 따라서 다르고 처리 방식 또한 다르기 때문에 값의 무결성을 지키기 위해서 용량을 차지하더라도 문자열로 보내는 걸까요?
애초에 통신 자체는 문자열로 하고, 부동소수점에 해당하는 문자열은 해석하는 과정을 거쳐 메모리에 저장을 하므로, '전송 전 문자열 변환 -> 통신 -> 수신 후 소수점 해석'의 과정을 거치는 것 보다 통으로 문자열로 다루고 '문자열 전송 -> 통신 -> 수신 후 소수점 해석'의 과정을 거치는 게 더 간결한 것도 있겠습니다.
개발자의 성향에 따라 다른걸로 이해하시면 될것같습니다. 문자열로 보낼지, ASCII로 보낼지, 4/8바이트 표현 그대로 보낼지는 자유입니다. 문자열로 보내면 수신한 데이터를 float, double 형태로 변환하는 추가적인 과정(비효율)이 생기겠지만, 수신측에서 데이터를 받고 아무 처리 없이 바로 로그를 출력했을 때 사람이 이해할 수 있는 형태로 표현되어 편의상 선호하는 개발자도 있는 것 같습니다.
JSON 포맷말인가요? JSON 은 그냥 단순하고 특정 기술에 비의존적이고 개발자가 읽기 쉬운 포맷이라 많이 이용될 뿐이고 정확도가 중요하면 다른 방식으로 통신할겁니다.
애초에 JSON 이 아니라도 문자열로 소수를 보내는건 다 비슷한 이유일거에요
보통 API는 텍스트기반 전송이기 때문에 문자열로 전송하는 것 뿐이지 다른 이유는 없습니다. 게다가 요즘엔 압축이 보편되어있어 효율도 나쁘지 않구요.
통신시 양방 시스템간의 메모리 저장 방식(빅/리틀엔디언)에 따른 차이가 발생하더라도 그 값이 보장되어야하므로 문자열 전송을 원칙으로 합니다.
어떻게 영상 하나 하나가 주옥같습니다 형님..
4:44 잠깐 이제 알았는데 5.1달러면 510센트 아님????
그렇네 ㅋㅋ
Db에서 누적평균 누적표준편차 구할때도
합, 제곱합을 정수로 누적하고
마지막에 결과 보여줄때만
연산해서 평균, 표준편차 보여줘야
최대한 근사한 평균, 표준편차 구할수있음
영상 정말 잘봤습니다. 영상을 보고 궁금증이 생겨 실례를 무릅쓰고 질문 드리고 싶습니다.
Q1. 0.125 같이 깔끔하게 2진법으로 변환되는 수들을 사용하면 오차가 발생하지 않게되나요?
Q2. 이런 오차가 더 큰 값으로만 일어나는 이유가 있을까요?
예) 1.1 + 0.1 > 1.2
Q2 는 저도 궁금합니다!!
1. 순환소수 문제가 안 일어나는 수는 오차가 없습니다.
2. 오차가 큰 쪽으로 일어나기보단 저장공간 내에서 허락하는 가장 비슷한 수로 저장이 됩니다.
A1. 2진법과 10진법의 변환시에 2의 제곱을 통해서 변환을 하는데 0.125는 1/8이라서 딱 2의 -3승입니다.
A2. 10진법 순환소수를 통해서 이해하면 됩니다. 순환소수는 n/9, n/99등으로 무조건 n/10^m보다 큽니다. 1/9=1.1111...을 생각해봅시다. 소수를 절삭한다면 소수점 아래 n째 단위로 끊습니다. 소수점 아래 첫째짜리에서 끊는다면 1.1이 되고 1.1(10진수의 1.1)은 1.111...(2진수의 1.1 비유)보다 작죠? 두번째 자리에서 끊어도 1.11이 되고 이는 1.1111...(2진수의 1.1 비유) 보다 작죠?
1.1은 실제 저장된 값을 보면 1.100000000X로 표현됩니다,
실제 값과 저정된 값의 차이는 머신입실론이라고 하는데 1.1의 머신입실론과 0.1의 머신입실론의 합이 1.2의 머신입실론보다 크기 때문에 그렇게 표현됩니다.
하지만 1.1 + 0.1 > 0.8 + 0.4 의 결과는 false입니다. 0.8 + 0.4의 머신입실론 값이 더 크기 때문입니다.
따라서 더 큰값으로만 일어난다고 할 수 없습니다,
1. 이러한 오차가 일어나는 이유는 '정밀도 손실' 때문입니다.
1번에서 질문하신 2진법으로 변환되는 수들을 사용하여 계산을 한다고 해도, 1.2222222 와 같은 무한소수의 값을 얻게 됩니다.
한마디로 10진법이든 2진법이든 1.2를 정확하게 계산하는 방법은 없습니다.
이유는 c, java, javascript, ruby 등이 IEEE-754로 표현되기 때문입니다.
Q. 그럼 해결 못하는 건가요?
어림수를 구하면 됩니다.
let sum = 1.1 + 0.1
console.log( +sum.toFixed(2) );
무한소수를 완벽하게 잘라내는 방법은 없습니다. 단순 꼬리 잘라 어림수를 만든 편법입니다.
2. 윗분들이 자세히 설명해주셨네요.
보잘것 없지만 설명을 좀 해드리자면,
1.1 + 0.1 > 1.2 와 같은 대소비교가 되는 이유는
간단하게 1번의 내용과 같습니다
1.2222222 > 1.2 이렇게 보시면 편합니다.
아주 좋은 토픽 잘 듣고 갑니다. 저도 MCU 펌웨어를 C로 주로 짜는데 소수점을 사용할 일이 있으면 offset 적용합니다
코딩애플 사이트에 cs 강의도 추가됐음 좋겟네요 센세
썸네일 보자마자 영상 더 볼것도 없이 부동 소수점이 생각나네요. 안나면 프로그래머 아닙니다! 저 파이썬 대화형 뭐시기 하는건 부동소수점(float) 연산을 사용하기때문에 저런 문제가 발생하죠.
이 영상 안봣으면 죽을뻔했네;;
ㄹㅇ.. .
ㄹㅇㅋㅋ
ㄹㅇㄷㄷ
나 살아버렸어..
앞으로 매일 아침마다 코딩애플 형 있는곳 방향으로 절 세번해야겠다
고정소수점이 있는 언어들도 꽤 있는데 조심할 껀 소수점 자릿수에 대한 이해가 없으면 똑같은 결과를 초래합니다.
좋은 정보 감사합니다
전공하면서 학교에서 배우는 거 드럽게 없고 다 개인 공부로 했네;; 하면서 복학 준비 중인데 시나브로 흡수되는 게 있구나.. 부동 소수점 추억이다
잘 배우고 갑니다.
한편 5.1달러는 5,100센트보단 510센트에 가까울 것 같네요.
0:08 뒤에가 잘려서 더했는데 왜 1.1 + 0.1 이 1.2 보다 크게 나온건가요.? 1.2 에 잘린수가 더 커서 그런가요??
0.1을 이진수로 나타내면 0.0 0011 0011 0011 0011.... 이라는 사실상 0.1보다 커지는 순환소수로 나타나서 더하면 1.2보다 값이 더 커져요
그래서 환율까지 들어가서 소수점이 중요한 핀테크 업계에서는 1.1+0.1==1.2로 쓰면 안 되고 1.1+0.1-1.2==0으로 써야함
수치해석 수업에서는 이런저런 경우에서 오차가 얼마만큼 날 것인지에 대해 배울 수 있습니다.
오차 구하는거 진짜 싫어..
4:37 5.1 달러 = 5100 센트가 아니라 510 센트
와 오늘 수업 내용 공부하다가
유튜브 켰는데 알고리즘으로 이 영상이 떠버리네
이해가 안갔는데 정말 감사합니다
Java 에서 Long -> BigDecimal 로 자릿수를 늘려서(형 변환 시) 저장을 할때 65.9 -> 65.90000000001 이런식으로 변환이 될 떄가 있던데 영상과 같은 이유일까요?
어떻게 하셨는진 모르겠지만 BigDecimal.valueOf 로 한게 아니라면 해보시길 바래요
이 영상을 처음 봤을 때는 그냥 그런갑다 하고 갔는데 얼마 전에 코딩하다가 소수를 썼는데 오차가 나는걸 보고 바로 돌아왔습니다..
코더가 컴퓨터의 비위를 맞춰줘야 하는 시대가 빨리 지나가버렸으면 좋겠네요.
그순간 일자리를 잃을듯
'역사 속의 소프트웨어 오류' 라는 책을 보시면 더 많은 사례들이 있더군요
1장이 0.000000095의 오차가 앗아간 28명의 생명이구요
매우 중요한 내용을 알려주셔서 감사합니다
저거 맞춰서 1.1 + 0.1 == 1.2 가 true 나오는 함수 있었던 거 같은데
함수가 아니라 그 근처면 true 해주는 거였던거 같은데
하지만 그래도 오차가 발생한단 사실 자체는 변하질 않으니까 잘 알아둡시다
파이썬에서 1인 줄 알았는데 1.000000002 이래 돼 있어서 1이랑 다르던거 기억나네
간단히 어떤 숫자가 들어있는지 보고싶으면 엑셀 수식으로 한 후에 표기방식을 소수점 최대로 해놓으면 됩니다.
엑셀은 VBA
비전공자입니다
2:00 에서 왜 2+127을 하나요?
영상 감사합니다
그러게요
와드
지수가 -127까지 나올 수 있는데
음수까지 표현해서 저장하기 귀찮아서요
@@codingapple 아하 생각해보니 그렇네요
귀찮아서라기보다, IEEE 표준 계산 방식이라 보면됩니다. 정규화(소수점 이동) 후에, 단일정밀도의 경우 8비트로 만들기 위해 bias 값인 127을 더해줍니다. 정밀도에 따라 할당되는 각 영역에 바이트도 다르고 지수부에 더해지는 bias 값도 달라진다고 생각하시면 됩니다.