Giter Site home page Giter Site logo

after_some_latex's People

Contributors

davideperon avatar lobisquit avatar matcip avatar mrektor avatar pittix avatar prosperolo avatar xtina94 avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar

after_some_latex's Issues

Project gitflow

Given this project is a group one, we must agree on the way to actually use git (this is called sometimes gitflow).

My proposal is to keep master branch as clean as possible, committing there only changes that are approved by the most of us.
To allow this, I would suggest the use of branches as pull request: I will explain in detail below.
(if you have no clue what I'm talking about, see here or ask below ๐Ÿ˜‰)

  1. When you want to push upstream some work (either new sections or modifications about existing pieces), you should commit them to a new branch, with a significant name (ex. modify_main_file). This allows separation from old and reviewed work with new one.
    git checkout -b new_argument

    # ... modifications to project files ...
    git add .
    git commit -m "Added fancy wordart"

    git add .
    git commit -m "Added serious stuff"
    # iterate until your contribution (in this case new argument) is concluded

    git push --set-upstream origin new_argument
  1. After having pushed them online, next step is to propose them for inclusion in master branch: this is done opening a pull request, see #1 for reference. This allows the others to review the new proposal work, adding comments and / or modifications (in the form of commits).
    See here GitHub procedure for creating one.

  2. When everyone is happy with the work done, it is pulled in master branch, through Merge pull request button. I recommend to delete branches whose pull request has been accepted, to keep repository clean.

For any suggestion or proposal of modification, don't hesitate to reply below.

Project guidelines

Here I summarize some indications on how to structure project and latex files. Write below for modification proposals and /or clarifications.

Project directory tree

It should be like this:

  • network_modeling
    • img/ (for images)
    • network_modeling.tex (main file, in which put as inputs files below)
    • introduction.tex
    • chapter_1.tex
    • chapter_2.tex
    • ...

Latex style

  • I think it would improve readability a lot to indent latex code inside all tex files, see 97f4e90 for reference.
    I suggest indentation using tabulations, starting from \subsection{...}, see as before my commit.
    (I know that this argument can trigger wars among project members, so suggestions are welcome)

Tips

To be homogeneous and write less

  • \prob is the sostitution for \mathbb{P}
  • \exp is the sostitution for \mathbb{E}
  • \stackrel{}{} is useful to put text over symbols
  • to align multirow equations, use the cases environment (guide here)

Network modeling program (all classes)

  • Probability recap: see #4

  • Markov chains see #1

    • markov property
    • homogeneus MC
    • Probability matrix (1 and n-step)
  • Poisson's processes

    • definition -> law of rare events (no demonstration here, see KT p. 23) NOT MANDATORY
    • exponential inter-arrival time (<- cit recap)
  • Particular poisson processes

    • M/G/1 as MC: tn as departure times
    • G/M/1 as MC: tn as arrival times
  • First step analysis (<- Markov property) 582d24e

  • Random walks (as particular MC) NOT MANDATORY 04eaa22

  • Synchronization model 762a7d2

  • First passage time theta_ij, f_ij(n) definitions 582d24e

  • Asymptotic behaviour, see #1

    • regular MC

    • limiting distribution: proof of existence and uniqueness for regular finite MC

    • accessibility and communication between states: classes of states

    • period d(j) is a class property

    • sufficient and necessary condition for recurrent states (sum_n p_ii^(n) = + inf)

    • recurrence as a class property

    • basic limit theorem for MCs -> proof of existence and uniqueness of limiting distribution for aperiodic, irreducible, recurrent classes

    • Lemma 4.1: yet another sufficient and necessary condition for recurrent states


      see #6

    • guess on G/M/1 limiting distribution (c beta^k)

    • periodic MC definition -> limiting distribution of falling into a recurrent class from a transient state

    • Th. 3.1 (KT page 91)

    • Th. finite MC has at least one positive recurrent state and (Th.) no null recurrent states

    • Lemma 4.13 (Ross, 2nd edition, pages 78-82), irreducible MC has f_i0 = 1 for i!=0

    • Th. 4.14 (Ross, 2nd edition, pages 78-82), transient MC has non-zero bounded solution for Zj system

    • Th 4.2 (KT page 95): necessary condition on MC irreducible and aperiodic

      • recap table of all conditions above
    • M/G/1 is transient/recurrent conditions for rho > 1 1806861

  • Poisson process reloaded

    • Lemma: sum of indipendent Poisson is Poisson
    • Law of rare events (demonstration) NOT MANDATORY
    • Poisson arrivals in [0, t] | number of arrivals in [0, t] are uniformly distributed in [0, t]
    • Th. Poisson arrivals in [0, u] | number of arrival in [0, t] are binomial distributed ~ bin(n, u/t) ~~> nice diagram intensity-time
    • M/G/inf
  • BG 275: slotted multi-access

    • assumptions
    • drift analysis
    • aloha & slotted aloha: correct analysis for m finite and m -> inf
    • Pake's lemma: sufficient condition on drift for stable (positive recurrent) MCs
    • Kaplan's lemma: sufficient condition on drift for not stable (not positive recurrent) MCs
    • enhanced aloha: CSMA & CSMA/CD
  • Renewal processes: see pull #9

    • Introduction. c5eae12
    • Renewal equation
    • Wald equation
    • Elementary renewal theorem
    • Key renewal theorem
    • Limiting distribution of the excess life
    • Delayed renewal processes
    • Theorem 3.6
    • Semi-Markov process
  • Go-Back-N

  • sensor networks NOT MANDATORY 777fffd

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.