R resources

IT 2014.10.01 19:10
크리에이티브 커먼즈 라이선스
Creative Commons License


http://www.r-project.org/

http://www.cookbook-r.com/

http://www.r-bloggers.com/

http://www.inside-r.org/

http://rseek.org/

http://romainfrancois.blog.free.fr/

http://www.statmethods.net/

신고

'IT' 카테고리의 다른 글

R resources  (0) 2014.10.01
R  (0) 2014.07.02
Maple 강의자료  (0) 2009.04.10
국내 아키텍트 평균 연봉은 6450만원  (0) 2009.02.17
Friend functions and classes  (0) 2008.09.03
Virtual function with parameter types different from those of a base class  (0) 2008.08.28
Posted by simon_ryu

R

IT 2014.07.02 00:32
크리에이티브 커먼즈 라이선스
Creative Commons License

http://goo.gl/A3uRsh

http://statmethods.net

http://goo.gl/M0RQ5z

http://proquest.safaribooksonline.com/book/programming/r/9781118448960/chapter-2-essentials-of-the-r-language/c02_sec1_0006_htm#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODExMTg0NDg5NjAlMkY5NzgxMTE4NDQ4OTYwX2VwdWJfY292X2h0bSZxdWVyeT0=

 

http://www.r-project.org/mail.html

http://stats.stackexchange.com

http://stackoverflow.com

 

신고

'IT' 카테고리의 다른 글

R resources  (0) 2014.10.01
R  (0) 2014.07.02
Maple 강의자료  (0) 2009.04.10
국내 아키텍트 평균 연봉은 6450만원  (0) 2009.02.17
Friend functions and classes  (0) 2008.09.03
Virtual function with parameter types different from those of a base class  (0) 2008.08.28
Posted by simon_ryu

Maple 강의자료

IT 2009.04.10 14:39
크리에이티브 커먼즈 라이선스
Creative Commons License
Maple 9을 중심으로 간단한 소개와 사용방법설명
.mw 파일은 Maple 버전 9이상에서만 open할 수 있음.

신고

'IT' 카테고리의 다른 글

R resources  (0) 2014.10.01
R  (0) 2014.07.02
Maple 강의자료  (0) 2009.04.10
국내 아키텍트 평균 연봉은 6450만원  (0) 2009.02.17
Friend functions and classes  (0) 2008.09.03
Virtual function with parameter types different from those of a base class  (0) 2008.08.28
Posted by simon_ryu
크리에이티브 커먼즈 라이선스
Creative Commons License

한국SW아키텍트연합 조사, 올해 가장 주목기술로 'IT융합'꼽아

개발경력 10~15년차 이상인 국내 아키텍트들의 평균 연봉은 6450만원인 것으로 나타났다. 또한 10명 중 6명의 아키텍트들은 올해 가장 관심을 가져야 할 IT 기술로 IT융합을 꼽는 것으로 조사됐다.

16일 한국SW아키텍트연합(KASA)이 삼성SDS, LG CNS 등 주요 IT서비스 업체와 컨설팅 업체들의 팀장급 등 10~15년 개발경력을 갖고 있는 52명의 아키텍트들을 대상으로 조사한 ‘2009년 SW아키텍처 전망 보고서’에 따르면, 국내 아키텍트의 평균 연령은 40~50대가 57.7%, 평균 연봉은 6450만원이며 응답자의 42.3%가 7000만원 이상, 1억원 이상이 7.7%를 차지했다.

또한 2009년 기술 전망과 관련해서는 응답자의 61.9%가 IT융합을 꼽았고, 다음으로 클라우드 컴퓨팅(59.5%), 가상화(47.6%), IPTV(31.0%) 등을 들었다. 

2009년 아키텍처의 설계목표로 응답자의 52.4%가 비용절감을 꼽았다. 프로젝트에서 소프트웨어 도입 평가 기준으로 응답자의 72.5%가 가격을 선택했고 다음으로 안정성(52.5%), 기술지원(47.5%) 등을 들었다.

한편 하드웨어는 응답자의 82.5%가 안정성이 중요하다고 답했으며, 가격(75%), 성능(67.5%) 등이 그 뒤를 이었다. 이들이 참여하는 프로젝트의 운영체제는 71.9%가 유닉스 계열이고 개발환경의 81.3%가 자바를 차지했다. 자바를 선택한 이유는 J2EE기반의 미들웨어의 사용이 32.3%, 개발자풀이 22.6%, 개발생산성이 22.6%를 차지했다.
한편 닷넷은 프로젝트이 12.5%를 차지했는데, 닷넷을 선택한 이유로는 개발툴의 생산성이 30.8%, 윈도 환경에서 개발이 23.1%를 차지했다. 

정부의 SW정책에 대해 어떻게 생각하느냐는 질문에는 차세대 성장동력으로 키워달라는 응답이 34.4%, SW투자증대가 필요하다는 응답이 31.3%에 달했다. 

전체 아키텍처 가운데 오픈소스를 적용한 곳은 개발프레임워크(82.8%), 개발툴(58.6%), 형상관리(41.4%)의 순으로 나타났다. 이어 오픈소스를 사용하지 않는 이유로는 기술지원(77.4%), 안정성(58.15%), 기능적 성숙도(22.6%)를 꼽았다.

가장 선호하는 오픈소스 기술은 리눅스, JBoss톰캣, 스프링 프레임웍, MySQL데이터베이스, 이클립스, 아파치웹서버 등으로 나타났다. 

한국SW아키텍트 연합은 아키텍트 실무자, 정보통신 기술사, 대학교수, SW아키텍처 관련 오피니언 리더 등 업계 및 학계의 SW아키텍트 관련 단체 4곳으로 구성돼 있다.

이병희 기자 shake@ittoday.co.kr 

기사원본출처: 아이티투데이

신고
Posted by simon_ryu

Friend functions and classes

IT 2008.09.03 10:24
크리에이티브 커먼즈 라이선스
Creative Commons License

socure: C++ for dummies by Stephen Randy Davis

Occasionally, you want a non-member function to have access to the protected
members of a class. You do so by declaring the function to be a friend of the class by using the keyword friend. Sometimes, an external function can use direct access to a data member. I know this appears to break the strictly defined, well-sealed-off class interface position that I’ve been advocating, but just consider the following. First,
including a friend function is, in effect, adding that function to the interface (that’s why a class shouldn’t have too many friends). You’re okay as long as you attempt to treat this function as a normal function that, oh yeah, happens to have direct access. Second, providing a public access method that acts as a thin veil over a data member doesn’t do anything to abstract away class details. Such a thin veneer function fulfills the letter of the law, but not the spirit.

The friend declaration appears in the class that contains the protected member. The friend declaration is like a prototype declaration in that it includes the extended name and the return type. In the following example, the function initialize() can now access anything it wants in Student:

class Student
{
friend void initialize(Student*);
public:
// same public members as before...
protected:
int semesterHours; // hours earned toward graduation
float gpa;
};
// the following function is a friend of Student
// so it can access the protected members
void initialize(Student *pS)
{
pS->gpa = 0; // this is now legal...
pS->semesterHours = 0; // ...when it wasn’t before
}

A single function can be declared a friend of two classes at the same time. Although this can be convenient, it tends to bind the two classes together. This binding of classes is normally considered bad because it makes one class dependent on the other. If the two classes naturally belong together, however, it’s not all bad, as shown here:

class Student; // forward declaration
class Teacher
{
friend void registration(Teacher& t, Student& s);
public:
void assignGrades();
protected:
int noStudents;
Student *pList[100];
};
class Student
{
friend void registration(Teacher& t, Student& s);
public:
// same public members as before...
protected:
Teacher *pT;
int semesterHours; // hours earned toward graduation
float gpa;
};

void registration(Teacher& t, Student& s)
{
// initialize the Student object
s.semesterHours = 0;
s.gpa = 0;
// if there’s room...
if (t.noStudents < 100)
{
// ...add it onto the end of the list
t.pList[t.noStudents] = &s;
t.noStudents++;
}
}

In this example, the registration() function can reach into both the Student and Teacher classes to tie them together at registration time, without being a member function of either one. The first line in the example declares the class Student, but none of its members. This is called a forward declaration and just defines the name of the
class so that other classes, such as Teacher, can define a pointer to it. Forward references are necessary when two classes refer to each other. A member function of one class may be declared a friend of another class, as shown here:

class Teacher
{
// ...other members as well...
public:
void assignGrades();
};
class Student
{
friend void Teacher::assignGrades();
public:
// same public members as before...
protected:
int semesterHours; // hours earned toward graduation
float gpa;
};
void Teacher::assignGrades()
{
// can access protected members of Teacher from here
}
Unlike in the non-member example, the member function assignGrades()
must be declared before the class Student can declare it to be a friend.

An entire class can be named a friend of another. This has the effect of
making every member function of the class a friend
:

class Student; // forward declaration
class Teacher
{
protected:
int noStudents;
Student *pList[100];
public:
void assignGrades();
};
class Student
{
friend class Teacher; // make entire class a friend
public:
// same public members as before...
protected:
int semesterHours; // hours earned toward graduation
float gpa;
};
Now, any member function of Teacher has access to the protected members
of Student. Declaring one class a friend of the other inseparably binds the
two classes together.

신고
Posted by simon_ryu
TAG C++
크리에이티브 커먼즈 라이선스
Creative Commons License
(source: Effective C++, 2E | Item 50 by Scott Meyers)

class Base {
public:
virtual void f(int x);
};
class Derived: public Base {
public:
virtual void f(double *pd);
};
Derived *pd = new Derived;
pd->f(10); // error!

The problem is that Derived::f hides Base::f, even though they take different
parameter types
, so compilers demand that the call to f take a double*, which the literal 10 most certainly is not.

Suppose that when you called f, you really did want to call the version in Derived, but you accidentally used the wrong parameter type. Further suppose that Derived is way down in an inheritance hierarchy and that you were unaware that Derived indirectly inherits from some base class BaseClass, and that BaseClass declares a virtual function f that takes an int. In that case, you would have inadvertently called BaseClass::f, a function you didn't even know existed! This kind of error could occur frequently where large class hierarchies are used, so Stroustrup decided to nip it in the bud by having derived class members hide base class members on a per-name basis.

Note that if not declared with the same agruments in the derived classes, the member functions are not overridden polymorphically, whether or not they are declared virtual.

Note, by the way, that if the writer of Derived wants to allow clients to access Base::f,
this is easily accomplished via a simple using declaration:

class Derived: public Base {
public:
using Base::f; // import Base::f into
                         // Derived's scope
virtual void f(double *pd);
};
Derived *pd = new Derived;
pd->f(10); // fine, calls Base::f

For compilers not yet supporting using declarations, an alternative is to employ an
inline function
:

class Derived: public Base {
public:
virtual void f(int x) { Base::f(x); }
virtual void f(double *pd);
};
Derived *pd = new Derived;
pd->f(10); // fine, calls Derived::f(int),
                  // which calls Base::f(int)
신고
Posted by simon_ryu
TAG C++
크리에이티브 커먼즈 라이선스
Creative Commons License

(source: Effective C++, 2E | Item 16 by Scott Meyers)

class Derived: public Base {
public:
Derived(int initialValue)
: Base(initialValue), y(initialValue) {}
Derived(const Derived& rhs) // erroneous copy
: y(rhs.y) {} // constructor
private:
int y;
};

// correct copy constructor
class Derived: public Base {
public:
Derived(const Derived& rhs): Base(rhs), y(rhs.y) {}
...
};

// erroneous assignment operator
Derived& Derived::operator=(const Derived& rhs)
{
if (this == &rhs) return *this;

this->m_member = rhs.m_member; // assign to Derived's
// lone data member
return *this;
}

// correct assignment operator (type 1)
// erroneous assignment operator
Derived& Derived::operator=(const Derived& rhs)
{
if (this == &rhs) return *this;

Base::operator=(rhs); // call this->Base::operator=
this->m_member = rhs.m_member;
return *this;
}

// correct assignment operator (type 2)
// erroneous assignment operator
Derived& Derived::operator=(const Derived& rhs)
{
if (this == &rhs) return *this;

static_cast<Base&>(*this) = rhs; // some complier allows only this one
this->m_member = rhs.m_member;
return *this;
}

신고
Posted by simon_ryu
TAG C++


티스토리 툴바