-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validatie #2
Comments
potentiële oplossingen
|
Eigenlijk zijn dit twee verschillende dingen. Er is inderdaad het probleem van de datakwaliteit (zie #8), wat we kunnen aanpakken door outliers are automatisch uit te gooien, zoals je voorstelt, en door de data handmatig na te lopen. Maar als we dat eenmaal gedaan hebben en we krijgen een model uit de analyse, hoe beslissen we dan of dat model redelijk goed werkt? Het zou bijvoorbeeld zo kunnen zijn dat we om de een of andere reden toch niet de juiste variabelen hebben geselecteerd (#1), waardoor het model niet goed is. De meest simpele benadering is, denk ik, om de analyse in maxent te doen en dan te kijken naar de AUC, die dan >0.7 moet zijn (zie Raes & Aguirre-Gutierrez, 2018). |
Wat we nu doen is een combinatie van de AUC en de null model methode van Raes & Ter Steege |
Trouwens, doen we inderdaad de null model methode? Of alleen AUC? Als we alleen de AUC doen dan is het de hoogste prioriteit dat we ook die null model methode doen. |
Ik heb nu alleen AUC gedaan. Ik ga morgen uitzoeken hoe ik die null model methode ook erbij kan doen. |
Maar het is in principe wel al zo dat je een aantal occurrences apart zet om de test mee te doen, toch? Ik bedoel, het aanmaken van die partities zit al in de Maxent_Function(), als ik het goed begrijp |
Ja in de maxent functie zet ik 25% van de data apart om de AUC test mee te doen. Bij een null model vergelijk je de AUC die uit de maxent komt met een de AUC van een random model. Alleen ben ik nu het artikel van niels aan het lezen over null models en hierin zegt hij volgensmij dat als je de AUC berekend door een split sample approach dat deze splitsing de AUC heel erg beïnvloed. Dus ik denk dat de AUC die ik berekend heb niet vergelijkbaar is met de AUC uit een random model omdat je hier geen split sample approach gebruikt. |
Als ik het script bekijk van Niels (die had hij een tijdje geleden naar ons gemaild), dan gebruikt hij de jackknife approach en dan hoef je de data niet te splitsen. Daarna evaluate hij het hele model model zonder er een splitsing in te maken. Ik denk dat als wij ook een jackknife training van het model doen dat we de AUC's wel met elkaar kunnen vergelijken. |
ok, nou ja, als het op die manier werkt dan lijkt me dat prima. Zolang we
maar meer qua validatie doen dan alleen de AUC vergelijken. Is het dan dus
zo dat we op die manier ook meer occurrences zouden kunnen overhouden omdat
we dan geen k-fold partitie hoeven aan te maken?
|
Dus het probleem is dat we onze validatie op meer moeten baseren dan de AUC? want de null model methode is ook weer gebaseerd op de AUC. Ik zoek nu even uit of we idd meer occurences overhouden. |
Volgens mij was het zo met die AUC dat de ruwe waarde beinvloed wordt door
het aantal occurrences en de extent van het gebied, zodanig dat ruwe AUC
waardes tussen modellen niet goed te vergelijken zijn. De methode van Raes
en Ter Steege doet een soort resampling om daar voor te corrigeren, toch?
… |
Zoals ik het nu begrijp is het volgende de bedoeling volgens Raes en Ter Steege :
Voor onze resultaten heeft dit wel gevolgen want we kunnen het dus runnen met test en training data of met alleen trainingsdata. Ik denk dat dit vooral invloed heeft op de modellen met weinig occurence points. |
- Ze berekenen de AUC van het Maxent model met alleen trainingsdata,
dus er wordt helemaal niet gesplit
Dat is op zich mooi, inderdaad met name voor de soorten met weinig
occurrences.
1. null- model op basis van de hele extent (je trekt dus random
samples uit het hele gebied)
2. bias corrected null-model (je trekt dan random samples uit de
occurence dataset). je haalt de random samples uit de occurence dataset
omdat er waarschijnlijk alleen onderzoek is gedaan op makkelijk begaanbare
gebieden.
Zijn dat dan de daadwerkelijke occurrences die je sampelt?
- het null model run je 100 keer en daar komt een distributie van AUC
values uit. als de AUC met de echte occurence data buiten het 95%
confidence interval (one-sided) valt van de random AUC values dan is het
model significant beter.
Yikes, ok, dat betekent dan dat het berekenen van de modellen zo 100x zo
lang gaat duren. Als je eenmaal hebt uitgevonden hoe we dat gaan runnen dan
moeten we dat even splitsen: een deel op mijn laptop, een deel op die van
jou, een deel op mijn desktop en een deel in de cloud, waar we 8 cores
hebben.
|
Jaa het gaat echt heel lang duren denk ik :'). Ik weet nu ook nog niet zeker of ik de berekeningen goed doe en welk null model ik het beste kan gebruiken. Denk jij dat Niels Raes nog een keer tijd heeft voor wat vragen? |
Hi Niels,
heb je de komende week ergens misschien nog een keertje tijd om je licht te
laten schijnen over onze implementatie van je null model validatie (sensu
Raes & Ter Steege)?
Thanks!
Rutger
…On Thu, Mar 7, 2019 at 3:27 PM ElkeHendrix ***@***.***> wrote:
Jaa het gaat echt heel lang duren denk ik :'). Ik weet nu ook nog niet
zeker of ik de berekeningen goed doe en welk null model ik het beste kan
gebruiken. Denk jij dat Niels Raes nog een keer tijd heeft voor wat vragen?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGf-smvL8yRHVXrZeU9uzy6LynghvOZks5vUSHBgaJpZM4Z3YdJ>
.
|
Feedback Niels:
|
We trekken nu random samples uit alle occurence points (die zijn te zien in het zwart) min de occurence points van de soort waar we op dat moment naar kijken. Alle rode occurence points laten de points zien binnen de model extent. Dit levert in een paar gevallen problemen op:
er zijn maar 2 metingen in hetzelfde gebied gedaan. hetzelfde probleem bij de Ovibos moschatus er zijn maar 8 andere metingen in hetzelfde gebied gedaan zelfde probleem bij Rusa timorensis geen andere punten We moeten dus denk ik gewoon een random sample uit de model environment trekken en daar ons null model op baseren. Maar dan hebben we geen collection bias eruit gehaald. dan zijn er nog een paar modellen die niet runnen
|
Hoe gaan we de kwaliteit van de modellen valideren? Er gaan vast situaties zijn waar de data gewoon niet goed genoeg zijn voor een bepaalde soort: te weinig waarnemingen, misidentificaties, "waarnemingen" in dierentuinen, verkeerde lat/lon coderingen, etc. Hoe gaan we objectief bepalen dat we een bepaalde soort echt niet mee kunnen nemen in de analyse?
The text was updated successfully, but these errors were encountered: