그리고 나를 한 방향이나 다른 방향으로 두지 마십시오 .... 나는 한 가지를 지지하지 않습니다
아무도 넣지 않습니다. 내 말은 이제 현대 OOP 언어의 FP 칩과 다중 패러다임 언어의 OOP 칩이 있다는 것입니다. 또한 많은 FP 칩이 특별하고 놀라운 것으로 제시되며 실제로 동일한 계란은 프로필에만 있습니다. 파스칼의 클로저나 C의 함수 실행 지연과 같이 작업의 결과가 아니라 포인터가 전달될 때 그것들은 오랫동안 존재했고 존재했습니다. 모든 언어에서 일반적으로 매개변수를 값으로 전달하는 것과 관련하여 기사의 예에서 일반적으로 제공되는 것이 있습니다. js를 제외한 거의 모든 곳에서 작동하지 않습니다(아직 Python 제외).
OOP의 기본 요소를 통해 완료됩니다. 아마도 나는 FP 기술을 잃었지만 여기서는 OOP가 훨씬 간단하고 읽기 쉬워 보였습니다.
코드는 매우 간단하고 짧습니다( description ). FP에 쓰면 비교해보는 재미가 쏠쏠하다.
시간이 나면 계산기를 확인하겠습니다. 그리고 당신은 텔레파시입니다. 다른 주제에서 질문하려고 했지만 "전투 모드"에서 디버깅한 경험에 따르면 여기에서 묻겠습니다. T_OHLC_V 데이터의 "구멍"이 MT4 및 MT5에서 가능한가요?
저것들. 예를 들어 브레이크(연결 끊김, 터미널 정지, 시스템 정지) 후 새 데이터가 먼저 간격을 두고 도착한 다음 간격/"구멍"이 마치 어레이 내부처럼 기록될 수 있습니까? 물론 지표 및 전문가를 위해 이러한 감지기를 직접 작성하거나 이미 확인 경험이 있으므로 걱정할 필요가 없습니다.
그리고 FP 경험이 없는데(아니면 있는데 이름은 몰랐어요) 자동소총은 어디로 가져가야 하나요? ), 나는 절차적 패러다임으로 극복할 수 있다고 생각합니다.
이상한 기사. OOP는 어떤 식으로든 절차 스타일과 다르지 않습니다. 기본적으로 절차적 스타일로 모든 작업을 수행할 수 있지만 그 반대의 경우도 끔찍한 코드 팽창 없이는 불가능합니다. OOP는 근본적으로 다른 스타일이 아닌 상부 구조입니다.
기사가 절차가 아닌 기능에 관한 것이라면(잘못을 발견하면 명확하지 않음), 완전히 다른 적용 영역을 가진 것을 비교하는 이유는 무엇입니까?
토픽 스타터, 당신 자신이 뭔가를 쓰고 지금 당신은 무엇에 대해 이야기하고 있었습니까? 기능적 또는 절차적?
OOP의 출현과 함께 그는 캡슐화, 상속 및 기타 모피즘으로 저를 많이 두렵게 했습니다. OOP 소개를 시작하는 데 인기가 있는 이 유형을 사용했습니다. 그들은 단순히 데이터를 함수와 함께 하나의 블록(클래스)에 씁니다. 하지만 그때마다 새로운 용어를 사용하는 것이 유행이라는 사실에 익숙해졌습니다. OOP가 필요할 때 - 아무 문제 없지만, 제 소견으로는 절차적 버전보다 2배는 더 왕성하고 느리기 때문에 최대한 절차적 버전을 관리합니다.
그리고 질문이 생겼습니다. 왜냐하면. 나는 FP와 OOP 및 절차적 옵션 외에 다른 옵션에 대한 의견을 듣고 싶었습니다. 아마도 누군가는 매우 긍정적인 경험을 했을 것입니다. 그리고 너무 무리하지 않고 안정적인 믹스를 사용하는 것이 현명하다고 생각합니다.
#property strict#property script_show_inputsinputdouble inPerformance = 100 ; // Сколько процентов дает система за периодinputdouble inGift = 50 ; // Награда управляющего в процентах (< 100)inputint inN = 12 ; // Сколько расчетных периодовstruct BASE
{
double Investor;
double Manager;
double Summary;
// Если управляющий снимает деньги в конце каждого расчетного периода.void Set1( constdouble Performance, constdouble Gift, constint N )
{
this .Investor = :: MathPow ( 1 + (Performance - 1 )* ( 1 - Gift), N);
this .Manager = ( this .Investor - 1 ) * Gift / ( 1 - Gift);
this .Summary = this .Investor + this .Manager;
return ;
}
// Если ничего не делалось в расчетные периоды.void Set2( constdouble Performance, constdouble Gift, constint N )
{
this .Summary = :: MathPow (Performance, N);
this .Manager = ( this .Summary - 1 ) * Gift;
this .Investor = this .Summary - this .Manager;
return ;
}
// Если управляющий снимает деньги в конце каждого расчетного периода и реинвестирует их.void Set3( constdouble Performance, constdouble Gift, constint N )
{
this .Summary = :: MathPow (Performance, N);
this .Investor = :: MathPow ( 1 + (Performance - 1 )* ( 1 - Gift), N);
this .Manager = this .Summary - this .Investor;
return ;
}
voidoperator *=( constdouble Deposit = 1 )
{
this .Investor *= Deposit;
this .Manager *= Deposit;
this .Summary *= Deposit;
return ;
}
#define TOSTRING(A) #A + " = " + :: DoubleToString (A, 4 ) + " "string ToString( constbool FlagName = true ) const
{
return (FlagName ? TOSTRING(Investor) + TOSTRING(Manager) + TOSTRING(Summary)
: :: StringFormat ( "||%-12.4f||%-12.4f||%-12.4f||" , this .Investor, this .Manager, this .Summary));
}
#undef TOSTRING
};
struct PAMM
{
double Performance; // Доходность за расчетный периодdouble Gift; // Вознагражение управляющего.int N; // Сколько расчетных периодов.
BASE Base1; // Если управляющий снимает деньги в конце каждого расчетного периода.
BASE Base2; // Если ничего не делалось в расчетные периоды.
BASE Base3; // Если управляющий снимает деньги в конце каждого расчетного периода и реинвестирует их.void Set( constdouble dPerformance, constdouble dGift, constint iN )
{
this .Performance = dPerformance;
this .Gift = dGift;
this .N = iN;
this .Base1.Set1( 1 + this .Performance / 100 , this .Gift / 100 , this .N);
this .Base2.Set2( 1 + this .Performance / 100 , this .Gift / 100 , this .N);
this .Base3.Set3( 1 + this .Performance / 100 , this .Gift / 100 , this .N);
}
voidoperator *=( constdouble Deposit = 1 )
{
this .Base1 *= Deposit;
this .Base2 *= Deposit;
this .Base3 *= Deposit;
return ;
}
string GetDescription( void ) const
{
return ( "Доходность за расчетный период " + :: DoubleToString ( this .Performance, 1 ) + "%\n" +
"Вознагражение управляющего " + :: DoubleToString ( this .Gift, 1 ) + "%\n" +
"Количество расчетных периодов. " + ( string ) this .N);
}
string ToString( constbool FlagName = true , constbool FlagDescription = true ) const
{
return (FlagDescription ? "Данные для инвестиционного счета со следующими характеристиками:\n\n" + this .GetDescription() +
"\n\nКонечный результат для Инвестора, Управляющего и Суммарно:""\n\nЕсли управляющий снимает деньги в конце каждого расчетного периода (1).\n" + this .Base1.ToString(FlagName) +
"\n\nЕсли ничего не делалось в расчетные периоды (2).\n" + this .Base2.ToString(FlagName) +
"\n\nЕсли управляющий снимает деньги в конце каждого расчетного периода и реинвестирует их (3).\n" + this .Base3.ToString(FlagName)
: this .Base1.ToString(FlagName) + this .Base2.ToString(FlagName) + this .Base3.ToString(FlagName));
}
};
voidOnStart ()
{
PAMM Pamm;
Pamm.Set(inPerformance, inGift, inN);
Print (Pamm.ToString());
string Str = Pamm.GetDescription() + "\n " ;
for ( int i = 1 ; i <= 3 ; i++ )
Str += :: StringFormat ( "||%-12s||%-12s||%-12s||" , "Investor" + ( string )i, "Manager" + ( string )i, "Summary" + ( string )i);
for ( int i = 1 ; i <= inN; i++ )
{
Pamm.Set(inPerformance, inGift, i);
Str += StringFormat ( "\n%-2d:" , i) + Pamm.ToString( false , false );
}
Print (Str);
}
공식적으로 이것은 OOP입니다. 그러나 가장 원시적인 부분입니다. 그러나 그는 그녀 없이는 살 수 없었습니다. 아마도 어리석게도 뇌가 다른 것으로 바뀌었고 나는 이것을 리벳으로 고정합니다.
)는 어셈블러에서도 수행할 수 있습니다. 문제는 어느 것이 더 쉬운가입니다.
그리고 나를 한 방향이나 다른 방향으로 두지 마십시오 .... 나는 한 가지를 지지하지 않습니다
아무도 넣지 않습니다. 내 말은 이제 현대 OOP 언어의 FP 칩과 다중 패러다임 언어의 OOP 칩이 있다는 것입니다. 또한 많은 FP 칩이 특별하고 놀라운 것으로 제시되며 실제로 동일한 계란은 프로필에만 있습니다. 파스칼의 클로저나 C의 함수 실행 지연과 같이 작업의 결과가 아니라 포인터가 전달될 때 그것들은 오랫동안 존재했고 존재했습니다. 모든 언어에서 일반적으로 매개변수를 값으로 전달하는 것과 관련하여 기사의 예에서 일반적으로 제공되는 것이 있습니다. js를 제외한 거의 모든 곳에서 작동하지 않습니다(아직 Python 제외).
나는 할 수 없습니다. 그러나 나는 그것에서 원시적인 것들을 사용합니다. 최근 에 매우 간단한 코드를 게시했습니다 .
나는 내가 결국 무엇을 봐야할지 이해하지 못했을 때 FP에서 쓰기 시작했습니다.
OOP의 기본 요소를 통해 완료되었습니다. 아마도 나는 FP 기술을 잃었지만 여기서는 OOP가 훨씬 간단하고 읽기 쉬워 보였습니다.
코드는 매우 간단하고 짧습니다( description ). FP에 쓰면 비교해보는 재미가 쏠쏠하다.
코드는 훨씬 작으며 여기에 자주 게시됩니다. 여기에 배포하는 것이 좋습니다. 교육 목적으로 사용할 것입니다.
Dmitry Fedoseev가 자신의 버전을 작성한 다음 Expert가 자신의 버전을 작성했으면 합니다.)나는 할 수 없습니다. 그러나 나는 그것에서 원시적인 것들을 사용합니다. 최근 에 매우 간단한 코드를 게시했습니다 .
나는 내가 결국 무엇을 봐야할지 이해하지 못했을 때 FP에서 쓰기 시작했습니다.
OOP의 기본 요소를 통해 완료됩니다. 아마도 나는 FP 기술을 잃었지만 여기서는 OOP가 훨씬 간단하고 읽기 쉬워 보였습니다.
코드는 매우 간단하고 짧습니다( description ). FP에 쓰면 비교해보는 재미가 쏠쏠하다.
시간이 나면 계산기를 확인하겠습니다. 그리고 당신은 텔레파시입니다. 다른 주제에서 질문하려고 했지만 "전투 모드"에서 디버깅한 경험에 따르면 여기에서 묻겠습니다. T_OHLC_V 데이터의 "구멍"이 MT4 및 MT5에서 가능한가요?
저것들. 예를 들어 브레이크(연결 끊김, 터미널 정지, 시스템 정지) 후 새 데이터가 먼저 간격을 두고 도착한 다음 간격/"구멍"이 마치 어레이 내부처럼 기록될 수 있습니까? 물론 지표 및 전문가를 위해 이러한 감지기를 직접 작성하거나 이미 확인 경험이 있으므로 걱정할 필요가 없습니다.
그리고 FP 경험이 없는데(아니면 있는데 이름은 몰랐어요) 자동소총은 어디로 가져가야 하나요? ), 나는 절차적 패러다임으로 극복할 수 있다고 생각합니다.
추신 재요청 요청)
이상한 기사. OOP는 어떤 식으로든 절차 스타일과 다르지 않습니다. 기본적으로 절차적 스타일로 모든 작업을 수행할 수 있지만 그 반대의 경우도 끔찍한 코드 팽창 없이는 불가능합니다. OOP는 근본적으로 다른 스타일이 아닌 상부 구조입니다.
기사가 절차가 아닌 기능에 관한 것이라면(잘못을 발견하면 명확하지 않음), 완전히 다른 적용 영역을 가진 것을 비교하는 이유는 무엇입니까?
토픽 스타터, 당신 자신이 뭔가를 쓰고 지금 당신은 무엇에 대해 이야기하고 있었습니까? 기능적 또는 절차적?
OOP의 출현과 함께 그는 캡슐화, 상속 및 기타 모피즘으로 저를 많이 두렵게 했습니다. OOP 소개를 시작하는 데 인기가 있는 이 유형을 사용했습니다. 그들은 단순히 데이터를 함수와 함께 하나의 블록(클래스)에 씁니다. 하지만 그때마다 새로운 용어를 사용하는 것이 유행이라는 사실에 익숙해졌습니다. OOP가 필요할 때 - 아무 문제 없지만, 제 소견으로는 절차적 버전보다 2배는 더 왕성하고 느리기 때문에 최대한 절차적 버전을 관리합니다.
그리고 질문이 생겼습니다. 왜냐하면. 나는 FP와 OOP 및 절차적 옵션 외에 다른 옵션에 대한 의견을 듣고 싶었습니다. 아마도 누군가는 매우 긍정적인 경험을 했을 것입니다. 그리고 너무 무리하지 않고 안정적인 믹스를 사용하는 것이 현명하다고 생각합니다.
코드는 훨씬 작으며 여기에 자주 게시됩니다. 여기에 배포하는 것이 좋습니다. 교육 목적으로 사용할 것입니다.
깔개.
공식적으로 이것은 OOP입니다. 그러나 가장 원시적인 부분입니다. 그러나 그는 그녀 없이는 살 수 없었습니다. 아마도 어리석게도 뇌가 다른 것으로 바뀌었고 나는 이것을 리벳으로 고정합니다.
피터 하하하 그만해
나의 접근, 양동이 - 냄비
피터 하하하 그만해
나의 접근, 양동이 - 냄비
오랜만에 보는 것.
정말 정말 다른 별명으로 갔다?
오랫동안 보지 못한 것.
정말 정말 다른 별명으로 갔다?
강력한 AI를 만들기 위해 떠났다고 합니다.
강력한 AI를 만들기 위해 떠났다고 합니다.