Track this back : http://jaram.tistory.com/trackback/76
[용어] OFDM - orthogonal frequency division multiplex
대역폭당 전송 속도의 향상과 멀티패스 간섭을 방지하는 두 가지 양립을 겨냥한 디지털 변조 방식. 1995년 9월부터 영국과 스웨덴에서 실용 방송이 시작되었다. 지상파(VHF/UHF 대)를 이용한 차세대 TV 방송을 위한 유럽의 DAB(Digital Audio Broadcasting)가 표준 방식으로 일본에서도 방식으로 채택했다. OFDM의 특징은 가지는 수백 개의 반송파(서브캐리어)를 사용하는 다반송파 변조 방식이다. 그러나 QAM과 VSB는 단일 반송파이다. OFDM이라고 하는 이름이 나타내듯이 각 반송파는 직교 관계에 있다. 그 때문에 각 반송파의 주파수 성분이 서로 겹쳐 있어도 좋다. 일반적인 주파수 분할 다중(FDM; Frequency Division Multiplex)보다 훨씬 많은 반송파를 주입하기 때문에 주파수 이용률이 높아진다. 이들 각 반송파에 직병렬 변환한 부호화 데이터를 할당하고 나서 디지털 변조한다. 반송파를 많게 하면 대역폭 당 전송 속도를 높일 수 있다. 전송 속도를 일정하게 한 채로 반송파를 늘리면 반송파 1파당의 심벌 전송 속도가 느려진다. 심벌 주기가 길어지고 멀티패스에 의한 지연 신호의 영향을 배제할 수 있다. 파형 등화기가 필요 없어진다. 그러나 반송파의 수에는 한계가 있다. 각 반송파의 디지털 변조는 역 FFT(고속 프리에 변환)에 의해 주파수 영역에서 시간 영역으로 변환하는 것으로 실행된다. 즉 역 FFT의 점수는 반송파의 수와 동일하게 된다. 이것을 위해서 FFT의 처리 성능이 반송파의 수를 결정하게 된다. - digital modulation, VSB, QAM
저는 제 나름대로 설명을 해볼게요^^ ofdm이란 [직렬고속데이타를 병력저속데이타]로 보내는것이다. 즉 동작이 무지 빠른애 한명이 10번 왔다갔다 해서 나른 양이나 좀 느리더라도 동작이 확실한 녀석 5명이 천천히 나른양이나 같다. 저는 이렇게 이해 했습니다. 그럼 왜 5명이 나르게 하느냐 하면 윗분 말씀처럼 전파환경(공기)에서 페이딩에 의해 너무 빠른녀석은 시간축에서 지연이 되기 때문에 자기가 1이었는 0이었는지 헷갈리수 있기 때문에 동작이 확실한 느린녀석들을 쓰려고 하는거 같습니다.
Track this back : http://jaram.tistory.com/trackback/73
[자연형 하천] 분당 탄천
종종 들려 좋은 글을 읽고 오는 제임스님이 오랜만에 글을 포스팅 하셨습니다. 내용은 "안양천"과 관련된 내용입니다.
저희 회사는 분당에 자리잡고 있습니다. 정확하게 이야기하면 정자역과 수내역 사이에 있습니다.
분당에도 "탄천"이라는 작은 천이 있습니다. 이곳도 "자연형 하천"으로 전환 하면서 부터 개천에 오리와 물고기들이 많이 보입니다.
자연형 하천이라는 것은 인공적인 변형을 가하지 않은는 자연 상태의 하천입니다. 쉽게 양쪽에 콘크리트로 뚝을 쌓거나 중간에 제방으로 막아 놓지 않고, 그냥 마음대로 물이 흐르도록 내버려 두는 것입니다.
이런 하천은 구블구블하고 유속도 불규칙하며 일단 ^^ 물도 깨끗해지고 수풀이 무성하여 수상생물들이 서식할 수 있는 환경이 만들어 지죠. 또한 오리녀석들이 풀숲에서 살수도 있구요. 이런 곳이 바로 "습지"가 되는 것 같습니다. (네이뇬을 조금 참조 해서 코멘트를 달았습니다.)
3년을 지켜 보며 물이 깨끗지는 것을 지켜 보고 있습니다. 앞으로 몇년이 더 지난다면 물에서 뛰어 노는 사람들도 볼수 있지 않을까 기대 해봅니다.
Track this back : http://jaram.tistory.com/trackback/72
[알고리즘]힙(heap)을 이용한 우선순위 큐
대딩때 가장 즐겁게 만들었던 우선순위 Heap입니다.^^ 참 단촐 하면서도 가장 재미있게 한 레포트였습니다.
항상 n-1을 유지 하기 때문에 Static 한 Arrary를 Pointer 이용하여 각 노드들의 포인터만 저장 될 수 있도록 하고 Indexing을 통하여 우선순위 Heap을 핸들링 하는 것이 좋겠다 생각 한다.
Push와 Pop을 이용하여 새로운 Node를 삽입하게 되고 삽입 된 노드는 항상 가장 아래에 입력이 됩니다. 즉 N-1에 입력이 된다고 할 수 있다.
Pop이 이루어질 때는 우선 순위가 갖아 높은 최상의 Node가 Pop이 되고 Pop이 되면 자식 노드중 가장 큰 값을 다시 최상으로 올리는 재배열이 이루어져야 한다.
요것만 지켜지면 Max Heap이 됩니다.
아래 내용은 내용의 출처는 http://timenote.net/ 에 기록자 님의 작성한 원문이다. 특별히 저자분의 동의 없이 내용을 훔쳐 왔다는게 마음에 걸리고 동의를 받아야 하겠다.
힙(heap)이란 특수한 형태의 완전이진트리의 구조를 가진다. 힙은 각 노드의 키 값이(자식이 있다면) 그 자식의 키 값보다 작지 않은 완전 이진 트리이다. 힙의 구조를 살펴보면 아래와 같다.
완전 이진트리인 힙의 일반적인 형태
힙은 일반적으로 우선순위 큐(priority queue)를 구현할 때 자주 사용된다. 이전에 구현해 보았던 큐와는 달리 우선순위 큐에서는 우선순위가 가장 높은 원소를 먼저 삭제한다. 예를 들어 운영체제의 작업 스케줄러가 관리자에게 높은 우선순위를 부여하고 학생에게는 낮은 우선순위를 부여하는 우선순위 시스템을 사용한다고 가정하자. 이 경우 작업들을 유지하는 우선순위 큐를 최대 힙으로 구현할 수 있다.
힙은 우선순위 큐를 구현하는 한 방법일 뿐이다. 실제로 우선순위큐를 표현하기 위한 방법으로는 순서없는 배열, 순서없는 연결 리스트, 정렬된 배열, 정렬된 연결 리스트, 힙 등이 있다. 이 중 삽입과 삭제에 대한 복잡도가 둘다 log n의 복잡도를 가지는 것은 힙이다. 그렇기 때문에 우선순위큐를 표현하는 방법들중 힙을 선호하게 만든다. 그러면 힙의 삽입과 삭제 방법을 보도록하자.
아래 그림은 힙의 삽입 방법이다.
힙에서의 삽입 과정은 배열의 제일 뒤에 새로운 원소를 삽입하고 부모 노드의 키 값과 비교해서 부모 노드보다 작을 때까지 교체과정을 거친다. 즉, 삽입시에 최대한의 비교과정을 거치더라도 루트 노드까지만 비교하면 되므로 복잡도는 log n 을 따르게 된다. 다음은 힙에서 삭제가 일어나는 과정을 보도록 하겠다.
힙에서의 삭제 과정
힙에서의 삭제는 항상 루트의 값이 제거 되므로 루트의 값이 제거된 후에도 힙을 유지할 수 있도록 하기 위한 처리가 필요하다. 우선 완전 이진트리가 되어야 하므로 제일 뒤의 원소(여기서는 6)를 루트의 자리에 위치 시킨다. 그리고 힙의 특성상(여기서는 최대힙) 부모노드의 키값이 자식 노드의 키값보다 커야 하므로 자식 노드와 비교하면서 키값이 자식노드보다 클 때까지 반복해 나간다.
Track this back : http://jaram.tistory.com/trackback/71
다시 들쳐 보는 문법 및 레퍼함수 - fseek
제목을 어떻게 붙일까하다가 "다시 들쳐 보는 문법 및 레퍼함수"이라 하였다. 특별히 fseek를 사용하는데 어려운 일이 있는 것도 아니다.
다만 가물 가물 해져가는 기억을 위해 실험하고 기록하여 이짓( IT )을 오래도록 해먹기 위한 발악쯤으로 생각 하면 될 듯...
fseek를 MSDN을 참조하면...
* 특정 위치로 파일의 포인터를 움직인다. * 64bit를 위한 offset이 존재 한다는 것을 알 수 있다.
msdn에서 함수에 대한 설명을 볼때 가장 중요하게 볼 것은 역시, 인자 값과, 리턴 값일 것이다. 아래 내용을 잘 살펴보면
"If successful, fseek and _fseeki64 returns 0. Otherwise, it returns a nonzero value. " 성공과 실패에 대한 return 값을 정의하고 있다.
MSDN을 살펴보면 친절하게도 예제 코드도 제공 해준다. 굿이다.
Moves the file pointer to a specified location.
int fseek(
FILE *stream,
long offset,
int origin
);
int _fseeki64(
FILE *stream,
__int64 offset,
int origin
);
Parameters
stream
Pointer to FILE structure.
offset
Number of bytes from origin.
origin
Initial position.
Return Value
If successful, fseek and _fseeki64 returns 0. Otherwise, it returns a nonzero value. On devices incapable of seeking, the return value is undefined. If stream is a null pointer, or if origin is not one of allowed values described below, fseek and _fseeki64 invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions set errno to EINVAL and return -1.
Remarks
The fseek and _fseeki64 functions moves the file pointer (if any) associated with stream to a new location that is offset bytes from origin. The next operation on the stream takes place at the new location. On a stream open for update, the next operation can be either a read or a write. The argument origin must be one of the following constants, defined in STDIO.H:
SEEK_CUR
Current position of file pointer.
SEEK_END
End of file.
SEEK_SET
Beginning of file.
You can use fseek and _fseeki64 to reposition the pointer anywhere in a file. The pointer can also be positioned beyond the end of the file. fseek and _fseeki64clears the end-of-file indicator and negates the effect of any prior ungetc calls against stream.
When a file is opened for appending data, the current file position is determined by the last I/O operation, not by where the next write would occur. If no I/O operation has yet occurred on a file opened for appending, the file position is the start of the file.
For streams opened in text mode, fseek and _fseeki64have limited use, because carriage return–linefeed translations can cause fseek and _fseeki64to produce unexpected results. The only fseek and _fseeki64operations guaranteed to work on streams opened in text mode are:
Seeking with an offset of 0 relative to any of the origin values.
Seeking from the beginning of the file with an offset value returned from a call to ftell when using fseekor _ftelli64when using_fseeki64.
Also in text mode, CTRL+Z is interpreted as an end-of-file character on input. In files opened for reading/writing, fopen and all related routines check for a CTRL+Z at the end of the file and remove it if possible. This is done because using the combination of fseek and ftellor_fseeki64 and _ftelli64, to move within a file that ends with a CTRL+Z may cause fseek or _fseeki64 to behave improperly near the end of the file.
When the CRT opens a file that begins with a Byte Order Mark (BOM), the file pointer is positioned after the BOM (that is, at the start of the file's actual content). If you have to fseek to the beginning of the file, use ftell to get the initial position and fseek to it rather than to position 0.
This function locks out other threads during execution and is therefore thread-safe. For a non-locking version, see _fseek_nolock, _fseeki64_nolock.
Requirements
Function
Required header
Compatibility
fseek
<stdio.h>
ANSI, Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows NT 4.0, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003
_fseeki64
<stdio.h>
Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows NT 4.0, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003
For additional compatibility information, see Compatibility in the Introduction.
// crt_fseek.c
// This program opens the file FSEEK.OUT and
// moves the pointer to the file's beginning.
#include <stdio.h>
int main( void )
{
FILE *stream;
char line[81];
int result;
if ( fopen_s( &stream, "fseek.out", "w+" ) != 0 )
{
printf( "The file fseek.out was not opened\n" );
return -1;
}
fprintf( stream, "The fseek begins here: "
"This is the file 'fseek.out'.\n" );
result = fseek( stream, 23L, SEEK_SET);
if( result )
perror( "Fseek failed" );
else
{
printf( "File pointer is set to middle of first line.\n" );
fgets( line, 80, stream );
printf( "%s", line );
}
fclose( stream );
}
Output
File pointer is set to middle of first line. This is the file 'fseek.out'.