Ticarette makine öğrenimi: teori, pratik, ticaret ve daha fazlası - sayfa 3151

Yeni yorum
 
mytarmailS #:

Geçmiş penceresinin boyutu, tablo verilerine sahip klasik MO'lar için büyük bir sınırlamadır

AS (asoc. rules) böyle bir hastalıktan muzdarip değildir, yapılandırılmamış verileri mükemmel bir şekilde sindirirler, dahası, her gözlem keyfi boyutta olabilir.

Ve "görüş penceresi" (tarih penceresi) sadece bilgisayar gücü ile sınırlandırılabilir. ya da sağduyu.


Dolayısıyla, geçmiş penceresinin boyutuyla ilgili örneğiniz sadece AC için ve MO'ya karşı bir oydur.


Bana biraz daha argüman sunun, gerçekten bir şeyleri kaçırıyor muyum merak ediyorum.

Bir soru daha, AU'ya ne kadar ilgi duyuyorsunuz?

Kuralların içine dalmadım. Biçimsel dilbilgisi uygulamasına diğer taraftan geldiğimi zaten yazmıştım - fiyata stokastik dilbilgisi tarafından oluşturulduğu şekliyle baktım. Bu yaklaşımdan tam olarak hantallığı nedeniyle vazgeçtim, ki bu her şeyden önce aşırı eğitime neden olduğu için kötü.

Şimdi ağır modellerden kaçınıyorum. Benim için ana gayri resmi kural, modelin ağırlığının örnekteki bilginin ağırlığına karşılık gelmesi gerektiğidir.

Modeliniz tam teşekküllü bir fiyat modeli için yeterince ağır, ancak elimizdeki gerçek fiyat örneği (diğer bilgileri eklesek bile) böyle bir model için yeterli değil.

Doğal olarak, IMHO

 
mytarmailS #:

Peki AMO örnekten nasıl bir model çıkarıyor?

Açıklık getirmek için her şeyi çok mütevazı bir şekilde anlattım, gerçekte daha çok şuna benziyor.



Ve modeliniz sadece bunu görüyor: (son 5 saatlik mum).

Ayrıca endeksle bir bağlantı olmadığını unutmayın, eğer önemli bir olay dün 200 mum önce olduysa, bugün aynı olay 1555 mum önce olabilir veya örneğin 12....

AC böyle bir model bulacaktır, AMO bulamayacaktır!

AMO, her özelliğin tabloda her zaman aynı sütuna sahip olmasına ihtiyaç duyar, böylece her zaman aynı indeks altında tetiklenir.


ya da bunun gibi, ki bu da oldukça görseldir.

[[1]]
[1] ".....A...............................................................B........C..............SELL"

[[2]]
[1] ".......A........B...........C...........SELL"

[[3]]
[1] "........................................A........B.........................C.............SELL"

[[4]]
[1] "..A.............................................................B..............C...SELL"

[[5]]
[1] ".......A..........................................B...C...SELL"

ve modelleyici bunu görür.

[[1]]
[1] ".....A...............................................................B........C.............. SELL"

[[2]]
[1] ".......A........B...........C........... SELL"

[[3]]
[1] "........................................A........B.........................C............. SELL"

[[4]]
[1] "..A.............................................................B..............C... SELL"

[[5]]
[1] ".......A..........................................B...C... SELL"


Her neyse, umarım demek istediğimi anlatabilmişimdir.

 
Aleksey Nikolayev #:

Bu arada, piton çalışması nasıl gidiyor?

 
mytarmailS #:

Bu arada, piton çalışması nasıl gidiyor?

İyi bir dildir, ancak belli bir seviyeden sonra programcı olmayanlar için çok karmaşık hale gelir. Örneğin, C'de uzantı yazmak R'de yazmaktan çok daha zordur. Numpy'deki tabloları gerçekten sevdim.

 
Aleksey Nikolayev #:

Kuralların içine dalmadım. Biçimsel dilbilgisi uygulamasına diğer taraftan geldiğimi zaten yazmıştım - fiyata stokastik dilbilgisi tarafından oluşturulduğu şekliyle baktım. Bu yaklaşımdan tam olarak hantallığı nedeniyle vazgeçtim, ki bu her şeyden önce aşırı eğitime neden olduğu için kötü.

Artık ağır modellerden kaçınıyorum. Benim için ana gayri resmi kural, modelin ağırlığının örnekteki bilginin ağırlığına karşılık gelmesi gerektiğidir.

Modeliniz tam teşekküllü bir fiyat modeli olacak kadar ağır, ancak elimizdeki gerçek fiyat örneği (diğer bilgileri eklesek bile) böyle bir model için yeterli değil.

Doğal olarak, IMHO

100%

 
mytarmailS #:

Ayrıca, endeksle bir bağlantı olmadığını unutmayın, eğer önemli bir olay dün 200 mum önce gerçekleşmişse, bugün aynı olay 1555 mum önce veya örneğin 12 mum önce gerçekleşmiş olabilir....

AC böyle bir model bulacaktır, AMO bulamayacaktır!

AMO, her özelliğin tabloda her zaman aynı sütuna sahip olmasına ihtiyaç duyar, böylece her zaman aynı indeks altında tetiklenir.


ya da bunun gibi, ki bu da oldukça görsel.

Merak ediyorum, yaklaşık yarım yıl önce tarif ettiğim şeyi tam olarak yapıyorum.

Kurallarınızın bir özelliğin değerini indekse başvurmadan dikey olarak nasıl aradığını anlamıyorum - benim konseptimde kabul edilebilir bir arama aralığı olmalı - uygulamanızı anlamıyorum.

 
Aleksey Vyazmikin #:

Meraklı, yaklaşık altı ay önce tarif ettiğim şeyi aynen yapıyor.

Kurallarınızın bir özelliğin değerini indekse başvurmadan dikey olarak nasıl aradığını anlamıyorum - benim konseptimde kabul edilebilir bir arama aralığı olmalı - uygulamanızı anlamıyorum.

İlişkisel kuralların olağan algoritmalarıyla, göreve bağlı olarak farklı.

Size o zaman (yarım yıl önce) sorununuz için bir çözüm (kod) vermiştim, unuttunuz mu?
 
Aleksey Nikolayev #:

İyi bir dildir, ancak belli bir seviyeden sonra programcı olmayanlar için çok karmaşık hale gelir. Örneğin, C'de uzantı yazmak R'de yazmaktan çok daha zordur. Numpy'deki tabloları gerçekten sevdim.

kutsal soru)

pazar araştırması için - R mi python mu?

 
mytarmailS #:

holivar sorusu)

Pazar araştırması için - R mi Python mu?

Şu anda benim tarafımdan yapılan pazar araştırması için - R. Gelecekte başkaları veya kendim için kefil olmaya hazır değilim).

 
mytarmailS #:
Birleştirici kuralların olağan algoritmaları, probleme bağlı olarak farklı.

Size o zaman (yarım yıl önce) sorununuz için bir çözüm (kod) vermiştim, unuttunuz mu?

Hangi koddan bahsettiğimizi bile bilmiyorum - görünüşe göre bir şey çalıştırılamadı. Hangi koddan bahsediyoruz?

Derinliğin zaman içinde önemli olaylar olmadığını iddia ediyorsunuz - ve kural tarafından nasıl yazıldığını - anlamadım.

1...314431453146314731483149315031513152315331543155315631573158...3399
Yeni yorum