development

이것은 기술적으로“Hello World”에 대한 O (1) 알고리즘입니까?

big-blog 2020. 7. 18. 09:28
반응형

이것은 기술적으로“Hello World”에 대한 O (1) 알고리즘입니까?


이것이 "Hello, World!"에 대한 O (1) 알고리즘으로 분류됩니까? ??

public class Hello1
{
   public static void Main()
   {
      DateTime TwentyYearsLater = new DateTime(2035,01,01);
      while ( DateTime.Now < TwentyYearsLater )
      { 
          System.Console.WriteLine("It's still not time to print the hello ...");
      }
      System.Console.WriteLine("Hello, World!");
   }
}

나는 사용하려고 생각하고있다.

DateTime TwentyYearsLater = new DateTime(2035,01,01);
while ( DateTime.Now < TwentyYearsLater )
{ 
   // ... 
}

누군가가 특정 복잡도의 알고리즘을 요청할 때마다 농담으로 넣을 바쁜 루프로서의 코드 스 니펫. 이것이 맞습니까?


이 문맥에서 Big O 표기법은 함수 입력의 크기와 해당 입력의 결과를 계산하기 위해 수행해야하는 작업 수 사이의 관계를 설명하는 데 사용됩니다.

조작에 출력과 관련 될 수있는 입력이 없으므로 Big O 표기법을 사용하는 것은 의미가 없습니다. 작업에 걸리는 시간은 작업 의 입력과 무관 합니다 (없음). 이 때문에 없는 것을 존재하지 않는 관계를 설명하는 입력과, 당신이 빅 O를 사용할 수 없습니다 수행 작업의 수 사이의 관계는


Big-O 표기법은 대략 '작업량 N에 대해 연산을 받았는데 N에 비례하여 계산 시간이 얼마나 걸립니까?' 예를 들어, N 크기의 배열을 정렬하면 N ^ 2, Nlog (N) 등이 걸릴 수 있습니다.

여기에는 작동 할 입력 데이터가 없습니다. 그래서 그렇지 않습니다 O(anything).

더 나쁘다. 이것은 기술적으로 알고리즘이 아닙니다. 알고리즘은 수학 함수의 값을 계산하는 방법입니다. 수학 함수는 한 입력에서 출력으로의 매핑입니다. 이것은 입력을받지 않고 아무것도 반환하지 않기 때문에 수학적인 의미에서 함수가 아닙니다. 위키 백과에서 :

알고리즘은 유한 한 공간과 시간 내에 함수를 계산하기 위해 잘 정의 된 공식 언어로 표현할 수있는 효과적인 방법입니다. 초기 상태 및 초기 입력 (아마도 비어 있음)에서 시작하여, 명령은 실행될 때 유한 한 수의 잘 정의 된 연속 상태를 진행하여 결국 "출력"을 생성하고 최종 종료 상태에서 종료되는 계산을 설명합니다.

이것이 기술적으로 제어 시스템입니다. 위키 백과에서;

제어 시스템은 다른 장치 또는 시스템의 동작을 관리, 명령, 지시 또는 규제하는 장치 또는 장치 세트입니다.

수학 함수와 알고리즘의 차이점과 콘솔 출력, 그래픽 표시 또는 로봇 제어와 같은 부작용을 수행하는 컴퓨터의 강력한 기능에 대해보다 심층적 인 답변을 원하는 사람들 은이 백서를 읽어보십시오. 강력한 교회 여행 가설

요약

컴퓨팅의 고전적인 관점은 계산을 입력 (이론 수 또는 유한 문자열)의 출력으로 변환 된 닫힌 상자로 계산합니다. 컴퓨팅의 대화식 관점에 따르면, 계산은 입력에서 출력으로의 함수 기반 변환이 아니라 지속적인 대화식 프로세스입니다. 특히 외부 세계와의 통신은 계산 전 또는 후에가 아니라 계산 중에 발생합니다. 이 접근 방식은 계산이란 무엇이며 어떻게 모델링되는지에 대한 이해를 근본적으로 바꿉니다.

새로운 패러다임으로 상호 작용을 수용하는 것은 Turing Machines (TM)가 모든 계산을 캡처한다는 믿음이 널리 퍼져있는 SCT (Short Church-Turing Thesis)에 의해 방해를 받으므로 TM보다 더 표현적인 계산 모델은 불가능합니다. 이 논문에서, 우리는 SCT가 튜링이 의도하지 않은 방식으로 원래의 교회 여행 논문 (CTT)을 재 해석한다는 것을 보여줍니다. 일반적으로 원본과 동등한 것으로 가정하는 것은 신화입니다. 우리는 SCT에 대한 광범위한 믿음의 역사적 이유를 식별하고 분석합니다. 그것이 거짓이라는 것을 받아들임으로써 만 우리는 대안적인 계산 패러다임으로서 상호 작용을 채택 할 수 있습니다


아니, 코드가의 시간 복잡도를 가지고 O(2^|<DeltaTime>|),

현재 시간을 올바르게 코딩합니다.
제 영어를 먼저 사과하겠습니다.

CS에서 Big O가 무엇이며 어떻게 작동합니까?

Big O 표기법 은 프로그램의 입력을 실행 시간과 연결하는 데 사용되지 않습니다 .
큰 O 표기법은 엄격하지 않은 두 양점근 비율 을 표현하는 방법 입니다.

알고리즘 분석의 경우이 두 수량은 입력 (먼저 "측정"기능이 있어야 함) 및 실행 시간 아닙니다 .
그것들은 문제 1 의 인스턴스의 코딩 길이 와 관심있는 메트릭이다.

일반적으로 사용되는 측정 항목은

  1. 주어진 계산 모델에서 알고리즘을 완료하는 데 필요한 단계 수입니다.
  2. 이러한 개념이 존재하는 경우 계산 모델에 필요한 공간.

첫 번째 점 은 전이 2 기능 의 적용 횟수 , 즉 "단계"로 변환되고 두 번째 점 은 적어도 한 번 작성된 다른 테이프 셀 의 수를 변환하도록 암시 적으로 TM을 모델로 가정합니다 .

또한 원래의 인코딩 대신 다항식 관련 인코딩을 사용할 수 있다고 종종 암시 적으로 가정합니까? 예를 들어, 배열 O(n)의 인스턴스를 코딩하는 데 길이가 n*b+(n-1)여기서 b각 요소의 (일정한) 수의 기호가 있습니다. 이것은 b계산 모델의 상수로 간주 되기 때문에 위의 표현 n은 무의식적으로 동일하기 때문입니다.

등의 알고리즘 이유도 설명 평가판 부문 입니다 지수 기본적으로 인에도 불구하고 알고리즘 for(i=2; i<=sqr(N); i++)알고리즘과 같은 3 .

참조 .

이것은 또한 큰 O 표기법이 문제를 설명하는 데 필요한 많은 매개 변수를 사용할 수 있음을 의미합니다 . 일부 알고리즘에 k 매개 변수 가있는 것은 드문 일이 아닙니다 .

따라서 이것은 "입력"또는 "입력 이 없습니다 "에 관한 것이 아닙니다 .

연구 사례

Big O 표기법은 알고리즘에 의문을 제기하지 않으며 현재 수행중인 작업을 알고 있다고 가정합니다. 그것은 본질적으로 까다로울 수있는 알고리즘에 이르기까지 모든 곳에서 적용 할 수있는 도구입니다 (귀하와 마찬가지로).

문제를 해결하려면 현재 날짜와 미래 날짜를 사용 했으므로 문제의 일부 여야합니다. 간단히 말해서, 그들은 문제의 사례의 일부입니다.

구체적으로 인스턴스는 다음과 같습니다.

<DeltaTime>

어디 <>수단 어떤 비 병리학, 선택의 코딩.

매우 중요한 설명 은 아래를 참조하십시오 .

따라서 O(2^|<DeltaTime>|)현재 시간의 가치에 따라 여러 번 반복하므로 O 복잡성 시간이 길어 집니다. 점근 적 표기법은 상수를 제거하므로 유용하므로 다른 숫자 상수를 넣는 데는 아무런 의미가 없습니다 (예를 들어, O(10^|<DeltaTime>|*any_time_unit)무의미한 사용).

까다로운 부분은

위의 중요한 가정은 계산 모델이 5 배로 , 시간에 따라 실제 시간을 의미한다고 가정했습니다. 표준 계산 모델에는 그러한 개념이 없으며 TM은 시간을 알지 못합니다. 시간은 걸음 수와 연결됩니다 . 이것이 우리의 현실이 작동하는 방식이기 때문입니다 4 .

그러나 모델에서 시간은 계산의 일부이므로 Main은 순수하지 않지만 개념은 동일하다고 말함으로써 기능적 사람들의 용어를 사용할 수 있습니다.

이를 이해하기 위해서는 프레임 워크가 실제 시간보다 2 배, 5 배, 10 배 빠른 가짜 시간을 사용하는 것을 막을 수있는 것은 없습니다. 이렇게하면 코드가 "시간"의 "반", "1/5", "1/10"으로 실행됩니다.

이 리플렉션은의 인코딩을 선택하는 데 중요하며 <DeltaTime>, 이는 <(CurrentTime, TimeInFuture)>를 작성하는 압축 된 방법입니다. 사전에 시간이 존재하지 않기 때문에 CurrentTime의 코딩은 전날 Now (또는 다른 선택) 라는 단어 어제 로 코딩 될 수 있습니다. 코딩 시간이 실제 시간으로 증가 한다는 가정을 깨뜨림으로써 앞으로 나아갑니다 (DeltaTime 중 하나가 감소합니다)

유용한 것을하기 위해서는 계산 모델에서 시간을 올바르게 모델링해야합니다.

우리가 할 수있는 유일한 안전한 선택은 물리적 시간이 앞으로 나아갈 때 길이가 증가하지만 여전히 단항을 사용하지 않는 타임 스탬프를 인코딩하는 것입니다. 이것은 우리에게 필요한 유일한 시간 속성이며 인코딩에 필요한 속성입니다. 알고리즘에 시간이 복잡해질 수있는 것은 이런 유형의 인코딩에서만 가능합니다.

' 시간 복잡성 은 무엇입니까 ?'라는 문구에서 시간 이라는 단어에서 혼란이 생깁니다. 그리고 ' 시간얼마나 걸리나요?' 매우 다른 것들을 의미합니다

아아 용어는 같은 단어를 사용하지만 머리에 "단계 복잡성"을 사용하여 질문을 다시 할 수 있습니다. 대답이 실제로 이해되는 데 도움이되기를 바랍니다 ^ _ ^


1 각 인스턴스의 길이는 다르지만 임의의 길이는 아니기 때문에 점근 적 접근 방식의 필요성을 설명합니다.
2 여기에 올바른 영어 단어를 사용하고 싶습니다.
3 또한 이것이 우리가 종종 log(log(n))수학에서 용어를 찾는 이유 입니다.
4 단계에서, 단계는 유한하지만, 널 (null)이 아니거나 연결되지 않은 시간 간격을 차지해야합니다.
5 이것은 물리적 시간에 대한 지식인 계산 모드, 즉 용어로 표현할 수 있음을 의미합니다. 유추는 .NET 프레임 워크에서 제네릭이 작동하는 방식입니다.


여기에 많은 훌륭한 답변이 있지만, 그것들을 모두 조금씩 바꿔 보도록하겠습니다.

기능 을 설명하기위한 Big-O 표기법이 있습니다 . 알고리즘 분석에 적용하려면 먼저 함수 측면에서이 알고리즘의 일부 특성을 정의해야 합니다 . 일반적인 선택은 입력 크기 의 함수로 단계 수를 고려 하는 것입니다 . 다른 답변에서 언급했듯이 명확하게 정의 된 "입력"이 없기 때문에 귀하의 경우에 그러한 기능을 생각해내는 것이 이상하게 보입니다. 그래도 여전히 시도 할 수 있습니다.

  • 우리는 알고리즘을 일정한 크기의 함수로 간주하여 어떤 크기의 입력이든 무시하고 고정 된 시간 동안 기다렸다가 끝냅니다. 이 경우 런타임은 f (n) = const 이며 O (1) 시간 알고리즘입니다. 이것이 당신이 기대하는 것입니다. 맞습니까? 예, 기술적으로 O (1)-알고리즘 입니다.
  • TwentyYearsLater"입력 크기"와 같은 관심 매개 변수로 간주 할 수 있습니다 . 이 경우 런타임은 f (n) = (nx)입니다. 여기서 x 는 호출 시점의 "현재 시간"입니다. 이런 식으로 보면 O (n) 시간 알고리즘입니다. 기술적으로 O (1) 알고리즘 을 다른 사람에게 보여줄 때마다이 반론을 예상하십시오 .
  • 그러나 k =TwentyYearsLater 가 입력이면 크기 n 은 실제로이를 나타내는 데 필요한 비트 수, 즉 n = log (k) 입니다. 따라서 입력 n 의 크기 와 런타임 간의 종속성은 f (n) = 2 ^ n-x 입니다. 알고리즘이 기하 급수적으로 느려진 것 같습니다! 어.
  • 프로그램에 대한 또 다른 입력은 실제로 OS 에서 루프 호출 순서에 대한 응답 스트림입니다DateTime.Now . 실제로이 전체 시퀀스가 ​​프로그램을 실행하는 순간에 입력으로 제공된다고 상상할 수 있습니다. 런타임은이 시퀀스의 속성, 즉 첫 번째 TwentyYearsLater요소 까지의 길이에 의존하는 것으로 간주 될 수 있습니다 . 이 경우 런타임은 다시 f (n) = n 이고 알고리즘은 O (n) 입니다.

그러나 다시, 귀하의 질문에 당신은 런타임에 관심이 있다고 말하지 않았습니다. 메모리 사용을 의미한다면? 상황을 모델링하는 방법에 따라 알고리즘이 O (1)-메모리 또는 아마도 O (n)-메모리라고 말할 수 있습니다 (구현이 DateTime.Now전체 호출 순서를 추적해야하는 이유가 있다면).

And if your goal was to come up with something absurd, why don't you go all in and say that you are interested in how the size of the algorithm's code in pixels on the screen depends on the chosen zoom level. This might be something like f(zoom) = 1/zoom and you can proudly declare your algorithm to be O(1/n)-pixel size!


I have to disagree with Servy slightly. There is an input to this program, even if it's not obvious, and that's the system's time. This might be a technicality you hadn't intended, but your TwentyYearsFromNow variable isn't twenty years from the system's time now, it's statically assigned to January 1st, 2035.

So if you take this code and execute it on a machine that has a system time of January 1st, 1970, it's going to take 65 years to complete, regardless of how fast the computer is (there may be some variation if its clock is faulty). If you take this code and execute it on a machine that has a system time of January 2nd, 2035, it will complete almost instantly.

I would say your input, n, is January 1st, 2035 - DateTime.Now, and it's O(n).

Then there's also the issue of the number of operations. Some people have noted that faster computers will hit the loop faster, causing more operations, but that's irrelevant. When working with big-O notation, we don't consider the speed of the processor or the exact number of operations. If you took this algorithm and ran it on a computer, and then ran it again but for 10x longer on the same computer, you would expect the number of operations to grow by the same factor of 10x.

As for this:

I'm thinking of using the [redacted code] snippet of code as a busy loop to put in as a joke whenever someone asks for an algorithm of a certain complexity. Would this be correct?

No, not really. Other answers have covered this, so I just wanted to mention it. You can't generally correlate years of execution to any big-O notation. Eg. There's no way to say 20 years of execution = O(n^87) or anything else for that matter. Even in the algorithm you gave, I could change the TwentyYearsFromNow to the year 20110, 75699436, or 123456789 and the big-O is still O(n).


Big-O analysis deals with the amount of processing involved as the amount of data being processed increases without limit.

Here, you're really only dealing with a single object of fixed size. As such, applying big-O analysis depends heavily (primarily?) upon how you define your terms.

For example, you could mean printing output in general, and imposing a wait so long that any reasonable amount of data would/will be printed in precisely the same period of time. You also have to add a little more in the way of somewhat unusual (if not outright wrong) definitions to get very far though--particularly, big-O analysis is usually defined in terms of the number of fundamental operations needed to carry out a particular task (but note that complexity can also be considered in terms of things like memory use, not just CPU use/operations carried out).

The number of fundamental operations usually translates fairly closely to time taken, however, so it isn't a huge stretch treat the two as synonymous. Unfortunately, however, we're still stuck with that other part: the amount of data being processed increasing without limit. That being the case, no fixed delay you can impose will really work. To equate O(1) with O(N), you'd have to impose an infinite delay so that any fixed amount of data took forever to print, just as an infinite amount of data would.


big-O relative to what?

You seem to be intuiting that twentyYearsLater is an "input". If indeed you wrote your function as

void helloWorld(int years) {
   // ...
}

It would be O(N) where N = years (or just say O(years)).

I would say your algorithm is O(N) relative to whatever number you happen to write in the line of code starting with twentyYearsLater =. But people do usually not consider numbers in the actual source code as the input. They might consider the command line input as the input, or the function signature input as the input, but, most likely not the source code itself. That is what you are disputing with your friend - is this the "input"? You set up your code in a way to make it intuitively seem like an input, and you can definitely ask its big O running time with respect to the number N on line 6 of your program, but if you use such a non-default choice as input you really need to be explicit about it.

But if you take the input to be something more usual, like the command line or the input to the function, there is no output at all and the function is O(1). It takes twenty years, but since big-O does not change up to a constant multiple, O(1) = O(twenty years).

Similar question - what is the runtime of:

void sortArrayOfSizeTenMillion(int[] array)

Assuming it does what it says and the input is valid, and the algorithm harnesses a quicksort or bubble sort or anything reasonable, it's O(1).


This "algorithm" is correctly described as O(1) or constant time. It's been argued that there is no input to this program, hence there is no N to analyze in terms of Big Oh. I disagree that there is no input. When this is compiled into an executable and invoked, the user can specify any input of arbitrary length. That input length is the N.

The program just ignores the input (of whatever length), so the time taken (or the number of machine instructions executed) is the same irrespective of the length of the input (given fixed environment = start time + hardware), hence O(1).


One thing I'm surprised hasn't been mentioned yet: big-O notation is an upper bound!

The issue everyone has noticed is that there is no N describing the inputs to the algorithm, so there is nothing to do big-O analysis with. However, this is easily mitigated with some basic trickery, such as accepting an int n and printing "Hello World" n times. That would get around that complaint and get back to the real question of how that DateTime monstrosity works.

There is no actual guarantee that the while loop will ever terminate. We like to think it has to at some time, but consider that DateTime.now returns the system date and time. There is actually no guarantee that this is monotonically increasing. It is possible that there is some pathologically trained monkey constantly changing the system date and time back to October 21, 2015 12:00:00 UTC until someone gives the monkey some auto-fitting shoes and a hoverboard. This loop can actually run for an infinite amount of time!

When you actually dig into the mathematical definition of big-O notations, they are upper bounds. They demonstrate the worst case scenario, no matter how unlikely. The worst case* scenario here is an infinite runtime, so we are forced to declare that there is no big-O notation to describe the runtime complexity of this algorithm. It doens't exist, just as 1/0 doesn't exist.

* Edit: from my discussion with KT, it is not always valid to presume the scenario we are modeling with big-O notation is the worst-case. In most cases, if an individual fails to specify which case we're using, they intended to explore the worst case. However, you can do a big-O complexity analysis on the best-case runtime.


Complexity is used to measure computational "horsepower" in terms of time/space. Big O notation is used to compare which problems are "computable" or "not computable" and also to compare which solutions -algorithms- are better than other. As such, you can divide any algorithm into two categories: those that can be solved in polynomial time and those that can't.

Problems like the Sieve of Erathostene are O(n ^exp) and thus are solvable for small values of n. They are computable, just not in polynomial time (NP) and thus when asked if a given number is prime or not, the answer depends on the magnitude of such number. Moreover, complexity does not depend on the hardware, so having faster computers changes nothing...

Hello World is not an algorithm and as such is senseless to attempt to determine its complexity -which is none. A simple algorithm can be something like: given a random number, determine if it is even or odd. Now, does it matter that the given number has 500 digits? No, because you just have to check if the last digit is even or odd. A more complex algorithm would be to determine if a given number divides evenly by 3. Although some numbers are "easy" to compute, others are "hard" and this is because of its magnitude: compare the time it takes to determine the remaninder between a number with one digit and other with 500 digits.

A more complex case would be to decode a text. You have an apparent random array of symbols which you also know are conveying a message for those having the decrypting key. Let's say that the sender used the key to the left and your Hello World would read: Gwkki Qieks. The "big-hammer, no-brain" solution would produce all combinations for those letters: from Aaaa to Zzzz and then search a word dictionary to identify which words are valid and share the two common letters in the cypher (i, k) in the same position. This transformation function is what Big O measures!


Most people seem to be missing two very important things.

  1. The program does have an input. It is the hard-coded date/time against which the system time is being compared. The inputs are under the control of the person running the algorithm,and the system time is not. The only thing the person running this program can control is the date/time they've hard-coded into the comparison.

  2. The program varies based on the input value, but not the size of the input set, which is what big-O notation is concerned with.

Therefore, it is indeterminate, and the best 'big-O' notation for this program would probably be O(null), or possibly O(NaN).


Everyone’s correctly pointed out that you don’t define N, but the answer is no under the most reasonable interpretation. If N is the length of the string we’re printing and “hello, world!” is just an example, as we might infer from the description of this as an algorithm “for hello, world!,” then the algorithm is O(N), because you might have an output string that takes thirty, forty or fifty years to print, and you’re adding only a constant time to that. O(kN+c) ∈ O(N).

Addendum:

To my surprise, someone is disputing this. Recall the definitions of big O and big Θ. Assume we have an algorithm that waits for a constant amount of time c and then prints out a message of length N in linear time. (This is a generalization of the original code sample.) Let’s arbitrarily say that we wait twenty years to start printing, and that printing a trillion characters takes another twenty years. Let c = 20 and k = 10¹², for example, but any positive real numbers will do. That’s a rate of d = c/k (in this case 2×10⁻¹¹) years per character, so our execution time f(N) is asymptotically dN+c years. Whenever N > k, dN = c/k N > c. Therefore, dN < dN+c = f(N) < 2 dN for all N > k, and f(N) ∈ Θ(N). Q.E.D.


I think people are getting thrown off because the code doesn't look like a traditional algorithm. Here is a translation of the code that is more well-formed, but stays true to the spirit of OP's question.

void TrolloWorld(long currentUnixTime, long loopsPerMs){
    long laterUnixTime = 2051222400000;  //unix time of 01/01/2035, 00:00:00
    long numLoops = (laterUnixTime-currentUnixTime)*loopsPerMs;

    for (long i=0; i<numLoops; i++){
        print ("It's still not time to print the hello …");
    }
    print("Hello, World!");
}

The inputs are explicit whereas before they were implicitly given by the time the code was started at and by the speed of the hardware running the code. The code is deterministic and has a well-defined output for given inputs.

Because of the limitations that are imposed on the inputs we can provide, there is an upper bound to the number of operations that will be executed, so this algorithm is in fact O(1).


At this point in time, yes

This algorithm has an implicit input, namely the time that the program is started at. The execution time will vary linearly1 depending on when it is started. During the year 2035 and after, the while loop immediately exits and the program terminates after constant operations2. So it could be said that the runtime is O(max(2035 - start year, 1))3. But since our start year has a minimum value, the algorithm will never take more than 20 years to execute (i.e. a constant value).

You can make your algorithm more in keeping with your intent by defining DateTime TwentyYearsLater = DateTime.Now + new TimeSpan(365*20,0,0,0);4

1 This holds for the more technical sense of execution time measured as number of operations because there is a maximum number of operations per time unit.
2 Assuming fetching DateTime.Now is a constant operation, which is reasonable.
3 I'm somewhat abusing big O notation here because this is a decreasing function with respect to start year, but we could easily rectify this by expressing it in terms of years prior to 2035.
4 Then the algorithm no longer depends on the implicit input of the start time, but that's of no consequence.


I'd argue that this is O(n). using http://www.cforcoding.com/2009/07/plain-english-explanation-of-big-o.html as a reference.

What is Big O?

Big O notation seeks to describe the relative complexity of an algorithm by reducing the growth rate to the key factors when the key factor tends towards infinity.

and

The best example of Big-O I can think of is doing arithmetic. The basic arithmetic operations we learnt in school were:

addition; subtraction; multiplication; and division. Each of these is an operation or a problem. A method of solving these is called an algorithm.

For your example,

given the input of n = 20 (with units years).

the algorithm is a mathematical function f(). where f() happens to be wait for n years, with 'debug' strings in between. The scale factor is 1. f() can be reduced/or increased by changing this scale factor.

for this case, the output is also 20 (changing the input changes the output linearly).

essentially the function is

f(n) = n*1 = n
    if  n = 20, then 
f(20) = 20 

참고 URL : https://stackoverflow.com/questions/34048740/is-this-technically-an-o1-algorithm-for-hello-world

반응형