Full text search for "test"
- 20120402_fpga_fft . . . . 2 matches
1. 전체 fft C 코드 위치 ~/test_c/fft_ver0.1
1. 부분적인 자료 추출을 위한 테스트 코드 위치 ~/test_c/mis/main.c
- BlogChanges . . . . 1 match
test
- CalendarMacro . . . . 1 match
{{{#!blog wskim 2010-12-03T04:29:57 test
- FortuneCookies . . . . 1 match
* Courage is your greatest present need.
- HelpOnMacros . . . . 1 match
[[Include(test)]]
- LAPACK . . . . 2 matches
gfortran -o test test.f90 -llapack -lblas
- Linux_device_module_basic . . . . 48 matches
printk("test module ver 0.1\n");
printk("end of test module\n");
obj-m := test.o
'''insmod test.ko'''
'''remod test'''
#define DRVNAME "test_dev"
int test_open(struct inode *inode, struct file *filp)
int test_release(struct inode *inode, struct file *filp)
ssize_t test_read(struct file *filp, const char *buf, size_t count, loff_t *f_pos)
ssize_t test_write(struct file *filp, const char *buf, size_t count, loff_t *f_pos)
int test_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg)
struct file_operations test_fops =
.open = test_open,
.read = test_read,
.write = test_write,
.ioctl = test_ioctl,
.release = test_release,
printk("test driver inint..\n");
result = register_chrdev(DRVMAJOR, DRVNAME, &test_fops);
printk("test driver inint fail\n");
- Linux_iconv파일의언어설정변경Iconv설명 . . . . 2 matches
iconv -c -f euckr -t utf8 test_euckr.sql > test_utf8.sql
- Linux_pci_driver_example . . . . 1 match
obj-m := test.o
- LocalKeywords . . . . 15 matches
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
test WymSkPhN
- LocalKeywords/CommonWords . . . . 1 match
test
- LocalKeywords/CommonWordsKo . . . . 2 matches
test
test'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'
- MLA_SM . . . . 1 match
||generalization ||test set performance ||
- MariaDB . . . . 1 match
Remove test database and access to it? [Y/n] Y
- WikiSandBox . . . . 4 matches
This is a *test*.
This is a *test*.
테스트 위키!! attachment:276380_2.jpg Save test. zd TEST
[[Clip(test)]]
- arXiv_1911 . . . . 26 matches
Below, we describe a variant of the method, called Elastic-net based Machine-learning for Understanding (EMU method or method thereafter), we use to identify glitches in Sec. II; we show the results of testing this method on recent LIGO data in Sec. III; and we discuss the results in Sec. IV.
We use the Omicron [7] event trigger generator to identify glitch times for training and testing our model. (Once trained, our model is fully independent of Omicron and the strain data; it considers only parameters computed from auxiliary channels, as described below.) Omicron analyzes low-latency strain data to find events of excess power and reports parameters of these glitches, including start time, peak time, and duration.
Most machine learning techniques assume that each feature is on approximately the same scale; otherwise, features whose raw values are large in magnitude would dominate the others. A standard normalization procedure is to replace raw values with their standard score (i.e., the number of standard deviations away from the training mean that the raw value falls), so each feature has zero mean and unit standard deviation over the training set [31, 32]. For each analysis under consideration, we compute the mean and standard deviation over the training set; then for every point in the training, validation, and test sets, we subtract the mean and divide by the standard deviation of that feature in the training set.
Given a set of n training data points in p dimensions (i.e., each data point has p features) and n correspond- ing binary labels (the ground truth), a logistic regression model is trained by iteratively minimizing the residual error between the predicted class probability of the training data and ground truth. The trained model consists of a set of p coefficients (or “weights”) w and a bias term b; the dot product of these coefficients and a test data point plus the bias term is passed through a logistic function to obtain an estimate of the probability that the point should be classified 0 or 1.
We performed a grid search across a range of both parameters using data from LIGO Livingston Observatory (LLO) during ER14 and evaluated the results on a held-out validation dataset drawn from a separate period of time (see Fig. 3). Using a validation dataset separate from both the training set and the test set on which we report our results allows us to choose hyperparameters that will generalize well to unseen data without overfitting- ting to our training or test data [31, 32].
We use the EMU method described above to classify glitchy and glitch-free times for several recent segments of data from LLO. We show two test cases from different, recent runs: one from a locked segment during ER14, and a second from a locked segment during O3.
The classifier model for each analysis was trained independently using data drawn from a time period close to but not overlapping with the time period from which the test dataset for that analysis was drawn. We do not perform hyperparameter optimization as we did for ER14 in Sec. II E again for O3, because the procedure is computationally intensive and the similar nature of the data means the optimal hyperparameters would likely not be significantly different.
For each analysis, we create a test dataset drawn from a period of time separate from the training dataset (and, in the case of ER14, separate from the validation dataset as well), as illustrated in Fig. 3. We standardize the test dataset according to the means and standard deviations of the features in the training dataset. We then pass the test dataset through the classifier without labels and compare the predictions to the known ground truth for each point. For each incorrect classification, we can specify whether the result is a false positive (a glitch-free time classified as glitchy) or a false negative (a glitchy time classified as glitch-free).
At the default decision threshold of 0.5, the accuracy on the ER14 test dataset is 83.8%, with a true positive rate of 73.0% and a true negative rate of 94.6%. The accuracy on the O3 test dataset is 79.9%, with a true positive rate of 62.1% and a true negative rate of 97.7%. We also show the overall accuracy, true positive rate, and true negative rate over time during the test periods for each analysis in Figs. 7 and 9.
If we restrict our analysis in training and testing to glitches with a signal-to-noise ratio (SNR) at or above 6, we achieve an overall accuracy of 88.2% for ER14 and 90.3% for O3, with true positive rates of 80.8% and 86.7%, and true negative rates of 95.4% and 93.8% respectively. (The minimum SNR reported by Omicron is 5; roughly 30% of glitches have an SNR at or above 6.) The corresponding ROC curves are displayed in Fig. 6.
For the ER14 test analysis, we use the trained classifier model that performed best on the ER14 validation dataset used for hyperparameter optimization, as described in Sec. IIE. The training dataset is therefore the same as described there. Recall that to create this dataset we sampled 7,500 glitch-free points in time (as described in Sec. IIB) and 7,500 of the 30,141 Omicron glitches during the period between GPS times 1,235,870,000 and 1,235,900,000. After preliminary data reduction as described in Sec. II A, the number of channels considered was 38,235, so the training and test datasets have 382,350 features.
The test data is drawn from 9,616 seconds between GPS times 1,235,910,000 and 1,235,919,616. We sampled 2,500 glitch-free points in time and 2,500 of the 6,479 Omicron glitches during that period, chosen at random. As with the training, we also ignored any samples falling too close to the beginning or end of a 64-second raw frame file. The classifier achieves an accuracy of 83.8% on this test dataset, with a true positive rate of 73.0% and a true negative rate of 94.6%.
The classifier’s accuracy, true positive rate, and true negative rate over time in the test period are shown in Fig. 7. This result indicates that the performance is relatively consistent over time, but may be affected by transient changes in the state of the detector that was not seen during training.
For the O3 analysis, we trained a new classifier on a training dataset drawn from 10,000 seconds during April 10, 2019 (GPS times 1,238,900,000 to 1,238,910,000). We used a smaller amount of time for the training period for this analysis because the results shown in Fig. 5 indicate that 10,000 seconds of training data is sufficient for good performance. Similar to the ER14 training dataset, we sampled 2,500 glitch-free points in time and 2,500 of the 8,098 Omicron glitches during that period, chosen at random, and we ignored any samples falling too close to the beginning or end of a 64-second raw frame file. After preliminary data reduction as described in Sec. II A, the number of channels considered is 38,327, so the training and test datasets have 383,270 features.
The test data is drawn from 30,000 seconds between GPS times 1,238,910,000 and 1,238,940,000. We sampled 7,500 glitch-free points in time and 7,500 of the 24,243 Omicron glitches during that period, chosen at random, and we ignored any samples falling too close to the beginning or end of a 64-second raw frame file. The classifier achieves an accuracy of 79.9% on this test dataset, with a true positive rate of 62.1% and a true negative rate of 97.7%.
The accuracy, true positive rate, and true negative rate overtime during the test period are shown in Fig. 9. As with ER14, this result indicates that the performance is relatively consistent over time, but there is a visible dip in true negative rate and corresponding dip in accuracy soon after the beginning of the test period, suggesting some nonstationarity in the data or the state of the detector. This is not surprising, especially since the model was trained on only about three hours of data; it should be taken into account that this method would likely become increasingly susceptible to such issues the less training data it sees and the more time has passed since the training.
We divided the ER14 training dataset into 10 subsets (10 were chosen arbitrarily) identified by k-means and trained 10 elastic net logistic regression classifiers, using one of the glitch subsets as the positive class and all glitch-free samples as the negative class for each classifier. For testing, we then used the cluster centroids computed on the training set to assign each data point of the ER14 validation dataset to one of the 10 classes and evaluated the performance of each classifier on its corresponding validation subset. The results are shown in Fig. 10.
- auxcam_job . . . . 7 matches
attachment:confusion_train.png?width=500px attachment:confusion_test.png?width=500px
|| || training set || test set ||
||50 epoch || attachment:confusion_ownweight_train.png?width=500px || attachment:confusion_ownweight_test.png?width=500px ||
||100 epoch || attachment:confusion_ownweight100_train.png?width=500px || attachment:confusion_ownweight100_test.png?width=500px ||
|| 150 epoch || attachment:confusion_ownweight150_train.png?width=500px || attachment:confusion_ownweight150_test.png?width=500px ||
|| || training set || test set ||
||150 epoch || attachment:confusion_shareDoubleweight_train.png?width=500px || attachment:confusion_shareDoubleweight_test.png?width=500px ||
- batch_normalization . . . . 2 matches
이 중 Covariate Shift는 이러한 머신러닝에서 나타나는 Shift 타입이다. training 과 test의 dataset의 분포가 다룰 수 있다. 실제 응용에서 trainging dataset을 이용해서 학습을 진행하고 실제 문제에 적용했을 경우 흔하게 발생할 수 있다. [* ''Kaggle - Covariate shift'', <https://www.kaggle.com/pavansanagapati/tutorial-covariate-shift-sberbank-housing-eda>]
= Training과 Test 차이 =
mnist_test = dsets.MNIST(root='MNIST_data/', train=True, download=True, transform=transforms.ToTensor())
- big_file_copy . . . . 1 match
(tar cvf - .) | (ssh nims_gpu "cd /mnt/sda1/test/DangGi; tar xvfp -")
- caffe_installation . . . . 3 matches
python setup.py test
make test
make runtest
- cockpit . . . . 1 match
https://cockpit-project.org/guide/latest/cockpit.conf.5
- cprogramming_file_inout . . . . 2 matches
if ( ( f = fopen("test.txt", "w") ) == NULL )
if ( (in = fopen("test.txt", "rt")) == NULL) {
- cv_report1 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- cv_report2 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- cv_report3 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- data_mining_weka . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- data_mining_weka2 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
Test mode: Classes to clusters evaluation on training data
Test mode: Classes to clusters evaluation on training data
Test mode: Classes to clusters evaluation on training data
Test mode: Classes to clusters evaluation on training data
- debian_release_info . . . . 5 matches
데비안은 stable, testing, unstable로 구분해서 릴리스[[footnote(http://www.debian.org/releases/index.ko.html)]]를 공개한다.
'''testing'''
testing 배포본은 stable 릴리스에 아직 들어가지 않았지만 곧 들어갈 패키지를 포함하고 있습니다. 이 배포본을 사용해서 얻을 수 있는 이점은 더 많은 최신 소프트웨어를 사용할 수 있다는 것입니다.
testing이란 무엇인가와 어떻게 stable이 되는가에 관한 더 자세한 정보는 데비안 FAQ를 보세요.
현재 testing 배포본은 wheezy입니다.
- docker_influxdb . . . . 10 matches
image: bitnami/influxdb:latest
-e DOCKER_INFLUXDB_INIT_BUCKET=test-bucket \
-e DOCKER_INFLUXDB_INIT_BUCKET=test-bucket \
docker run -d -p 8086:8086 --name influxdb -v $PWD/data:/var/lib/influxdb2 -v $PWD/config:/etc/influxdb2 -e DOCKER_INFLUXDB_INIT_MODE=setup -e DOCKER_INFLUXDB_INIT_USERNAME=wskim -e DOCKER_INFLUXDB_INIT_PASSWORD=kims1028 -e DOCKER_INFLUXDB_INIT_ORG=my-org -e DOCKER_INFLUXDB_INIT_BUCKET=test-bucket -e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=my-secret-token influxdb
create database test_db
use test_db
insert test_table,text=abcd,name=wskim value=1,number1=1,number2=2
위와 같이 데이터베이스와 measurement (test_table)을 생성했다. 여기서 tag key와 field key를 알아보자.
show tag key from test_table
show field key from test_table
- docker_mongodb . . . . 5 matches
Using default tag: latest
latest: Pulling from library/mongo
Status: Downloaded newer image for mongo:latest
docker.io/library/mongo:latest
mongo latest 07630e791de3 12 days ago 449MB
- docker_redis . . . . 1 match
redis latest c8ac0a9bed1d 3 months ago 140MB
- docker_tutorial . . . . 8 matches
wget https://get.docker.com/builds/Linux/x86_64/docker-latest -O /usr/bin/docker
centos latest dade6cb4530a 4 days ago 210.1 MB
Status: Downloaded newer image for ubuntu:latest
centos latest dade6cb4530a 4 days ago 210.1 MB
ubuntu latest 5ba9dab47459 13 days ago 188.3 MB
14.04/moniwiki latest bafa3bf04806 24 seconds ago 261.5 MB
centos latest dade6cb4530a 4 days ago 210.1 MB
ubuntu latest 5ba9dab47459 13 days ago 188.3 MB
- dsp_report10 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- dsp_report7 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- dsp_report8 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- dsp_report9 . . . . 1 match
[[HTML(<div class="test" align="right"><h3>컴퓨터 공학과 201760112 김환선</h1></div>)]]
- earthquakeWithAI . . . . 2 matches
'''Earthquakes and seismic station in the region of interest (near Guthrie, OK) from 14 February 2014 to 16 November 2016.''' GS.OK029 and GS. OK027 are the two stations that record continuously the ground motion velocity.The colored circles are the events in the training data set. Each event is labeled with its corresponding area. The thick black lines delimit the six areas. The black squares are the events in the test data set. Two events from the test set are highlighted because they do not belong to the same earthquake sequences and are nonrepeating events.
- fileroom . . . . 1 match
[[UploadedFiles(test)]]
- fpga_index . . . . 1 match
* [:fpga_test_guide FPGA 프로젝트 설치 및 테스트 가이드]
- fpga_tutorial . . . . 2 matches
module test_main(
module test_main # (
- gw_ml_review . . . . 4 matches
attachment:data_point.png?'''[[br]]그림''' 1. ''The figure shows how the training and testing points were chosen.''
attachment:result1.png?'''[[br]]그림''' 5. ''Left panel: Confusion matrix of classifier A on a test set having SNR = 0.5 (the accuracy is 94.7%). Note that this classifier never obtains false positives. Right panel: Confusion matrix of classifier A on a test set having SNR = 0.6 (the accuracy is 100% for all signals with SNR ≥ 0.6.)''
attachment:result2.png?'''[[br]]그림''' 6. ''Left panel: Confusion matrix of classifier B on a test set having SNR = 0.5 (the accuracy is 99.8%). Right panel: Accuracy of classifier B as a function of SNR. Unlike classifier A, the accuracy of classifier B at SNR ≥ 0.7 saturates at approximately 99.89%, due to the constant rate of false detections.''
- hawkes_process . . . . 1 match
반면, Hawkes process에서는 각 구간 \(t\)에 대해서 다른 \(\lambda^*(t)\)를 갖는다. [* https://hawkeslib.readthedocs.io/en/latest/tutorial.html]
- iEEG_seizure . . . . 2 matches
ftest = np.zeros(0)
ftest = np.concatenate((fdata,signal.filtfilt(b, a, wdata[i])))
- index_2016 . . . . 1 match
2. [:bandwidth_test AMD OpenCL 최적화 ]
- julia . . . . 13 matches
(@v1.8) pkg> generate test
Generating project test:
test/Project.toml
test/src/test.jl
(@v1.8) pkg> activate test
Activating project at `~/work/julia/test`
(test) pkg> add CSV
Updating `~/work/julia/test/Project.toml`
Updating `~/work/julia/test/Manifest.toml`
(test) pkg> status
Project test v0.1.0
Status `~/work/julia/test/Project.toml`
- kubernetes . . . . 1 match
https://blog.alexellis.io/test-drive-k3s-on-raspberry-pi/
- lecture_note_machine_learning_exercise . . . . 2 matches
leave one out cross validation(LOOCV)은 샘플 수 만큼 모델을 만들고, 각 모델을 만들 때에 하나의 샘플만 제외하면서 그 제외한 샘플로 Test set performace를 계산하여 평균을 내는 방법이다.
'''B. What is the mean squared test set error of running a linear regression on this data, assuming the rightmost three points are in the test set, and the others are in the training set.
- linux_compiler_assembler_process . . . . 27 matches
-- end of test1.c
-- start of test2.c
위 의 예제를 컴파일 한다고 생각해보자. test1.c에서 func1()의 내용을 기계어로 바꾸고 싶은데 func2()를 호출하는 시점에서는 별로 문제가 안된다. func2()는 같은 소스 코드 내에 존재하고 func2()를 호출하는 instruction과 func2()의 실제 위치(어드레스)의 차이를 계산해 낼 수 있으므로 상대 어드레스를 이용하는 함수 호출 instruction으로 완전히 기계어로 바꿀 수 있다. 그런데 문제는 func3()를 호출할 때는 func3()의 실제 위치(address)를 계산할 수 없다는 문제점이 있다. 당연히 동일한 파일에 존재하는 함수가 아니므로 그 함수가 존재하게 될 어드레스를 계산할 수 없다. 어드레스를 모르는데 함수 호출 instruction을 완전히 만들 수 있을까? 만들 수 없다. 당연히 전역 변수 mydata를 access하는 부분도 마찬가지로 mydata의 어드레스를 모르므로 완전히 instruction으로 바꿀 수 없다. 그럼 어떻게 해야 될까?
그때 assembler는 그냥 함수 어드레스 없는 함수 호출 instruction을 기계어로 바꾸어 놓는다. 그런 다음에 그 instruction에 “func3()를 호출한다”라는 표지를 붙여 놓는다. 그럼 그 후의 과정(linking)에서 func3()의 address를 계산했을 때 그 빈 공간을 채워 넣게 된다. mydata와 같은 전역 변수도 마찬가지로 동작한다. test1.c을 컴파일할 때는 “func3()”, “mydata” 라는 표지를 사용해야 한다. 그럼 test2.c를 컴파일 할 때는 무엇이 필요할까? 상식적으로 생각하면 “func3()”, “mydata”가 여기 있다라는 정보를 가지고 있어야한다.
정리하면 object 파일 안에는 그 object 파일에 들어있는 symbol들(test1.o에서는 func1과 func2, test2.o에서는 func3와 mydata)에 대한 정보가 들어있고, 그 object 파일이 reference하고 있는 symbol들(test1.o에서 func3와 mydata 사용)에 대한 정보가 들어 있다.
위 에서 object 코드라고 하지 않고 relocatable object 코드라고 지칭했는데 relocatable이 뜻하는 것을 잠시 집고 넘어 가자. Relocatable을 사전에서 찾아보면 “재배치가 가능한” 정도의 뜻이다. “재배치가 가능한” 이라는 의미는 상당히 모호하다. 좀 더 구체적으로 말하자면 위에서 설명된 symbol들의 절대 어드레스가 정해지지 않았다는 뜻이다. 즉 test1.c의 func1()이 절대 어드레스 0x80000000에 존재해야 한다라고 정해지지 않고 어떤 절대 어드레스에 존재해도 관계 없다는 뜻이다. 그런데 이 말과 헷갈리는 말이 한가지 더 있는데 그것은 position independent code이다. C 언어 컴파일 과정에서 설명한 옵션중에 -f 시리즈가 있었다. 그 중에 -fpic라는 position independent code를 만들라고 강제하는 옵션이 있다. position independent code도 역시 절대 어드레스상에 어느 위치에 있어도 무방한 code를 지칭한다. 하지만 두 가지는 분명 차이가 있는데, 그냥 넘어가기로 하자. 쉽게 relocatable은 절대 어드레스가 결정되지 않았다는 뜻, 그러나 position independent code와는 다른 말이다.
test2.o(size 0x3000)
test1.o(size 0x2000)
절 대 address 0xAAAAAAAA에 test1.o의 내용을 가져다 놓는다. test1.o의 크기(파일 크기와는 의미가 조금 다르지만 그냥 무시하고 파일 크기라고 생각하기 바람)가 0x2000이므로 다음에 test2.o를 쌓을 수 있는 address는 0xAAAAAAAA+0x2000가 된다. 그곳에 다시 test2.o를 쌓고 또 test2.o의 크기를 보고 새로운 address 계산하고 또 object 코드 쌓고, 계속 반복이다. 이렇게 쌓을 때 초기 절대 address 0xAAAAAAAA가 무슨 값을 가지게 되면 모든 object 파일에 있는 symbol의 절대 address도 계산해 나갈 수 있을 것이다. 그걸로 symbol reference를 resolve하게 된다. 그 초기 절대 address 0xAAAAAAAA의 값을 정하는 것을 location이라고 한다. 그럼 왜 절대 address를 결정해야 할까? 꼭 그래야 할 필요는 없지만 CPU의 instruction이 대부분의 경우 절대 address를 필요로 하는 경우가 많기 때문이라고 할 수 있다.
보 통의 경우는 아니지만 사용자가 직접 assembly 코딩을 하는 경우가 종종 있다. 아무래도 사람이 기계보다는 훨씬 똑똑하기 때문에 사람이 직접 assembly 코딩을 해서 최적화를 시도하여 소프트웨어의 수행 시간을 단축시키거나, 아니면 linux kernel이나 bootloader 등과 같이 꼭 assembly가 필요한 경우가 있다. 이때도 보통의 경우는 소프트웨어의 전 부분을 assembly 코딩하는 것이 아니라 특정 부분만 assembly 코딩을 하고 나머지는 C 언어나 다른 high-level 프로그래밍 언어를 써서 서로 연동을 하도록 한다. 그럼 C 언어에서 assembly 코딩된 함수를 호출할 때(반대의 경우도 마찬가지), 함수의 argument는 어떻게 전달되는 지, 함수의 return 값은 어떻게 돌려지는지 등을 알아볼 필요가 있다. 이렇게 argument와 return 값의 전달은 CPU architecture마다 다르고 그것을 일정한 약속(convention)에 따라서 처리해 주게 된다. 위의 hello.s를 i386용 gcc로 만들었다면 파일 중간에 xorl %eax,%eax라는 것이 보일 것이다. 자기 자신과 exclusive or를 수행하면 0(zero)이 되는데 이것이 바로 hello.c에서 return 0를 assembly 코드로 바꾼 것이다. 결국 i386 gcc에서는 %eax 레지스터에 return 값을 넣는다는 convention이 있는 것이다.(실제로는 gcc뿐 아니라 i386의 convention으로 convention을 따르는 모든 compiler가 %eax 레지스터를 이용하여 return값을 되돌린다.) argument의 경우도 test용 C 소스를 만들어서 살펴볼 수 있을 것이다. 물론 해당 CPU architecture의 assembly 소스코드를 어느 정도 읽을 수 있는 사람들에게만 해당하는 이야기 이다. stack frame도 비슷한 얘기 쯤으로 알아 두길 바란다.
전처리 파일 생성 명령은 gcc -E -o test.i test.c 입니다.
어셈 파일 생성 명령은 gcc -S -o test.s test.c 입니다.
오브젝트 파일 생성 명령은 gcc -c -o test.o test.c 입니다.
마지막으로 링크과정을 거쳐 실행파일을 만듭니다. gcc -g -o test test.c
gcc -v --save-temps -o test test.c
- linux_iconv . . . . 2 matches
iconv -c -f euckr -t utf8 test_euckr.sql > test_utf8.sql
- linux_index . . . . 1 match
[test]
- linux_programming_EXPORT_SYMBOL . . . . 2 matches
void check_test(int a)
EXPORT_SYMBOL(check_test);
- linux_smbfs_mount . . . . 7 matches
사용자 이름 : testuser
공유폴더 : cifs-test
마운트 경로 : /mount-test
mount -t cifs -o user='testuser',password='1234' //192.168.0.2/cifs-test /mount-test
//192.168.1.30/smb /test cifs defaults,username=smb,pass=비밀번호적기,iocharset=utf8 0 0
- linux_ubunt_subversion . . . . 5 matches
svn import -m "importing test project" . file://home/svn/test
M test.c
svn diff test.c
svn diff --diff-cmd meld test.c
- math_liner_algebra . . . . 2 matches
* When it’s installed, it tests and times a variety of approaches approaches to each routine and selects the version that to each routine, and selects the version that
runs the fastest.
- minepy . . . . 1 match
http://minepy.readthedocs.io/en/latest/
- multi_GPU_pytorch . . . . 1 match
https://pytorch-lightning.readthedocs.io/en/latest/multi_gpu.html
- multiprocessing . . . . 1 match
Multiprocessing을 사용하게 되면 프로세스 생성하여 계산을 수행하게 되는데 이 경우 각 프로세스별로 독립적인 메모리를 사용하기 때문에 프로세스간 데이터를 공유하기 위한 방법이 필요하다. 그 방법 중에 하나로 Shared Memory가 있는데[* https://mingze-gao.com/posts/python-shared-memory-in-multiprocessing/#test-result] 아래 코드는 이 Shared Memory를 테스트한 것이다.
- nextcloud.conf . . . . 2 matches
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
- nextcloud_ssl.conf . . . . 2 matches
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
- numerical_analysis_note . . . . 1 match
'''정리 3.1)''' 와이어스트라스[* Karl Weierstrass (1815~1897) ) is often referred to as the father of modern analysis because of his insistence on rigor in the demonstration of mathematical results. He was instrumental in developing tests for convergence of series, and determining ways to rigorously define irrational numbers. He was the first to demonstrate that a function could be everywhere continuous but nowhere differentiable, a result that shocked some of his contemporaries.] 다항식 근사 정리(Weierstrass Approximation Theorem)
- pci_interface_review . . . . 1 match
[:bandwidth_test AMD 메모리 객체 최적화]
- programming_cli_ex . . . . 1 match
printf("\t\thello {num} : test command\n");
- programming_function_point . . . . 7 matches
void f1(int c, char* test)
void f2(int c, char* test)
void f3(int c, char* test)
void f4(int c, char* test)
printf("f4 %d %s\n", c, test);
char test[10]="hello";
k[3](uni.a,test);
- programming_gcc_multi_version . . . . 1 match
$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
- programming_library . . . . 20 matches
[root@localhost test]# gcc -c mysum.c
[root@localhost test]# ar rc libmysum.a mysum.o
[root@localhost test]# gcc -o print_sum print_num.c -L./ -lmysum
[root@localhost test]# gcc -fPIC -c mysum.c
[root@localhost test]# gcc -shared -W1,-soname,libmysum.so.1 -o libmysum.so.1.0.1 mysum.o
[root@localhost test]# cp libmysum.so.1.0.1 /usr/local/lib
[root@localhost test]# ln -s /usr/local/lib/libmysum.so.1.0.1 /usr/local/lib/libmysum.so
[root@localhost test]# ln -s /usr/local/lib/libmysum.so.1.0.1 /usr/local/lib/libmysum.so # gcc 링크를 위한 파일
[root@localhost test]# ln -s /usr/local/lib/libmysum.so.1.0.1 /usr/local/lib/libmysum.so.1 # 동적 링크를 위한 파일
[root@coco test]# gcc -o print_sum print_sum.c -L/usr/local/lib -lmysum
[root@localhost test]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/my/lib
[root@localhost test]# cat /usr/my/lib >> /etc/ld.so.conf
[root@localhost test]# ldconfig
[root@localhost test]# gcc -o print_sum_dl print_sum_dl.c -ldl
[root@localhost test]# ./print_sum_dl
[root@localhost test]#
[root@localhost test]# gcc -c -fPIC mymulti.c
[root@localhost test]# gcc -shared -W1,-soname,libmymulti.so.1 -o libmymulti.so.1.0.1 mymulti.o
[root@localhost test]# ./print_sum_dl
[root@localhost test]# ./print_sum_dl
- programming_sh_copy . . . . 2 matches
if [ ! -f ./test ]; then
touch test
- python_c_c++ . . . . 2 matches
list World::test(list l)
void test(boost::python::object &obj_ptr,int n)
- python_chat_program . . . . 8 matches
sqlite> insert into name_table (name) values ('test');
sqlite> insert into passwd_table (uid, passwd) select uid, "passwd_test" from name_table where name="test";
sqlite> select t2.name, t1.passwd from passwd_table t1 inner join name_table t2 on t1.uid = t2.uid where t2.name='test';
test|passwd_test
간단한 예제로 사용자에 해당하는 테이블을 만들고 각각의 사용자의 Password를 저장하는 테이블을 name_table, passwd_table 이라는 이름으로 만들어 보고 "wskim", "test" 두 명의 사용자를 생성하고 각각의 Password를 넣어주고 "test" 사용자의 Password를 확인하는 과정을 기술해 보았습니다.
- pytorch_exeample_mnist_grad_cam . . . . 4 matches
mnist_test = dset.MNIST("./", train=False,
test_loader = torch.utils.data.DataLoader(mnist_test,batch_size=batch_size, shuffle=True,num_workers=2,drop_last=True)
for image,label in test_loader:
print("Test Data Accuracy: {}%".format(100*(top_1_count/total).numpy()))
- raspberry_pi_dht22 . . . . 2 matches
$ wget https://project-downloads.drogon.net/wiringpi-latest.deb
$ sudo dpkg -i wiringpi-latest.deb
- raspberry_pi_ntp_server . . . . 1 match
sudo ppstest /dev/pps0
- raspberry_pi_sensor . . . . 2 matches
$ wget https://project-downloads.drogon.net/wiringpi-latest.deb
$ sudo dpkg -i wiringpi-latest.deb
- roc_curves . . . . 5 matches
attachment:test.png?title='''[[br]]그림''' 1. ''Test Result''
'''Positive likelihood ratio''' : ratio between the probability of a positive test result given the presence of the disease and the probability of a positive test result given the absence of the disease, i.e.
'''Negative likelihood ratio''' : ratio between the probability of a negative test result given the presence of the disease and the probability of a negative test result given the absence of the disease, i.e.
- rust_language . . . . 1 match
* GPIO [* https://docs.rs/gpio/latest/gpio/]
- slack_api_chatbot . . . . 1 match
message = "Hello, this is a test message from Python!" # 보낼 메시지
- test . . . . 3 matches
attachment:test/Circle_r=1.svg.png?width=300px&align=center&title="hello"
== MoniWiki:test/ex1 ==
== [:test/ex2 /ex2] ==
- test2 . . . . 17 matches
보 통의 경우는 아니지만 사용자가 직접 assembly 코딩을 하는 경우가 종종 있다. 아무래도 사람이 기계보다는 훨씬 똑똑하기 때문에 사람이 직접 assembly 코딩을 해서 최적화를 시도하여 소프트웨어의 수행 시간을 단축시키거나, 아니면 linux kernel이나 bootloader 등과 같이 꼭 assembly가 필요한 경우가 있다. 이때도 보통의 경우는 소프트웨어의 전 부분을 assembly 코딩하는 것이 아니라 특정 부분만 assembly 코딩을 하고 나머지는 C 언어나 다른 high-level 프로그래밍 언어를 써서 서로 연동을 하도록 한다. 그럼 C 언어에서 assembly 코딩된 함수를 호출할 때(반대의 경우도 마찬가지), 함수의 argument는 어떻게 전달되는 지, 함수의 return 값은 어떻게 돌려지는지 등을 알아볼 필요가 있다. 이렇게 argument와 return 값의 전달은 CPU architecture마다 다르고 그것을 일정한 약속(convention)에 따라서 처리해 주게 된다. 위의 hello.s를 i386용 gcc로 만들었다면 파일 중간에 xorl %eax,%eax라는 것이 보일 것이다. 자기 자신과 exclusive or를 수행하면 0(zero)이 되는데 이것이 바로 hello.c에서 return 0를 assembly 코드로 바꾼 것이다. 결국 i386 gcc에서는 %eax 레지스터에 return 값을 넣는다는 convention이 있는 것이다.(실제로는 gcc뿐 아니라 i386의 convention으로 convention을 따르는 모든 compiler가 %eax 레지스터를 이용하여 return값을 되돌린다.) argument의 경우도 test용 C 소스를 만들어서 살펴볼 수 있을 것이다. 물론 해당 CPU architecture의 assembly 소스코드를 어느 정도 읽을 수 있는 사람들에게만 해당하는 이야기 이다. stack frame도 비슷한 얘기 쯤으로 알아 두길 바란다.
-- end of test1.c
-- start of test2.c
위 의 예제를 컴파일 한다고 생각해보자. test1.c에서 func1()의 내용을 기계어로 바꾸고 싶은데 func2()를 호출하는 시점에서는 별로 문제가 안된다. func2()는 같은 소스 코드 내에 존재하고 func2()를 호출하는 instruction과 func2()의 실제 위치(어드레스)의 차이를 계산해 낼 수 있으므로 상대 어드레스를 이용하는 함수 호출 instruction으로 완전히 기계어로 바꿀 수 있다. 그런데 문제는 func3()를 호출할 때는 func3()의 실제 위치(address)를 계산할 수 없다는 문제점이 있다. 당연히 동일한 파일에 존재하는 함수가 아니므로 그 함수가 존재하게 될 어드레스를 계산할 수 없다. 어드레스를 모르는데 함수 호출 instruction을 완전히 만들 수 있을까? 만들 수 없다. 당연히 전역 변수 mydata를 access하는 부분도 마찬가지로 mydata의 어드레스를 모르므로 완전히 instruction으로 바꿀 수 없다. 그럼 어떻게 해야 될까?
그때 assembler는 그냥 함수 어드레스 없는 함수 호출 instruction을 기계어로 바꾸어 놓는다. 그런 다음에 그 instruction에 “func3()를 호출한다”라는 표지를 붙여 놓는다. 그럼 그 후의 과정(linking)에서 func3()의 address를 계산했을 때 그 빈 공간을 채워 넣게 된다. mydata와 같은 전역 변수도 마찬가지로 동작한다. test1.c을 컴파일할 때는 “func3()”, “mydata” 라는 표지를 사용해야 한다. 그럼 test2.c를 컴파일 할 때는 무엇이 필요할까? 상식적으로 생각하면 “func3()”, “mydata”가 여기 있다라는 정보를 가지고 있어야한다.
정리하면 object 파일 안에는 그 object 파일에 들어있는 symbol들(test1.o에서는 func1과 func2, test2.o에서는 func3와 mydata)에 대한 정보가 들어있고, 그 object 파일이 reference하고 있는 symbol들(test1.o에서 func3와 mydata 사용)에 대한 정보가 들어 있다.
위 에서 object 코드라고 하지 않고 relocatable object 코드라고 지칭했는데 relocatable이 뜻하는 것을 잠시 집고 넘어 가자. Relocatable을 사전에서 찾아보면 “재배치가 가능한” 정도의 뜻이다. “재배치가 가능한” 이라는 의미는 상당히 모호하다. 좀 더 구체적으로 말하자면 위에서 설명된 symbol들의 절대 어드레스가 정해지지 않았다는 뜻이다. 즉 test1.c의 func1()이 절대 어드레스 0x80000000에 존재해야 한다라고 정해지지 않고 어떤 절대 어드레스에 존재해도 관계 없다는 뜻이다. 그런데 이 말과 헷갈리는 말이 한가지 더 있는데 그것은 position independent code이다. C 언어 컴파일 과정에서 설명한 옵션중에 -f 시리즈가 있었다. 그 중에 -fpic라는 position independent code를 만들라고 강제하는 옵션이 있다. position independent code도 역시 절대 어드레스상에 어느 위치에 있어도 무방한 code를 지칭한다. 하지만 두 가지는 분명 차이가 있는데, 그냥 넘어가기로 하자. 쉽게 relocatable은 절대 어드레스가 결정되지 않았다는 뜻, 그러나 position independent code와는 다른 말이다.
test2.o(size 0x3000)
test1.o(size 0x2000)
절 대 address 0xAAAAAAAA에 test1.o의 내용을 가져다 놓는다. test1.o의 크기(파일 크기와는 의미가 조금 다르지만 그냥 무시하고 파일 크기라고 생각하기 바람)가 0x2000이므로 다음에 test2.o를 쌓을 수 있는 address는 0xAAAAAAAA+0x2000가 된다. 그곳에 다시 test2.o를 쌓고 또 test2.o의 크기를 보고 새로운 address 계산하고 또 object 코드 쌓고, 계속 반복이다. 이렇게 쌓을 때 초기 절대 address 0xAAAAAAAA가 무슨 값을 가지게 되면 모든 object 파일에 있는 symbol의 절대 address도 계산해 나갈 수 있을 것이다. 그걸로 symbol reference를 resolve하게 된다. 그 초기 절대 address 0xAAAAAAAA의 값을 정하는 것을 location이라고 한다. 그럼 왜 절대 address를 결정해야 할까? 꼭 그래야 할 필요는 없지만 CPU의 instruction이 대부분의 경우 절대 address를 필요로 하는 경우가 많기 때문이라고 할 수 있다.
- usb_driver . . . . 1 match
name: "usb test",
- work2012_09_list . . . . 1 match
test.c 파일을 생성하고 double real image 형식의 txt 파일을 읽어 single로 출력 하도록
- work2020_01_list . . . . 10 matches
however, i do not think it is a 'problem' of numpy, but rather a design decision. accordingly to numpy's own test/demo code(here), the macro import_array and import_ufunc are meant to be used directly in the top-level module function, that is, initxxx or PyInit_xxx, not to be wrapped in another function, for example, boost::numpy::initialize/wrap_import_array in our scenario. with python2, initxxx requires no return value, so the macro import_array returns nothing in the if branch, with python3, PyInit_xxx requires a return type of PyObject*, so import_array returns NULL, pretty reasonable.
-T, --notest build without running tests in %test section
post, files, environment, test, labels, none)
From: tensorflow/tensorflow:latest
%test
echo "Define any test commands that should be executed after container has been"
$ singularity build /tmp/debian1.sif library://debian:latest
$ singularity build --sandbox /tmp/debian docker://debian:latest
- work_mmpc_update . . . . 2 matches
[[UploadFile(test)]]
[[UploadedFiles(test)]]
Found 81 matching pages out of 776 total pages
You can also click here to search title.
Whansun`s Deep learning Wiki