Implémentation en R d’un modèle de micro-réserve utilisant l’algorithme XGBoost.
Ce package a pour objectif de contenir tout le matériel nécessaire afin de pouvoir reproduire le projet de recherche de Gabriel Crépeault-Cauchon effectué pour le cours ACT-2101 au cours de la session d’automne 2019 à l’Université Laval.
Résumé du projet de recherche
Le projet de recherche avait pour but de reproduire le modèle de F. Duval et M. Pigeon (2019) , qui propose d’utiliser l’algorithme XGBoost afin de prédire le montant payé à l’ultime d’une réclamation en assurance, afin de pouvoir faire une estimation de la réserve individuelle à appliquer. Dans le cadre du projet de recherche, le modèle a été implémenté avec R sur un portefeuille de réclamations simulé à l’aide d’un réseau de neurones (Gabrielli et Wuthrich, 2018).
Installation du package
Pour l’instant, le package n’est pas accessible depuis le CRAN. Il est toutefois possible de le télécharger sur votre session R avec la commande suivante :
Dans l’éventualité où ce package pourrait être publié sur le CRAN, la partie de la documentation des différents éléments du package a été faite en anglais. Ce site web sert uniquement à supporter le rapport du projet de recherche.
Éléments contenus dans le package xgbmr
Fonctions personnalisées, principalement utilisée dans les chapitres implémentation et résultats
Fonction helper qui permettent de faciliter le tuning d’un modèle XGBoost. Ces fonctions peuvent être réutilisés pour ajuster un modèle XGBoost dans un tout autre contexte.
Application shiny Black Box Explain, qui utilise les principales fonctions du package iml afin de visualiser (de façon interactive) l’interprétabilité du modèle (Feature importance, PDP/ICE curves, LIME models, pred-on-truth graphs, etc).
Références
Duval, F., & Pigeon, M. (2019). Individual loss reserving using a gradient boosting-based approach. Risks, 7(3), 79.
Gabrielli, A., & V Wüthrich, M. (2018). An individual claims history simulation machine. Risks, 6(2), 29.
This plugin allows you to pass the currently logged in user info to the model layer
of a CakePHP application.
It comes bundled with the FootprintBehavior to allow you control over columns
such as user_id, created_by, company_id similar to the core’s TimestampBehavior.
You then need to load the plugin by running console command:
bin/cake plugin load Muffin/Footprint
The Footprint plugin must be loaded before the Authentication plugin,
so you should updated your config/plugins.php or Application::bootstrap() accordingly.
Usage
Middleware
Add the FootprintMiddleware to the middleware queue in your Application::middleware()
method:
$middleware->add('Muffin/Footprint.Footprint');
It must be added afterAuthenticationMiddleware to ensure that it can read
the identify info after authentication is done.
If you don’t have direct access to the place where AuthenticationMiddleware is added then check here.
Behavior
To use the included behavior to automatically update the created_by and modified_by
fields of a record for example, add the following to your table’s initialize() method:
This will insert the currently logged in user’s primary key in user_id and modified_by
fields when creating a record, on the modified_by field again when updating
the record and it will use the associated user record’s company id in the
company_id field when creating a record.
You can also provide a closure that accepts an EntityInterface and returns a bool:
In some cases you don’t have direct access to the place where the AuthenticationMiddleware is added. Then you will have to add this to your src/Application.php
useAuthentication\Middleware\AuthenticationMiddleware;
useCake\Event\EventInterface;
useCake\Http\MiddlewareQueue;
useMuffin\Footprint\Middleware\FootprintMiddleware;
// inside the bootstrap() method$this->getEventManager()->on(
'Server.buildMiddleware',
function (EventInterface$event, MiddlewareQueue$middleware) {
$middleware->insertAfter(AuthenticationMiddleware::class, FootprintMiddleware::class);
}
);
Patches & Features
Fork
Mod, fix
Test – this is important, so it’s not unintentionally broken
Commit – do not mess with license, todo, version, etc. (if you do change any,
bump them into commits of their own that I can ignore when I pull)
Open-source Django project crafted on top of Modernize, an open-source Bootstrap 5 design from AdminMart.
The product is designed to deliver the best possible user experience with highly customizable feature-rich pages. Modernize has easy and intuitive responsive design whether it is viewed on retina screens or laptops.
Flag that allows self-assignment to an issue or pull request.
allow_no_assignees
boolean
No
False
Flag that prevents the action from failing when there are no assignees.
assignment_options
string
No
ISSUE
Assignment options in a GitHub action related to automatically assigning issues and pull requests.
By default, write permission allows the GitHub action only to create and edit issues in public repositories.
You must use admin permission or a more restricted setting for private repositories.
You can generate a personal access token with the required scopes.
Working only with issues
Example of how to configure your .yml file to auto-assign users only for issues.
It is a simple loader of files OFF (Object File Format) written in C++ using OpenGL. The code read the file which is totally basic and contains only triangles, i.e. 3 vertexes by triangle; and no color per vertex/triangle. In order to support quads or more, it is necessary the subdivision of the primitives.
The data structure used is very simple. It is based on stores the number of vertexes, triangles and two dynamic arrays (you can change them by vectors). Also, the base data type such as point3f and others were performed using the OpenGL Mathematics (http://glm.g-truc.net/).
The code includes the GLM, FreeGLUT (including dll/lib) and a simple .OFF file to test. There are several pages which have .OFF file to download. It works for Visual Studio compiler because its using #pragma comment to link the .lib of freeglut.
I REMEMBER AGAIN: this code is only to be used as a template. There is no efficiency inside the code, Actually, it includes the slower and deprecated way to render in OpenGL: glBegin/glEnd.
Dataloader is a generic utility to be used as part of your application’s data fetching layer to provide a simplified and consistent API to perform batching and caching within a request. It is heavily inspired by Facebook’s dataloader.
Getting started
First, install Dataloader using bundler:
gem"dataloader"
To get started, instantiate Dataloader. Each Dataloader instance represents a unique cache. Typically instances are created per request when used within a web-server. To see how to use with GraphQL server, see section below.
Dataloader is dependent on promise.rb (Promise class) which you can use freely for batch-ready code (e.g. loader can return Promise that returns a Promise that returns a Promise). Dataloader will try to batch most of them.
Basic usage
# It will be called only once with ids = [0, 1, 2]loader=Dataloader.newdo |ids|
User.find(*ids)end# Schedule data to loadpromise_one=loader.load(0)promise_two=loader.load_many([1,2])# Get promises resultsuser0=promise_one.syncuser1,user2=promise_two.sync
A batch loading block accepts an Array of keys, and returns a Promise which resolves to an Array or Hash of values.
Dataloader will coalesce all individual loads which occur until first .sync is called on any promise returned by #load or #load_many, and then call your batch function with all requested keys.
user_loader.load(1).then{ |user| user_loader.load(user.invited_by_id))}.then{ |invited_by| "User 1 was invited by ${invited_by[:name]}"}# Elsewhere in your backenduser_loader.load(2).then{ |user| user_loader.load(user.invited_by_id))}.then{ |invited_by| "User 2 was invited by ${invited_by[:name]}"}
A naive solution is to issue four SQL queries to get required information, but with Dataloader this application will make at most two queries (one to load users, and second one to load invites).
Dataloader allows you to decouple unrelated parts of your application without sacrificing the performance of batch data-loading. While the loader presents an API that loads individual values, all concurrent requests will be coalesced and presented to your batch loading function. This allows your application to safely distribute data fetching requirements throughout your application and maintain minimal outgoing data requests.
Batch function
A batch loading function accepts an Array of keys, and returns Array of values or Hash that maps from keys to values (or a Promise that returns such Array or Hash). There are a few constraints that must be upheld:
The Array of values must be the same length as the Array of keys.
Each index in the Array of values must correspond to the same index in the Array of keys.
If Hash is returned, it must include all keys passed to batch loading function
For example, if your batch function was provided the Array of keys: [ 2, 9, 6 ], you could return one of following:
Dataloader provides a memoization cache for all loads which occur withing single instance of it. After #load is called once with a given key, the resulting Promise is cached to eliminate redundant loads.
In addition to relieving pressure on your data storage, caching results per-request also creates fewer objects which may relieve memory pressure on your application:
Dataloader caching does not replace Redis, Memcache, or any other shared application-level cache. DataLoader is first and foremost a data loading mechanism, and its cache only serves the purpose of not repeatedly loading the same data in the context of a single request to your Application. To do this, it maintains a simple in-memory memoization cache (more accurately: #load is a memoized function).
Avoid multiple requests from different users using the same Dataloader instance, which could result in cached data incorrectly appearing in each request. Typically, Dataloader instances are created when a request begins, and are not used once the request ends.
See Using with GraphQL section to see how you can pass dataloader instances using context.
Caching errors
If a batch load fails (that is, a batch function throws or returns a rejected Promise), then the requested values will not be cached. However if a batch function returns an Error instance for an individual value, that Error will be cached to avoid frequently loading the same Error.
In some circumstances you may wish to clear the cache for these individual Errors:
In certain uncommon cases, a Dataloader which does not cache may be desirable. Calling Dataloader.new({ cache: nil }) { ... } will ensure that every call to #load will produce a new Promise, and requested keys will not be saved in memory.
However, when the memoization cache is disabled, your batch function will receive an array of keys which may contain duplicates! Each key will be associated with each call to #load. Your batch loader should provide a value for each instance of the requested key.
Dataloader is a class for fetching data given unique keys such as the id column (or any other key).
Each Dataloader instance contains a unique memoized cache. Because of it, it is recommended to use one Datalaoder instance per web request. You can use more long-lived instances, but then you need to take care of manually cleaning the cache.
You shouldn’t share the same dataloader instance across different threads. This behavior is currently undefined.
Dataloader.new(options = {}, &batch_load)
Create a new Dataloader given a batch loading function and options.
batch_load: A block which accepts an Array of keys, and returns Array of values or Hash that maps from keys to values (or a Promise that returns such value).
options: An optional hash of options:
:key A function to produce a cache key for a given load key. Defaults to function { |key| key }. Useful to provide when objects are keys and two similarly shaped objects should be considered equivalent.
:cache An instance of cache used for caching of promies. Defaults to Concurrent::Map.new.
The only required API is #compute_if_absent(key)).
You can pass nil if you want to disable the cache.
You can pass pre-populated cache as well. The values can be Promises.
:max_batch_size Limits the number of items that get passed in to the batchLoadFn. Defaults to INFINITY. You can pass 1 to disable batching.
