ANMIAN

#include <stdio.h>
#include <math.h>

int IsPerfectSquareNumber(unsigned long number);
int IsPrime(unsigned long number);

int main(void)
{
        unsigned long number;

        printf("자연수 하나를 입력하십시오 : ");
        scanf("%lu", &number);
        printf("%lu는 완전제곱수%s니다.\n", number, IsPerfectSquareNumber(number)?" 입":"가 아닙");
        return 0;
}

int IsPerfectSquareNumber(unsigned long number)
{
        unsigned long i, j;

        for(i=2; i<=number; i++)
        {
                if(IsPrime(i))
                {
                        for(j = 0; (number%i)==0; j++)
                                number/=i;
                        if((j % 2) != 0)
                                return 0;
                }
        }
        return 1;
}

int IsPrime(unsigned long number)
{
        unsigned long i, sqrt_number;

        if(number < 2)
                return 0;
        sqrt_number = (unsigned long)sqrt(number);
        for(i=2; i<=sqrt_number; i++)
                if(number%i == 0)
                        return 0;
        return 1;
}

IsPrime함수의 사용이다. IsPerfectSquareNumber함수 내에서 for문을 돌면서 2부터 1씩 증가시키는 값으로 나누어질수 있는만큼 계속 나누어간다. 소인수분해는 소수(Prime number)로 나누어야 한다. 그런데 2로 나눈 나머지가 다시 2로 나누어지면 반복해서 나누는 과정이 있다.
                        for(j = 0; (number%i)==0; j++)
                                number/=i;
이 부분이다. 이 구문을 만나면 소수가 아닌 숫자로는 for문의 판별식((number%i)==0)을 만족할 수 없으므로 애초에 for문에 들어가지 못한다.
예를 들어 8로 나누어지는 수라면 이미 2로 3번 나누었다. 6으로 나누어지는 수라면 2에서 한번 3에서 한번 나누었으므로 i가 6까지 왔으면 당연히 나눌수 없게된다.

#include <stdio.h>
#include <math.h>
int IsPerfectSquareNumber(unsigned long number);

int main(void)
{
        unsigned long number;
        printf("자연수 하나를 입력하십시오 : ");
        scanf("%lu", &number);
        printf("%lu는 완전제곱수%s니다.\n", number, IsPerfectSquareNumber(number)?" 입":"가 아닙");
        return 0;
}
int IsPerfectSquareNumber(unsigned long number)
{
        unsigned long i, j;
        for(i=2; i<=number; i++)
        {
            for(j = 0; (number%i)==0; j++)
                    number/=i;
            if((j % 2) != 0)
                    return 0;
        }
        return 1;
}

여기서 if문은 어떤 수가 되건 어떠한 값(소수가 아니더라도)의 제곱이 되면 완전제곱이므로 같은 수가 쌍으로 있으면 완전제곱이 될 수 있다는 생각이다. 예를 들어 144(= 12*12)는 2*2*2*2*3*3이므로 2^4*3^2으로 표현된다. 2가 두쌍 3이 한쌍 있으므로 완전제곱이 된다.

#include <stdio.h>
#include <math.h>

int IsPerfectSquareNumber(unsigned long number);

int main(void)
{
        unsigned long number;
        printf("자연수 하나를 입력하십시오 : ");
        scanf("%lu", &number);
        printf("%lu는 완전제곱수%s니다.\n", number, IsPerfectSquareNumber(number)?" 입":"가 아닙");
        return 0;
}

int IsPerfectSquareNumber(unsigned long number)
{
       unsigned long ga = (unsigned long )sqrt(number); //ga == geometric_average
       return ((ga * ga) == number);
}

기하평균을 정수로 변환시킨 후 다시 제곱하여 원래의 수가 나오는지 확인하는 것이다.
만약 기하평균이 정수가 아니라면 slicing이 발생하여 소수점 아래는 버린다. 그러면 제곱을 해도 원래의 값이 되지 않는다. 형 변환의 위험을 역이용하였다. 위험한거 아냐?라고 생각한다면 큰 오해다. 마지막 소스는 수학적으로 문제가 없으며 처음보다 훨씬 안전한 소스라고 생각한다.

Software internationalization is difficult under the best of circumstances, but it always amazed me how often one particular country came up in discussions of internationalization problems: Turkey.

For example, this Rick Strahl post from mid-2005 is one of many examples I've encountered:

I've been tracking a really funky bug in my West Wind Web Store application that seems to crop up only very infrequently in my error logs. In a previous post I mentioned that I had instituted some additional logging features – specifically making sure that I would also log the locale of the user accessing the application.

Well, three bug reports later I noticed that all errors occurred with a Turkish (tr) browser. So I changed my browser's default language to Turkish and sure enough I could see the error occur.

Or, say, this 2005 post from Scott Hanselman:

I had blogged earlier about a bug in dasBlog that affected Turkish users. When a Turkish browser reported an HTTP Accept-Language header indicating Turkish as the preferred language, no blog posts would show up. As fix, I suggested that users change their blog templates, but I knew that wasn't an appropriate fix.

I understand that Turkish prisons are not to be trifled with, but the question remains: why do Turkish people take such cruel and perverse delight in breaking our fine software? What's wrong with Turkey?

As with so many other problems in software development, the question shouldn't be what's wrong with Turkey, but rather, what the hell is wrong with software developers? Some of this is sort of obvious if you have any cultural awareness whatsoever.

• In the United States, we would typically format today's date as 3/14/2008. In Turkey, they format it as 14.3.2008.
• In the United States, we use commas to group digits, like so: 32,768. In Turkey, they group digits using a period, so the same number would be entered as 32.768.

These minor formatting differences are usually not a big deal for output and display purposes, but it's a whole different ballgame when you're parsing input. You'd naturally expect people to input dates and numbers in the format they're used to. If your code assumes that input will be in typical American English format, there will be.. trouble.

Most languages have this covered; there are functions that allow you to read or write dates and numbers appropriately for various cultures. In .NET, for example, it's the difference between these two calls:

int.Parse("32.768");
int.Parse("32,768", System.Globalization.NumberFormatInfo.InvariantInfo);

Because no culture is specified, the first call will parse the number according to the rules of the default culture that code is running under. Let's hope it's running under a Turkish version of Windows, so it can parse the number correctly. The second call, however, explicitly specifies a culture. The "invariant" culture is every American programmer's secret dream realized: we merely close our eyes and wish away all those confusing languages and cultures and their crazy, bug-inducing date and number formatting schemes in favor of our own. A nice enough dream while it lasts, but instead of rudely asking your users to "speak American" through the invariant culture, you could politely ask them to enter data in ISO international standard format instead.

Anyway, point being, this kind of culture support is baked into most modern programming languages, so all you need to do is make sure your developers are aware of it-- and more importantly, that they're thinking about situations when they might need to use it.

But all that date and time formatting stuff is easy. Or about as easy as i18n ever gets, anyway. Strings are where it really starts to get hairy. Guess where this code fails?

switch (myType.ToLower())
{
   case "integer" : ;
}

If you guessed Turkey, you're wrong! Just kidding. Of course it fails in Turkey. When we convert the string "integer" to upper and lower case in the Turkish locale, we get some strange characters back:

"INTEGER".ToLower() = "ınteger"
"integer".ToUpper() = "İNTEGER"

It's sort of hard to see the subtle differences here unless we ratchet up the font size:

There's obviously no way these strings are going to match "integer" or "INTEGER" respectively. This is known as the Turkish I problem, and the solution should feel awfully familiar by now:

"INTEGER".ToLower(System.Globalization.CultureInfo.InvariantCulture)

That will produce the expected output, or at least, the output that matches the comparison in the original code snippet.

This is, of course, only the tip of the iceberg when it comes to internationalization. We haven't even touched on the truly difficult locales like Hebrew and Arabic. But I do agree with Jeff Moser-- if your code can pass the Turkey test, you're doing quite well. Certainly better than most.

If you care a whit about localization or internationalization, force your code to run under the Turkish locale as soon as reasonably possible. It's a strong bellwether for your code running in most-- but by no means all-- cultures and locales.