From f443e84c64ce91cf83830d82841d39adb1853539 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 13:46:24 +0430
Subject: [PATCH 01/21] Update style-guide.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
بخش اول که ببینم چطو میشه
---
docs/manual/style-guide.md | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index c83d1f7..a7163fa 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -1,5 +1,13 @@
# Style Guide
+
+ در این بخش ها ما به بررسی بخش از عبارات اصطلاحی در نوشتن برنامه به زبان جولیا می پردازیم
+ .
+ هیچ کدام از این قوانین مطلق نیستند
+ .
+ انها تنها برای کمک به اشنا شدن شما با زبان و کمک برای انتخاب بین راه حل های طراحی موجود است
+ .
+
The following sections explain a few aspects of idiomatic Julia coding style. None of these rules
are absolute; they are only suggestions to help familiarize you with the language and to help
you choose among alternative designs.
From dcd57e1af59038a3880966097065457127b61f0c Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 16:02:22 +0430
Subject: [PATCH 02/21] Update style-guide.md
---
docs/manual/style-guide.md | 40 +++++++++++++++++++++++++++++++++-----
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index a7163fa..5a2fb39 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -1,5 +1,4 @@
-# Style Guide
-
+# Style Guide(راهنمای سبک نوشتن)
در این بخش ها ما به بررسی بخش از عبارات اصطلاحی در نوشتن برنامه به زبان جولیا می پردازیم
.
@@ -13,11 +12,40 @@ are absolute; they are only suggestions to help familiarize you with the languag
you choose among alternative designs.
## Indentation
-
+
+ برای سطح های مختلف
+ indentation
+ از 4 تا اسپیس می توانید استفاده کنید
+ .
+
Use 4 spaces per indentation level.
-## Write functions, not just scripts
-
+## Write functions, not just scripts(نوشتن توابع)
+
+ یکی از راه های سریع حل یک مسئله، نوشتن کد به صورت یک سری گام در بالاترین سطح است ولی بهتر است هر چه سریعتر برنامه خود را به یکسری تابع تقسیم کنید
+ .
+ توابع بهتر از حالت قبل قابل استفاده مجدد و تست شدن هستند
+ ,
+ واینکه چه گام هایی تمام شده اند و چه ورودی ها و خروجی هایی داشتند را مشخص میکنند
+ .
+ در ادامه در زبان جولیا کد های داخل توابع
+ ،
+ سریعتر از کد های سطح اول اجرا می شوند
+ .
+ که این به عملکرد کامپایلر جولیا بازمی گردد
+ .
+
+
+ همین طور تاکیید این نکته مهم است که توابع بهتر است
+ ورودی بگیرند به جای اینکه به صورت
+ global
+ از متغیر ها استفاده کنند
+ .
+ )جدای از ثابت ها مانند
+ [`pi`](@ref)
+ )
+
+
Writing code as a series of steps at the top level is a quick way to get started solving a problem,
but you should try to divide a program into functions as soon as possible. Functions are more
reusable and testable, and clarify what steps are being done and what their inputs and outputs
@@ -29,6 +57,8 @@ on global variables (aside from constants like [`pi`](@ref)).
## Avoid writing overly-specific types
+
+
Code should be as generic as possible. Instead of writing:
```julia
From 90913bd819bde30fee313fe3b2a5c0ac6ea7f0c2 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 16:11:07 +0430
Subject: [PATCH 03/21] Update style-guide.md
---
docs/manual/style-guide.md | 30 ++++++++++++++++++++++++------
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 5a2fb39..f54f751 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -41,11 +41,10 @@ Use 4 spaces per indentation level.
global
از متغیر ها استفاده کنند
.
- )جدای از ثابت ها مانند
- [`pi`](@ref)
- )
+ جدای از ثابت ها مانند
+ [`pi`](@ref)
Writing code as a series of steps at the top level is a quick way to get started solving a problem,
but you should try to divide a program into functions as soon as possible. Functions are more
reusable and testable, and clarify what steps are being done and what their inputs and outputs
@@ -55,22 +54,41 @@ Julia's compiler works.
It is also worth emphasizing that functions should take arguments, instead of operating directly
on global variables (aside from constants like [`pi`](@ref)).
-## Avoid writing overly-specific types
+## Avoid writing overly-specific types(جلوگیری از نوشتن تایپ های بیش از حد مشخص)
+کد باید تا جایی که میتوانیم
+ generic
+ عمومی باشد
+ .
+ به جای رویه زیر
Code should be as generic as possible. Instead of writing:
```julia
Complex{Float64}(x)
```
-
+
+ بهتر است که از توابع در دسترس عمومی
+ )
+ اصطلاحا
+ genenric
+ استفاده شود
+ .
+
it's better to use available generic functions:
```julia
complex(float(x))
```
-
+
+ رویه دوم
+ `x`
+ را به تایپ مورد نظر تبدیل میکند
+ .
+ به جای اینکه همیشه به یک نوع تبدیل کند
+ .
+
The second version will convert `x` to an appropriate type, instead of always the same type.
This style point is especially relevant to function arguments. For example, don't declare an argument
From 9b71cbb6304cc799ae88d3d3ddcab751553639b5 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 16:25:30 +0430
Subject: [PATCH 04/21] Update style-guide.md
---
docs/manual/style-guide.md | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index f54f751..386463f 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -41,10 +41,12 @@ Use 4 spaces per indentation level.
global
از متغیر ها استفاده کنند
.
+ )
جدای از ثابت ها مانند
- [`pi`](@ref)
+ [`pi`](@ref))
+
Writing code as a series of steps at the top level is a quick way to get started solving a problem,
but you should try to divide a program into functions as soon as possible. Functions are more
reusable and testable, and clarify what steps are being done and what their inputs and outputs
@@ -89,6 +91,19 @@ complex(float(x))
به جای اینکه همیشه به یک نوع تبدیل کند
.
+
+ این طرز نوشتن مخصوصا مربوط به ورودی های تابع است
+ .
+ برای مثال ما نوع ارگومان را
+ `Int`
+ یا
+
+ [`Int32`](@ref)
+ در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از اسم گذاری های تابع معتبر نباشد،یک ارور
+ [`MethodError`](@ref)
+ به ما داده میشود
+ .
+
The second version will convert `x` to an appropriate type, instead of always the same type.
This style point is especially relevant to function arguments. For example, don't declare an argument
From e5acb52b65841dc3534d9f7b3830cf8d8a6ed103 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 16:34:50 +0430
Subject: [PATCH 05/21] Update style-guide.md
---
docs/manual/style-guide.md | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 386463f..91875f3 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -7,9 +7,6 @@
انها تنها برای کمک به اشنا شدن شما با زبان و کمک برای انتخاب بین راه حل های طراحی موجود است
.
-The following sections explain a few aspects of idiomatic Julia coding style. None of these rules
-are absolute; they are only suggestions to help familiarize you with the language and to help
-you choose among alternative designs.
## Indentation
@@ -18,7 +15,6 @@ you choose among alternative designs.
از 4 تا اسپیس می توانید استفاده کنید
.
-Use 4 spaces per indentation level.
## Write functions, not just scripts(نوشتن توابع)
@@ -45,6 +41,7 @@ Use 4 spaces per indentation level.
جدای از ثابت ها مانند
+
[`pi`](@ref))
Writing code as a series of steps at the top level is a quick way to get started solving a problem,
@@ -103,7 +100,7 @@ complex(float(x))
[`MethodError`](@ref)
به ما داده میشود
.
-
+ Duck typing
The second version will convert `x` to an appropriate type, instead of always the same type.
This style point is especially relevant to function arguments. For example, don't declare an argument
From e0db5f37c6844719cd63d09f0a213f44eb4a983e Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 17:08:14 +0430
Subject: [PATCH 06/21] Update style-guide.md
---
docs/manual/style-guide.md | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 91875f3..662a28a 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -43,12 +43,6 @@
[`pi`](@ref))
-
-Writing code as a series of steps at the top level is a quick way to get started solving a problem,
-but you should try to divide a program into functions as soon as possible. Functions are more
-reusable and testable, and clarify what steps are being done and what their inputs and outputs
-are. Furthermore, code inside functions tends to run much faster than top level code, due to how
-Julia's compiler works.
It is also worth emphasizing that functions should take arguments, instead of operating directly
on global variables (aside from constants like [`pi`](@ref)).
@@ -62,7 +56,6 @@ on global variables (aside from constants like [`pi`](@ref)).
.
به جای رویه زیر
-Code should be as generic as possible. Instead of writing:
```julia
Complex{Float64}(x)
@@ -75,7 +68,6 @@ Complex{Float64}(x)
استفاده شود
.
-it's better to use available generic functions:
```julia
complex(float(x))
@@ -94,6 +86,12 @@ complex(float(x))
برای مثال ما نوع ارگومان را
`Int`
یا
+ Int32
+ در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از
+اسم گذاری های تابع معتبر نباشد،یک ارور
+ MethodError
+ به ما داده میشود
+ .
[`Int32`](@ref)
در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از اسم گذاری های تابع معتبر نباشد،یک ارور
From 293b1353efebb08c822bc02ba78db6b193834e71 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 17:10:27 +0430
Subject: [PATCH 07/21] Update style-guide.md
---
docs/manual/style-guide.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 662a28a..db33dac 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -89,7 +89,7 @@ complex(float(x))
Int32
در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از
اسم گذاری های تابع معتبر نباشد،یک ارور
- MethodError
+ MethodError
به ما داده میشود
.
From 9d3b2dd52a01e9b558e749eacda11d788dbc1421 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 17:14:37 +0430
Subject: [PATCH 08/21] Update style-guide.md
---
docs/manual/style-guide.md | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index db33dac..682538f 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -44,9 +44,6 @@
[`pi`](@ref))
-It is also worth emphasizing that functions should take arguments, instead of operating directly
-on global variables (aside from constants like [`pi`](@ref)).
-
## Avoid writing overly-specific types(جلوگیری از نوشتن تایپ های بیش از حد مشخص)
@@ -86,6 +83,7 @@ complex(float(x))
برای مثال ما نوع ارگومان را
`Int`
یا
+
Int32
Int32
در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از
اسم گذاری های تابع معتبر نباشد،یک ارور
From a088b65c11661a44add1326261273d3c2d7534c9 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 17:16:46 +0430
Subject: [PATCH 09/21] Update style-guide.md
---
docs/manual/style-guide.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 682538f..bcaf820 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -83,11 +83,11 @@ complex(float(x))
برای مثال ما نوع ارگومان را
`Int`
یا
-
Int32
-
Int32
+
Int32
+
در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از
اسم گذاری های تابع معتبر نباشد،یک ارور
-
MethodError
+
MethodError
به ما داده میشود
.
From 371a3bed7c5daf2ad5168dec24345fa1c3de6315 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 19:06:34 +0430
Subject: [PATCH 10/21] Update style-guide.md
---
docs/manual/style-guide.md | 163 ++++++++++++++++++++++++++++++-------
1 file changed, 132 insertions(+), 31 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index bcaf820..f7dc89e 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -83,30 +83,24 @@ complex(float(x))
برای مثال ما نوع ارگومان را
`Int`
یا
- Int32
+ Int32
در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از
اسم گذاری های تابع معتبر نباشد،یک ارور
MethodError
به ما داده میشود
.
-
- [`Int32`](@ref)
- در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از اسم گذاری های تابع معتبر نباشد،یک ارور
- [`MethodError`](@ref)
- به ما داده میشود
+ به این مسئله
+ duck typing
+ می گویند
.
- Duck typing
-The second version will convert `x` to an appropriate type, instead of always the same type.
-
-This style point is especially relevant to function arguments. For example, don't declare an argument
-to be of type `Int` or [`Int32`](@ref) if it really could be any integer, expressed with the abstract
-type [`Integer`](@ref). In fact, in many cases you can omit the argument type altogether,
-unless it is needed to disambiguate from other method definitions, since a
-[`MethodError`](@ref) will be thrown anyway if a type is passed that does not support any
-of the requisite operations. (This is known as
-[duck typing](https://en.wikipedia.org/wiki/Duck_typing).)
-
+
+
+ برای مثال تعریف زیر را برای تابع
+ addone
+ در نظر بگیرید که عدد یک را با ارگومان ورودیش جمع می کند
+ :
+
For example, consider the following definitions of a function `addone` that returns one plus its
argument:
@@ -116,7 +110,42 @@ addone(x::Integer) = x + oneunit(x) # any integer type
addone(x::Number) = x + oneunit(x) # any numeric type
addone(x) = x + oneunit(x) # any type supporting + and oneunit
```
-
+
+ اخرین تعریف
+ addone
+ برای تمام ارگومان ها از نوع
+
oneunit
+ )
+ که یکی را برمی گرداند که هم نوع
+ 'x'
+ باشد که از تایپی که مناسب نباشد و در نتیجه به ارور برخورد کردن خودداری میکند
+ وتابع
+
'+'
+ با ان ارگومان اجرا میشود
+ .
+ نکته مهم این است که ما هیچ مشکلی در اجرا و عملکرد
+ `addone(x) = x + oneunit(x)`
+ نسبت به حالتی که تایپ را بنویسیم نداریم
+ )
+ به طور اصطلاح
+we dont have performance penalty
+ (
+ چون جولیا به طور اتوماتیک تابع
+ `addone`
+ را به ازای ارگومان
+ `x::Int`
+ صدا میزند
+ و
+ `oneunit`
+ با
+ 1
+ جایگزین می شود
+ .
+ بنابراین هر سه تعریف اول از تابع
+ `addone`
+ به طور کامل به تعریف چهارم کاهش می یابند
+ .
+
The last definition of `addone` handles any type supporting [`oneunit`](@ref) (which returns 1 in
the same type as `x`, which avoids unwanted type promotion) and the [`+`](@ref) function with
those arguments. The key thing to realize is that there is *no performance penalty* to defining
@@ -126,8 +155,12 @@ compile a specialized `addone` function for `x::Int` arguments, with the call to
replaced by its inlined value `1`. Therefore, the first three definitions of `addone` above are
completely redundant with the fourth definition.
-## Handle excess argument diversity in the caller
+## Handle excess argument diversity in the caller(تعدد ارگومان در تابع)
+
+ به جای
+ :
+
Instead of:
```julia
@@ -137,7 +170,10 @@ function foo(x, y)
end
foo(x, y)
```
-
+
+ از این کد استفاده کنید
+ :
+
use:
```julia
@@ -146,16 +182,37 @@ function foo(x::Int, y::Int)
end
foo(Int(x), Int(y))
```
-
+
+ این سبک نوشتن بهتر است زیرا دیگر ارگومان هایی از نوع دیگر را قبول نمیکند و باعث اشتباه کمتر برنامه نویس می شود
+ .
+ وفقط نوع
+ `Int`
+ را قبول میکند
+ .
+
This is better style because `foo` does not really accept numbers of all types; it really needs
`Int` s.
-
+
+ یک مسئله اینجا این است که این تابع به صورت ذاتی فقط
+ integer
+ قبول میکند
+ .
+ شاید بهتر بود تابع تضمیم بگیرد که با
+ non-integers
+ چگونه تصمیم بگیرد
+ (مانند کف یا سقف گرفتن عمل کند)
+ مسئله دیگر این است که این دقیق مشخص کردن نوع ورودی ارگومان توابع ابتکار عمل را برای تعاریف بدی تابع می گیرد
+ .
+
One issue here is that if a function inherently requires integers, it might be better to force
the caller to decide how non-integers should be converted (e.g. floor or ceiling). Another issue
is that declaring more specific types leaves more "space" for future method definitions.
## [Append `!` to names of functions that modify their arguments]
-
+
+ به جای
+ :
+
Instead of:
```julia
@@ -166,7 +223,10 @@ function double(a::AbstractArray{<:Number})
return a
end
```
-
+
+ از این کد استفاده کنید
+ :
+
use:
```julia
@@ -177,29 +237,68 @@ function double!(a::AbstractArray{<:Number})
return a
end
```
-
+
+Julia Base
+ از این روش مرسوم استفاده میکند و توابعی با هر دو صورت کپی شده و اصلاح شده استفاده میکند
+ .
+
+ (e.g., [`sort`](@ref) and [`sort!`](@ref))
+
+و بقیه فقط فزم اصلاح شده اند
+ .
+ و این برای چنین توابعی عادی است که ارایه اصلاح شده را برگردانند
+ .
+
+ (e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref))
+
Julia Base uses this convention throughout and contains examples of functions
with both copying and modifying forms (e.g., [`sort`](@ref) and [`sort!`](@ref)), and others
which are just modifying (e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref)). It
is typical for such functions to also return the modified array for convenience.
-## Avoid strange type `Union`s
-
+## Avoid strange type `Union`s(از نوع های عجیب "اجتماع " دوری کنید)
+
+ تایپ ها یا نوع هایی مثل
+ `Union{Function,AbstractString}`
+ نشانه هایی هستند که طراحی شما میتوانست بهتر و تمیز تر باشد
+ .
+
Types such as `Union{Function,AbstractString}` are often a sign that some design could be cleaner.
-## Avoid elaborate container types
-
+## Avoid elaborate container types(از نوع های در برگیرنده پیچیده بپرهیزید)
+
+ معمولا ساخت ارایه به صورت زیر کمک شایانی نمی کند
+ :
+
It is usually not much help to construct arrays like the following:
```julia
a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
```
-
+
+ در این حالت
+ `Vector{Any}(undef, n)`
+ بهتر است .
+ و همچنین برای کامپایلر کمک کننده تراست که یک حاشیه نویسی هایی به صورت زیر انجام دهد که
+ بسیاری از نوع های جایگزین را به یک نوع تبدیل کند
+ .
+
+ (e.g. `a[i]::Int`)
+
In this case `Vector{Any}(undef, n)` is better. It is also more helpful to the compiler to annotate specific
uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type.
## Use naming conventions consistent with Julia `base/`
-
+
+ *
+ ماژول ها و نوع متغیر ها از حروف بزرگ تشکیل شده اند و در اصطلاح
+ camel case
+ هستند برای مثال
+ `module SparseArrays`
+ و
+ `struct UnitRange`
+ *
+
* modules and type names use capitalization and camel case: `module SparseArrays`, `struct UnitRange`.
* functions are lowercase ([`maximum`](@ref), [`convert`](@ref)) and, when readable, with multiple
words squashed together ([`isequal`](@ref), [`haskey`](@ref)). When necessary, use underscores
@@ -208,6 +307,8 @@ uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type.
* conciseness is valued, but avoid abbreviation ([`indexin`](@ref) rather than `indxin`) as
it becomes difficult to remember whether and how particular words are abbreviated.
+
+
If a function name requires multiple words, consider whether it might represent more than one
concept and might be better split into pieces.
From bf010faaa42f4e2ac152c74b4613d7565c0df399 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 19:09:23 +0430
Subject: [PATCH 11/21] Update style-guide.md
---
docs/manual/style-guide.md | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index f7dc89e..b70b87f 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -146,14 +146,6 @@ we dont have performance penalty
به طور کامل به تعریف چهارم کاهش می یابند
.
-The last definition of `addone` handles any type supporting [`oneunit`](@ref) (which returns 1 in
-the same type as `x`, which avoids unwanted type promotion) and the [`+`](@ref) function with
-those arguments. The key thing to realize is that there is *no performance penalty* to defining
-*only* the general `addone(x) = x + oneunit(x)`, because Julia will automatically compile specialized
-versions as needed. For example, the first time you call `addone(12)`, Julia will automatically
-compile a specialized `addone` function for `x::Int` arguments, with the call to `oneunit`
-replaced by its inlined value `1`. Therefore, the first three definitions of `addone` above are
-completely redundant with the fourth definition.
## Handle excess argument diversity in the caller(تعدد ارگومان در تابع)
@@ -190,8 +182,6 @@ foo(Int(x), Int(y))
را قبول میکند
.
-This is better style because `foo` does not really accept numbers of all types; it really needs
-`Int` s.
یک مسئله اینجا این است که این تابع به صورت ذاتی فقط
integer
@@ -204,9 +194,6 @@ This is better style because `foo` does not really accept numbers of all types;
مسئله دیگر این است که این دقیق مشخص کردن نوع ورودی ارگومان توابع ابتکار عمل را برای تعاریف بدی تابع می گیرد
.
-One issue here is that if a function inherently requires integers, it might be better to force
-the caller to decide how non-integers should be converted (e.g. floor or ceiling). Another issue
-is that declaring more specific types leaves more "space" for future method definitions.
## [Append `!` to names of functions that modify their arguments]
@@ -238,10 +225,12 @@ function double!(a::AbstractArray{<:Number})
end
```
-Julia Base
+همچنین
+ Julia Base
از این روش مرسوم استفاده میکند و توابعی با هر دو صورت کپی شده و اصلاح شده استفاده میکند
.
+
(e.g., [`sort`](@ref) and [`sort!`](@ref))
و بقیه فقط فزم اصلاح شده اند
From 43b5917cb2b0f3e832676155cf5838c5aa90dad3 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 19:11:33 +0430
Subject: [PATCH 12/21] Update style-guide.md
---
docs/manual/style-guide.md | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index b70b87f..d4f6d4a 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -101,8 +101,7 @@ complex(float(x))
در نظر بگیرید که عدد یک را با ارگومان ورودیش جمع می کند
:
-For example, consider the following definitions of a function `addone` that returns one plus its
-argument:
+
```julia
addone(x::Int) = x + 1 # works only for Int
@@ -238,12 +237,9 @@ end
و این برای چنین توابعی عادی است که ارایه اصلاح شده را برگردانند
.
+
(e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref))
-Julia Base uses this convention throughout and contains examples of functions
-with both copying and modifying forms (e.g., [`sort`](@ref) and [`sort!`](@ref)), and others
-which are just modifying (e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref)). It
-is typical for such functions to also return the modified array for convenience.
## Avoid strange type `Union`s(از نوع های عجیب "اجتماع " دوری کنید)
@@ -252,14 +248,12 @@ is typical for such functions to also return the modified array for convenience.
نشانه هایی هستند که طراحی شما میتوانست بهتر و تمیز تر باشد
.
-Types such as `Union{Function,AbstractString}` are often a sign that some design could be cleaner.
## Avoid elaborate container types(از نوع های در برگیرنده پیچیده بپرهیزید)
معمولا ساخت ارایه به صورت زیر کمک شایانی نمی کند
:
-It is usually not much help to construct arrays like the following:
```julia
a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
From 900313d9ad98e02b77c0a4573524832e4fa33b71 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 19:36:40 +0430
Subject: [PATCH 13/21] Update style-guide.md
---
docs/manual/style-guide.md | 65 +++++++++++++++++++++++++++++++-------
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index d4f6d4a..b0eba5e 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -280,31 +280,74 @@ uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type.
`module SparseArrays`
و
`struct UnitRange`
+
*
-
- * modules and type names use capitalization and camel case: `module SparseArrays`, `struct UnitRange`.
- * functions are lowercase ([`maximum`](@ref), [`convert`](@ref)) and, when readable, with multiple
- words squashed together ([`isequal`](@ref), [`haskey`](@ref)). When necessary, use underscores
- as word separators. Underscores are also used to indicate a combination of concepts ([`remotecall_fetch`](@ref)
- as a more efficient implementation of `fetch(remotecall(...))`) or as modifiers.
- * conciseness is valued, but avoid abbreviation ([`indexin`](@ref) rather than `indxin`) as
- it becomes difficult to remember whether and how particular words are abbreviated.
+ توابع با حروف کوچک یا به اصطلاح
+ lowercase
+ هستند
+ .
+ مانند
+ `maximum`
+ و
+ `convert`
+ و وقتی از چند کلمه تشکیل شده باشد
+ مانند
+ `isequal`
+ و
+ `haskey`
+ .
+ اگر لازم بود
+ از
+ underscore
+ به عنوان کلمه جدا کن استفاده منید
+ .
+ underscores
+ معمولا برای نشان دادن ترکیب چند موضوع استفاده می شوند
+ مثلا
+ `remotecall_fetch`
+ ورژن با عملکرد بهتر برای تابع
+ `fetch(remotecall(...))`
+ است
+ .
+
+ *
+ مختصر نوشتن خیلی خوب است ولی از خلاصه نویسی بپرهیزید برای مثال
+ `indexin`
+ بهتر است از
+ `indxin`
+ چون باعث میشود سخت تر به یاد بیاوریم که هر لغت مختصر شده کدام کلمه است
+ .
+
+
+ اگربرای اسم یک تابع به چند کلمه نیاز داشتید ،این موضوع را که به چند تا موضوع مربوط است و بهتر است انها را به چند تا تابع تقسیم کنید
+ .
-If a function name requires multiple words, consider whether it might represent more than one
-concept and might be better split into pieces.
## Write functions with argument ordering similar to Julia Base
-
+
+ به عنوان قانونی کلی کتابخانه
+ BASE
+ از ترتیب زیر برای ارگومان های تابع استفاده میکند.
+ :
+
As a general rule, the Base library uses the following order of arguments to functions,
as applicable:
+1. **ارگومان تابع**.
+
1. **Function argument**.
+
+
+
Putting a function argument first permits the use of [`do`](@ref) blocks for passing
multiline anonymous functions.
2. **I/O stream**.
+
+
+
Specifying the `IO` object first permits passing the function to functions such as
[`sprint`](@ref), e.g. `sprint(show, x)`.
From 9c9c63cf2871c7eb558b0f5f46c43dff60123e82 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 21:56:56 +0430
Subject: [PATCH 14/21] Update style-guide.md
---
docs/manual/style-guide.md | 230 ++++++++++++++++++++++++++++---------
1 file changed, 178 insertions(+), 52 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index b0eba5e..519f838 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -266,11 +266,9 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
بسیاری از نوع های جایگزین را به یک نوع تبدیل کند
.
+
(e.g. `a[i]::Int`)
-In this case `Vector{Any}(undef, n)` is better. It is also more helpful to the compiler to annotate specific
-uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type.
-
## Use naming conventions consistent with Julia `base/`
*
@@ -332,57 +330,156 @@ uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type.
از ترتیب زیر برای ارگومان های تابع استفاده میکند.
:
-As a general rule, the Base library uses the following order of arguments to functions,
-as applicable:
-
1. **ارگومان تابع**.
-
-1. **Function argument**.
-
+اضافه کردن ارگومان تابع به ما اجازه میدهد که از بلاک
+ do
+ استفاده کنیم .
+ برای اجرا کردن توابع چندخطی
+ anonymous
+ .
- Putting a function argument first permits the use of [`do`](@ref) blocks for passing
- multiline anonymous functions.
2. **I/O stream**.
-
+مشخص کردن اینکه اشیا
+ `IO`
+ اجازه میدهند تابع به توابع دیگر مثل
+ `sprint(show, x)`
+ پاس داده شود
+ .
- Specifying the `IO` object first permits passing the function to functions such as
- [`sprint`](@ref), e.g. `sprint(show, x)`.
-
+
+ [`sprint`](@ref)
3. **Input being mutated**.
- For example, in [`fill!(x, v)`](@ref fill!), `x` is the object being mutated and it
- appears before the value to be inserted into `x`.
+
+برای مثال در تابع
+
`fill!(x, v)`
+ متغیر
+ `x`
+ شئ است که جهش یافته
+ (mutated)
+ و قبل از مقدار قرار داده شده در
+ `x`
+ ظاهر میشود
+ .
+
4. **Type**.
- Passing a type typically means that the output will have the given type.
- In [`parse(Int, "1")`](@ref parse), the type comes before the string to parse.
- There are many such examples where the type appears first, but it's useful to note that
- in [`read(io, String)`](@ref read), the `IO` argument appears before the type, which is
- in keeping with the order outlined here.
+
+پاس دادن یک تایپ (یا نوع)به طور عادی به این معنی است که خروجی ما به طور عادی به صورت همان نوع داده شده است .
+ در تابع
+
`parse(Int, "1")`
+ تایپ مورد نظر قبل از رشته ای که باید
+ parse
+ شود می اید
+ .
+ در بسیاری از مثال ها که نوع خروجب اول می اید ولی مفید است که ذکر کنیم که
+ ارگومان
+ `IO`
+ در تابع
+
`read(io, String)`
+ قبل از تایپ (نوع) ظاهر می شود که مطابق ترتیب ذکر شده در اینجاست
+ .
+
5. **Input not being mutated**.
- In `fill!(x, v)`, `v` is *not* being mutated and it comes after `x`.
+
+در تابع
+
`fill!(x, v)`
+ متغیر
+ `v`
+ تغییر نکرده و بعد از
+ `x`
+ می اید
+ .
+
6. **Key**.
- For associative collections, this is the key of the key-value pair(s).
- For other indexed collections, this is the index.
+
+برای مجموعه های انجمنی به اصطلاح
+ (associative)
+ این کلید زوج های کلید-مقدار
+ s
+ است و برای سایر مجموعه ها بیان کننده شماره
+ (index)
+ است.
+
7. **Value**.
- For associative collections, this is the value of the key-value pair(s).
- In cases like [`fill!(x, v)`](@ref fill!), this is `v`.
-
+
+برای مجموعه های انجمنی به اصطلاح
+ (associative)
+ این مقدار زوج های کلید-مقدار
+ s
+ است و
+ در حالاتی مثل
+
`fill!(x, v)`
+ همان
+ 'v'
+ است
+ .
+
8. **Everything else**.
+
+هر ارگومان دیگری
+
Any other arguments.
9. **Varargs**.
+
+
+این اصطلاح به ارگومان هایی اشاره می کند که در انتهای فرایند صدا شدن
+ (call)
+ تابع
+ قابل لیست شدن باشند
+ .
+ به عنوان مثال در
+ `Matrix{T}(undef, dims)`
+ ابعاد ماتریس میتوانند به عنوان یک
+
`Tuple`
+ یعنی
+ `Matrix{T}(undef, (1,2))
+ یا به عنوان
+ `Vararg`](@ref)s,
+ e.g. `Matrix{T}(undef, 1, 2)`.
+
This refers to arguments that can be listed indefinitely at the end of a function call.
For example, in `Matrix{T}(undef, dims)`, the dimensions can be given as a
[`Tuple`](@ref), e.g. `Matrix{T}(undef, (1,2))`, or as [`Vararg`](@ref)s,
e.g. `Matrix{T}(undef, 1, 2)`.
10. **Keyword arguments**.
+
+ در جولیا ارگومان های کیبورد باید در هر صورت در اخر تعریف توابع بیایند
+ .
+ انها برای کامل شدن مطلب ابنجا ذکر شده اند
+ .
+
+ اکثر قریب به اتفاق توابع از هر نوع ارگومان ذکر شده در بالا استفاده نمی کنند
+ .
+ اعداد صرفاً تقدم را نشان می دهند که باید برای هر ارگومان قابل استفاده یک تابع استفاده شود
+
+ بدیهی است مقدار کمی استثنا وجود دارد.
+
+ برای مثال در تابع
+
`convert`
+ تایپ (یا نوع )خروجی همیشه بایداول بیاید
+ .
+ در تابع
+
`setindex!`
+ مقدار قبل از اندیس ها می اید پس می توانند به عنوان
+ varargs
+ در نظر گرفته شوند
+ .
+
+ درهنگام طراحی
+ API
+ ها
+ ،
+ پایبندی به این دستور کلی تا آنجا که ممکن است احتمالاً به کاربران شما تجربه سازگارتری میدهد
+ .
+
In Julia keyword arguments have to come last anyway in function definitions; they're
listed here for the sake of completeness.
@@ -398,18 +495,21 @@ provided as varargs.
When designing APIs, adhering to this general order as much as possible is likely to give
users of your functions a more consistent experience.
-## Don't overuse try-catch
-
+## Don't overuse try-catch(بیش از اندازه استفاده نکنید)
+
+
It is better to avoid errors than to rely on catching them.
## Don't parenthesize conditions
-
+
+
Julia doesn't require parens around conditions in `if` and `while`. Write:
```julia
if a == b
```
-
+
+
instead of:
```julia
@@ -417,25 +517,29 @@ if (a == b)
```
## Don't overuse `...`
-
+
+
Splicing function arguments can be addictive. Instead of `[a..., b...]`, use simply `[a; b]`,
which already concatenates arrays. [`collect(a)`](@ref) is better than `[a...]`, but since `a`
is already iterable it is often even better to leave it alone, and not convert it to an array.
## Don't use unnecessary static parameters
-
+
+
A function signature:
```julia
foo(x::T) where {T<:Real} = ...
```
-
+
+
should be written as:
```julia
foo(x::Real) = ...
```
-
+
+
instead, especially if `T` is not used in the function body. Even if `T` is used, it can be replaced
with [`typeof(x)`](@ref) if convenient. There is no performance difference. Note that this is
not a general caution against static parameters, just against uses where they are not needed.
@@ -444,14 +548,16 @@ Note also that container types, specifically may need type parameters in functio
FAQ [Avoid fields with abstract containers](@ref) for more information.
## Avoid confusion about whether something is an instance or a type
-
+
+
Sets of definitions like the following are confusing:
```julia
foo(::Type{MyType}) = ...
foo(::MyType) = foo(MyType)
```
-
+
+
Decide whether the concept in question will be written as `MyType` or `MyType()`, and stick to
it.
@@ -464,7 +570,8 @@ whether values are valid. This design is preferred over making the enumeration a
with the "values" as subtypes.
## Don't overuse macros
-
+
+
Be aware of when a macro could really be a function instead.
Calling [`eval`](@ref) inside a macro is a particularly dangerous warning sign; it means the
@@ -472,7 +579,8 @@ macro will only work when called at the top level. If such a macro is written as
it will naturally have access to the run-time values it needs.
## Don't expose unsafe operations at the interface level
-
+
+
If you have a type that uses a native pointer:
```julia
@@ -481,13 +589,15 @@ mutable struct NativeType
...
end
```
-
+
+
don't write definitions like the following:
```julia
getindex(x::NativeType, i) = unsafe_load(x.p, i)
```
-
+
+
The problem is that users of this type can write `x[i]` without realizing that the operation is
unsafe, and then be susceptible to memory bugs.
@@ -495,7 +605,8 @@ Such a function should either check the operation to ensure it is safe, or have
in its name to alert callers.
## Don't overload methods of base container types
-
+
+
It is possible to write definitions like the following:
```julia
@@ -507,7 +618,8 @@ this should be avoided. The trouble is that users will expect a well-known type
to behave in a certain way, and overly customizing its behavior can make it harder to work with.
## Avoid type piracy
-
+
+
"Type piracy" refers to the practice of extending or redefining methods in Base
or other packages on types that you have not defined. In some cases, you can get away with
type piracy with little ill effect. In extreme cases, however, you can even crash Julia
@@ -523,7 +635,8 @@ import Base.*
*(x::Symbol, y::Symbol) = Symbol(x,y)
end
```
-
+
+
The problem is that now any other module that uses `Base.*` will also see this definition.
Since `Symbol` is defined in Base and is used by other modules, this can change the
behavior of unrelated code unexpectedly. There are several alternatives here, including
@@ -538,19 +651,22 @@ wrapper for some C code, which another package might then pirate to implement a
higher-level, Julia-friendly API.
## Be careful with type equality
-
+
+
You generally want to use [`isa`](@ref) and [`<:`](@ref) for testing types,
not `==`. Checking types for exact equality typically only makes sense when comparing to a known
concrete type (e.g. `T == Float64`), or if you *really, really* know what you're doing.
## Do not write `x->f(x)`
-
+
+
Since higher-order functions are often called with anonymous functions, it is easy to conclude
that this is desirable or even necessary. But any function can be passed directly, without being
"wrapped" in an anonymous function. Instead of writing `map(x->f(x), a)`, write [`map(f, a)`](@ref).
## Avoid using floats for numeric literals in generic code when possible
-
+
+
If you write generic code which handles numbers, and which can be expected to run with many different
numeric type arguments, try using literals of a numeric type that will affect the arguments as
little as possible through promotion.
@@ -570,8 +686,9 @@ julia> f(1/2)
julia> f(1)
2.0
```
-
-while
+
+ هنگامی که
+
```jldoctest
julia> g(x) = 2 * x
@@ -586,7 +703,8 @@ julia> g(1/2)
julia> g(1)
2
```
-
+
+
As you can see, the second version, where we used an `Int` literal, preserved the type of the
input argument, while the first didn't. This is because e.g. `promote_type(Int, Float64) == Float64`,
and promotion happens with the multiplication. Similarly, [`Rational`](@ref) literals are less type disruptive
@@ -605,6 +723,14 @@ julia> h(1/2)
julia> h(1)
2//1
```
-
+
+ پس به منظور سادگی استفاده از کد شما
+ در صورت امکان از کلمات
+ 'Int'
+ و برای اعداد غیر صحیح از
+ `Rational{Int}`
+ استفاده کنید
+ .
+
Thus, use `Int` literals when possible, with `Rational{Int}` for literal non-integer numbers,
in order to make it easier to use your code.
From a8baed6c3536f2d0bcfe2caf35fe0c3056b11c12 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Fri, 9 Jul 2021 22:10:14 +0430
Subject: [PATCH 15/21] Update style-guide.md
---
docs/manual/style-guide.md | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 519f838..9ef54e7 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -480,28 +480,26 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
پایبندی به این دستور کلی تا آنجا که ممکن است احتمالاً به کاربران شما تجربه سازگارتری میدهد
.
- In Julia keyword arguments have to come last anyway in function definitions; they're
- listed here for the sake of completeness.
-
-The vast majority of functions will not take every kind of argument listed above; the
-numbers merely denote the precedence that should be used for any applicable arguments
-to a function.
-
-There are of course a few exceptions.
-For example, in [`convert`](@ref), the type should always come first.
-In [`setindex!`](@ref), the value comes before the indices so that the indices can be
-provided as varargs.
-
-When designing APIs, adhering to this general order as much as possible is likely to give
-users of your functions a more consistent experience.
## Don't overuse try-catch(بیش از اندازه استفاده نکنید)
+ بهتر است از گرفتن خطا اجتناب کنید تا اینکه انهارا
+ catch
+ کنید
+ .
It is better to avoid errors than to rely on catching them.
-## Don't parenthesize conditions
+## Don't parenthesize conditions(شرط ها را با پرانتز ننویسید)
+ جولیا نیازی به پرانتز برای نوشتن شرط ها در
+ if
+ و
+ while
+ نیازی ندارد
+ .
+ بنویسید
+ :
Julia doesn't require parens around conditions in `if` and `while`. Write:
@@ -509,8 +507,10 @@ Julia doesn't require parens around conditions in `if` and `while`. Write:
if a == b
```
+ به جای
+ :
-instead of:
+
```julia
if (a == b)
From 9f823eb8851ec36f98f39001c4fa6f0e631b9d07 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 00:13:39 +0430
Subject: [PATCH 16/21] Update style-guide.md
---
docs/manual/style-guide.md | 127 ++++++++++++++++++++++++++-----------
1 file changed, 91 insertions(+), 36 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 9ef54e7..1ad3dd7 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -152,7 +152,7 @@ we dont have performance penalty
به جای
:
-Instead of:
+
```julia
function foo(x, y)
@@ -165,7 +165,6 @@ foo(x, y)
از این کد استفاده کنید
:
-use:
```julia
function foo(x::Int, y::Int)
@@ -199,7 +198,6 @@ foo(Int(x), Int(y))
به جای
:
-Instead of:
```julia
function double(a::AbstractArray{<:Number})
@@ -213,7 +211,6 @@ end
از این کد استفاده کنید
:
-use:
```julia
function double!(a::AbstractArray{<:Number})
@@ -351,6 +348,7 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
[`sprint`](@ref)
+
3. **Input being mutated**.
برای مثال در تابع
@@ -420,6 +418,7 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
است
.
+
8. **Everything else**.
هر ارگومان دیگری
@@ -444,10 +443,6 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
`Vararg`](@ref)s,
e.g. `Matrix{T}(undef, 1, 2)`.
- This refers to arguments that can be listed indefinitely at the end of a function call.
- For example, in `Matrix{T}(undef, dims)`, the dimensions can be given as a
- [`Tuple`](@ref), e.g. `Matrix{T}(undef, (1,2))`, or as [`Vararg`](@ref)s,
- e.g. `Matrix{T}(undef, 1, 2)`.
10. **Keyword arguments**.
@@ -488,7 +483,6 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
کنید
.
-It is better to avoid errors than to rely on catching them.
## Don't parenthesize conditions(شرط ها را با پرانتز ننویسید)
@@ -501,7 +495,6 @@ It is better to avoid errors than to rely on catching them.
بنویسید
:
-Julia doesn't require parens around conditions in `if` and `while`. Write:
```julia
if a == b
@@ -516,61 +509,123 @@ if a == b
if (a == b)
```
-## Don't overuse `...`
-
+## Don't overuse `...`(دوباره استفاده نکنید)
+
+ اتصال
+ ارگومان توابع یا به اصطلاح
+ (splicing)
+ میتواند کاری خطرناک باشد
+ .
+ به جای
+ [a..., b...]
+ به سادگی از
+ [a; b]
+ استفاده کنید که خودش عمل
+ concatation
+ را برای ارایه انجام میدهد.
+ collect(a)
+ بهتر از
+ [a...]
+ است ولی زمانی که
+ a
+ خودش قابل تکرار است ،معمولا بهتر است که انها را خودش انجام دهیم و به ارایه تبدیل نکنیم
+ .
+
+
+
-Splicing function arguments can be addictive. Instead of `[a..., b...]`, use simply `[a; b]`,
-which already concatenates arrays. [`collect(a)`](@ref) is better than `[a...]`, but since `a`
-is already iterable it is often even better to leave it alone, and not convert it to an array.
-## Don't use unnecessary static parameters
+## Don't use unnecessary static parameters(از پارامترهای غیر ضروری استاتیک استفاده نکنید)
+ امضای تابع
+ :
-A function signature:
```julia
foo(x::T) where {T<:Real} = ...
```
+ بهتر است بدین صورت نوشته شود
+ :
-should be written as:
```julia
foo(x::Real) = ...
```
-
-instead, especially if `T` is not used in the function body. Even if `T` is used, it can be replaced
-with [`typeof(x)`](@ref) if convenient. There is no performance difference. Note that this is
-not a general caution against static parameters, just against uses where they are not needed.
+ در مقابل ،مخصوصا اگر
+ T
+ در بدنه تابع استفاده نشده باشد، حتی اگر استفاده شدهباشد در صورت راحتی میتواند با
+
typeof(x)
+ جایگزین شود
+و از لحاظ عملکردی فرقی ندارند.
+ توجه داشته باشید که این یک احتیاط کلی و عمومی در برابر پارامترهای استاتیک نیست بلکه فقط درمقابل مواقعی است که استفاده از انها لازم نباشد.
+
+توجه داشته باشید که تایپ های دربرگیرنده
+ container types
+ به طور ویژهاحتیاج به تایپ پارامتر در صدا زدن تابع دارند .
+ برای اطلاعات بیشتر به
+
Avoid fields with abstract containers
+ مراجعه کنید.
-Note also that container types, specifically may need type parameters in function calls. See the
-FAQ [Avoid fields with abstract containers](@ref) for more information.
+
-## Avoid confusion about whether something is an instance or a type
+## Avoid confusion about whether something is an instance or a type(سردرگمی تایپ و نمونه )
+ مجموعه ای از تعاریف مانند تعاریف زیر گیج کننده هستند
+ :
-Sets of definitions like the following are confusing:
```julia
foo(::Type{MyType}) = ...
foo(::MyType) = foo(MyType)
```
-
-Decide whether the concept in question will be written as `MyType` or `MyType()`, and stick to
-it.
+ تصمیم بگیرید که ایا مفهوم و موضوع مورد سوال به صورت
+ MyType
+ یا
+ MyType()
+ قابل نوشت است و از ان پیروی کنید.
+
+ استایل و طراحی موردنظر ما استفاده پیش فرض از نمونه ها واگر واقعا اضافه کردن انها برای حل مسئله لازم بود ،بعدا فقط افزودن متد هایی که شامل
+ Type{MyType}
+ می شوند
+ .
+
+ اگر تایپ به صورت موثر یک شکارشگر
+ enum
+ باشد بهتر است به صورت تایپ تکی
+ (single type )
+ تعریف شود.
+ البته در حالت ایده ال)
+ بهتر است
+ immutable
+ (باشد
+با مقدار شمارش شده
+ (enumration value)
+ یک نمونه یا شی از ان باشد کانستراکتور ها و کانورژن ها می توانند چک کنند که لیل مقادیر قابل اطمینان هستندد یا خیر .
+ این طراحی نسبت به حالتی که
+ enum
+ هارا یک تایپ ابسترکت تعریف کرده و "مقادیر" را به صورت زیر نوع تعریف کنیم ، بهتر است .
+
-The preferred style is to use instances by default, and only add methods involving `Type{MyType}`
-later if they become necessary to solve some problems.
-If a type is effectively an enumeration, it should be defined as a single (ideally immutable struct or primitive)
-type, with the enumeration values being instances of it. Constructors and conversions can check
-whether values are valid. This design is preferred over making the enumeration an abstract type,
-with the "values" as subtypes.
+
-## Don't overuse macros
+## Don't overuse macros(زیاد از کاکرو استفاده نکنید)
+ باید بدانیم که چه موقع یک ماکرو میتواند یک تابع به حساب اید .
+
+ صدا کردن
+
eval
+ داخل یک ماکرو به طور خاص یک علامت خطرنام است .
+ به این معناست که ماکرو فقط در حالتی کار میکند که در بالاترین سطخ
+ (top level)
+ صدا شده باشد.
+ اگر این ماکرو به صورت تابع نوشته شده باشد،به طور طبیعی به مقادیر
+ run-time
+ ای که نیاز دارد دسترسی دارد
+ .
Be aware of when a macro could really be a function instead.
From d839a2446cfccd7bf8767365c713cca8a27f85da Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 00:45:38 +0430
Subject: [PATCH 17/21] =?UTF-8?q?=D8=AA=D9=87=20=DA=A9=D8=A7=D8=B1=20?=
=?UTF-8?q?=D8=A7=D9=85=D8=B4=D8=A8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
docs/manual/style-guide.md | 77 +++++++++++++++++++++++++++++---------
1 file changed, 60 insertions(+), 17 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index 1ad3dd7..faaf4d3 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -372,7 +372,7 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
parse
شود می اید
.
- در بسیاری از مثال ها که نوع خروجب اول می اید ولی مفید است که ذکر کنیم که
+ در بسیاری از مثال ها که نوع خروجی اول می اید ولی مفید است که ذکر کنیم که
ارگومان
`IO`
در تابع
@@ -627,16 +627,13 @@ foo(::MyType) = foo(MyType)
ای که نیاز دارد دسترسی دارد
.
-Be aware of when a macro could really be a function instead.
-Calling [`eval`](@ref) inside a macro is a particularly dangerous warning sign; it means the
-macro will only work when called at the top level. If such a macro is written as a function instead,
-it will naturally have access to the run-time values it needs.
-## Don't expose unsafe operations at the interface level
+## Don't expose unsafe operations at the interface level(در سطح رابط از عمل خطرناک استفاده نکنیذ)
+ اگر شما یک تایپ دارید که از یک اشاره گر بومی استفاده می کند.
+ (native pointer):
-If you have a type that uses a native pointer:
```julia
mutable struct NativeType
@@ -645,6 +642,8 @@ mutable struct NativeType
end
```
+ تعاریف را مانند مثال زیر ننویسید
+ :
don't write definitions like the following:
@@ -652,22 +651,28 @@ don't write definitions like the following:
getindex(x::NativeType, i) = unsafe_load(x.p, i)
```
+ مشکل اینجاست که کاربر این تایپ می تواند بنویسد
+ x[i]
+ بدون اینکه بفهمد این عملیات امن نیست.
+و ممکن است دچار باگ های حافظه شود.
+
+ چنین تابعی باید عملیات هایش چک شود تا تضمین شود که امن بوده است و یا یکجایی در اسم خود کلمه
+ unsafe
+ داشته باشد که صدازننده این تابع ،این موضوع را بداند.
+
-The problem is that users of this type can write `x[i]` without realizing that the operation is
-unsafe, and then be susceptible to memory bugs.
-
-Such a function should either check the operation to ensure it is safe, or have `unsafe` somewhere
-in its name to alert callers.
## Don't overload methods of base container types
+ ممکن است تعاریفی مانند زیر بنویسیم
+ :
-It is possible to write definitions like the following:
```julia
show(io::IO, v::Vector{MyType}) = ...
```
-
+
+
This would provide custom showing of vectors with a specific new element type. While tempting,
this should be avoided. The trouble is that users will expect a well-known type like `Vector()`
to behave in a certain way, and overly customizing its behavior can make it harder to work with.
@@ -705,15 +710,32 @@ conversions between color spaces. Another example might be a package that acts a
wrapper for some C code, which another package might then pirate to implement a
higher-level, Julia-friendly API.
-## Be careful with type equality
+## Be careful with type equality(در برابر بودن تایپ دقت کنید)
+ ما به صورت کلی از
+
You generally want to use [`isa`](@ref) and [`<:`](@ref) for testing types,
not `==`. Checking types for exact equality typically only makes sense when comparing to a known
concrete type (e.g. `T == Float64`), or if you *really, really* know what you're doing.
-## Do not write `x->f(x)`
+## Do not write `x->f(x)`(این را ننویسید)
+ تا جایی که توابع با ترتیب بالاتر در اجرا معمولا به وسیله توابع ناشناس
+ anonymous
+ ساخته شده اند ،راحت است دریابیم که این خوب یا حتی لازم است .
+ ولی هر تابعی میتواند به صورت مستقیم پاس داده شود ،بدون اینکه در توابع ناشناس
+ (anonymous)
+ به اصطلاح
+ (wrapped)
+ شوند .
+
+ به جای نوشتن
+ map(x->f(x), a)
+ بنویسید
+
map(f, a)
+ .
+
Since higher-order functions are often called with anonymous functions, it is easy to conclude
that this is desirable or even necessary. But any function can be passed directly, without being
@@ -726,7 +748,10 @@ If you write generic code which handles numbers, and which can be expected to ru
numeric type arguments, try using literals of a numeric type that will affect the arguments as
little as possible through promotion.
-For example,
+
+ به عنوان مثال
+ ,
+
```jldoctest
julia> f(x) = 2.0 * x
@@ -759,6 +784,24 @@ julia> g(1)
2
```
+ همان طور که می بینید ،ورژن دوم موقعی که ما از
+ Int
+ استفاده کردیم به عنوان نوع ارگومان ورودی در نظر گرفته شد ولی دفعه اول چنین اتفاقی نیافتاد .
+ زیرا
+promote_type(Int, Float64) == Float64
+ و ترفیع با ضرب اتفاق می افتد.
+ به طور مشابه حرف های
+ Rational
+ کمتر
+ مخل نوع هستند تا
+ حرف های
+ Float64
+ ولی بیشتر از
+ Int
+ خراب کننده هستند
+ :
+
+
As you can see, the second version, where we used an `Int` literal, preserved the type of the
input argument, while the first didn't. This is because e.g. `promote_type(Int, Float64) == Float64`,
From ae21cff1b85e8b6dcd8697a13b83c2498ee93a03 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 12:16:52 +0430
Subject: [PATCH 18/21] =?UTF-8?q?=D9=86=D8=B3=D8=AE=D9=87=20=D9=86=D9=87?=
=?UTF-8?q?=D8=A7=DB=8C=DB=8C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
docs/manual/style-guide.md | 123 +++++++++++++++++++++++--------------
1 file changed, 78 insertions(+), 45 deletions(-)
diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md
index faaf4d3..f7adff7 100644
--- a/docs/manual/style-guide.md
+++ b/docs/manual/style-guide.md
@@ -423,7 +423,6 @@ a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n)
هر ارگومان دیگری
- Any other arguments.
9. **Varargs**.
@@ -612,7 +611,7 @@ foo(::MyType) = foo(MyType)
-## Don't overuse macros(زیاد از کاکرو استفاده نکنید)
+## Don't overuse macros(زیاد از ماکرو استفاده نکنید)
باید بدانیم که چه موقع یک ماکرو میتواند یک تابع به حساب اید .
@@ -645,7 +644,6 @@ end
تعاریف را مانند مثال زیر ننویسید
:
-don't write definitions like the following:
```julia
getindex(x::NativeType, i) = unsafe_load(x.p, i)
@@ -672,22 +670,34 @@ getindex(x::NativeType, i) = unsafe_load(x.p, i)
show(io::IO, v::Vector{MyType}) = ...
```
+ این ممکن است یک نمایشی از بردار ها بدهد که نوع اعضای ان یک نوع جدید باشد.
+ در حالیکه این کار وسوسه کننده است باید از ان خودداری شود.
+ مشکل این اسن که کاربر انتظار نوع مشهوری مثل
+ Vector()
+ را دارد پس به روش بالا عمل کردن و زیاد شخصی سازی توابع کار با ان ها را سخت تر می کند.
-This would provide custom showing of vectors with a specific new element type. While tempting,
-this should be avoided. The trouble is that users will expect a well-known type like `Vector()`
-to behave in a certain way, and overly customizing its behavior can make it harder to work with.
-## Avoid type piracy
+
+## Avoid type piracy(از سطح امنیت دادن به تایپ ها بپرهیزید)
+ کلمه
+ "Type piracy"
+ یا سطح امنیت تایپ
+ به عمل گسترش یا تعریف مجدد روش ها در
+ Base
+ اشاره دارد.
+ در بعضی از حالات ،با کمی تاثیر بد میتوانید با ان کنار بیایید ولی در حالات خیلی اکستریم، حتی میتواند منجر به خراب شدن جولیا شود
+اگر تعریف مجدد یا اکستنشن تابع شما منجر به تولید ورودی غیر قابل قبولی که به تابع مثلا)
+
ccall
+ شود.
+ (
+ Type piracy
+ میتواند منجر به پیچیده شدن کد و ایجاد مشکلاتی که به سختی قابل پیش بینی وتشخیص باشند ، شود.
+
+ به عنوان مثال ،فرض کنید میخواهی د عمل ضرب را بر روی سمبل ها در یک ماژول تعریف کنید
+ :
+
-"Type piracy" refers to the practice of extending or redefining methods in Base
-or other packages on types that you have not defined. In some cases, you can get away with
-type piracy with little ill effect. In extreme cases, however, you can even crash Julia
-(e.g. if your method extension or redefinition causes invalid input to be passed to a
-`ccall`). Type piracy can complicate reasoning about code, and may introduce
-incompatibilities that are hard to predict and diagnose.
-
-As an example, suppose you wanted to define multiplication on symbols in a module:
```julia
module A
@@ -696,30 +706,60 @@ import Base.*
end
```
+ مشکل این است که الان هر ماژول دیگری که از
+ Base
+ استفاده میکند هم این تعریف یا تابع را میبیند و تا زمانی که
+ Symbol
+ در
+ Base
+ تعریف شده باشد،توسط دیگر ماژول ها استفاده میشود.
+ و این میتواند رفتار و عملکرد کد های در ضاهر بی ربط به ان را تغییر دهد و یا مختل کند .
+ یکسری راه های دیگر نیز برای این حالت وجود دارد، مانند در نظر گرفتن یک اسم دیگر برای تابع
+ و یا دسته بندی
+ (wrapping)
+ نماد
+ Symbol
+ در نوع دیگری که تعریف کردید.
+
+ بعضی اوقات پکیج های
+ coupled
+ ممکن است به نوعی از
+ type piracy
+ برای جداکردن ویژگی هایی از تعاریف استفاده کرده باشند مخصوصا وقتی که ان بکیج ها توسط تعدادی برنامه نویس طراحی شده باشند.
+ که با هم همکاری داشتند وقتی که تعاریف و یا تابع ها قابل استفاده مجدد هستند .
+ برای مثال فرض کنید یک پکیج یکسری تایپ برای کار با رنگ ها فراهم میکند و پکیج دیگر میتواند یکسری تابع برای ان تایپ های که اجازه تبدیل بین فضا های رنگ را دارد ، تعریف کند
+ مثال دیگر ممکن است این باشد که یک پکیجیک
+ wrapper
+ برای کد ها به زبان
+ c
+ باشد درحالیکه دیگری باید یک
+ API
+ سطح بالا به زبان جولیا پیاده سازی مند.
+
-The problem is that now any other module that uses `Base.*` will also see this definition.
-Since `Symbol` is defined in Base and is used by other modules, this can change the
-behavior of unrelated code unexpectedly. There are several alternatives here, including
-using a different function name, or wrapping the `Symbol`s in another type that you define.
-
-Sometimes, coupled packages may engage in type piracy to separate features from definitions,
-especially when the packages were designed by collaborating authors, and when the
-definitions are reusable. For example, one package might provide some types useful for
-working with colors; another package could define methods for those types that enable
-conversions between color spaces. Another example might be a package that acts as a thin
-wrapper for some C code, which another package might then pirate to implement a
-higher-level, Julia-friendly API.
## Be careful with type equality(در برابر بودن تایپ دقت کنید)
- ما به صورت کلی از
-
+ ما به صورت کلی دوست داریم که از
+
isa
+ و
+
<:
+ برای چک کردن نوع ارگومان استفاده کنیم .
+ و نه
+
==
+ چک کردن نوع به صورت تساوی دقیق با نماد قبل فقط موقعی خوب و منطقی به نظر میرسد که که با یک
+ concrete
+ تایپ داده شده مقایسه شود.
+ مثل
+ `T == Float64`
+ ویا حتما حتما حتما بدانید که چگونه از ان استفاده می کنید.
+
+
-You generally want to use [`isa`](@ref) and [`<:`](@ref) for testing types,
-not `==`. Checking types for exact equality typically only makes sense when comparing to a known
-concrete type (e.g. `T == Float64`), or if you *really, really* know what you're doing.
+
## Do not write `x->f(x)`(این را ننویسید)
+
تا جایی که توابع با ترتیب بالاتر در اجرا معمولا به وسیله توابع ناشناس
anonymous
@@ -737,20 +777,19 @@ concrete type (e.g. `T == Float64`), or if you *really, really* know what you're
.
-Since higher-order functions are often called with anonymous functions, it is easy to conclude
-that this is desirable or even necessary. But any function can be passed directly, without being
-"wrapped" in an anonymous function. Instead of writing `map(x->f(x), a)`, write [`map(f, a)`](@ref).
## Avoid using floats for numeric literals in generic code when possible
+ اگر شما یک کد عمومی یا
+ generic
+ بنویسید که روی اعداد کار میکند و انتظار دارید روی تمام ارگومان های تایپ عددی کار کند،سعی کنید از حرف های تایپ های عددی استفاده کنید که باعث میشود دامنه نوع ارگومان های قابل قبول مینیمال شود.
+
+
-If you write generic code which handles numbers, and which can be expected to run with many different
-numeric type arguments, try using literals of a numeric type that will affect the arguments as
-little as possible through promotion.
به عنوان مثال
- ,
+
```jldoctest
@@ -803,10 +842,6 @@ promote_type(Int, Float64) == Float64
-As you can see, the second version, where we used an `Int` literal, preserved the type of the
-input argument, while the first didn't. This is because e.g. `promote_type(Int, Float64) == Float64`,
-and promotion happens with the multiplication. Similarly, [`Rational`](@ref) literals are less type disruptive
-than [`Float64`](@ref) literals, but more disruptive than `Int`s:
```jldoctest
julia> h(x) = 2//1 * x
@@ -830,5 +865,3 @@ julia> h(1)
استفاده کنید
.
-Thus, use `Int` literals when possible, with `Rational{Int}` for literal non-integer numbers,
-in order to make it easier to use your code.
From 95d0f78d6f895331d441136eff346d07f8e3182d Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 14:13:13 +0430
Subject: [PATCH 19/21] Update faq.md
---
docs/manual/faq.md | 111 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 94 insertions(+), 17 deletions(-)
diff --git a/docs/manual/faq.md b/docs/manual/faq.md
index 00b6456..1b5503d 100644
--- a/docs/manual/faq.md
+++ b/docs/manual/faq.md
@@ -1,26 +1,103 @@
-# Frequently Asked Questions
+# Frequently Asked Questions(سوالات پرتکرار)
## General
-### Is Julia named after someone or something?
-
-No.
-
-### Why don't you compile Matlab/Python/R/… code to Julia?
-
-Since many people are familiar with the syntax of other dynamic languages, and lots of code has already been written in those languages, it is natural to wonder why we didn't just plug a Matlab or Python front-end into a Julia back-end (or “transpile” code to Julia) in order to get all the performance benefits of Julia without requiring programmers to learn a new language. Simple, right?
-
-The basic issue is that there is *nothing special about Julia's compiler*: we use a commonplace compiler (LLVM) with no “secret sauce” that other language developers don't know about. Indeed, Julia's compiler is in many ways much simpler than those of other dynamic languages (e.g. PyPy or LuaJIT). Julia's performance advantage derives almost entirely from its front-end: its language semantics allow a [well-written Julia program](@ref man-performance-tips) to *give more opportunities to the compiler* to generate efficient code and memory layouts. If you tried to compile Matlab or Python code to Julia, our compiler would be limited by the semantics of Matlab or Python to producing code no better than that of existing compilers for those languages (and probably worse). The key role of semantics is also why several existing Python compilers (like Numba and Pythran) only attempt to optimize a small subset of the language (e.g. operations on Numpy arrays and scalars), and for this subset they are already doing at least as well as we could for the same semantics. The people working on those projects are incredibly smart and have accomplished amazing things, but retrofitting a compiler onto a language that was designed to be interpreted is a very difficult problem.
-
-Julia's advantage is that good performance is not limited to a small subset of “built-in” types and operations, and one can write high-level type-generic code that works on arbitrary user-defined types while remaining fast and memory-efficient. Types in languages like Python simply don't provide enough information to the compiler for similar capabilities, so as soon as you used those languages as a Julia front-end you would be stuck.
-
-For similar reasons, automated translation to Julia would also typically generate unreadable, slow, non-idiomatic code that would not be a good starting point for a native Julia port from another language.
-
-On the other hand, language *interoperability* is extremely useful: we want to exploit existing high-quality code in other languages from Julia (and vice versa)! The best way to enable this is not a transpiler, but rather via easy inter-language calling facilities. We have worked hard on this, from the built-in `ccall` intrinsic (to call C and Fortran libraries) to [JuliaInterop](https://github.com/JuliaInterop) packages that connect Julia to Python, Matlab, C++, and more.
+### Is Julia named after someone or something?(ایا اسم جولیا برگرفته از شخص یا چیزی است؟)
+
+خیر
+
+### Why don't you compile Matlab/Python/R/… code to Julia?(چرا کد متلب و ار و پایتون روی جولیا اجرا نمی شود؟)
+
+ از انجایی که بسیاری از مردم با سینتکس بقیه زبان های داینامیک برناهم نویسی اشنا هستند و بسیاری از کد ها به این زبانها نوشته شده است،طبیعی است که تعجب کنید چرا سیتکس زبان هایی مثل
+ mathlab
+ یا
+ python
+ را نگرفتیم و با
+ backend
+ جولیا به اصطلاح
+ transpile
+ کنیم تا تمام مزایای عملکردی جولیا را داشته باشیم بدون اینکه نیاز باشد برنامه نویس یک زبان جدید یاد بگیرد .
+ ساده است ؟ بله؟
+
+ مسئله اولیه این است که هیچ چیز خاصی درباره کامپایلر جولیا وجو ندارد ما از یک کامپایلر
+ LLVM
+ بدون هیچ چیز اضافه ای که برنامه نویس های دیگر درباره ان نمیدانند استفاده نکردیم .
+ قطعا کامپایلر جولیا ار خیلی جهات به مراتب ساده تر از زبانهایی مثل
+ PyPy or LuaJIT
+ است.
+ مزایای
+ عملکرد جولیا
+ برگرفته از قسمت
+ front-end
+ ان است.
+ معنا شناسی
+ (semantics)
+ ان این اجازه را میدهد که یک برنامه نویس خوب این اجازه را به کامپایلز بدهد که کدهای بهتری از لحظ موثر بودن و لایه های مموری تولید کند.
+ اگر شما تا به حال کامپایل کردن کد های
+ mathlab
+ یا
+ python
+ را در جولیا امتحان کرده باشید،کامپایلر زبان محدود میشود و نمیتواند کد های بهتری نسبت به کامپابلر همان زبان پایتون یا جنریت و تولید کند.
+ (و شاید هم بدتر)
+ نکته کلیدی عملکرد فهمیدن کد این است که چرا کامپابلر های پایتون مثل
+ Numba
+ یا
+ Pythran
+ تنها تلاش میکنند که زیرمجموعه کوچکی از زبان را اپتیمایز کنند مثل
+ عمل هایی بر روی ارایه و اعداد در
+ numpy
+ و برای همین زیرمجموعه هم خیلی کمتر از برنامه نویسان جولیا کار را انجام میدهند .
+ افرادی که روی این پروژه ها کار میکنند بسیار باهوش هستند و
+ کارهای شگفت انگیزی انجام داده اند .
+ اما مقاوم سازی مجدد یک کامپایلر بر روی زبانی که برای تفسیر
+ (interpreting)
+ طراحی شده است ، یک مشکل بسیار دشوار است.
+
+ مزیت جولیا نسبت این است که این عملکرد خوب و اپتیمایز بر روی یک زیرمجموعه تایپ ها و عملگر های
+ “built-in”
+ محدود نشده است و برنامه نویس میتواند یک یک برنامه بسطح بالا با تایپ عمومی بنویسد که بر روی
+ انواع مختلف
+ type-generic code
+ توسط کاربر تعریف شده درحلیکه هنوز سریع و از نظر حتفظه کم حافظه است.
+ تایپ ها در زبانهایی مثل پایتون به سادگی اطلاعات زیادی با این توان در اختیار کامپایلر قرار نمیدهند
+ .
+ و تا زمانی که از انها برای
+ front-end
+ جولیا استفاده میکنید از این ویژگی نیمتوانید بهر ببرید.
+
+ به دلایل مشابه
+automated translation
+ نیز برای جولیا یک کد ناخوانا و ارام به نسبت و نه اصطلاحی
+ (منظور این است که مختص به جولیا باشد.)
+ تولید می کند که نقطه شروعی برای یک زبان
+ (native)
+مثل جولیا
+ نیست.
+
+ در طورف دیگر ویژگی
+*interoperability*
+ یک زبان بسیار بدردبخور است .
+ ما می خواهیم از کد با کیفیت بالا موجود به زبانهای دیگر از جولیا (و بالعکس) بهره برداری کنیم!
+بهترین راه برای اینکار یک
+ transpiler
+ نیست بلکه از طریق ویژگی هایی است که در خود زبان تعبیه شده
+ (easy inter-language calling facilities)
+ ما به سختی روی این موضوع کار کردیم از
+
ccall
+ داخلی برای ارتباط با زبان
+ C
+ و کتابخانه های
+Fortran
+ به
+پکیج های
+
juliaInterop
+که زبان جولیا را به پایتون و متلب و سی پلاس پلاس و غیره مرتبط میکنند.
+
+
## Sessions and the REPL
-### How do I delete an object in memory?
+### How do I delete an object in memory?(چگونه یک شی را از مموری پاک کنیم ؟)
Julia does not have an analog of MATLAB's `clear` function; once a name is defined in a Julia
session (technically, in module `Main`), it is always present.
From 5b91a5c3f0a721697ac125ff2507c75f6ff1c605 Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 15:12:15 +0430
Subject: [PATCH 20/21] update until function
---
docs/manual/faq.md | 216 +++++++++++++++++++++++++++++++++++----------
1 file changed, 167 insertions(+), 49 deletions(-)
diff --git a/docs/manual/faq.md b/docs/manual/faq.md
index 1b5503d..1020047 100644
--- a/docs/manual/faq.md
+++ b/docs/manual/faq.md
@@ -98,31 +98,75 @@ Fortran
## Sessions and the REPL
### How do I delete an object in memory?(چگونه یک شی را از مموری پاک کنیم ؟)
+
+ جولیا مانند
+ mathlab
+ یک تابع
+ clear
+ ندارد .
+ وقتی که یک اسم در یک
+ session
+ جولیا تعریف شد.
+ (
+ دقیق تر در ماژول
+ main
+ )
+ همیشه انجا وجود دارد.
+
+اگر استفاده از مموری جز نگرانی های شماست ،میتوانید همیشه اشیای خود را با ان هایی که فضا یا مموری کمتری می گیرند جا به جا کنید.
+
+ برای مثال اگر
+ A
+ یک ارایه با سایز اردر گیگابایت باشد و دیگر در برنامه نیازی به ان نباشد،میتوانید با دستور
+ A = nothing
+ مموری را خالی کنید.
+ و ان فضا دفعه بعدی که
+ garbage collector
+ اجرا شد فضا را خالی میکند.
+ و همینطور میتوانید با تابع زیر ان را مجبور به اجرا کنید .
+
+
GC.gc()
+ که در
+ Base
+ قرار دارد
+ همین طور استفاده از
+ َA
+ به احتمال زیاد در این حالت منجر به خطا میشود.
+ زیرا بیشتر توابع بر روی تایپ
+ nothing
+ تعریف نشده اند .
+
+
-Julia does not have an analog of MATLAB's `clear` function; once a name is defined in a Julia
-session (technically, in module `Main`), it is always present.
-
-If memory usage is your concern, you can always replace objects with ones that consume less memory.
- For example, if `A` is a gigabyte-sized array that you no longer need, you can free the memory
-with `A = nothing`. The memory will be released the next time the garbage collector runs; you can force
-this to happen with [`GC.gc()`](@ref Base.GC.gc). Moreover, an attempt to use `A` will likely result in an error, because most methods are not defined on type `Nothing`.
-
-### How can I modify the declaration of a type in my session?
+### How can I modify the declaration of a type in my session?(چگونه تایپ را عوض میکنم؟)
+
+ شاید شما نوعی را تعریف کرده باشید و سپس متوجه شوید که باید یک قسمت جدید اضافه کنید.
+ اگر اینکار را بر روی
+ REPL
+ امتحان کرده باشید ، خطای زیر را دریافت می کنید
+ :
+
-Perhaps you've defined a type and then realize you need to add a new field. If you try this at
-the REPL, you get the error:
```
ERROR: invalid redefinition of constant MyType
```
-
-Types in module `Main` cannot be redefined.
-
-While this can be inconvenient when you are developing new code, there's an excellent workaround.
- Modules can be replaced by redefining them, and so if you wrap all your new code inside a module
-you can redefine types and constants. You can't import the type names into `Main` and then expect
-to be able to redefine them there, but you can use the module name to resolve the scope. In other
-words, while developing you might use a workflow something like this:
+
+ تایپ ها در ماژول
+ main
+ نمیتوانند دوباره تعریف شوند.
+
+ اگرچه این کار در هنگام نوشتن کد جدید ناخوشایند است ، اما یک راه حل عالی وجود دارد.
+ماژول ها میتوانند با دوباره تعریف کردنشان جا به جا شوند.
+ پس اگر شما کد خود را دورن یک ماژول بپیچید
+ به اصطلاح
+ wrap
+ کنید میتوانید ثابت ها و تایپ ها را دوباره تعریف کنید.
+،
+ نمی توانید نام نوع را در "Main" وارد کنید و سپس انتظار داشته باشید
+برای اینکه بتوانید در آنجا دوباره تعریف کنید ، اما می توانید از نام ماژول برای حل محدوده استفاده کنید. در دیگر
+سخن ، در حالی که شما ممکن است از گردش کار مانند این استفاده کنید:
+
```julia
include("mynewcode.jl") # this defines a module MyModule
@@ -138,31 +182,72 @@ obj3 = MyModule.someotherfunction(obj2, c)
## [Scripting]
-### How do I check if the current file is being run as the main script?
-
-When a file is run as the main script using `julia file.jl` one might want to activate extra
-functionality like command line argument handling. A way to determine that a file is run in
-this fashion is to check if `abspath(PROGRAM_FILE) == @__FILE__` is `true`.
+### How do I check if the current file is being run as the main script?(چگونه چک کنم این فایل دارد روی جریان اصلی اجرا میشود یا نه؟)
+
+ زمانی که یک فایل با استفاده از
+ julia file.jl
+ بر روی
+ main script
+ اجرا میشود،
+یک نفر ممکن است بخواهد عملکردهای دیگری اضافه بر سازمان مانند کنترل ارگومتن در
+ command line
+ را فعال کند .
+ روشی برای تعیین اینکه یک فایل به این صورت اجرا شده است ، این است که ایا
+
+
+`abspath(PROGRAM_FILE) == @__FILE__` is `true`.
### [How do I catch CTRL-C in a script?]
-
-Running a Julia script using `julia file.jl` does not throw
-[`InterruptException`](@ref) when you try to terminate it with CTRL-C
-(SIGINT). To run a certain code before terminating a Julia script,
-which may or may not be caused by CTRL-C, use [`atexit`](@ref).
-Alternatively, you can use `julia -e 'include(popfirst!(ARGS))'
-file.jl` to execute a script while being able to catch
-`InterruptException` in the [`try`](@ref) block.
+
+ اجرا کردن یک اسکریپت جولیا با استفاده از
+ julia file.jl
+ اکسپشن
+
InterruptExeption
+ را پرت نمیکند.
+زمانی که شما این پروسه را با زدن
+ CTRL-C
+(SIGINT)
+ تمام میکنید.
+ برای اجرا کردن کد قبل از بستن یک اسکریپت جولیا که ممکن است با
+ CTRL-C
+ ویا بدون ان ایجاد شده باشد،
+از
+
atexit
+ استفاده کنید همین طور ، میتوانید از
+julia -e 'include(popfirst!(ARGS))
+file.jl
+برای اجرا کردن یک اسکریپت زمانی که میتوانید اکسپشن
+
InterruptExeption
+ را در بلاک
+ try
+ catch
+ کنید.
+
### How do I pass options to `julia` using `#!/usr/bin/env`?
-
-Passing options to `julia` in so-called shebang by, e.g.,
-`#!/usr/bin/env julia --startup-file=no` may not work in some
-platforms such as Linux. This is because argument parsing in shebang
-is platform-dependent and not well-specified. In a Unix-like
-environment, a reliable way to pass options to `julia` in an
-executable script would be to start the script as a `bash` script and
-use `exec` to replace the process to `julia`:
+
+ پاس دادن اپشن ها به
+ `julia`
+در اصطلاح
+ shebang
+ گفته میشود.
+#!/usr/bin/env julia --startup-file=no
+ ممکن است در بعضی از پلتفرم ها مثل لینوکس کار نکند.
+ که این به این خاطر است که ارگومانی که در
+shebang
+ کار
+ parsing
+ بر روی ان انجام شده است نسبت به پلتفرم مستقل نیست و به ان بستگی دارد.
+ یک راه قابل اطمینان برای پاس دادن اپشن ها به
+`julia`
+ در یک اسکریپت قابل اجرا میتواند این باشد که اسکریپت را مانند
+ bash
+ اسکریت شروع کنند و از
+ exec
+ برای انتقال پروسه به
+ julia
+ استفاده کنند.
+
```julia
#!/bin/bash
@@ -173,13 +258,40 @@ exec julia --color=yes --startup-file=no "${BASH_SOURCE[0]}" "$@"
@show ARGS # put any Julia code here
```
-In the example above, the code between `#=` and `=#` is run as a `bash`
-script. Julia ignores this part since it is a multi-line comment for
-Julia. The Julia code after `=#` is ignored by `bash` since it stops
-parsing the file once it reaches to the `exec` statement.
+
+ در مثال بالا ، کدی که بین
+ #=
+ و
+ =#
+ بود به صورت
+ `bash`
+script
+ اجرا شد.
+ جولیا به این بخش کاری ندارد تا وقتیی که یک کامنت چند خطه برای جولیاست.
+ کد های جولیا بعد از علامت
+ =#
+ توسط
+ bash
+ ایگنور میشوند (ران نمیشوند)
+ تا زمانی که در
+ parse
+ کردن فایل متوقف شود زمانی که
+ state
+ ما یعنی
+ exec
+ میرسد.
+
+ توجه کنید برای
+
+
-!!! note
- In order to [catch CTRL-C](@ref catch-ctrl-c) in the script you can use
+ [catch CTRL-C](@ref catch-ctrl-c)
+
+
+
+ بر روی اسکریپت میتوانید
+
+
```julia
#!/bin/bash
#=
@@ -191,11 +303,14 @@ parsing the file once it reaches to the `exec` statement.
```
instead. Note that with this strategy [`PROGRAM_FILE`](@ref) will not be set.
-## Functions
+## Functions(توابع)
-### I passed an argument `x` to a function, modified it inside that function, but on the outside, the variable `x` is still unchanged. Why?
+### I passed an argument `x` to a function, modified it inside that function, but on the outside, the variable `x` is still unchanged. Why?(چرا من یک متغیر را درون تابع تغییر دادم ولی بیرون ان تغییر نکرده است؟)
-Suppose you call a function like this:
+
+ فرض کنید چنین تابعی را صدا کرده اید
+ :
+
```jldoctest
julia> x = 10
@@ -213,6 +328,9 @@ julia> x # x is unchanged!
10
```
+
+
+
In Julia, the binding of a variable `x` cannot be changed by passing `x` as an argument to a function.
When calling `change_value!(x)` in the above example, `y` is a newly created variable, bound initially
to the value of `x`, i.e. `10`; then `y` is rebound to the constant `17`, while the variable
From c070f4b8db7566e91b756675036deb29e9c1fc5e Mon Sep 17 00:00:00 2001
From: hossein <61795938+rahmani-hossein@users.noreply.github.com>
Date: Sat, 10 Jul 2021 16:50:29 +0430
Subject: [PATCH 21/21] end of my chapter
---
docs/manual/faq.md | 195 ++++++++++++++++++++++++++++++++++-----------
1 file changed, 149 insertions(+), 46 deletions(-)
diff --git a/docs/manual/faq.md b/docs/manual/faq.md
index 1020047..fbf715f 100644
--- a/docs/manual/faq.md
+++ b/docs/manual/faq.md
@@ -329,16 +329,41 @@ julia> x # x is unchanged!
```
-
+ در جولیا،
+مقداری که به یک متغیر نسبت داده شده یا
+ binding of a variable
+ x
+ نمیتواند در اثر پاس دادن به یک ارگومان تابع تغییر کند .
+ وقتی تابع
+ hange_value!(x)
+ در مثال بالا را صدا می زنیم،متغیر
+ y
+ یک متغیر است که به سادگی ساخته شده است .
+ که اول در تابع یک مقدار به مقدار
+ x
+ می دهد مقدار 10
+ سپس
+ y
+ مقدار 17 میگیرد.
+ هنگامی که متغیر
+ x
+ در لایه خارجی هنوز دست نخورده است.
+
+ درحالیکه،اگر
+ x
+ به یک شی از ارایه
+ assign
+ میشد
+ (یا هر تایپ
+ mutable(
+ از داخل تابع ،نمیتوانید اشاره گر
+ x
+ را عوض کنید یا به اصطلاح
+ unbind
+ اش کنید ولی میتوانید مقدارش را عوض کنید.
+ برای مثال
+ :
-In Julia, the binding of a variable `x` cannot be changed by passing `x` as an argument to a function.
-When calling `change_value!(x)` in the above example, `y` is a newly created variable, bound initially
-to the value of `x`, i.e. `10`; then `y` is rebound to the constant `17`, while the variable
-`x` of the outer scope is left untouched.
-
-However, if `x` is bound to an object of type `Array`
-(or any other *mutable* type). From within the function, you cannot "unbind" `x` from this Array,
-but you *can* change its content. For example:
```jldoctest
julia> x = [1,2,3]
@@ -362,18 +387,38 @@ julia> x
3
```
-Here we created a function `change_array!`, that assigns `5` to the first element of the passed
-array (bound to `x` at the call site, and bound to `A` within the function). Notice that, after
-the function call, `x` is still bound to the same array, but the content of that array changed:
-the variables `A` and `x` were distinct bindings referring to the same mutable `Array` object.
-
-### Can I use `using` or `import` inside a function?
+
+ اینجا ما یک تابع
+ change_array!
+ ساختیم که به خانه اول ارایه مقدار
+ '5'
+ را نسبت میدهد.
+ دقت کنید بعد از فراخوانی تابع،
+ x
+ هنوز به همان ارایه اشاره میکند.
+ ولی مقادیر ارایه فرق کرده است .
+ متغیر های
+ A
+ و
+ x
+ دو اشاره گر متمایز بودند که به یک ارایه تغییر پیدا کرده اشاره میکردند.
+
-No, you are not allowed to have a `using` or `import` statement inside a function. If you want
-to import a module but only use its symbols inside a specific function or set of functions, you
-have two options:
+### Can I use `using` or `import` inside a function?(ایا میتوانیم از این دو لفظ درون تابع استفاده کنیم؟)
-1. Use `import`:
+
+ نه ! ما اجازه نداریم که از کلیدواژه های
+ using
+ یا
+ import
+ درون تابع استفاده کنیم.
+ اگر میخواهید که یک ماژول را ایمپورت کنید ولی فقط از سمبل های درون یک تابع مشخص یا مجموعه ای از تابع ها استفاده کنید.
+ دو تا راه دارید
+ :
+
+
+ 1.از ایمپورت استفاده کنید:
+
```julia
import Foo
@@ -381,11 +426,23 @@ have two options:
# ... refer to Foo symbols via Foo.baz ...
end
```
-
- This loads the module `Foo` and defines a variable `Foo` that refers to the module, but does not
- import any of the other symbols from the module into the current namespace. You refer to the
- `Foo` symbols by their qualified names `Foo.bar` etc.
-2. Wrap your function in a module:
+
+ این کد ماژول
+ Foo
+ را لود میکند و یک متغیر
+ Foo
+ را تعریف میکند .
+ که به ماژول برمیگردد ولی هنوز هیچکدام از سیمبل های دیگر از ماژول را به
+ namespace
+ فعلی ایمپورت نمیکند.
+ شما با اسم های واجدشرایط
+ qualified names `Foo.bar`
+ به
+ Foo
+ اشاره می کنید.
+
+ 2.تابع خود را در یک ماژول قرار دهید:
+
```julia
module Bar
@@ -398,20 +455,35 @@ have two options:
using Bar
```
- This imports all the symbols from `Foo`, but only inside the module `Bar`.
+
+ این کد تمام
+ symbol
+ ها را از
+ Foo
+ ایمپورت میکند ولی فقط درون ماژول
+ Bar.
+
### What does the `...` operator do?
#### The two uses of the `...` operator: slurping and splatting
-
-Many newcomers to Julia find the use of `...` operator confusing. Part of what makes the `...`
-operator confusing is that it means two different things depending on context.
+
+ بسیاری از افرادی که به تازگی با جولیا کد میزنند،در استفاده از عملگر
+ ...
+ گیج میشوند.
+ یکی از دلایلی که این عملگر پیچیده است این است که با توجه به کانتکس مفهوم متفاوتی دارد.
+
#### `...` combines many arguments into one argument in function definitions
-
-In the context of function definitions, the `...` operator is used to combine many different arguments
-into a single argument. This use of `...` for combining many different arguments into a single
-argument is called slurping:
+
+ برخلاف استفاده عملگر
+ ...
+ که اجازه میدهد هرچقدر ارکومان که خواستیم ورودی بدهیم،همان عملگر همچنین برای ایجاد یک تابع که فقط یک ارگومان داردکه باید از سایر ارگومان ها جدا باشدوقتی در کانتکستفراخوانی تابع از ان صحبت می شود.
+ این استفاده از این عملگر
+ slurping
+ نام دارد
+ :
+
```jldoctest
julia> function printargs(args...)
@@ -428,16 +500,31 @@ Arg #1 = 1
Arg #2 = 2
Arg #3 = 3
```
+
+ اگر جولیا یک زبان بود که با استفاده از کاراکتر های
+ ASCII
+ حرف های بیشتری میساخت،
+عملگر
+ slurping
+ باید به جای
+ ...
+ به صورت
+<-...
+ نوشته میشد.
+
-If Julia were a language that made more liberal use of ASCII characters, the slurping operator
-might have been written as `<-...` instead of `...`.
-
-#### `...` splits one argument into many different arguments in function calls
+#### `...` splits one argument into many different arguments in function calls(جدا کردن یک ارگومان از دیگر ارگومان ها در هنگام صدا کردن ان )
-In contrast to the use of the `...` operator to denote slurping many different arguments into
-one argument when defining a function, the `...` operator is also used to cause a single function
-argument to be split apart into many different arguments when used in the context of a function
-call. This use of `...` is called splatting:
+
+ برخلاف استفاده عملگر
+ ...
+ که اجازه میدهد هرچقدر ارکومان که خواستیم ورودی بدهیم،همان عملگر همچنین برای ایجاد یک تابع که فقط یک ارگومان داردکه باید از سایر ارگومان ها جدا باشدوقتی در کانتکستفراخوانی تابع از ان صحبت می شود.
+ این استفاده از این عملگر
+ splatting
+ نام دارد
+ :
+
+
```jldoctest
julia> function threeargs(a, b, c)
@@ -458,13 +545,26 @@ a = 1::Int64
b = 2::Int64
c = 3::Int64
```
-
-If Julia were a language that made more liberal use of ASCII characters, the splatting operator
-might have been written as `...->` instead of `...`.
+
+ اگر جولیا یک زبان بود که با استفاده از کاراکتر های
+ ASCII
+ حرف های بیشتری میساخت،
+عملگر
+ splatting
+ باید به جای
+ ...
+ به صورت
+ ...->
+ نوشته میشد.
+
### What is the return value of an assignment?
-
-The operator `=` always returns the right-hand side, therefore:
+
+ عملگر
+ =
+ همیشه نتیجه محاسبه سمت راست خود را برمیگرداند
+ :
+
```jldoctest
julia> function threeint()
@@ -484,8 +584,11 @@ julia> threeint()
julia> threefloat()
3.0
```
+
+ و به طور مشابه
+ :
+
-and similarly:
```jldoctest
julia> function threetup()