slides_smartphones_2.qmd

---
title: "Application des modèles SFA à l'étude des prix"
subtitle: "<script>const currentDT = new Date().toLocaleDateString();document.write(currentDT);</script>"
author: "`Aybuké BICAT` & `Corentin DUCLOUX`"
institute: <img src = https://corentinducloux.fr/Reveal.js/univ-tours.png width="70%">
title-slide-attributes:
    data-notes: "Bonjour à tous, on va vous présenter la deuxième partie de notre projet 3R portant sur l'application des modèles SFA à l'étude des prix. Avant de rappeler les fondements théoriques des modèles SFA ainsi que les résultats de l'estimation, on va revenir sur notre problématique appliquée."
format: 
  revealjs:
    slide-number: true
    mermaid-format: svg
    chalkboard: true
    transition: slide
    background-transition: fade
    theme: [blood, custom.scss]
    incremental: true   
    footer: "--- Recherche, Réalisation, Restitution ---"
    logo: https://corentinducloux.fr/dossier_img/mecen_transparent.png
    controls : true
    preview-links: auto
    view-distance: 20
    reference-location: document
    bibliography: references.bib
    include-in-header:
        - text: |
            <style>
            #title-slide .title {
            font-size: 1.75em;
            }
            </style>
link-external-icon: true
engine: knitr
---

```{r}
#| label: lib_imports
library(gt)
library(arrow)
library(tidyverse)
library(frontier)
library(moments)
library(patchwork)
library(ggtext)
library(showtext)
```

```{r}
#| label: theming
#| echo: false
theme_set(theme_minimal())
thematic::thematic_on(bg = "#222222", fg = "white", accent = "purple", font = "PT Sans")
```

```{r}
#| label: custom_funcs
makestars <- function(pvalues) {
    return(
        dplyr::case_when(
            pvalues < 0.001 ~ "_***_",
            pvalues < 0.05 ~ "_***_",
            pvalues < 0.1 ~ "_***_",
            .default = ""
        )
    )
}

`%nin%` <- negate(`%in%`)
```

## Problématique {background-color="black" background-image="https://vivreaulycee.fr/wp-content/uploads/2018/12/question-mark-2492009_1280-1200x480.jpg" background-size="cover" background-opacity="0.75"}

`Combinaison d'un modèle SFA et d'une régression hédonique pour évaluer la discordance entre les prix de smartphones et leur valeur.`

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

::: {.notes}
*Corentin*


Notre problématique était la suivante : *Voir slide*

En se basant sur cette problématique, nous voulions, en plus d'une estimation économétrique qui présente son lot de complexité (nous le verrons par la suite), créer une application, et plus précisément un comparateur d'efficacité.

En premier lieu, il convient de se poser une question qui semble évidente à première vue, mais qui, quand on s'y penche de plus près, est assez sophistiquée. 

- Cette question c'est "Qu'est ce qu'un comparateur exactement ?"
:::

## Comparateur {.smaller}

> *Un comparateur en ligne, qu'est ce que c'est ?*


::: {.callout-tip}

## Définition

Un comparateur est un site web qui permet de comparer différents produits ou services.

Principalement axé sur les prix, il peut également prendre en compte les aspects techniques et la qualité des produits.

- <https://www.idealo.fr>
- <https://www.ledenicheur.fr>
- <https://www.kimovil.com/fr/>

:::

::: {.footer}
--- Recherche, Réalisation, `Restitution` ---
:::

:::{.notes}
*Buk*


Un comparateur est un site web qui permet de comparer différents produits ou services.

Principalement axé sur les prix, il peut également prendre en compte les aspects techniques et la qualité des produits.

Les exemples sont multiples : Comparateur de vols, d'assurances, de voitures, de banques...

En bref il existe une variété de cas d'usage et un nombre croissant d'utilisateurs faisant appel à ces comparateurs avant d'acheter un bien ou un service.

On a aussi mis à disposition des exemples de comparateurs sur nos slides. 

Les deux premiers sont des références dans le domaine des comparateurs de prix généralistes.

Le troisième, `kimovil` est spécialisé dans l'analyse des smartphones et est assez analogue à ce que nous allons proposer puisqu'il n'est pas uniquement un comparateur de prix mais qu'il inclut une dimension de modélisation, plus précisément un score qui est déterminé grâce à du **Machine Learning**.

Cela étant, la description du score est assez sommaire, il est simplement précisé que plus de 200 variables sont utilisées... 

$\Rightarrow$ Finalement ce score est plutôt opaque.

:::

## Obligations d'information sur les comparateurs {.smaller}

Les opérateurs de plateforme en ligne doivent délivrer au consommateur une information **loyale**, **claire** et **transparente**, selon l’article [L. 111-7 du code de la consommation](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000033219601).

Les comparateurs en ligne sont donc eux aussi soumis à ces obligations de loyauté et de transparence.

- Page dédiée accessible depuis toutes les autres pages du comparateur informant le fonctionnement de celui-ci.

- Faire figurer sur chaque page de résultats  les informations concernant les critères de classement.

- Indiquer via la mention explicite **« annonce »** les résultats liés à des partenariats rémunérés.

::: {.footer}
--- Recherche, Réalisation, `Restitution` ---
:::

:::{.notes}
*Corentin*

Aybuké n'en a pas parlé mais il y a des questions juridiques / économiques / statistiques et algorithmiques qui se posent.

Il va sans dire que très peu de comparateurs respectent le premier point, souvent pour une raison simple : ce sont juste des listings de prix de téléphones du moins cher au plus cher, il n'y a pas vraiment de fonctionnement à proprement parler.

De même, concernant les critères de classement.

En revanche le troisième point est presque toujours indiqué quelque part avec la mention *publicité* ou *annonce* quand il y a un partenariat rémunéré, et c'est normal car une grande partie des revenus de ces comparateurs provient de ces partenariats donc il font assez attention à ce point.

***

L'avantage de notre comparateur c'est qu'il respecte les deux premiers points, sans se soucier du troisième puisqu'on a pas de partenariats rémunérés. Tout ça permet d'offrir une grande transparence pour le consommateur.

:::

## Explication `SMART'SPECS`

:::: {.columns}

::: {.column width="50%"}
![](imgs/mermaid_graph.png){width=95%}
:::

::: {.column width="50%"}
<u>**Fonctionnalités**</u> : 

- Statistiques élémentaires
- Restitution d'informations
- Effort visuel et nombreuses fonctionnalités
- Moteur basé sur un modèle **SFA**
:::

::::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*

Je vais vous rappeler l'architecture de notre application, avec les blocs **Python** et **R** respectivement en jaune et en bleu.

On a intégré les résultats par ce qu'on appelle le seuil d'efficacité qui correspond en fait à un score.

Concernant les données, on s'est basé sur des données scrapées en février uniquement sur le site du revendeur **Boulanger**.

Les modèles qu'on a construit que vous voyez dans le bloc en bleu définissent le score (l'efficacité) en terme de prix.

Ensuite pour ce qui est des fonctionnalités :

:::

## `SMART'SPECS` Démonstration

**🚀 Lancement de l'application** <img src="imgs/logo.png" alt="Logo" style="vertical-align: middle; margin-right: 2.5px; width: 60px; height: 60px;">




::: {.callout-note}

## Depuis le terminal

*Lancement du shell poetry* :

```powershell
py -m poetry shell
```

*Lancement de l'application* :

```powershell
python -m streamlit run Accueil.py
```


:::

:::{.callout-note}

## Depuis le lien de l'application déployée

- **Lien** : [https://smart-specs.streamlit.app/](https://smart-specs.streamlit.app/)

:::


::: {.footer}
--- Recherche, Réalisation, `Restitution` ---
:::

:::{.notes}

1. **Page d'accueil**

*Buk*


Quand on lance l'application, on arrive donc sur une page d'accueil soignée pour expliquer l'utilité de notre comparateur Smart Specs, permettant de vous assister dans la quête de votre smartphone idéal. 

Il est précisé pour l'utilisateur qu'un modèle SFA est utilisé en arrière-plan mais on vous rappelera plus en détail le fonctionnement du modèle SFA quand on arrivera à la partie des résultats.

On peut aussi voir la dernière d'actualisation du scraping. Par rapport à la première présentation, ce sont donc des données plus récentes, issues de février.

On peut ensuite s'intéresser à plusieurs autres pages.

2. **Insights**

*Corentin*


Les insights sont simplement des statistiques descriptives qui nous permettent de mettre en avant des résultats pas forcément observables dans l'achat d'un téléphone.

On peut par exemple s'intéresser au prix moyen par marque. On retrouve, sans surprise, comme dans la première présentation, que XIAOMI propose les téléphones les moins chers en moyenne tandis qu'APPLE propose les téléphones les plus chers en moyenne.

Pour le nombre de modèles vendus par marque, on retrouve XIAOMI, SAMSUNG & APPLE sur le podium et qui possèdent à eux trois plus de 300 téléphones commercialisés soit 80% du total sur Boulanger.


*Buk*
Pour ce qui est du prix en fonction de la RAM, on peut voir que le prix médian augmente avec la RAM, ce qui est plutôt logique. On voit aussi grâce au jitterplot à côté du boxplot que la dispersion augmente à mesure que la RAM augmente.

On peut faire les mêmes interprétations pour le boxplot du prix en fonction du stockage mais on remarque qu'il y a un peu moins de dispersion.



*Corentin*
Enfin, il y a aussi la distribution des prix, qu'on vous avait exposé dans la première présentation et qui, on le rappelle, possédait une distribution asymétrique. C'est toujours le cas, et on remarque de manière plus importante encore deux pics dans la distribution des prix, qui nous permettent de distinguer des téléphones **bas de gamme** et **haut de gamme**.

L'option distribution marginale permet de visualiser la distribution des téléphones sans aggrégation par intervalle de prix, c'est à dire qu'on est en mesure de voir pour chaque modèle le prix exact.

Enfin, l'option la plus intéressante selon nous est la distribution par marque, qui permet de subdiviser la distribution générale par marque.

Ce qui pourrait être intéressant serait de sélectionner les marques qui nous intéressent : par exemple XIAOMI et APPLE, et on remarque que XIAOMI est sur une gamme de prix bas tandis que pour APPLE la gamme de prix est plus étalée. On voit globalement que ces deux marques ne sont pas sur le même marché.

3. **Efficacité**

*Buk*

Après avoir pris connaissance de ces insights, l'utilisateur peut naviguer sur la page d'analyse de l'efficacité calculée par le modèle SFA, qui est le point central de notre application.

Initialement, pour une question de lisibilité les deux seules marques sélectionnées sont APPLE & SAMSUNG, mais on peut choisir plus de marques si on le souhaite. De même, le prix maximal d'un smartphone est fixé à 500 €, que l'utilisateur pourra ensuite modifier à sa guise.

On voit ensuite deux indicateurs : le nombre de téléphones efficaces et inefficaces. Ces indicateurs proviennent du nuage de points des efficacités en fonction du prix qu'on peut voir ici. Tous les téléphones compris dans la zone rouge sont considérés comme *inefficaces*, c'est à dire que ce sont de mauvais rapports qualité-prix alors que ceux qui sont au-dessus sont de bons rapport qualité-prix. A noter que ce seuil peut être aussi modifié par l'utilisateur si il veut plus de contrôle.

En plus de tout ça, l'utilisateur dispose aussi d'un diagramme en barres dynamique de l'efficacité moyenne par marque.

4. **Comparateur**

*Corentin*


L'idée est ensuite de s'appuyer sur la page d'analyse de l'efficacité pour comparer deux téléphones à prix similaires mais à efficacité différente. La page Comparateur permet précisément de faire ça.

Ce comparateur est plus complet que ceux actuellement existants parce qu'il inclue évidemment l'efficacité mais aussi un système permettant de comparer les caractéristiques comme la RAM, le stockage, etc.

$\Rightarrow$ On peut par exemple choisir l'**iPhone 14 plus** (256 Go) et le **Google Pixel 8 Pro** (128 Go) qui ont des prix similaires mais des efficacités légèrement différentes.

5. **Détails**

*Buk*


Cet onglet permet de visualiser tous les modèles disponibles et leurs caractéristiques, ou alors de filtrer l'ensemble des téléphones disponibles selon la marque, la capacité de stockage et la RAM. Dans le tableau on peut filtrer selon chaque variable disponible.

:::

## Présentation des modèles

| **Modèle**                        | **Variables** | **Estimateur** |
|-----------------------------------|---------------|----------------|
| _Régression linéaire (hédonique)_ | niveau-niveau | `MCO`          |
| _Régression linéaire (hédonique)_ | log-niveau    | `MCO`          |
| _SFA (frontière de coût)_         | log-niveau    | `MV`           |

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Buk*

Avant de rentrer dans la partie des estimations économétriques, on va vous faire quelques rapides rappels de notre partie de recherche pour vous rafraîchir la mémoire.

Et ensuite on vous présentera les résultats de 3 modèles différents que vous voyez à l'écran.
:::


## Hedonic Pricing ~ Rappel théorique (I)

Cadre apporté par @rosen1974. On étudie un bien différencié $z$ décrit par le vecteur de ses $n$ caractéristiques mesurables tel que : 

:::{.fragment .fade-in}
$$z = (z_1, z_2, \dots, z_n)$$ 
:::

:::{.fragment .fade-in}
> *La différenciation horizontale et verticale des produits implique qu'une vaste gamme de paniers est disponible.*
:::

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::

::: {.notes}
*Buk*



Dans le cadre apporté par Rosen, on étudie un bien différencié z décrit par le vecteur de ses n caractéristiques mesurables.
Vecteur


Il peut y avoir plusieurs combinaisons z1,zn différentes ce qui fait que le bien est différencié.


On peut alors parler de :

**Différenciation Horizontale** $\Rightarrow$ A prix donné, il n'y a pas unanimité dans le choix des consommateurs entre 2 biens (jaune et rouge) : ce sont des différences de goûts.

**Différenciation Verticale** $\Rightarrow$ A prix donné, il y a unanimité dans le choix des consommateurs entre 2 voitures biens : l'un est meilleur que l'autre.

$\rightarrow$ Ces différenciations vont faire qu'une vaste gamme de paniers sera dispo sur le marché.
:::

## Hedonic Pricing ~ Rappel théorique (II)

```{r}
set.seed(43)
num_points <- 6
data <- data.frame(
    x = sample(0:10, num_points, replace = TRUE),
    y = sample(0:10, num_points, replace = TRUE),
    products = paste("Bien", 1:num_points)
)


ggplot(data, aes(x = x, y = y, color = products)) +
    geom_point(size = 5) +
    labs(
        title = "Plan de différents biens avec 2 caractéristiques.",
        x = expression(z[1]),
        y = expression(z[2])
    ) +
    theme(
        plot.title = element_text(size = 20),
        axis.title = element_text(size = 16),
        axis.text = element_text(size = 14),
        legend.title = element_blank(),
        legend.text = element_text(size = 14),
        text = element_text(color = "white")
    )
```

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::

::: {.notes}
*Buk*


On est habitué à représenter les préférences des consommateurs en termes de quantités de biens $x_1$, $x_2$. Ici, changement de paradigme : on va en fait représenter les préférences des consommateurs en termes de caractéristiques de biens.

:::

## Hedonic Pricing ~ Rappel théorique (III)

- Le consommateur n'achète qu'**une seule** unité de bien qui est une combinaison d'attributs $z_1, z_2, \dots, z_n$.
- Un prix est donc défini en chaque point du plan et guide les choix de localisation des consommateurs et des producteurs concernant les ensembles de caractéristiques achetés et vendus.

:::{.fragment .fade-in}
$$\boxed{p(z) = p(z_1, z_2, \dots, z_n)}$$
:::

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::

:::{.notes}
*Corentin*


Achat d'une seule unité de bien car historiquement, Rosen s'intéresse principalement aux biens durables (Machine à laver, logements, voitures, smartphones...). Pourquoi ? C'est parce que c'est beaucoup plus simple d'obtenir des caractéristiques observables sur ces biens durables que sur des biens consommables.

On aboutit à une relation fonctionnelle entre les caractéristiques des biens
et leur prix, appelée fonction de prix hédonique $p(z)$.

En fait, on recherche le lien qu'il y a entre le prix et les caractéristiques d'un produit et ce qu'on mesure résulte potentiellement d'effets de préférence des consommateurs ou de coûts des producteurs.

Tout ça pour dire que l'augmentation du prix peut donc être lié à un effet coût ou un effet demande, et la difficulté c'est que ces effets sont difficilement dissociables.

:::

## OLS LEVEL-LEVEL (I) {.smaller}

**Forme fonctionnelle :**

$$
\begin{split}
price_i = \beta_0 + \beta_1 storage_i + \beta_2 brand_i + \beta_3 ram_i\\
+ \beta_4 induction_i + \beta_5 screen\_size_i + \beta_6 screen\_type_i\\
+ \beta_7 made\_in_i + \beta_8 upgrade\_storage_i + \beta_{9} das\_limbs_i \\
+ \beta_{10} network_i + \beta_{11} ppi_i + \epsilon_i
\end{split}
$$

<hr>

:::: {.columns}
::: {.column width="50%"}
- *storage* : Capacité de stockage
- *brand* : Marque 
- *ram* : RAM du téléphone
- *induction* : Charge à induction 
- *screen_size* : Taille de l'écran
- *screen_type* : Type d'écran
:::

::: {.column width="50%"}
- *made_in* : Lieu de fabrication
- *upgrade_storage* : Carte SD
- *das_limbs* : DAS membres
- *network* : Réseau
- *ppi* : Pixels par Pouce
:::
::::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::


:::{.notes}
*Buk*

On en arrive à la partie d'application du pricing hédonique $\Rightarrow$ On va décomposer le prix d'un bien, en l'occurence un smartphone, en 11 caractéristiques : le stockage, la marque, la ram, la taille et le type d'écran, etc.

Ici on retrouve le modèle en niveau dont les variables n'ont pas été choisies au hasard mais qui ont fait l'objet d'une sélection de variables grâce à un algorithme génétique, on l'avait expliqué mais on ne va pas re-rentrer dans les détails. L'intérêt de ce modèle en niveau c'est de pouvoir directement interpréter les coefficients comme des prix (effets marginaux). 

:::

## OLS LEVEL-LEVEL (II) {.smaller}

```{r}
df_phones <- read_delim("Web_Scraping/data/df_clean_2.csv", delim = ";")

df_phones <- df_phones |> mutate(
    storage = case_when(storage == 8 ~ 128, .default = as.double(storage)),
    screen_type = case_when(model == "Samsung Galaxy Z Fold 3" ~ "Pliable", .default = as.character(screen_type))
)

levelhedonic <- lm(
    price ~ storage + brand + ram + induction + screen_size + screen_type + made_in + upgrade_storage + das_limbs + network + ppi,
    data = df_phones
)

r_squared_level <- round(summary(levelhedonic)$r.squared, 3)

r_adj_squared_level <- round(summary(levelhedonic)$adj.r.squared, 3)

summary(levelhedonic)$coefficients |>
    as.data.frame() |>
    rownames_to_column(var = "Variables") |>
    as_tibble() |>
    janitor::clean_names() |>
    mutate(
        variables = case_when(
            variables == "brandGOOGLE" ~ "*brand* `(GOOGLE)`",
            variables == "brandHONOR" ~ "*brand* `(HONOR)`",
            variables == "brandMOTOROLA" ~ "*brand* `(MOTOROLA)`",
            variables == "brandOPPO" ~ "*brand* `(OPPO)`",
            variables == "brandSAMSUNG" ~ "*brand* `(SAMSUNG)`",
            variables == "brandSONY" ~ "*brand* `(SONY)`",
            variables == "brandXIAOMI" ~ "*brand* `(XIAOMI)`",
            variables == "inductionTRUE" ~ "*induction* `(True)`",
            variables == "screen_typeBords incurvés" ~ "*screen_type* `(Bords Incurvés)`",
            variables == "screen_typePlat" ~ "*screen_type* `(Plat)`",
            variables == "screen_typePliable" ~ "*screen_type* `(Pliable)`",
            variables == "made_inJapon" ~ "*made_in* `(Japon)`",
            variables == "made_inThaïlande" ~ "*made_in* `(Thaïlande)`",
            variables == "made_inViêt Nam" ~ "*made_in* `(Viêt Nam)`",
            variables == "upgrade_storageTRUE" ~ "*upgrade_storage* `(True)`",
            variables == "network5G" ~ "*network* `(5G)`",
            .default = as.character(glue::glue("*{variables}*"))
        )
    ) |>
    mutate(signif = makestars(pr_t)) |>
    gt() |>
    cols_hide(c(t_value, pr_t)) |>
    cols_label(
        variables = gt::md("**Variables**"),
        estimate = gt::md("**Coefficients**"),
        std_error = gt::md("**Ecart Type**"),
        signif = gt::md("**Significativité**")
    ) |>
    tab_header(
        title = md("Résultats de l'estimation pour le modèle  de pricing **Hédonique**"),
        subtitle = md("*Variable dépendante* : `price`")
    ) |>
    fmt_number(
        columns = c(std_error, pr_t),
        decimals = 2,
        drop_trailing_zeros = TRUE
    ) |>
    data_color(
        columns = estimate,
        rows = estimate < 0,
        method = "numeric",
        palette = c("red", "orange"),
        apply_to = "text"
    ) |>
    data_color(
        columns = estimate,
        rows = estimate > 0,
        method = "numeric",
        palette = c("lightgreen", "darkgreen"),
        apply_to = "text"
    ) |>
    fmt_currency(
        columns = c(estimate),
        currency = "euro",
        placement = "right",
        incl_space = TRUE
    ) |>
    fmt_markdown(c(variables, signif)) |>
    tab_footnote(
        md(glue::glue("$R^2=$ {r_squared_level}"))
    ) |>
    tab_footnote(
        md(glue::glue("| $R^2_{{adj}}=$ {r_adj_squared_level}"))
    ) |>
    tab_options(
        table.background.color = "#222222",
        table.font.color = "white",
        table.font.size = 8,
    ) |>
    opt_interactive(page_size_default = 5, use_highlight = TRUE)
```

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::


:::{.notes}
*Buk*

On a un $R^2$ qui est très bon : 86,7 % de la variance du prix est expliquée par nos variables. En fait, ça nous confirme que ça a du sens d'étudier les prix des téléphones en fonction des caractéristiques.

Ici le coefficient $\beta_1$ s’interprète comme l’effet marginal d’1 Go supplémentaire
de capacité de stockage sur le prix, c'est à dire que si la capacité de stockage augmente de 1 Go, alors, le prix augmente de 92 centimes, cet.par.

- En ayant comme catégorie de référence Apple pour la variable marque (brand), on peut
voir que toutes les marques ont un impact négatif sur le prix, cet. par.

- La marque la plus valorisée derrière Apple est **SONY** avec 304.56 € de différence
par rapport à **APPLE**.

- La marque la moins valorisée est **XIAOMI** avec 585.62 € de différence par rapport
à **APPLE**.

- Une augmentation d’1 Go de ram augmente le prix de 26.97 €, cet. par. (Faire lien avec graph insight)

Pour le type d’écran (screen_type), la catégorie de référence est borderless (un écran sans
bordure).

- Disposer d’un écran à bord incurvé diminue le prix de 240.50 € par rapport à la
catégorie de référence borderless, cet. par.

- Pour l’écran plat, le prix diminue de 100.54 € par rapport à la catégorie de réfé-
rence, cet. par.

- Avoir un écran pliable fait augmenter le prix de 144.66 € par rapport à la catégorie
de référence, cet. par.
:::

## OLS LEVEL-LEVEL (III)

```{r}
performance::check_posterior_predictions(levelhedonic)
```

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*


Aussi, une étape visuelle qu'on peut mettre en place est de vérifier l’ajustement du
modèle. La vérification prédictive a posteriori permet de simuler des données répliquées avec le modèle ajusté puis les comparer aux données observées (en coulisses il y a du bootstrap derrière).

$\Rightarrow$ L’objectif est de détecter si le modèle est inadéquat pour décrire les données. Les simulations vont nous aider à évaluer la perf du modèle.

Ici on retrouve bien en vert la distribution bimodale des prix qu'on avait vu dans notre application, mais par contre le modèle a du mal à la représenter, surtout pour les téléphones entre 200 et 500 €.
:::

## OLS LEVEL-LEVEL (IV) {.smaller}

```{r}
ggplot(levelhedonic, aes(x = .fitted, y = .resid)) +
    geom_point() +
    geom_hline(yintercept = 0, color = "darkgreen") +
    labs(x = expression(hat(y[i])), y = expression(e[i])) +
    ggtitle("Valeurs prédites et résidus")
```

```{r}
heterosced_levelhedonic <- performance::check_heteroscedasticity(levelhedonic)
```

::: {.fragment .fade-in}
::: {.fragment .highlight-red}

**Présence d'hétéroscédasticité** (Variance des erreurs $\epsilon_i$ non constantes) ~ $p-value < 0.05$.

:::
:::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*

Vous vous en doutez, mais vu le graphique précédent, il y a une hypothèse importante qui est violée dans ce modèle, et évidemment on voit bien que les résidus ne sont pas homoscédastiques, et le test de *Breusch-Pagan* nous le confirme.
:::

## OLS LEVEL-LEVEL (V) {.smaller}

```{r}
mean_resid <- mean(levelhedonic$resid)
sd_resid <- sd(levelhedonic$resid)

ggplot(levelhedonic, aes(x = .resid)) +
    geom_histogram(aes(y = after_stat(density)), bins = 40, fill = "white", alpha = 0.7) +
    stat_function(fun = dnorm, args = list(mean = mean_resid, sd = sd_resid), color = "darkgreen", size = 1) +
    labs(x = "Résidus", y = "Densité") +
    ggtitle("Histogramme des résidus avec loi normale superposée")

skewness_levelhedonic <- skewness(levelhedonic$residuals)
```

- Valeur du coefficient d'asymétrie : **`r round(skewness_levelhedonic,2)`**

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

::: {.notes}
*Corentin*

Enfin, on peut aussi s'intéresser à la normalité des résidus en regardant le coefficient d'asymétrie

On voit que le coefficient est positif. Cette asymétrie positive indique une concentration de valeurs sur le côté gauche de la distribution, on peut d'ailleurs le voir sur l'histogramme.
:::


## OLS LOG-LEVEL (I) {.smaller}

**Forme fonctionnelle :**

$$
\begin{split}
\ln(price_i) = \beta_0 + \beta_1 storage_i + \beta_2 brand_i + \beta_3 ram_i\\
+ \beta_4 induction_i + \beta_5 screen\_size_i + \beta_6 screen\_type_i\\
+ \beta_7 made\_in_i + \beta_8 upgrade\_storage_i + \beta_{9} das\_limbs_i \\
+ \beta_{10} network_i + \beta_{11} ppi_i + \epsilon_i
\end{split}
$$

<hr>

::: {.callout-note}

Prendre le logarithme de la variable dépendante *(price)* peut aider à stabiliser la variance et réduire l'hétéroscédasticité.

:::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
::: 

::: {.notes}
*Buk*


Prendre le logarithme de la variable dépendante *(price)* peut aider à stabiliser la variance et réduire l'hétéroscédasticité.


On aurait aussi pu utiliser la méthode des moindres carrés pondérés pour essayer d'éliminer l'hétéroscédasticité, mais en fait la spécification log-linéaire est requise pour l'estimation d'un modèle SFA ce qui lui confère un avantage supplémentaire.
:::

## OLS LOG-LEVEL (II) {.smaller}

```{r}
loghedonic <- lm(
    logprice ~ storage + brand + ram + induction + screen_size + screen_type + made_in + upgrade_storage + das_limbs + network + ppi,
    data = df_phones
)

r_squared_log <- round(summary(loghedonic)$r.squared, 3)

r_adj_squared_log <- round(summary(loghedonic)$adj.r.squared, 3)

summary(loghedonic)$coefficients |>
    as.data.frame() |>
    rownames_to_column(var = "Variables") |>
    as_tibble() |>
    janitor::clean_names() |>
    mutate(
        variables = case_when(
            variables == "brandGOOGLE" ~ "*brand* `(GOOGLE)`",
            variables == "brandHONOR" ~ "*brand* `(HONOR)`",
            variables == "brandMOTOROLA" ~ "*brand* `(MOTOROLA)`",
            variables == "brandOPPO" ~ "*brand* `(OPPO)`",
            variables == "brandSAMSUNG" ~ "*brand* `(SAMSUNG)`",
            variables == "brandSONY" ~ "*brand* `(SONY)`",
            variables == "brandXIAOMI" ~ "*brand* `(XIAOMI)`",
            variables == "inductionTRUE" ~ "*induction* `(True)`",
            variables == "screen_typeBords incurvés" ~ "*screen_type* `(Bords Incurvés)`",
            variables == "screen_typePlat" ~ "*screen_type* `(Plat)`",
            variables == "screen_typePliable" ~ "*screen_type* `(Pliable)`",
            variables == "made_inJapon" ~ "*made_in* `(Japon)`",
            variables == "made_inThaïlande" ~ "*made_in* `(Thaïlande)`",
            variables == "made_inViêt Nam" ~ "*made_in* `(Viêt Nam)`",
            variables == "upgrade_storageTRUE" ~ "*upgrade_storage* `(True)`",
            variables == "network5G" ~ "*network* `(5G)`",
            .default = as.character(glue::glue("*{variables}*"))
        )
    ) |>
    mutate(signif = makestars(pr_t)) |>
    gt() |>
    cols_hide(c(t_value, pr_t)) |>
    cols_label(
        variables = gt::md("**Variables**"),
        estimate = gt::md("**Coefficients**"),
        std_error = gt::md("**Ecart Type**"),
        signif = gt::md("**Significativité**")
    ) |>
    tab_header(
        title = md("Résultats de l'estimation pour le modèle  de pricing **Hédonique**"),
        subtitle = md("*Variable dépendante* : `log(price)`")
    ) |>
    fmt_number(
        columns = c(estimate, std_error, pr_t),
        decimals = 2,
        drop_trailing_zeros = TRUE,
    ) |>
    fmt_percent(
        columns = estimate,
        rows = between(estimate, 0, 4),
        pattern = "+{x}"
    ) |>
    fmt_percent(
        columns = estimate,
        rows = estimate < 0,
    ) |>
    data_color(
        columns = estimate,
        rows = variables != "(Intercept)",
        method = "numeric",
        palette = c("red", "orange"),
        apply_to = "text"
    ) |>
    data_color(
        columns = estimate,
        rows = estimate > 0,
        method = "numeric",
        palette = c("lightgreen", "darkgreen"),
        apply_to = "text"
    ) |>
    fmt_markdown(c(signif, variables)) |>
    tab_footnote(
        md(glue::glue("$R^2=$ {r_squared_log}"))
    ) |>
    tab_footnote(
        md(glue::glue("| $R^2_{{adj}}=$ {r_adj_squared_log}"))
    ) |>
    tab_options(
        table.background.color = "#222222",
        table.font.color = "white"
    ) |>
    opt_interactive(page_size_default = 5, use_highlight = TRUE)
```



::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Buk*


$R^2$ meilleur que dans la régression précédente mais on ne peut pas les comparer directement car on n'a pas la même variable explicative à cause du log.

Ici le coefficient $\beta_1$ s’interprète comme le changement en pourcentage du prix lorsque
la capacité de stockage augmente d’1 Go, c'est à dire que si la capacité de stockage augmente de 1 Go, alors, le prix augmente de 0.06%, cet.par.

- En ayant comme catégorie de référence Apple pour la variable marque (brand), on peut
voir que toutes les marques ont un impact négatif sur le prix, cet. par.

– La marque la plus valorisée derrière Apple est SAMSUNG avec une différence de prix
de 39.53%.
– La marque la moins valorisée est XIAOMI avec une différence de prix de 101.06% par
rapport à Apple.

- Si la ram augmente de 1 Go, alors le prix augmente de 7.8%, cet. par

– Disposer d’un écran à bord incurvé diminue le prix de 9.97% par rapport à la
catégorie de référence, cet. par.
– Pour l’écran plat, le prix diminue de 2.8% par rapport à la catégorie de réfé-
rence, cet. par.
– Avoir un écran pliable fait augmenter le prix de 39.13% par rapport à la catégorie
de référence, cet. par.
:::

## OLS LOG-LEVEL (III)

```{r}
performance::check_posterior_predictions(loghedonic)
```

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*

Ici on voit que même si le modèle a du mal à prédire une certaine portion de la distribution, il s'en sort très bien sur les extrémités et globalement l'adéquation du modèle semble meilleure.

$\Rightarrow$ La distribution n'est pas la même car on est passé au log.
:::

## OLS LOG-LEVEL (IV) {.smaller}

```{r}
ggplot(loghedonic, aes(x = .fitted, y = .resid)) +
    geom_point() +
    geom_hline(yintercept = 0, color = "darkgreen") +
    labs(x = expression(hat(y[i])), y = expression(e[i])) +
    ggtitle("Valeurs prédites et résidus")
```

```{r}
heterosced_loghedonic <- performance::check_heteroscedasticity(loghedonic)
```

::: {.fragment .fade-in}
::: {.fragment .highlight-green}

**Pas de présence d'hétéroscédasticité** (Variance des erreurs $\epsilon_i$ constantes) ~ $p-value = 0.354$.

:::
:::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*


On le voit bien graphiquement et c'est confirmé par le test de *Breusch-Pagan* qu'il n'y a plus de problème d'hétéroscédasticité dans ce modèle.
:::

## OLS LOG-LEVEL (V) {.smaller}

```{r}
mean_resid <- mean(loghedonic$resid)
sd_resid <- sd(loghedonic$resid)

ggplot(loghedonic, aes(x = .resid)) +
    geom_histogram(
        aes(y = after_stat(density)), 
        bins = 40,
        fill = "white",
        alpha = 0.7
    ) +
    stat_function(
        fun = dnorm, 
        args = list(mean = mean_resid, sd = sd_resid),
        color = "darkgreen",
        size = 1
    ) +
    labs(x = "Résidus", y = "Densité") +
    ggtitle("Histogramme des résidus avec loi normale superposée")

skewness_loghedonic <- skewness(loghedonic$residuals)
```

- Valeur du coefficient d'asymétrie : **`r round(skewness_loghedonic,2)`**

::: {.fragment}

@kumbhakar2015 mentionnent l'utilisation du coefficient d'asymétrie comme *"test"* préalable à la spécification d'une **SFA**.

:::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

::: {.notes}
*Corentin*


Ici on remarque que les résidus semblent suivre une loi normale, mais on a quand même encore un coefficient d'asymétrie positif.

L'idée derrière le test est la suivante : Pour une spécification SFA frontière de coût avec erreur composée, la distribution des résidus de l'estimation par MCO
doit avoir une asymétrie positive. Si cette asymétrie est positive, alors elle permet de confirmer l'existence d'une erreur unilatérale et donc la forme fonctionnelle SFA sera appropriée. On va justement revenir en détail sur tout ça dans la partie suivante.

:::

## SFA ~ RAPPELS (I) {.smaller}

@aigner1977 :

**Objectif** : Formulation et estimation de fonctions de frontière de production stochastique.

:::{.fragment .fade-in}
$${\displaystyle y_{i}=f(x_{i};\beta )\cdot TE_{i}}$$
:::

- $TE_i$ représente l'efficacité technique, définie comme le ratio d'output observé sur l'output maximum réalisable, c'est à dire : $TE_i = \dfrac{y_i}{y_i^*}$.

- Ajout d'un composant **stochastique** ${\exp \left\{{v_{i}}\right\}}$ qui représente les chocs aléatoires affectant la production. La fonction de production devient alors :

:::{.fragment .fade-in}
$$\boxed{{\displaystyle y_{i}=f(x_{i};\beta )\cdot TE_{i}\cdot \exp \left\{{v_{i}}\right\}}}$$

:::


::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::

:::{.notes}
*Aybuké*


On vous a présenté deux modèles qui appliquent le concept du pricing hédonique mais qui finalement restent des régressions linéaires classiques. 

- On repart d'une fonction de production, mais on lui ajoute un terme multiplicatif $TE_i$.

- Si $TE_i = 1$ alors la firme $i$ produit l'output maximum réalisable, alors que si $TE_i < 1$, il existe un écart entre l'output maximum et l'output effectivement observé.
:::

## SFA ~ RAPPELS (II) {.smaller}

On peut ré-écrire $TE_i$ sous la forme ${\displaystyle TE_{i}=\exp \left\{{-u_{i}}\right\}}$. Dès lors, nous obtenons l'équation suivante :

:::{.fragment .fade-in}

$${\displaystyle y_{i}=f(x_{i};\beta )\cdot \exp \left\{{-u_{i}}\right\}\cdot \exp \left\{{v_{i}}\right\}}$$ 

:::

La SFA (`Stochastic Frontier Analysis`) est une méthode paramétrique : elle requiert une forme fonctionnelle précise et les termes d'erreur $\epsilon_i$ ont une distribution particulière (composée) :

- $v_i$ est une erreur aléatoire $\Rightarrow$ variation inexpliquée par les variables indépendantes du modèle, avec $v_i \sim \mathcal{N}(0, \sigma^2_v)$.
- $u_i$ est un composant unilatéral qui peut être choisi parmi plusieurs distributions et $u_i \geq 0$.

:::{.fragment .fade-in}
> *La spécification de cette méthode permet d’estimer les scores de l’efficience technique de chaque firme (historiquement), ou produit, dans notre cas.*
:::

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::



:::{.notes}
*Corentin*

En fait ici en utilisant le logarithme on va passer d'une forme multiplicative à une forme additive.
:::

## SFA ~ RAPPELS (III) {.smaller}

:::: {.columns}

::: {.column width="60%"}
*<u>$^*$Exemple</u>* : 

![](imgs/stochastic_image.jpeg){width=95%}

$*$ Droits d'auteur : [Lutz Bornmann](https://www.researchgate.net/profile/Lutz-Bornmann)
:::

:::{.column width="40%"}

A partir de cette représentation on peut clairement distinguer les effets de $v_i$ (`noise`) et ceux de $u_i$ (`inefficiency`).

***

- $y_i^*=$ output maximum
- $\Leftrightarrow \ln y_i^* = \ln\left[f(x_i;\beta)\right] + v_i$
- $y_i =$ output observé
- $\Leftrightarrow \ln y_i = \ln y_i^* -u_i$
- $\Leftrightarrow \ln y_i = \ln\left[f(x_i;\beta)\right] + v_i -u_i$


:::{.fragment} 

$$\boxed{\ln y_i = \ln\left[f(x_i;\beta)\right] + \epsilon_i}$$
:::

:::

::::

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::

:::{.notes}
*Buk*


L'objectif de cette slide est d'expliquer graphiquement la SFA.

A partir de ce graph, on peut distinguer les termes d'erreur donc les effets de vu qui est le bruit, et ceux de ui qui est l'inefficacité.

- y1 = f(x) + v donne l'output max
- y2 = f(x) + v - u donne le niveau de production réelle

On peut donc voir que ui tire la production vers le bas alors que vi peut fixer le niiveau max possible de la production en dessous ou au-dessus de la frontière.


- On inclue aussi une transformation logarithmique permettant de manipuler plus facilement le terme d'erreur.

Une fois qu'on prend l'output max et qu'on enlève l'inefficacité, on obtient ln de yi qui est le niveau de production réelle.

On a aussi $\epsilon_i$ qui représente le terme d'erreur composé $v_i - u_i$.
:::

## Choix de distributions

```{r}
halfnorm_density <- function(x, mu, sigma) {
  ifelse(x >= mu, (2 / (sqrt(2 * pi) * sigma)) * exp(-(x - mu)^2 / (2 * sigma^2)), 0)
}

# Paramètres de la distribution half normal
mu_halfnorm <- 0
sigma_halfnorm <- 1 

ggplot(
    data.frame(x = c(0, 5)), aes(x = x)) +
    stat_function(
        fun = halfnorm_density,
        args = list(mu = mu_halfnorm, sigma = sigma_halfnorm),
        color = "darkgreen",
        linewidth = 1
    ) +
    stat_function(
        fun = dnorm,
        args = list(mean = 0, sd = 1),
        color = "orange",
        linetype = "dashed",
        linewidth = 1
    ) +
    theme(plot.title = element_markdown(face = "bold", size = 15)) +
    labs(
        title = "Distributions <span style='color:orange'>normale</span> et <span style='color:darkgreen'>semi-normale</span>",
        x = "",
        y = "Densité de probabilité") +
    scale_x_continuous(limits = c(-0, 5))
```

::: {.footer}
--- `Recherche`, Réalisation, Restitution ---
:::


:::{.notes}
*Corentin*

Je vais très rapidement vous expliquer aussi pourquoi on est obligé de passer à l'estimateur du Maximum de Vraisemblance et que les techniques des MCO ne fonctionnent plus ici : c'est tout simplement parce qu'on va combiner une disribution symétrique (en orange), celle de la loi normale avec une distribution qui ne l'est pas : celle de la semi-normale.
:::

## SFA Cost Frontier (I) {.smaller}

**Forme fonctionnelle :**

$$
\begin{split}
\ln(price_i) = \beta_0 + \beta_1 storage_i + \beta_2 brand_i + \beta_3 ram_i\\
+ \beta_4 induction_i + \beta_5 screen\_size_i + \beta_6 screen\_type_i\\
+ \beta_7 made\_in_i + \beta_8 upgrade\_storage_i + \beta_{9} das\_limbs_i \\
+ \beta_{10} network_i + \beta_{11} ppi_i + v_i + u_i
\end{split}
$$

<hr>

- Distribution choisie pour les $u_i \Rightarrow$ *semi-normale*.

- Distribution choisie *(par défaut)* pour les $v_i \Rightarrow$ *normale*.

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*

Dans ce modèle, on prend le point de vue du consommateur et dans l'ensemble des téléphones qui lui sont proposés qui disposent de plein de caractéristiques, on cherche à lui indiquer le prix minimum dans l'espace des caractéristiques.

Par rapport à la régression log-hédonique en fait on voit qu'il n'y a pas de grande différence à part l'erreur composée.
:::

## SFA Cost Frontier (II) {.smaller}

```{r}
scf <- sfa(
    log(price) ~ storage + brand + ram + induction + screen_size + screen_type 
    + made_in + upgrade_storage + das_limbs + network + ppi,
    data = df_phones,
    truncNorm = FALSE,
    ineffDecrease = FALSE
)

mean_eff <- efficiencies(scf) |> as_tibble() |> summarise(mean_eff = efficiency |> mean() |> round(3))
```


```{r}
summary(scf, extraPar = TRUE)$mleParam |>
    data.frame() |>
    rownames_to_column(var = "Variables") |>
    janitor::clean_names() |>
    mutate(
        variables = case_when(
            variables == "brandGOOGLE" ~ "*brand* `(GOOGLE)`",
            variables == "brandHONOR" ~ "*brand* `(HONOR)`",
            variables == "brandMOTOROLA" ~ "*brand* `(MOTOROLA)`",
            variables == "brandOPPO" ~ "*brand* `(OPPO)`",
            variables == "brandSAMSUNG" ~ "*brand* `(SAMSUNG)`",
            variables == "brandSONY" ~ "*brand* `(SONY)`",
            variables == "brandXIAOMI" ~ "*brand* `(XIAOMI)`",
            variables == "inductionTRUE" ~ "*induction* `(True)`",
            variables == "screen_typeBords incurvés" ~ "*screen_type* `(Bords Incurvés)`",
            variables == "screen_typePlat" ~ "*screen_type* `(Plat)`",
            variables == "screen_typePliable" ~ "*screen_type* `(Pliable)`",
            variables == "made_inJapon" ~ "*made_in* `(Japon)`",
            variables == "made_inThaïlande" ~ "*made_in* `(Thaïlande)`",
            variables == "made_inViêt Nam" ~ "*made_in* `(Viêt Nam)`",
            variables == "upgrade_storageTRUE" ~ "*upgrade_storage* `(True)`",
            variables == "network5G" ~ "*network* `(5G)`",
            .default = as.character(glue::glue("*{variables}*"))
        )
    ) |>
    mutate(signif = makestars(pr_z)) |>
    filter(variables %nin% c("*sigmaSqU*","*sigmaSqV*", "*sigma*", "*sigmaU*", "*sigmaV*", "*lambdaSq*", "*lambda*", "*varU*", "*sdU*")) |>
    gt() |>
    cols_hide(c(z_value, pr_z)) |>
    cols_label(
        variables = gt::md("**Variables**"),
        estimate = gt::md("**Coefficients**"),
        std_error = gt::md("**Ecart Type**"),
        signif = gt::md("**Significativité**")
    ) |>
    tab_header(
        title = md("Résultats de l'estimation pour le modèle **SFA**"),
        subtitle = md("*Variable dépendante* : `log(price)`")
    ) |>
    fmt_number(
        columns = c(estimate, std_error, pr_z),
        decimals = 3,
        drop_trailing_zeros = TRUE
    ) |>
    fmt_percent(
        columns = estimate,
        rows = variables %nin% c("*(Intercept)*","*sigmaSq*", "*gamma*", "*gammaVar*"),
        pattern = "+{x}"
    ) |>
    fmt_percent(
        columns = estimate,
        rows = estimate < 0,
    ) |>
    data_color(
        columns = estimate,
        rows = estimate < 0,
        method = "numeric",
        palette = c("red", "orange"),
        apply_to = "text"
    ) |>
    data_color(
        columns = estimate,
        rows = estimate > 0 & variables %nin% c("*(Intercept)*","*sigmaSq*", "*gamma*", "*gammaVar*"),
        method = "numeric",
        palette = c("lightgreen", "darkgreen"),
        apply_to = "text"
    ) |>
    fmt_markdown(c(variables,signif)) |>
    sub_missing() |>
    tab_footnote(
        md(glue::glue("**Efficacité moyenne** : {mean_eff}"))
    ) |>
    tab_footnote(
        md(glue::glue("**Efficacité moyenne** : {mean_eff}"))
    ) |>
    tab_options(
        table.background.color = "#222222",
        table.font.color = "white",
        table.font.size = 8,
    ) |>
    opt_interactive(page_size_default = 5, use_highlight = TRUE)
```

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

:::{.notes}
*Corentin*

On a les mêmes niveaux de significativité, les signes des coefficients sont les mêmes et les valeurs restent à peu près les mêmes avec un effet encore plus important des marques.

A savoir aussi, **gammaVar** ça correspond à la part de variance totale qui est due à l'inefficacité. Donc ici 37,5% de la variance totale est due à l'innefficacité.

:::

## SFA Cost Frontier (III) {.smaller}

**Efficacité moyenne par marque**

En utilisant l’espérance conditionnelle $E(\exp(-u_i)|\epsilon_i)$, on peut estimer le score d’efficacité pour chaque observation. 

- Commande `efficiencies()` du package `{frontier}`.

```{r}
eff_df <- efficiencies(scf) |> as_tibble()

bind_cols(df_phones, eff_df) |> 
    group_by(brand) |>
    summarise(
        min = min(efficiency),
        median = median(efficiency),
        mean = mean(efficiency),
        max = max(efficiency)
    ) |>
    mutate(brand = glue::glue("`{brand}`")) |> 
    gt() |> 
    fmt_number() |>
    fmt_markdown(brand) |> 
    cols_label(
        brand = md("**Marque**"),
        min = md("**Min**"),
        median = md("**Médiane**"),
        mean = md("**Moyenne**"),
        max = md("**Max**")
    ) |> 
    tab_options(
        table.background.color = "#222222",
        table.font.color = "white",
        table.font.size = 17,
    )
```

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

::: {.notes}
*Buk*

Une fois qu'on a réalisé l'estimation du modèle SFA, on récupère un résidu. Mais individuellement, on ne sait pas quelle est la part de $u_i$ dans $\epsilon_i$. 

Grâce au calcul de l'espérance conditionnelle individuelle, on peut donc déterminer quels téléphones sont les plus/moins efficaces de notre sélection. On peut aussi faire des regroupements par marque, ce qu'on a décidé de vous montrer sur ce tableau.

A noter que même si le package le fait pour nous en une commande c'est un calcul qui est complexe et qui fait plusieurs pages de formules qu'on a inclut dans le rapport mais qu'on ne va pas préciser ici.

:::

## SFA Cost Frontier (IV) {.smaller}

> Quel modèle choisir ?

```{r}
loglik_loghedonic <- logLik(loghedonic)[1]
loglik_sfa <- logLik(scf)[1]
```

- Log-Vraisemblance pour `OLS log-level` : ${\displaystyle {\ln\mathcal {L_1}}(\theta ;y, X)}=$ **`r round(loglik_loghedonic,2)`**

- Log-Vraisemblance pour `SFA Cost Frontier` : ${\displaystyle {\ln\mathcal {L_2}}(\theta ;y, X)}=$ **`r round(loglik_sfa,2)`**

:::{.fragment}
Avec $y$ le vecteur de $\ln(price)$ et $X$ la matrice de variables indépendantes.
:::

:::{.fragment}

**Test de rapport de vraisemblance**

$$
\begin{cases}
H_0: OLS \text{ log-level}\\
H_1: SFA \text{ cost frontier}
\end{cases}
$$
:::

- Statistique de test $\lambda_{RV} = 2 \cdot \left(\ln \mathcal{L_1}- \ln \mathcal{L_2}\right)$

```{r}
lrtest <- lrtest(scf)
pvalue_lrtest <- round(lrtest$`Pr(>Chisq)`[2],2)

#AIC(scf) < AIC(loghedonic)
```

:::{.fragment}
$\Rightarrow$ On rejette l'hypothèse nulle $H_0$ car la $p-value$ issue du test $=$ **`r pvalue_lrtest`** $< 0.05$.
:::

::: {.footer}
--- Recherche, `Réalisation`, Restitution ---
:::

::: {.notes}
*Corentin*

On peut maintenant chercher à savoir si il vaut mieux utiliser le modèle SFA Cost Frontier ou alors le modèle log-hedonic MCO.

En fait ça n'est pas très étonnant, ça rappelle le fait qu'on a trouvé des coefficients significatifs au niveau des paramètres permettant d'estimer l'inefficacité dans les résultats de l'estimation SFA Cost Frontier.

:::

## Conclusion

Axe d'amélioration $\Rightarrow$ diviser la distribution en 2 catégories et faire 2 modèles.

::: {.callout-tip}

## Atouts du projet

- Englobe une grande partie des matières étudiées en master

- Axe de recherche

- Axe appliqué avec la création d'une application fonctionnelle

:::

::: {.notes}
*Corentin*

En effet, on a utilisé les cours suivants :

- Analyse de données
- Ingénierie logicielle et scraping avec Python
- Econométrie avec R
- Cours d'économie avec pricing, microéconomie et analyse de la concurrence

*Aybuké*

D'un autre côté, en s'appuyant sur ce qui avait déjà été fait dans la littérature, on a pu appliquer ces connaissances dans un domaine assez peu exploré jusqu'à maintenant.

Enfin, évidemment, l'atout principal de ce projet c'est la création et le déploiement de notre application, qui, on l'espère, vous aidera dans le choix de votre futur téléphone !

**FIN**

***

@arrondo2018

@lancaster1966

@farrell1957

@harrison1978

@reinhard2000

@rosko2008

@mohamad2008

@bello2010

@ahmad2019

@boistel2008
:::

::: {.footer}
--- Recherche, Réalisation, `Restitution` ---
:::

## Références