白駿2480号

-質問

-解答1

これは私が初めて考えた結果です.

-解答2

3つの数字が異なる場合は、for문을 통해 처리のために
int配列を使用しました.有意差は認められなかった.
正直、白俊の속도測定は信用できない.
同じコードも、コミット時間によって異なる속도が表示されます.
そのため、どのコードがより速く、より役に立つかを知る必要があります.
妥当でない
データ量が小さい場合、
だから基礎知識がなければ백준의 결과を성능, 속도に変えます.
判断が難しい.
実際には、最初にcountTokensをforクエリの条件として使用します.

しかし、それを実行すると、正常に動作しません.

条件文が間違っているかどうか、コードに誤字があるかどうかなど
異常運転の原因は何ですか?
従って、上記の実行結果はいずれもa,b,cである
同じ場合は、条件は実行されません.
a,b,cの2つの同じ場合の条件を実行する
私がやっていることに気づいた.
次の悩みとテストの後、
わかりました.

countTokens関数は
合計を返します.

for文の動作原理を考えて、1回実行した後
2番目の条件
検査반환할 수 있는 토큰、条件により
繰り返し実行する方式に合致する.

つまり、上の出力結果に基づいてfor文が1回ずつ実行される
nextToken経由ではi < st.countTokens()なので、
合計토큰이 하나씩 출력は1つ1つしか減少しません.
ドアが回転すると토큰의 개수条件確認時、st.countToken(総トークン数)
-1ステータス.
言い換えれば、for文の条件は、for文が回転するたびに
変わります.
結果として、上記のコードはi < st.countTokens()です.
これによりnum[0]とnum[1]の数字が2になります.
入ります.num[2]は値を含まない
Javaがアレイ作成時に設定した初期値0を含む
ステータス.結果num[0]、num[1]、num[2]は2,2,0を含むfor문을 두번밖에 실행だからそうなったのです.

이해가 어려운 사람을 위해 for문의 동작을 설명해보겠다.

처음 for문의 코드를 실행할 때 countTokens의 값은 
3이다. 현재 i는 0이기 때문에 0 < 3 조건을 만족하고
코드가 실행된다. 

코드가 실행된 후 i는 1로 증가한다. 그 다음 
i < st.countTokens 조건을 검사하는데, 이 때 
st.countTokens의 값은 2이다. 왜냐면 이전 실행문에서
st.nextToken이라는 코드로 토큰 하나를 반환 받았기
때문에 총 토큰수가 3에서 2로 바뀐 것이다. 현재
i는 1이고 st.countTokens은 2이기 때문에 조건을
만족해 코드가 실행된다.

코드가 실행된 후 같은 방식으로 i는 2로 증가하지만
st.countTokens의 값은 1이다. 그렇다면 조건식
검사 시 2 > 1는 false이기 때문에 코드를 실행하지
않고 for문을 나오게 된다.

즉, 해당 for문을 돌릴때 countTokens를 통해 조건을
작성하는 것은 잘못된 설계인 것이다.

while+hasMoreTokens
顕著な差はないように見えます.
私もforeachを試してみたいのですが、どんなパラメータを使うべきか分かりません.
できなかった.ご存知の方がいらっしゃいましたらシェアしてください

-解答3

두 수가 동일한 조건문을 실행논리を使用し、残りは연산자です.
一つ一つ分離する.
演算のコードは2つの関数で構成されています.사용하지 않도록に有意差は認められなかった.
正直に言うと、コードの作成とテストはさまざまな方法で行えます.속도の原因を比較したいのですが
前に言ったように白俊の結果だからだ.
わかりにくい.

추후에 고수가 된다면 이 궁금증들을 해결해보고
싶다. 지금은 여러 방식으로 코드를 짜보고, 
그 과정에서 모르는 부분을 학습하는것을 우선 시
하고있다.

ドアがなくても上記の問題を解く方法を知っていれば.
みんなで分かち合ってください

-答えてくれ

https://velog.io/@cjhlsb/Algorithm-%EB%B0%B1%EC%A4%80-2480%EB%B2%88-%EC%A3%BC%EC%82%AC%EC%9C%84-%EC%84%B8%EA%B0%9C
上のリンクのコードは以下の通りです.

ここでは5四半期ではなく、4四半期です.성능, 속도とa == bはaを共有している.
バンドル後、a == c万件を別途処理した.Java API
Mathクラスの最大手法を用いて最低価格を求めた.
ただし、上記のコードのすべての内容を比較するとb == c、a == b、 a == cの3回を作成した理由は、
わかりません.aとbは等しく,aとcは等しく,bとcは等しい
自動的に同じように見えるので、一つ取り除くことができます.
四半期が4回の場合、5回の差は速度差です.
あまり高くないはずですjava b == cあるかどうか知りたくて回ってみました.

やはりコードが短く、内容が少ないため、
手に入らない.その結果、上記のコードはAPI를 사용하면 속도 차이です.
これは、Bufferedを使用して入力およびテストを行った結果です.

= Plus, Tip =


[switch vs if] 

switch문으로 구현 가능한 것은 모두 if문으로 구현 가능하다.
하지만 역은 성립하지 않는다. 그렇다면 if문으로 모든 조건을
처리할 수 있으니 편하게 if문만 쓰면 될까? 

찾아보니 조건의 숫자가 3~4개 이하라면 if문이 더 빠르고,
조건이 많아지면 switch문이 빠르다. 따라서 조건이 많은 
경우에 switch문을, 조건이 적거나 switch문으로
구현이 불가한 경우에 if문을 사용하면 좋을 것 같다.

하지만 이로인한 성능차이 보다 코드의 가독성, 의미에 
따라 if, switch를 선택하는 것이 좋다. 분야에 따라
다르지만 대부분의 경우에 if, switch 중 무엇을 썼느냐에 
따라 심각한 문제나 에러, 성능 저하가 일어나진 않기
때문이다.

추가적으로 랜덤 값이 입력될 경우 switch문이 if문 보다 
처리속도가 훨씬 빠르다. 반면 switch문은 case에 없는 값이
들어오면 속도가 현저하게 느려진다. if문은 조건이 바로 
검색될 시 처리속도가 빠르므로 사용자가 자주 사용하는 기능
을 상단에 먼저 작성해야 한다. 여러 기능을 비슷하게 사용한다면
switch문을 사용하는게 좋다.

정리하자면,
if문은 많이 쓰이는 기능(범용성이 높은)에 대한 조건을
상단부에 먼저 작성해줌으로써 성능을 개선할 수 있다.
조건의 수가 적을 경우 if, 많을 경우 switch를 추천한다.
값이 연속되거나 여러 조건이 유사한 빈도로 사용되면 
switch를 사용하는게 좋다. 하지만 성능상 차이는 
미비할 수도 있으니 가독성, 의미에 더 중점을 두어야한다.




[if 반복 사용 vs if-else if-else]

if() 
if()
라던지

if(){}
if(){}
로 코드를 작성하는게 가독성도 좋아보이고 깔끔하며
필자 기준으로는 기존에 접해보지 못한 방식이라 앞으로
코드를 이런식으로 짤 예정이였다.

하지만 찾아보니 위와 같은 방식은 필요한 상황에만 
써야하는 것이지 if-else if-else를 대신해 무조건
사용할 수는 없다는 것을 알 수 있었다.

다수의 if를 통해 조건을 작성하게되면 100개의 조건이 있을 
시 100번의 검사가 이루어지게된다. 반면 if-else if-else를
사용하게 되면 실행 중 해당하는 조건을 찾으면 나머지는 
검사하지 않게된다.