THẢO LUẬN

haha khá lắm, qui lại cũng là OT hả chứ không phải do quản lí kém?

+2
Avatar
đã bình luận cho bài viết
thg 9 8, 2017 1:23 SA

Anh ơi cho em hỏi ở trong protocol ProductListViewPresenter không có hàm init() nhưng sao ở dưới class ProductListPresenter lại có require init(...) ???

0
thg 9 8, 2017 1:19 SA

@bs90 (thankyou) bài viết không có ứng dụng vẹo gì, mình thích thì mình viết thôi =))

+4
thg 9 8, 2017 1:05 SA

@kiendinang Đã vote up! bài viết rất hay. Cho mình hỏi bài toán này có ứng dụng gì trong thực tế không (?)

0
thg 9 7, 2017 5:47 CH

Viết nốt đi bạn ơi, đang hay lại đứt dây

0
thg 9 7, 2017 3:35 CH

"Nếu QuickSort là nhanh nhất thì tại sao lại còn phải đẻ ra ti tỉ các loại thuật toán sắp xếp khác làm cái lề gì nhỉ?" :bride_with_veil_tone1:

0
thg 9 7, 2017 9:13 SA

Bạn đang hơi có chút nhầm lẫn thì phải. Hàm subscribe() được gọi đến từ main thread nên observable gốc sẽ chạy trên main thread. Còn đoạn code nằm trong subscribe() (chú ý là nằm trong) thì sẽ chạy trên thread của operator đứng trc nó nhé bạn.

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 9 7, 2017 8:32 SA

mình dùng đoạn ''' String folderSaveFile = context.getFilesDir().getAbsolutePath() ''' này thì mọi thứ đã ẩn như mình mong muốn. getFilesDir().getAbsolutePath() là code mình muốn hỏi để ẩn hình, giờ mình đã tìm ra rồi

+1

Hay quá. Bác còn nợ phần 2 nhé

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 9 7, 2017 2:32 SA

Cuối cùng thì em quyết định dùng https://konvajs.github.io/ http://heasygame.com/games/greenme

+1
thg 9 7, 2017 12:59 SA

(y), đúng rồi, ngày trước mình code cũng không biết, cứ tưởng cái nào .equal cũng được. Về sau, mới biết là cái nào khác null thì nên để ra trước (y). Còn chuyện trong bài viết, thì đoạn code đó cũng là đoạn ko đẹp, và ko có được approve 😄,

0
thg 9 6, 2017 11:53 CH

quá hay anh ơi!!!

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 9 6, 2017 6:23 CH

Mình thấy một vấn đề khá quen thuộc khi training một NN đó là Vanishing Gradients - gradient error sẽ nhỏ dần trong quá trình backpropagation. Đến một thời điểm nào đó connection weights của các layer thấp hơn sẽ không thay đổi (khi sử dụng Gradient Descent chẳng hạn), quá trình trainning sẽ không tìm được một kết quả tốt. Ngược lại nếu gradient lớn dần trong quá trình backpropagation thì sẽ dẫn đến hiện tượng Exploding Gradients - cũng không tốt một chút nào.

Có hai nguyên nhân chính dẫn đến hiện tượng trên:

  • Sử dụng saturating activation function (ví dụ như signmoid function)
  • Kĩ thuật khởi tạo các connection weights (weight initialization)

Ví dụ trong trường hợp sigmoid function, khi input lớn thì function sẽ trở nên bão hòa (saturating) tại 0 và 1, đạo hàm rất gần với 0, gradients trong quá trình backpropagation sẽ nhỏ dần khi đến các layer thấp hơn.

Signmoid

ReLU và các biến thể của nó thường được sử dụng thay cho sigmoid function, do nó không có hiện tượng bão hòa và khá nhanh khi tính toán.

ReLU(z)=max(0,z)ReLU(z) = max(0, z)

Tuy nhiên khi sử dụng ReLU chúng ta gặp phải một hiện tượng đó là Dying ReLUs, khi một số neuron sẽ chỉ cho ra giá trị là 0 trong quá trình trainning (khi connection weights của neuron được update và weighted sum của các inputs nhỏ hơn 0 -> output = 0 -> gradient = 0). Để giải quyết vấn đề này thì chúng ta sẽ dùng một số biến thể của ReLU.

Leaky ReLU

Ref: https://en.wikipedia.org/wiki/Rectifier_(neural_networks)#Leaky_ReLUs Ref: https://arxiv.org/pdf/1505.00853.pdf

LeakyReLU(z)=max(αz,z)LeakyReLU(z) = max(\alpha z, z)

Leaky ReLU

Ở đây alpha có tác dụng điều chỉnh độ dốc của hàm khi z < 0. Thay vì bằng 0 như trong ReLU output sẽ có giá trị thay đổi, tránh được hiện tượng dying ReLUs.

RReLU - Randomized Leaky ReLU

Tương tự như Leaky ReLU nhưng alpha sẽ được chọn ngẫu nhiên trong một khoảng nào đó khi training và được giữ nguyên trong quá trình testing -> tránh được hiện tượng overfitting.

RReLU

PReLU - Parametric Leaky ReLU

Ở biến thể này thì alpha sẽ được "learn" trong quá trình trainning thay vì là một hyperparameter. Nó hoạt động khá tốt khi dataset lớn nhưng có thể dẫn đến overfitting nếu dataset quá nhỏ.

PReLU

ELU - Exponential Linear Unit

Ref: https://en.wikipedia.org/wiki/Rectifier_(neural_networks)#ELUs

ELU(z)={zif z>=0α[exp(z)1]otherwise  ELU(z) = \begin{cases} z &\text{if } z >= 0 \\ \alpha [\exp(z) - 1] &\text{otherwise } \end{cases}

def elu(z, alpha=1):
    return np.where(z<0, alpha*(np.exp(z)-1), z)

ELU có performance khá tốt so với các biến thể trước đó của ReLU, với một số cải tiến như sau:

  • Cho ra giá trị âm khi z < 0, giá trị trung bình của đầu ra sẽ gần với 0 -> tránh được hiện tượng vanishing gradients
  • Gradient sẽ khác 0 khi z < 0 -> tránh được hiện tượng dying ReLUs
  • ELU là một hàm khá trơn -> việc sử dụng Gradient Descent sẽ hiệu quả hơn

ELU

SELU (Scaled Exponential Linear Units)

Ref: https://arxiv.org/pdf/1706.02515.pdf Ref: SELU + Dropout: https://github.com/bioinf-jku/SNNs/blob/master/selu.py

SELU(z)=λ{zif z>0α[exp(z)α]if z<=0 SELU(z) = \lambda \begin{cases} z &\text{if } z > 0 \\ \alpha [\exp(z) - \alpha] &\text{if } z <= 0 \end{cases}

def elu(z, alpha=1):
    return np.where(z < 0, alpha * (np.exp(z) - 1), z)


def selu(z,
         scale=1.0507009873554804934193349852946,
         alpha=1.6732632423543772848170429916717):
    return scale * elu(z, alpha)

Một loại activation function khá mới (2017) và có performance rất tốt so với các loại activation function khác.

SELU

Kết luận

Thông thường: ELU > Leaky ReLU (và các biến thể của nó) > ReLU > tanh > logistic (signmoid) Nếu quan tâm đến thời gian training: Leaky ReLUs > ELUs Thông thường giá trị của alpha sẽ là 0.01 cho leaky ReLU và 1 cho ELU Sử dụng RReLU nếu model overfitting tập training, PReLU nếu tập training lớn

:slight_smile: 😃 😄

+3
thg 9 6, 2017 3:12 CH

Bài viết hay quá cảm ơn bạn. mà mục 8 chuyện 2 mình thấy nên đổi thành a.equals(input) để tránh NPE nếu input vào là null

+1
thg 9 6, 2017 11:18 SA

Cho mình xin query của bạn 😄

0
thg 9 6, 2017 7:55 SA

getANumberObservable() //this will run on main thread .observeOn(Schedulers.io()) .map(new Func1<Integer, String>() { // this will run on a thread intended for I/O bound @Override public String call(Integer integer) { Log.i("Operator thread", Thread.currentThread().getName()); return String.valueOf(integer); } }) .subscribe(new Action1<String>() { // this will run on a thread intended for I/O bound @Override public void call(String s) { Log.i("Subscriber thread", Thread.currentThread().getName()); } });

Observable thread: main Operator thread: RxIoScheduler-2 // io Subscriber thread: RxIoScheduler-2 // io

Chào bạn. Cho mình hỏi sample của bạn gọi hàm .observeOn(Schedulers.io()) thì subscribe() sẽ chạy trên RXIOThread, vậy tại sao observable lại chạy trên main vậy, vì lúc đầu có nói nếu ko để subribeOn() thì mặc định Oservable sẽ chạy trên thread của nào chạy hàm subscribe, mà lúc này nó là RXIOThread

0
thg 9 6, 2017 7:09 SA

greate topic

0
Avatar
đã bình luận cho bài viết
thg 9 6, 2017 7:01 SA

(y)

0
thg 9 6, 2017 6:40 SA

Có, hiện tại mình đang sử dụng pycharm cho việc code python và phpstorm phục vụ cho php.

+1
Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí