hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
오픈 소스 인공지능 이점
오픈 소스 AI는 최첨단 도구에 대한 접근을 민주화하여 자원이 부족할 수 있는 개인 및 소규모 조직의 진입 장벽을 낮춘다. 이러한 기술을 자유롭게 사용할 수 있도록 함으로써 오픈 소스 AI는 개발자들이 재정적 제약으로 인해 접근하기 어려웠던 AI 솔루션을 혁신하고 만들 수 있도록 하여 독립 개발자, 연구원, 소규모 조직 및 스타트업이 독점 소프트웨어 라이선스의 재정적 부담 없이 고급 AI 모델을 활용할 수 있도록 한다. 이러한 경제성은 개발자들이 기존 모델을 수정하여 고유한 요구 사항을 충족할 수 있으므로 틈새 또는 전문화된 응용 분야에서 혁신을 장려한다.
코드, 데이터 및 연구 결과를 공유함으로써 오픈 소스 AI는 집단적 문제 해결 및 혁신을 가능하게 한다. 텐서플로 및 PyTorch와 같은 프레임워크 개발에서 볼 수 있는 대규모 협업은 기계 학습 (ML) 및 딥 러닝 분야의 발전을 가속화했다.
오픈 소스 인공지능 이점
이러한 플랫폼의 오픈 소스 특성은 또한 전 세계의 기여자(contributor)들이 기존 도구에 대한 수정 및 개선 사항을 제안할 수 있으므로 빠른 반복 및 개선을 용이하게 한다. ML 및 딥 러닝 내의 직접적인 개선을 넘어 이러한 협업은 공유된 지식과 전문 지식이 결합됨에 따라 AI 제품의 더 빠른 발전으로 이어질 수 있다.
개발 프로세스의 개방성은 다양한 기여를 장려하여 소외된 그룹도 AI의 미래를 형성할 수 있도록 한다. 이러한 포용성은 더욱 공평한 개발 환경을 조성할 뿐만 아니라 더 큰 이윤 중심의 기업들이 간과할 수 있는 편향을 해결하는 데 도움이 된다. 다양한 관점의 기여를 통해 오픈 소스 AI는 전 세계 커뮤니티에 더 공정하고 책임감 있으며 영향력 있는 기술을 만들 잠재력을 가지고 있다.
오픈 소스 인공지능 이점
오픈 소스 AI의 한 가지 주요 이점은 폐쇄형 대안과 비교하여 제공하는 향상된 투명성이다. 오픈 소스 모델을 통해 기본 알고리즘과 코드를 검사할 수 있으므로 책임감을 높이고 개발자가 모델이 결론에 도달하는 방식을 이해하는 데 도움이 된다. 또한 Llama 및 스테이블 디퓨전과 같은 오픈 웨이트 모델을 통해 개발자는 모델 매개변수에 직접 접근할 수 있어 응용 분야에서 편향을 줄이고 공정성을 높이는 데 도움이 될 수 있다. 이러한 투명성은 특히 의료, 형사 사법 및 금융과 같은 중요한 응용 분야에서 AI 시스템이 내린 결정의 결과가 상당할 수 있는 경우 (그러나 우려 사항 섹션에서 언급된 특정 위험을 초래할 수도 있음) 인간이 읽을 수 있는 출력을 가진 시스템, 즉 "설명 가능한 AI"를 생성하는 데 도움이 될 수 있다.
Nature 사설은 의료 서비스가 언제든지 중단될 수 있고 평가하기 어렵고 환자 프라이버시를 위협할 수 있는 AI 모델에 의존하게 될 수 있다고 제안한다. 저자들은 전 세계의 의료 기관, 학술 연구원, 임상의, 환자 및 기술 기업이 협력하여 기본 코드와 기본 모델에 쉽게 접근할 수 있고 자체 데이터 세트로 자유롭게 미세 조정할 수 있는 의료용 오픈 소스 모델을 구축해야 한다고 제안한다.
오픈 소스 인공지능 우려 사항
현재 오픈 소스 모델은 대부분의 작업에서 폐쇄형 모델보다 성능이 떨어지지만, 오픈 소스 모델은 격차를 좁히기 위해 더 빠르게 개선되고 있다.
모델의 오픈 소스 개발은 이론적인 위험을 가질 수 있다고 여겨져 왔다. 일단 모델이 공개되면 심각한 보안 문제가 감지되더라도 롤백하거나 업데이트할 수 없다. 예를 들어, 오픈 소스 AI는 옴진리교와 같은 바이오테러리즘 그룹이 AI 모델의 파인 튜닝 및 기타 안전 장치를 제거하여 AI가 더 파괴적인 테러 계획을 개발하는 데 도움을 줄 수 있도록 허용할 수 있다. 실제 테러 계획을 개발하는 데 주요 장애물은 필요한 재료와 장비에 대한 엄격한 제한에 있다. 또한, AI 발전의 빠른 속도는 오래된 모델을 사용하는 것을 덜 매력적으로 만들며, 이는 공격에 더 취약하지만 능력도 떨어진다.
2024년 7월, 미국은 모델 가중치 공개를 제한할 충분한 증거를 찾지 못했다고 명시한 대통령 보고서를 발표했다.
오픈 소스 인공지능 우려 사항
인공지능이 의도치 않게 편향된 제품을 만들어낸 수많은 사례가 있었다. 주목할 만한 예로는 아프리카계 미국인의 미래 범죄 및 재범 위험을 백인보다 높게 예측하는 AI 소프트웨어, 비원어민 화자에게 성능이 떨어지는 음성 인식 모델, 여성과 피부색이 어두운 사람에게 성능이 떨어지는 안면 인식 모델 등이 있다.
연구원들은 또한 오픈 소스 인공지능이 기존의 보안 및 윤리적 문제로 인해 비판을 받아왔다. Bandit, FlawFinder 및 Semgrep과 같은 취약점 스캐너를 사용하여 허깅 페이스와 깃허브에 있는 100,000개 이상의 오픈 소스 모델을 분석한 결과 30% 이상의 모델이 심각한 취약점을 가지고 있는 것으로 나타났다. 또한, 폐쇄형 모델은 일반적으로 오픈 소스 모델보다 안전 위험이 적다. 오픈 소스 모델을 증강할 수 있는 자유는 개발자들이 GPT4-Chan과 같이 윤리적 지침 없이 모델을 출시하게 만들었다.
오픈 소스 인공지능 우려 사항
편향된 데이터, 모델 생성의 결함, 이러한 결과의 가능성을 인식하거나 계획하지 못하는 등의 원인으로 인해 불공평하고 편향된 AI 결과로 이어질 수 있는 수많은 시스템적 문제가 존재한다. 연구에서 강조되었듯이, 데이터 세트에서 특정 인구 통계 그룹의 과소 대표와 같은 낮은 데이터 품질과 데이터 큐레이션 과정에서 발생하는 편향은 왜곡된 모델 출력으로 이어진다.
오픈 소스 AI 프로젝트에 대한 연구에 따르면 데이터 품질 검증에 실패했으며, 프로젝트의 28% 미만이 문서에 데이터 품질 문제를 포함했다. 이 연구는 또한 개발자들이 모델의 윤리적 함의에 충분한 강조를 두지 않으며, 개발자들이 윤리적 함의를 고려할 때에도 특정 지표 (모델의 동작)에 과도하게 초점을 맞추고 다른 지표 (데이터 품질 및 위험 완화 단계)를 간과하는 더 광범위한 우려를 보여주었다.
오픈 소스 인공지능 우려 사항
안전 및 편향과 같은 문제와 관련하여 많은 AI 시스템의 또 다른 주요 우려 사항은 투명성 부족이다. 많은 오픈 소스 AI 모델은 "블랙박스"로 작동하며, 의사 결정 과정을 생성자조차 쉽게 이해할 수 없다. 이러한 해석 가능성 부족은 책임감을 방해하여 모델이 특정 결정을 내린 이유를 식별하거나 다양한 그룹에 걸쳐 공정하게 작동하는지 확인하기 어렵게 만들 수 있다.
또한, AI 모델이 폐쇄형(독점형)일 경우, 널리 채택된 수많은 안면 인식 시스템의 경우와 같이 편향된 시스템이 간과될 수 있다. 이러한 숨겨진 편향은 독점 시스템이 AI가 내린 결정에 대한 신뢰 구간과 같이 이러한 편향을 드러내는 데 도움이 될 수 있는 결정 과정에 대해 아무것도 공개하지 않을 때 지속될 수 있다. 특히 의료 분야에서 사용되는 시스템의 경우, 시스템의 추론을 보고 이해하거나 답변이 어떻게 얻어졌는지에 대한 "[정확한] 설명"을 얻는 것은 "신뢰와 투명성을 보장하는 데 중요하다".
오픈 소스 인공지능 개선을 위한 프레임워크
이러한 문제에 대응하기 위한 노력은 AI의 윤리적 개발 및 배포를 안내하는 구조화된 문서화 프레임워크의 개발로 이어졌다.
모델 카드: Google 연구 논문에서 소개된 이 문서는 AI 모델의 의도된 용도, 제한 사항 및 다양한 인구 통계에 걸친 성능 지표에 대한 투명성을 제공한다. 이들은 윤리적 고려 사항을 강조하고 정보에 입각한 사용을 용이하게 하는 표준화된 도구 역할을 한다. 아직 비교적 새로운 개념이지만, Google은 이 프레임워크가 AI 투명성을 높이는 데 중요한 역할을 할 것이라고 믿는다.
오픈 소스 인공지능 개선을 위한 프레임워크
측정 모델링: 이 방법은 사회 과학적 관점을 통해 질적 및 양적 방법을 결합하여 개발자가 AI 시스템이 주장하는 것을 정확하게 측정하는지 확인하는 데 도움이 되는 프레임워크를 제공한다. 이 프레임워크는 재검사 신뢰도 ("구조 신뢰도") 및 모델이 모델링하려는 것을 측정하는지 여부 ("구조 타당성")라는 두 가지 핵심 개념에 중점을 둔다. 이러한 개념을 통해 이 모델은 개발자가 직접 측정할 수 없는 추상적인 아이디어 (예: 사회경제적 지위)를 구체적이고 측정 가능한 구성 요소로 분해하는 데 도움을 주며, 편향으로 이어질 수 있는 오류 또는 불일치를 확인한다. 이러한 가정을 명확히 함으로써 이 프레임워크는 더 공정하고 신뢰할 수 있는 AI 시스템을 만드는 데 도움이 된다.
AI 사용이 증가함에 따라 AI 투명성을 높이고 모델 편향을 줄이는 것이 점점 더 강조되는 우려 사항이 되었다. 이러한 프레임워크는 개발자와 이해 관계자가 편향을 식별하고 완화하여 AI 시스템의 공정성과 포용성을 증진하는 데 도움이 될 수 있다.
C++26
C++26은 C++23에 이어 C++ 프로그래밍 언어를 위한 국제 표준화 기구(ISO) 및 국제전기기술위원회(IEC) 14882 표준 버전의 비공식 이름이다. 이 버전의 현재 작업 초안은 N5014이다. C++ 표준 위원회에서 표준에 제안되고 채택된 문서와 2025년 6월 불가리아 소피아 및 온라인에서 개최된 표준화 회의록이 공개되어 있다. 초안의 문구는 기능적으로 완성되었으며, 국제 의견 투표를 위해 발송되고 있다. 2025년 11월 하와이 코나에서 열린 표준화 회의에서 일부 투표 의견을 해결한 후, C++ 표준 위원회는 투표 의견 해결을 완료하고 초안을 기술적으로 확정하며, 2026년 3월 런던에서 열리는 다음 표준화 회의에서 최종 승인 투표를 위해 초안을 발송할 것으로 예상된다. 일부 곧 출시될 기능을 구현한 실험적이고 표준 컴파일러는 Compiler Explorer를 통해 짧은 코드 스니펫에서 시도할 수 있다. 일부 컴파일러 변형은 "constexpr containers and adaptors"를 위한 "P3372"와 같이 구현하는 새로운 기능을 제안하는 문서의 짧은 식별자로만 구별된다.
C++26 기능
C++26에 채택된 변경 사항은 다음과 같다.
C++26 반응
초안이 기능적으로 완성된 소피아 C++ 표준 위원회 회의와 그 직후 열린 국제 C++ 컨퍼런스인 C++ On Sea에서 여러 사람들이 여행 보고서를 발표했다. 모두 특히 컴파일 시점 반영의 도입을 주요 변경 사항으로 강조했다. 허브 서터는 C++ 표준 위원회의 "언어 진화" 실무 그룹의 부의장인 하나 두시코바의 말을 인용하며, 이 변경 사항의 잠재적 영향을 "완전히 새로운 언어"라고 요약했다.
C++26의 계약 기능은 다양한 이유로 C++ 위원회 내 일부 사람들에 의해 비판을 받아왔다.
C++23
C++23, 공식적으로 ISO/IEC 14882:2024,는 C++20에 이어지는 C++ 프로그래밍 언어의 현재 개방형 표준이다. 이 버전의 최종 초안은 N4950이다.
2020년 2월, 프라하에서 열린 C++20 최종 회의에서 C++23에 대한 전체 계획이 채택되었다. C++23의 계획된 기능은 코루틴을 위한 라이브러리 지원, 모듈화된 표준 라이브러리, 실행자(executor), 네트워킹이었다.
C++23에 초점을 맞춘 첫 WG21 회의는 2020년 6월 초 바르나에서 열릴 예정이었으나, 코로나19 범유행으로 인해 취소되었다. 2020년 11월 뉴욕 회의와 2021년 2월 코나(Kona) 회의도 마찬가지였다. 2022년 11월까지 모든 회의는 가상으로 진행되었고, 2022년 11월 회의부터 2023년 2월 최종 회의까지는 하이브리드 형식으로 진행되었다. 이 표준은 2023년 2월 이서콰에서 열린 하이브리드 회의에서 WG21에 의해 기술적으로 최종 확정되었다.
C++23 현대적인 "Hello, world" 예제
작업 초안에 많은 라이브러리 변경 사항이 적용된 후, 새로운 "Hello, world" 프로그램은 다음과 같다.
C++23 기능
C++23에 승인된 변경 사항은 다음과 같다.
constexpr 변경 사항:
constexpr 함수 내의 비리터럴 변수, 레이블 및 goto
constexpr 함수 내에서 상수 표현식으로 사용 가능한 static 및 thread_local 변수 허용
constexpr 함수는 반환 타입과 매개변수 타입이 리터럴 타입일 필요가 없다.
핵심 상수 표현식의 요구 사항을 만족하는 호출이 없는 constexpr 함수를 작성하는 것이 이제 가능하다.
새로운 제약이 있는 범위 알고리즘:
std::ranges::starts_with
std::ranges::ends_with
std::ranges::contains
std::ranges::contains_subrange
std::ranges::find_last 및 기타 변형
iota, shift_left 및 shift_right의 범위화된 버전
범위 폴드 알고리즘
C++23 기능
새로운 범위 어댑터:
std::views::zip 및 기타 변형
std::views::adjacent 및 기타 변형
std::views::join_with
std::views::slide
std::views::chunk
std::views::chunk_by
std::views::as_rvalue
std::views::as_const
std::views::repeat
std::views::stride
std::views::cartesian_product
std::views::enumerate
새로운 멤버 함수 및 문자열 타입의 변경 사항:
std::basic_string_view::contains 및 std::basic_string::contains
std::basic_string 및 std::basic_string_view에 대한 nullptr로부터의 생성 비활성화
std::basic_string_view에 대한 명시적 범위 생성자
std::basic_string::resize_and_overwrite
효율적인 슬라이싱을 위한 std::basic_string::substr의 rvalue 참조 오버로드
C++23 기능
범위 라이브러리의 변경 사항:
조건부로 빌려온 범위
입력 범위 어댑터 및 std::counted_iterator 수정
std::ranges::join_view에 대한 제약 완화
std::ranges::split_view를 std::ranges::lazy_split_view로 이름 변경 및 새로운 split_view
개념 std::ranges::view에서 std::default_initializable 제약 조건 제거
소유권을 가진 뷰와 새로운 std::ranges::owning_view
std::ranges::istream_view 수정
텍스트 포매팅 라이브러리 변경 사항:
std::basic_format_string
컴파일 시간 형식 문자열 검사
std::format_to의 이진 코드 크기 감소
chrono 포매터에서 로케일 처리 문제 해결
너비 추정 개선 및 std::format의 채움 문자 허용
비상수 포맷 가능 타입 허용을 위한 형식 인자에서 전달 참조 사용
C++23 기능
제거된 기능:
가비지 컬렉션 지원 및 (엄격한) 포인터 안전성 (즉, 완화된 포인터 안전성만 의존 가능). 이 최소한의 가비지 컬렉션 지원(및 이를 위해 필요한 포인터 안전성)은 C++11에 추가되었지만, 어떤 컴파일러도 이를 지원한 적이 없으므로 C++23에서 제거되었다. 그러나 이것이 Boehm GC와 같이 C++와 함께 많은 GC 구현이 사용되지 않았다는 것을 의미하지는 않으며, 디버그 모드에서 누수 감지를 위해 (또한 누수 감지에도) 사용될 수 있으며, 이러한 GC는 다른 언어에서 사용하기 위해 종종 C++로 구현된다.
폐기된 기능:
복원된 폐기된 기능:
C++23 역사
대면 WG21 회의가 없는 상황에서, 다음 변경 사항들은 여러 가상 WG21 회의 후 적용되었으며, 여기서 여론조사(straw poll)를 통해 승인되었다.
2020년 11월 9일 가상 WG21 회의 후 다음 사항들이 추가되었으며, 여론조사를 통해 승인되었다.
2021년 2월 22일 가상 WG21 회의 후, 다음 기능들이 추가되었으며 여론조사를 통해 승인되었다.
2021년 6월에 열린 여름 ISO C++ 표준 본회의 가상 회의 후, 새로운 기능과 결함 보고서가 여론조사를 통해 승인되었다.
범위 라이브러리의 몇 가지 변경 사항:
임의 범위에 대한 일반화된 starts_with 및 ends_with.
split_view를 lazy_split_view로 이름 변경 및 새로운 split_view.
join_view에 대한 제약 완화.
개념 view에서 default_initializable 제약 조건 제거.
std::basic_string_view에 대한 범위 생성자.
2021년 10월에 열린 2021년 가을 ISO C++ 표준 본회의 가상 회의 후, 새로운 기능과 결함 보고서가 여론조사를 통해 승인되었다.
C++23 역사
범위 라이브러리 변경 사항:
뷰의 정제된 정의.
함수 템플릿 std::ranges::istream_view를 별칭 템플릿 std::ranges::istream_view, std::ranges::wistream_view 및 사용자 정의 지점 객체 std::views::istream으로 대체.
zip 범위 어댑터 패밀리:
zip_view
zip_transform_view
adjacent_view (및 std::views::pairwise는 std::views::adjacent<2>와 동등)
adjacent_transform_view (및 std::views::pairwise_transform는 std::views::adjacent_transform<2>와 동등)
C++23 역사
C 헤더 명확화. "헤더는 C++로만 유효해야 하는 코드에서는 유용하지 않다. 따라서 C 헤더는 C++ 표준 라이브러리에서 완전히 지원되고 폐기되지 않은 부분으로 제공되어야 하지만, 다국어 상호 운용 코드(polyglot interoperability code)가 아닌 코드에서는 사용이 권장되지 않는다. [..] 이 제안은 C 헤더를 더 이상 폐기되지 않도록 하여 향후 제거될 formal threat를 없앤다. 순수 C++ 코드에서 C 헤더 사용을 자제하도록 하는 실질적인 권장 사항은 이제 규범적 권장 사항으로 명시적으로 명시된다."
2022년 2월 7일 가상 WG21 회의 후, 다음 기능들이 추가되었으며 여론조사를 통해 승인되었다.
2022년 7월 25일 가상 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
세 가지 표준 부동 소수점 타입 외에 확장 부동 소수점 타입을 정의할 수 있도록 구현을 허용했다. 헤더 <stdfloat>를 통해 접근 가능한 이러한 확장 타입에 대한 타입 별칭 std::float16_t, std::float32_t, std::float64_t, std::float128_t, std::bfloat16_t와 해당 리터럴 접미사 f16 f32 f64 f128 bf16 또는 F16 F32 F64 F128 BF16을 추가하고, float를 인수로 받는 다양한 표준 라이브러리 함수에 오버로드를 추가했다.
2022년 11월 7일 하이브리드 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
2023년 2월 6일부터 11일까지 열린 최종 하이브리드 WG21 회의 후, 다음 기능 및 결함 보고서가 추가되었으며 여론조사를 통해 승인되었다.
C++03
C++03은 C++ 프로그래밍 언어에 대한 ISO/IEC 14882 표준의 한 버전이다. 이는 국제 표준화 기구 (ISO)와 국제전기기술위원회 (IEC)의 두 표준화 기구에 의해 ISO/IEC 14882:2003 표준으로 정의된다.
C++03은 이전 C++98 표준을 대체했다. C++03은 나중에 C++11로 대체되었다. C++03은 주로 구현자들이 더 큰 일관성과 이식성을 보장하기 위한 버그 수정 릴리스였다. 이 개정판은 92개의 핵심 언어 결함 보고서를 다루었으며, 125개의 라이브러리 결함 보고서를 다루었고, 단 하나의 새로운 언어 기능인 값 초기화만 포함했다.
C++03에서 다루어진 가장 주목할 만한 결함 보고서 중 하나는 라이브러리 결함 보고서 69였으며, 이 보고서의 해결은 벡터의 요소가 연속적으로 저장되어야 한다는 요구 사항을 추가했다. 이는 C++ std::vector 객체가 배열과 유사한 메모리 레이아웃을 사용한다는 일반적인 기대를 코드로 명시한 것이다. 대부분의 구현이 이러한 기대를 충족했지만, C++98에서는 필수가 아니었다.
C17 (C 표준 개정판)
C17은 공식적으로 ISO/IEC 9899:2018이며, C 프로그래밍 언어의 개방형 표준이다. 2017년에 준비되어 2018년 7월 5일에 출판되었다. 이 표준은 C11 (ISO/IEC 9899:2011 표준)을 대체했으며, 2024년 10월부터는 C23 (ISO/IEC 9899:2024)으로 대체되었다. 2017년에 개발 중이었고 2018년에 공식적으로 출판되었기 때문에 C17은 때때로 C18이라고도 불린다.
C17 (C 표준 개정판) C11으로부터의 변경 사항
C17은 새로운 언어 기능을 도입하지 않고 C11의 수많은 사소한 결함을 수정했다.
__STDC_VERSION__ 매크로는 201710L 값으로 증가되었다.
이전 표준으로부터의 변경 사항에 대한 자세한 목록은 C11에 대한 Clarification Request Summary를 참조한다. 변경 사항의 예로는 #elif, realloc, 오타 등에 대한 수정이 포함된다.
포터블 C 컴파일러
포터블 C 컴파일러(Portable C Compiler, pcc 또는 때로는 pccm - portable C compiler machine으로도 알려져 있음)는 1970년대 중반 벨 연구소의 스티븐 C. 존슨이 작성한 C 프로그래밍 언어용 초기 컴파일러로, 1973년 앨런 스나이더가 제안한 아이디어에 부분적으로 기반을 두었다. 데니스 리치의 승인 하에 "벨 연구소의 C 컴파일러로 배포되었다."
다양한 컴퓨터 아키텍처용 코드를 쉽게 출력하도록 조정할 수 있는 최초의 컴파일러 중 하나였던 pcc는 긴 수명을 가졌다. Seventh Edition Unix에서 처음 등장하여 1994년 4.4BSD가 출시될 때까지 BSD와 함께 제공되었으며, 이후 GNU 컴파일러 모음으로 대체되었다. 당시 매우 영향력이 커서 1980년대 초에는 대부분의 C 컴파일러가 이를 기반으로 했다. 앤더스 마그누손(Anders Magnusson)과 피터 A 존슨(Peter A Jonsson)은 2007년에 pcc 개발을 다시 시작하여 C99 표준을 지원하기 위해 광범위하게 재작성했다.
포터블 C 컴파일러 기능
pcc의 주요 특징은 이식성과 향상된 진단 기능이다. 이 컴파일러는 소스 파일 중 일부만이 기계 종속적이도록 설계되었다. 구문 오류에 비교적 강하고 동시대의 컴파일러보다 더 철저한 유효성 검사를 수행한다.
데니스 리치가 작성한 최초의 C 컴파일러는 재귀 하향 파서를 사용했고, PDP-11에 대한 특정 지식을 포함했으며, 생성된 어셈블리 언어 코드를 개선하기 위해 선택적인 기계별 최적화 도구에 의존했다. 대조적으로, 존슨의 pccm은 Yacc로 생성된 파서를 기반으로 했으며 더 일반적인 타겟 머신 모델을 사용했다. 두 컴파일러 모두 타겟별 어셈블리 언어 코드를 생성한 다음 이를 어셈블하여 링크 가능한 오브젝트 모듈을 생성했다.
벨 연구소에서 "QCC" 및 "RCC"로 알려진 후기 버전의 PCC는 다른 타겟 아키텍처 모델을 지원했다.
PCC가 구현하는 언어는 비야네 스트롭스트룹이 "클래식 C"라고 부른 K&R C의 확장 버전으로, `void` 반환 타입(값을 반환하지 않는 함수용), 열거형 및 구조체 할당을 포함한다.
포터블 C 컴파일러 현재 버전
스티브 존슨의 원본을 기반으로 한 새로운 버전의 pcc는 앤더스 매그너슨이 관리하고 있다. 이 컴파일러는 BSD 라이선스 하에 제공되며, 그 개발은 BSD 펀드라는 비영리 단체의 자금 지원을 받는다. 매그너슨에 따르면:
가장 큰 장점은 (라이선스 괴짜들에게 BSD 라이선스라는 점 외에도) 빠르다는 것이다. gcc보다 5-10배 빠르면서도 합리적인 코드를 생성한다. <...> 또한 포팅하기 매우 간단하다... — 앤더스 매그너슨
이 새로운 버전은 2007년 9월 NetBSD pkgsrc 및 OpenBSD 소스 트리에 추가되었고, 나중에 주 NetBSD 소스 트리에 추가되었다. 한때 BSD 기반 운영체제에서 GNU 컴파일러 모음을 대체할 수 있을 것이라는 추측이 있었지만, FreeBSD 및 NetBSD는 모두 클랭을 잠재적 대체재로 보고 있으며, OpenBSD의 테오 드 라트는 pcc가 아직 gcc를 대체할 준비가 되어 있지 않으며 gcc 제거가 최우선 순위는 아니라고 주장한다. 2009년 12월 29일, pcc는 기능적인 X86 OpenBSD 커널 이미지를 빌드할 수 있게 되었다.
포터블 C 컴파일러 현재 버전
pcc 버전 1.0은 2011년 4월 1일에 출시되었다.
이 릴리스부터 컴파일러는 X86 및 X86-64 프로세서 아키텍처를 지원하며 NetBSD, OpenBSD, FreeBSD, 다양한 리눅스 배포판 및 마이크로소프트 윈도우에서 실행된다.
더 많은 아키텍처 지원과 FORTRAN 77 및 C++ 프런트엔드를 포함한 추가 개발은 2022년 현재 진행 중이다.
PCC는 2012년에 OpenBSD 소스 트리에서 제거되었다. 개발이 정체되었고 GNU 컴파일러 모음의 실질적인 대안이 될 수 있도록 개발할 관리자가 나타나지 않았기 때문이다.
pcc의 최신 버전인 1.1.0은 2014년 12월 10일에 출시되었다.
타이니 C 컴파일러
타이니 C 컴파일러(Tiny C Compiler), TCC, tCc 또는 TinyCC는 파브리스 벨라르가 처음 작성한 x86 (32비트), X86-64 및 ARM 프로세서용 C 컴파일러이다. 디스크 공간이 적은 느린 컴퓨터(예: 구조 디스크)에서 작동하도록 설계되었다. 윈도우 운영체제 지원은 버전 0.9.23(2005년 6월 17일)에 추가되었다. TCC는 GNU 약소 일반 공중 사용 허가서에 따라 배포된다.
TCC는 ANSI C (C89/C90)의 모든 기능을 구현한다고 주장하며, C99 ISO 표준의 대부분과 인라인 어셈블리를 포함한 많은 GNU C 확장 기능을 구현한다.
타이니 C 컴파일러 기능
TCC는 다른 최신 C 컴파일러와 구별되는 여러 기능을 가지고 있다.
TCC는 명령줄 스위치를 사용하여 컴파일 시 프로그램을 자동으로 실행할 수 있다. 이를 통해 셔뱅 인터프리터 지시어 구문을 지원하는 유닉스 계열 시스템에서 프로그램을 셸 스크립트로 실행할 수 있다. TCC의 셔뱅 (공식 TCC 웹사이트에 명시된 바와 같이)은 #!/usr/local/bin/tcc -run이다 (TCC가 /usr/local/bin/tcc에 설치되어 있다고 가정하며, 설치 위치는 시스템에 따라 다를 수 있다).
타이니 C 컴파일러 컴파일된 프로그램 성능
일반적으로 TCC의 구현은 최적의 성능을 내는 결과보다는 작음에 중점을 둔다. TCC는 단일 패스로 코드를 생성하며, 다른 컴파일러에서 수행하는 대부분의 최적화를 수행하지 않는다. TCC는 각 문장을 자체적으로 컴파일하며, 각 문장 끝에서 레지스터 값은 스택에 다시 기록되고 다음 줄에서 레지스터의 값을 사용하더라도 다시 읽어야 한다(문장 사이에 불필요한 저장/로드 쌍을 생성함). TCC는 사용 가능한 레지스터 중 일부만 사용한다 (예: x86에서는 함수 호출 시 보존되어야 하므로 ebx, esi 또는 edi를 사용하지 않는다).
TCC는 몇 가지 최적화를 수행하는데, 모든 연산에 대한 상수 전파, 적절한 경우 곱셈과 나눗셈을 시프트로 최적화하고, 비교 연산자는 특별히 최적화된다 (프로세서 플래그에 대한 특수 캐시를 유지하여). 또한 단순한 레지스터 할당을 수행하여 단일 문 내에서 많은 불필요한 저장/로드 쌍을 방지한다.
다음은 두 가지 벤치마크 예시이다.
타이니 C 컴파일러 컴파일된 프로그램 성능
512MB RAM을 장착한 1.8GHz 인텔 센트리노 랩톱에서 재귀적 피보나치 수열 알고리즘을 사용한 결과, 마이크로소프트 비주얼 C++ 컴파일러 13.10.3052와 TCC 간에 눈에 띄는 결과 차이가 나타났다. 49번째 피보나치 수를 계산하는 데 MS 비주얼 C++ 프로그램은 TCC 컴파일 프로그램보다 약 18% 더 오래 걸렸다.
다른 C 컴파일러를 사용하여 GNU C 컴파일러 (GCC) 자체를 컴파일한 다음, 생성된 컴파일러를 사용하여 GCC를 다시 컴파일하여 비교하는 테스트를 수행했다. GCC 3.4.2와 비교했을 때, GCC를 컴파일하도록 수정된 TCC는 컴파일러를 10배 빠르게 컴파일할 수 있었지만, 생성된 .exe 파일은 57% 더 컸고 훨씬 느려서 GCC를 다시 컴파일하는 데 2.2배 더 오래 걸렸다.결과는 다음과 같았다. GCC C 컴파일러인 cc1을 자체적으로 실행하는 데는 GCC 3.4.2로 컴파일했을 때 518초, 마이크로소프트 C 컴파일러를 사용했을 때 545초, TCC를 사용했을 때 1145초가 걸렸다. 이러한 컴파일러를 처음 만드는 데 GCC (3.4.2)는 GCC 컴파일러를 컴파일하는 데 744초가 걸린 반면, TCC는 73초밖에 걸리지 않았다. 각 컴파일러의 최적화 수준은 -O1 또는 그와 유사했다.
타이니 C 컴파일러 역사
TCC는 2001년 IOCCC에서 벨라르가 우승하기 위해 작성한 프로그램인 Obfuscated Tiny C Compiler (OTCC)에서 비롯되었다. 그 후 벨라르는 프로그램을 확장하고 난독화를 해제하여 tcc를 만들었다.
2012년 2월 4일 이전에 파브리스 벨라르는 자신이 더 이상 TCC 작업에 참여하지 않는다고 보고하기 위해 프로젝트의 공식 웹페이지를 업데이트했다.
벨라르가 프로젝트에서 떠난 이후, 다양한 사람들과 그룹들이 TCC를 기반으로 구축하거나 문제를 해결하기 위해 TCC의 패치를 배포하거나 포크를 유지해왔다. 여기에는 데이브 닷지의 비공식 tcc 패치 모음, 데비안 및 kfreebsd 다운스트림 패치, 그리고 그리쉬카의 gcc 패치가 포함된다. 그리쉬카는 또한 프로젝트를 위한 공개 Git 저장소를 설정했다. 이 저장소에는 공유 빌드, 크로스 컴파일러, SELinux 호환성 등 수많은 기여가 추가된 mob 브랜치가 포함되어 있다. 그리쉬카의 GIT 저장소는 나중에 공식 TCC 저장소가 되었다 (파브리스 벨라르의 Savannah 프로젝트 페이지에 링크됨).
타이니 C 컴파일러 현재 상태
2017년 12월 현재 공식 TCC 메일링 리스트와 공식 Git 저장소(파브리스 벨라르의 Savannah 프로젝트 페이지에 링크됨) 모두 많은 개발자와 관심 있는 사용자들의 활발한 토론과 개발을 보여준다. 2017년 12월, 그리쉬카는 메일링 리스트에서 TCC 버전 0.9.27이 출시되었다고 발표했다.
LCC (컴파일러)
LCC("Local C Compiler" 또는 "Little C Compiler")는 ANSI C 프로그래밍 언어를 위한 작고 재표적화 가능한 컴파일러이다. 소스 코드는 개인 용도로 무료로 제공되지만, LCC에서 파생된 제품은 판매할 수 없으므로 일반적인 정의에 따르면 오픈 소스 또는 자유 소프트웨어가 아니다. 단, LCC에서 파생되지 않은 구성 요소는 판매할 수 있다. 이 컴파일러는 크리스 프레이저와 데이비드 핸슨이 개발했다.
LCC (컴파일러) LCC
LCC는 이해하기 매우 간단하고 문서화가 잘 되어 있다. 이 컴파일러의 설계는 프레이저와 핸슨의 저서인 "재표적화 가능한 C 컴파일러: 설계 및 구현(A Retargetable C Compiler: Design and Implementation)"에 설명되어 있다. 이 책에는 노웹을 사용하여 문학적 프로그램으로 작성된 컴파일러 버전 3.6의 대부분의 소스 코드가 포함되어 있다. 2011년 7월 현재 LCC의 최신 버전은 4.2이지만, 책의 많은 내용은 이 버전에도 여전히 적용된다. 책 출판 이후의 주요 변경 사항은 코드 생성기 인터페이스이며, 이는 별도의 문서에 설명되어 있다.
LCC의 소스 코드는 약 2만 줄로, 많은 주요 컴파일러보다 훨씬 작다.
LCC는 Alpha, SPARC, MIPS, x86을 포함한 여러 프로세서 아키텍처용 코드를 생성할 수 있다. 마이크로소프트의 공통 중간 언어를 생성하는 LCC 백엔드도 있다.
LCC (컴파일러) LCC를 통합한 프로젝트
이드 소프트웨어의 이드 테크 3 엔진은 LCC의 수정된 버전을 사용하여 각 게임 모듈 또는 타사 모드의 소스 코드를 가상 머신을 대상으로 하는 바이트코드로 컴파일한다. 이는 악의적인 모드 제작자가 제기하는 위협을 줄이기 위해 모듈이 시스템 호출과 엔진이 제공하는 제한된 파일 시스템 범위를 넘어 시스템에 무지하다는 것을 의미한다. 또 다른 고려 사항은 엔진용으로 작성된 게임과 모드가 재컴파일 없이 이식 가능하다는 것이다. 모듈을 실행하기 위해 이식만 하면 된다.
lcc-win32는 마이크로소프트 윈도우용 통합 개발 환경 패키지로, LCC의 포크를 포함한다. 2012년 4월 15일부터 사용할 수 있는 lcc-win64라는 amd64 대응 버전도 있다.
Pelles C의 컴파일러는 C11 및 C17 지원, amd64 지원, 인라인 확장과 같은 추가 최적화 기법 및 IDE를 제공하는 LCC의 크게 수정된 버전이다.
32비트 윈도우 머신의 경우, 매스웍스 매트랩 및 관련 제품에 다른 컴파일러가 설치되어 있지 않으면 Lcc가 기본값으로 사용된다.
LCC (컴파일러) 라이선스
LCC는 개인 용도로 무료이며, 모든 배포 미디어 및 제품 문서에 이를 인정하면 재배포할 수 있다. LCC 라이선스는 여러 경우에서 예시에 의존한다. LCC는 이윤을 목적으로 판매할 수 없지만, LCC 자체가 무료로 배포되는 한 이윤을 목적으로 판매되는 다른 소프트웨어와 함께 포함될 수 있다. 사용자별 및 무제한 사용 라이선스는 Addison-Wesley에 연락하여 얻을 수 있으며, 특히 C 컴파일러가 작업의 많은 부분을 구성할 수 있는 C++와 같은 언어의 컴파일러에 해당한다.
그놈 빌더
그놈 빌더(GNOME Builder)는 그놈 플랫폼을 위한 범용 통합 개발 환경 (IDE)으로, 주로 그놈 기반 애플리케이션 작성을 돕기 위해 설계되었다. 2015년 3월 24일에 처음 출시되었으며, Anjuta를 대체했다. 이 애플리케이션의 슬로건은 "그놈 기반 애플리케이션을 위한 도구 장인"이다.
그놈 빌더 기능
GUADEC 2016에서 크리스티안 헤르거트(Christian Hergert)는 그놈 빌더의 다가오는 버전에 대한 데모 - 유튜브를 제공했다. GTK Scene Graph Kit가 GTK에 병합되면 더 많은 기능이 통합될 것이다. sysprof는 포크되었고 버전 번호가 1.2.0에서 3.20으로 올라갔으며 버전 3.22에 통합되었다.
그놈 빌더는 GNOME 코드 어시스턴스를 사용하여 CSS, HTML, JS, JSON, 파이썬, 루비, SCSS, 셸 스크립트 및 XML에 대한 코드 진단을 제공한다. 파이썬 코드 완성에는 Jedi가 사용된다. C-like 언어의 코드 어시스턴스에는 클랭이 사용된다. 러스트 진단은 러스트 언어 서버와 통신하기 위해 Language Server Protocol을 사용하여 제공된다.
그놈 빌더 사용자 인터페이스
인터페이스의 대부분은 중앙에 위치한 코드 편집기에 할당된다. 편집기는 대부분의 프로그래밍 언어를 자동으로 인식하고 그에 따라 텍스트를 강조 표시한다. 버전 관리 시스템이 사용될 때, 줄 번호 옆의 색상 막대는 해당 줄의 변경 사항을 나타낸다. 지원되는 언어의 경우, 추가 기호가 오류가 있거나 형식이 잘못된 코드를 포함하는 줄을 강조 표시한다.
빌더는 빌더 자체, Vim과 유사한, 그리고 이맥스와 유사한 키보드 바인딩 사이를 전환할 수 있다.
코드 편집기 주변에는 추가 패널을 토글하여 볼 수 있다. 여기에는 프로젝트 트리, 터미널 창, 도움말 브라우저가 포함된다. 프로젝트 트리는 사용자가 파일 및 폴더 작업을 수행할 수 있도록 한다.
그놈 빌더 개발
그놈 빌더의 개발은 2015년 1월 Indiegogo 플랫폼에서 크라우드펀딩되었다. 캠페인은 목표 자금 30,000달러의 187% (56,245달러)를 달성했다.
ISO 로마자 표기법 목록
ISO 표준의 전자 및 로마자 표기법 목록:
ISO 259
ISO 259는 히브리 문자를 라틴 음소문자로 로마자를 표기하기 위한 국제 표준 시리즈로, 1984년에 제정되었으며, 업데이트된 ISO 259-2 (여러 모음 부호를 무시하고 단순화, 1994년) 및 ISO 259-3 (음소 변환, 1999년)이 있다.
ISO 259 ISO 259
1984년에 제정된 ISO 259는 성서 히브리어에 사용되는 발음 구별 기호(니쿠드)를 포함한 히브리어 문자의 전자이다.
다게쉬(글자 안의 점)는 항상 위점으로 전사된다: ḃ, ġ, ż 등. 위 표의 아포스트로피(׳‎‎)는 일부 글자 뒤에 사용하여 비히브리어 소리를 표기하는 히브리어 부호 게레쉬이다: ג׳‎ [d͡ʒ], ז׳‎ [ʒ], צ׳‎ [t͡ʃ] 등.
ISO 259 ISO 259-2
ISO 259-2는 ISO 259의 모음 발음 구별 부호를 단순화한 것으로, 현대 히브리어를 위해 설계되었다.
다게쉬는 표시된 경우를 제외하고는 전사되지 않는다. 위 표의 아포스트로피(׳‎‎)는 일부 글자 뒤에 사용하여 비히브리어 소리를 표기하는 히브리어 부호 게레쉬이다.
ISO 259 ISO 259-3
ISO 259-3은 우지 오르난의 로마자 표기법으로, ISO 최종 초안(FDIS) 단계에 이르렀지만 국제 표준(IS)으로 출판되지는 않았다. 이것은 히브리어의 다양한 방언이나 발음 스타일 전반에 걸쳐 히브리어 단어의 일반적인 구조를 전달하여, 사람과 기계 모두에 의해 원래 히브리어 문자로 재구성될 수 있도록 설계되었다.
이것은 히브리어의 한 발음 스타일을 문자 단위로 전자한 것도, 음성 전사한 것도 아니며, 오히려 여러 세대에 걸쳐 히브리어의 모든 다양한 방언과 발음이 동일한 구조의 다른 실현으로 간주될 수 있다는 관점에서 음소적이며, 미리 정의된 읽기 규칙에 따라 모든 발음 스타일이 직접 파생될 수 있다.
히브리어 문자의 각 자음 문자는 고유한 라틴 문자로 변환된다. ISO 259-3에는 모음 음소 5개에 해당하는 5개의 모음 문자가 있다: a, e, i, o, u. 이 외에, 일반적인 히브리어 철자에서 ⟨י‎⟩ 뒤에 오는 /ej/ 또는 /e/ 모음을 나타내는 여섯 번째 기호가 있다: ei.
ISO 259 ISO 259-3
다게쉬 하작(성서 히브리어의 중복 자음)은 이중 자음으로 전사된다. 다음과 같은 비음소적 모음은 무시된다:
ISO-259-3의 공식 제안은 히브리어 צ‎/ץ‎에 해당하는 라틴 문자로 C/c만을 제시하지만, 오르난은 이를 Ç/ç로 대체 로마자 표기하는 것도 허용했고, 2008년 이 주제에 대한 논문에서 자신이 선호한다고 썼으며, 2003년 이전 논문에서는 특히 히브리어 지명(예: 이스라엘 도로 표지판)의 로마자 표기에 Ç/ç 사용을 권장했다.
조지아어의 로마자 표기법
조지아어의 로마자 표기법(Romanization of Georgian)은 조지아어를 조지아 문자에서 로마자로 전자하는 과정이다.
조지아어의 로마자 표기법 조지아 국가 로마자 표기 체계
2002년 2월 조지아 국토측량학과 조지아 국립과학원 언어학 연구소에서 채택한 이 시스템은 조지아 문자를 로마자로 전자하는 시스템을 확립한다. 이 시스템은 1998년부터 운전면허증에 사용되어 왔다. 또한 2009년부터 BGN과 PCGN, 그리고 구글 번역에서도 사용된다.
조지아어의 로마자 표기법 비공식 로마자 표기 체계
인기에도 불구하고 이 시스템은 때때로 모호함을 유발한다. 이 시스템은 주로 사회 네트워크, 인터넷 포럼, 채팅방 등에서 사용된다. 이 시스템은 각 키를 알파벳의 각 글자에 연결하는 일반적인 QWERTY 기반 조지아어 자판 배열의 영향을 크게 받는다 (T, W, R, S, J, Z, C 7개 문자는 Shift 키를 사용하여 다른 글자를 만든다).
조지아어의 로마자 표기법 ISO 표준
ISO 9984:1996, "조지아 문자에서 라틴 문자로의 전자",는 2010년에 마지막으로 검토되고 확인되었다.
표준의 기본 원칙은 다음과 같다.
조지아어의 로마자 표기법 전자 표
고대 문자는 빨간색 배경으로 표시된다.
문서 형식 의미·사양 기술 언어
문서 형식 의미·사양 기술 언어(Document Style Semantics and Specification Language, DSSSL)는 표준 일반화 마크업 언어 문서에 스타일시트를 제공하기 위해 개발된 국제 표준이다.
DSSSL은 문서를 표현하기 전에 문서의 트리 구조를 조작하는 데 사용할 수 있는 트리 변환 프로세스와 소스 문서의 요소를 대상 표현인 흐름 객체 트리의 특정 노드와 연결하는 서식 지정 프로세스의 두 부분으로 구성된다. DSSSL 사양은 서로 다른 플랫폼 간에 교환할 수 있는 장치 독립적인 정보이다. DSSSL은 언어의 출력을 생성하는 백엔드 포맷터를 표준화하지 않는다. 이러한 포맷터는 온스크린 표시를 위해 출력을 렌더링하거나 특정 형식(예: 포스트스크립트 또는 서식 있는 텍스트 포맷)의 컴퓨터 파일에 기록할 수 있다.
스킴 프로그래밍 언어의 하위 집합을 기반으로 하며, ISO/IEC 10179:1996 표준으로 지정되었다. ISO/IEC JTC 1/SC 34(ISO/IEC 합동 기술 위원회 1, 소위원회 34 - 문서 설명 및 처리 언어)에 의해 개발되었다.
문서 형식 의미·사양 기술 언어
SGML에는 기계가 읽을 수 있지만 인간이 읽을 수 있는 형식은 아닌 정보가 포함되어 있다. "스타일시트"는 SGML에 저장된 정보를 더욱 보기 좋거나 접근 가능한 방식으로 표시하는 데 사용된다. DSSSL은 RTF, HTML, LaTeX를 포함한 광범위한 형식으로 변환할 수 있다.
DSSSL은 모든 SGML 기반 문서 유형과 호환되지만 주로 닥북과 함께 사용되었다. 1997년, 소프트웨어 엔지니어 게일 오베 그론모(Geir Ove Grønmo)는 KEDIT용 구문 강조 언어 정의를 발표했다.
XML이 SGML의 대안으로 등장하면서 XML의 관련 스타일시트 언어인 XSL도 1999년경부터 널리 빠르게 채택되었다. DSSSL은 줄어드는 SGML 분야에서 계속 사용되었지만, XSL은 DSSSL이 이전에 달성했던 것보다 훨씬 더 광범위하게, 그리고 더 많은 코더에 의해 사용되기 시작했다. 이는 닥북과 같은 이전 SGML의 강자들이 SGML에서 XML로 전환하고, 선호하는 스타일시트 언어를 DSSSL에서 XSL로 전환하면서 더욱 강조되었다.
1994년 또는 그 이전에 제임스 클라크는 월드 와이드 웹 컨소시엄의 고려를 위해 "DSSSL 라이트" 사양 초안을 작성하기 시작했다. DSSSL이 월드 와이드 웹에 너무 복잡하다고 생각했기 때문이다.
ISO 31-4
ISO 31-4는 국제 표준 ISO 31의 한 부분으로, 열과 관련된 물리량과 물리 단위의 이름과 기호를 정의한다. ISO 80000-5로 대체되었다.
정의는 다음과 같다.
ISO 31-4의 부록 A는 피트, 파운드, 초를 기반으로 한 열 단위와 랭킨도, 화씨, 영국 열량 단위 및 기타 단위를 나열한다. 부록 B는 세 가지 버전의 칼로리에 대한 변환 계수를 나열한다.
ISO 31-5
ISO 31-5는 국제 표준 ISO 31의 일부로, 전기 및 자기에 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다. 이 표준은 ISO 80000-6으로 대체되었다.
아래는 NIST 상수값에서 가져온 일부 정의이다.
ISO 31-6
ISO 31-6은 국제 표준인 ISO 31의 일부로, 빛과 관련 전자기파에 관련된 물리량 및 물리 단위의 명칭과 기호를 정의한다. 이 표준은 ISO 80000-7으로 대체되었다.
ISO 31-6은 1980년에 처음 발행되었고 1985년에 개정되었다. 1992년에 개정되었고 1998년에 수정되었다. 이 표준은 2008년에 ISO 80000-7으로 대체되면서 최종적으로 철회되었다.
ISO 31-6 정의
1980년에 정의된 ISO 31-6의 정의는 다음과 같다:
ISO 31-7
ISO 31-7은 국제 표준 ISO 31의 일부로, 음향학과 관련된 물리량 및 물리 단위의 명칭과 기호를 정의한다. 이 표준은 ISO 80000-8로 대체되었다.
그 정의에는 다음이 포함된다:
ISO 31-8
ISO 31-8은 국제 표준인 ISO 31의 일부로, 물리화학 및 분자물리학과 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다.
ISO 31-8 내용주
양 및 그 단위 표에서 ISO 31-8 표준은 물질의 기호를 아래첨자(예: cB, wB, pB)로 표시한다. 또한 물질의 기호와 상태는 일반적으로 같은 줄에 괄호 안에 넣는 것이 바람직하다고 명시한다(예: c(H2SO4)).
ISO 31-8 규범적 부속서
이 부속서는 원소 (화학) 번호 1(수소, H)부터 109(운닐레늄, Une)까지의 원자 번호순 원소 목록을 포함하며, 화학 원소의 이름과 표준 기호를 제공한다.
ISO 31-8:1992에 제공된 목록은 1998년 IUPAC "그린 북" Quantities, Units and Symbols in Physical Chemistry에서 인용되었으며, 표준 기호가 원소의 영어 이름과 관련이 없는 경우 정보 제공을 위해 괄호 안에 라틴어 이름을 추가하는 경우가 있다. 1992년 표준판이 발행된 이후 원자 번호 103을 초과하는 일부 원소는 발견되고 이름이 변경되었다.
화학 원소의 기호는 로마자(수직)로 작성되어야 한다. 기호 뒤에는 마침표를 찍지 않는다.
예:
H He C Ca
핵종 또는 분자를 지정하는 아래첨자 또는 위첨자는 다음 의미와 위치를 갖는다.
pH는 다음과 같이 조작적 정의된다. 용액 X의 경우, 먼저 갈바니 전지의 기전력 EX를 측정한다.
기준 전극 | 농축 KCl 용액 | 용액 X | H2 | Pt
ISO 31-8 규범적 부속서
그리고 알려지지 않은 pH, pH(X)의 용액 X를 알려진 표준 pH, pH(S)의 용액 S로 대체하는 것 외에는 위와 다른 갈바니 전지의 기전력 ES를 측정한다. 그러면 X의 pH는 다음과 같이 얻어진다.
pH(X) = pH(S) + (ES − EX) F / (RT ln 10)
여기서
F는 패러데이 상수이다.
R은 몰 기체 상수이다.
T는 열역학 온도이다.
이렇게 정의된 pH는 차원 1의 양, 즉 단위가 없다. 표준 용액 S의 pH(S) 값은 Definitions of pH scales, standard reference values, measurement of pH, and related terminology. Pure Appl. Chem. (1985), 57, pp 531–542에 나열되어 있으며, 추가 세부 정보를 찾을 수 있다.
pH는 근본적인 의미를 갖지 않으며, 공식적인 정의는 실용적인 것이다. 그러나 0.1 mol/L 미만의 물질량 농도를 가지며 강염기성 또는 강산성이 아닌 묽은 수용액(2 < pH < 12)의 제한된 범위에서는 정의가 다음과 같다.
pH = −log10[c(H+) y1 / (1 mol/L)] ± 0.02
여기서 c(H+)는 수소 이온 H+의 물질량 농도를 나타내고 y1은 용액 내 전형적인 1가-1가 전해질의 활동 계수를 나타낸다.
ISO 31-10
ISO 31-10은 국제 표준인 ISO 31의 일부로서 핵반응 및 이온화 방사선과 관련된 물리량 및 물리 단위의 이름과 기호를 정의한다. 이 표준은 70개의 물리량과 단위에 대한 이름과 기호를 제공한다. 적절한 경우, 변환 계수도 제공된다. 이 표준은 2009년에 폐지되었고 ISO 80000-10으로 대체되었다.
정의에는 다음이 포함된다:
ISO 31-11
ISO 31-11:1992은 국제 표준 ISO 31의 일부로, 물리 과학 및 기술에 사용되는 수학적 기호 및 기호를 정의한다. 이 표준은 2009년 ISO 80000-2:2009로 대체되었고, 이후 2019년 ISO-80000-2:2019로 개정되었다.
이 표준에는 수리논리학, 집합론, 산술 및 복소수, 함수 및 특수 함수와 값, 행렬, 벡터 및 텐서, 좌표계 및 기타 수학적 관계에 대한 기호 정의가 포함되었다.
ISO 217
ISO 217:2013 표준은 RA 및 SRA 용지 형식을 정의한다.
ISO 217 개요
이 용지 시리즈는 재단되지 않은 원지이다. RA는 "raw format A"(원시 형식 A)의 약어이며 SRA는 "supplementary raw format A"(보조 원시 형식 A)의 약어이다. RA 및 SRA 형식은 해당 A 시리즈 형식보다 약간 크다. 이렇게 하면 나중에 크기에 맞게 잘라낼 인쇄물에 블리드(가장자리까지 잉크)가 허용된다. 이 용지는 인쇄 및 제본 후 A 형식에 맞게 잘라진다.
ISO 217 허용 오차
RA 및 SRA 시리즈 형식의 용지는 의 종횡비를 갖도록 의도되었지만, 시작 형식의 치수는 정수 센티미터로 반올림되었다.
예를 들어, RA0 형식은 이론적인 치수 에서 860mm × 1220mm로 반올림되었다.
결과적인 실제 비율은 다음과 같다.
RA 시리즈의 크기는 ANSI/ASME Y14.1에 지정된 해당 인치 기반 미국 크기보다 약간 크다. 예를 들어 RA4는 대략 8 1⁄2 in × 12 in (220 mm × 300 mm)에 해당하고 ANSI A(별칭 미국 레터)는 8 1⁄2 in × 11 in (220 mm × 280 mm)로 정의된다.
ISO 128
ISO 128은 국제 표준화 기구(ISO)의 국제 표준으로, 기술 도면의 표시를 위한 일반 원칙, 특히 기술 도면에서 객체의 그래픽 표현을 다룬다.
ISO 128 주목성 확립
다음 독립적이고 고품질의 출처는 ISO 128에 대한 중요한 내용을 제공한다: