---
title: Valentin - Page 1
---
<style>
:root{--main-gray:#222;--secondary-gray:#323232;--main-blue:#54acee;--comments-color:#ff9fe5;--comments-author-color:#888;--h1-border-color:#666}.ui-content,body,html{background-color:var(--main-gray);color:#fff}.markdown-body .highlight pre,.markdown-body pre{background-color:var(--secondary-gray);color:#fff}.markdown-body h1{text-align:center;border-color:var(--h1-border-color);border-width:.01em;background-color:var(--secondary-gray);color:#fff;border-radius:5px 5px 5px 5px;box-shadow: 0px 2px 4px #121212;text-shadow: 0px 1px 3px black}.markdown-body h2{border-bottom-color:transparent}.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{background-color:transparent;color:#fff}.markdown-body h1 .octicon-link,.markdown-body h2 .octicon-link,.markdown-body h3 .octicon-link,.markdown-body h4 .octicon-link,.markdown-body h5 .octicon-link,.markdown-body h6 .octicon-link{color:#fff}.markdown-body img{background-color:transparent}.ui-toc-dropdown .nav>.active:focus>a,.ui-toc-dropdown .nav>.active:hover>a,.ui-toc-dropdown .nav>.active>a{color:#fff;border-left:3px solid var(--main-blue)}.back-to-top:focus,.back-to-top:hover,.expand-toggle:focus,.expand-toggle:hover,.go-to-bottom:focus,.go-to-bottom:hover{color:#fff}.ui-toc-dropdown{background-color:transparent}.ui-toc-label.btn{color:#fff}.ui-toc-dropdown .nav>li>a:focus,.ui-toc-dropdown .nav>li>a:hover{color:#fff;border-left:3px solid var(--main-blue)}.markdown-body blockquote{color:var(--comments-color)}.markdown-body code,.markdown-body tt{background-color:var(--secondary-gray)}.open-files-container li.selected a,a{color:var(--main-blue)}.alert-info{background-color:var(--secondary-gray);border-color:transparent}blockquote .small,blockquote footer,blockquote small{color:var(--comments-author-color)}.markdown-body hr{background-color:var(--secondary-gray);border-radius:5px 5px 5px 5px}.hljs-keyword,.hljs-selector-tag,.hljs-type{color:#f92472}.hljs-number,.hljs-literal,.hljs-symbol,.hljs-bullet,.hljs-attribute{color:#8c80ff}.hljs-comment,.hljs-meta{color:#74705d}.hljs-string,.hljs-variable,.hljs-template-variable,.hljs-strong,.hljs-emphasis,.hljs-quote{color:#e7db6a}.hljs-built_in,.hljs-builtin-name{color:#67d8ef}table{color: black;}
.page-container
{
display: flex;
flex-direction: row;
justify-content: center;
align-items: center;
}
.page-element
{
color: var(--main-blue);
text-align: center;
background-color:var(--secondary-gray);
border-radius:5px 5px 5px 5px;
padding: 0px 5px 5px 5px;
margin-left: 5px;
box-shadow: 0px 1.5px 1px black;
user-select: none;
}
.page-title
{
text-align: center;
color: #fff;
font-size: 2em;
text-shadow: 0px 1px 5px black;
}
</style>
:::info
**<p class="page-title">Valentin's Documentation<br>Page 1</p>**
:::
# Pages.
<html>
<div class="page-container">
<div class="page-element">↠</div>
<a href="https://hackmd.io/LeL-co7mQQuUp0m89WB75g" target="_self" class="page-element">1</a>
<a href="https://hackmd.io/CYqY5kUUQBa44UZraXbZSA" target="_self" class="page-element">2</a>
<div class="page-element">↞</div>
</div>
</html>
# Walkthroughs.
## Repository walkthrough.
- backEnd : The Django server of Citadle.
- doxygenDoc : Source code and tools for the documentation.
- ebop : The EBoP project files in Citadle for the Matlab interface (not maintained nor documented).
- ebopData : Rules, Keyboards, Exercices, Solutions, Symbols.
- ebopNew : The EBoP project files in Citadle for the Python-TypeScript interface.
- libCitadle : The compiled libraries of OCaml files of Citadle.
- libOntology : A library that can interact with Citadle using a Java backend. Probably used before in Memsalab.
- libProof : Library of .proof files and the corresponding parsed files in OCaml.
- maxima : Ocaml utility that calls Maxima in Ocaml.
- memsalab : Another project, was here before EBoP. Multi-scale model.
- parser : Citadle to OCaml parser.
- parserWIMS : Syntax analyzer that parse EOF files and translate in PLATON.
- symbtrans : OCaml library for the kernel of Citadle (the rewriting library exposing Expression and Strategy).
- tests : Contains all the files needed to test the project.
- tools : Various tools for development.
- userInterfaces : The folder where all the user interfaces are (developer, teacher and student).
## Dev files walkthrough.
- config_ebop_dvpt.json : fichier de configuration.
- node.proof : fichier des noeuds (représentation des mathématiques).
- strategy.proof : quelques stratégies générales (pas le plus important pour comprendre la structure).
- head.proof : des conversions (n2S et a2p) + quelques fonctions et stratégies (pas très utile pour commencer).
- function.proof : des fonctions de bas niveau + les fonctions verifyForm utilisées dans case.proof.
- module.proof : les fonctions les plus récentes principalement utilisées dans 'test.proof' et dans 'case.proof'.
- case.proof : les stratégies élémentaires de vérification (notamment celles d'Emilia) basées sur les fonctions verifyForm
- metarule.proof : les stratégies de vérification qui assemblent les stratégies élémentaires de case.proof + des tables de hachage des stratégies de vérification, des fonctions qui leurs sont associées, des feedbacks, des stratégies liées (à une stratégie mère).
- converter.proof : conversion json <-> noeuds ebop.
- dvpt.proof : la fonction phi (qui s'appelle 'verification').
- test.proof : le programme principal qui construit les tests (génération d'expressions 'i' = fonctions 'g', génération de la transformation de 'i' en 'o' = fonctions 'r', lancement des exécutions c'est à dire appel de la fonction 'verification' sur les expressions (i,o) générées).
- ebop.proof (désactivé pour l'instant) : le programme principal de ebop.
## Overleaf Doc walkthrough.
- (Chapter 2) Syntax Forms and their Use : les syntaxes utilisées (important quand il s'agira de rentrer dans les détails).
- (Chapter 3) Normalizations : les normalisations construites dans le module Normalize du fichier 'module.proof' (important après les syntaxes).
- (Chapter 4) Verification Strategies: rédactions inégales qui décrivent la façon dont les stratégies de 'metarule.proof' sont conçues (mais demande du nettoyage).
- (Chapter 5) Test Generation: principes (pas à jour) du fichier 'test.proof'.
- (Chapter 6) Introducing a New Strategy: (pas à jour) comment ajouter une stratégie dans metarule.proof (il y a des listes à mettre à jour).
# Math Reminders.
## Domain, Codomain, Range.
### Domain.
The Domain of a function is the set of all possible inputs of this function.
### Codomain.
The Codomain of a function is the set of all possible outputs of this function.
### Range.
The Range of a function is a subset of its Codomain, which is the actual set of outputs of this function (Range $\subseteq$ Codomain).
---
## Associative and Commutative properties.
### Associative property.
In a sequence of calculations using an associative operator, changing the grouping of the binary operations won't change the result.
Example: 4+5+10 = (4+10)+5.
### Commutative property.
In a sequence of calculations using a commutative operator, changing the order of values used in the binary operation won't change the result.
Example: 4+5 = 5+4.
Example: 4/5 ≠ 5/4.
---
## Power and Exponential.
The power function is a function of the form `f(x) = x^a`, where `a` is a constant exponent and `x` can take on any real value.
The exponential function, on the other hand, is a function of the form `f(x) = a^x`, where `a` is a constant base and `x` can take on any real value. a equal "e" in this case which is Euler's number.
---
## Prime numbers.
A prime number is a positive integer greater than 1 that is divisible only by 1 and itself. In other words, a prime number has exactly two positive divisors.
For example, 2 is a prime number because it is only divisible by 1 and 2. Similarly, 3 is a prime number because it is only divisible by 1 and 3. However, 4 is not a prime number because it is divisible by 1, 2, and 4. Likewise, 6 is not a prime number because it is divisible by 1, 2, 3, and 6.
First 15 PN: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47.
Any positive integer can be expressed as a product of prime numbers.
---
## Remarkable identities.
- $\frac{a}{b} = a * b^{-1}$
- $(a * b)^n = a^n * b^n$
- $\sqrt[a]{n} = a^{(1/n)}$
- $y^a * y^b = y^{(a+b)}$
- $\sqrt{\frac{a}{b}} = \frac{a}{b}^{\frac{1}{2}} = (a * b^{-1})^{\frac{1}{2}} = a^{\frac{1}{2}} * b^{(-1 * \frac{1}{2})} = a^{\frac{1}{2}} * b^{-\frac{1}{2}}$
- $y{^\frac{m}{n}} + y^{\frac{m}{n}} = 2 * (y^{\frac{m}{n}})$
- $y^{\frac{m}{n}} * x^{\frac{m}{n}} = (y * x)^{\frac{m}{n}}$
- $y^{\frac{m}{n}} * y^{\frac{m}{n}} = y^{2 * \frac{m}{n}}$
# Project Overview.
The idea of the verification process resides in the ability to check the validity of the transformations operated on two subsequant lines of resolution in a Math problem (only Math for now but aims to be generic to any problem that can be formalized).
(i,o) is the pair of input and output of a verification process.
Example:
(1) 1+2+3
(2) 3+3
1+2 was rewrote into a single 3, using a rule allowing a+b to become a. This is reduction, it doesn't check if a+b = a.
Here "i" is 1+2 and "o" is 3, which gives a pair [(1+2),3].
This part has changes since PHI arrived, but the approach is that the reduction phase will transform the `i` using all available strategie, which gives a list of all possible transformation, and if our `o` matches with any of them then we know it was a correct transformation.
JSON input string -> Normalization phase -> ebop.proof (BAC) -> LAC -> ... see [I/O Pipeline overview](https://michellenczner.gitlab.io/citadle/_e_bo_p_core_using.html) (Must be updated and create a section just for this).
The idea of an exercice is to have an exhaustive list of mistakes that a student can do for a given problem and search for them through strategies. The goal when designing an exercice is to be as concise as possible to note have to check for to many rules.
## Verification Process.
- The verification process first starts with the reduction process.
- The idea is to find (i',o') pairs matching with sub-terms of (i,o) for which the Verification Strategies are succeeding (matching through the process of pattern matching with the rewrite variables).
- The reduction process starts by reducing the operation that will require a LAC format.
- The verification strategies are inserted inside the reduction alogirhtm. They are based and rewrite rules that usually operate on the BAC syntax.
## AST Syntax.
Test: Citadle -> EBoP -> PrettyPrint
Release: JSON -> EBoP -> JSON
BAC (Binary Associative Commutative) -> 1+2+3 is add(1,add(2,3)).
LAC (List Associative Commutative) -> 1+2+3 is addList[1,2,3].
BAC is used during the conversion JSON <-> EBoP.
LAC is used during the reduction phase.
Before the BAC to LAC conversion happens, frac/div are changed to mult and subtraction to addition.
## Symbtrans.
- SymbTrans is an OCaml library exposing tre data structure and abstract/generic rewriting functions applicable on them.
- There are two types: Expression and Strategy. You can see the Expression that as the data type and the Strategy type as the logical type.
- The idea is to rewrite expressions based on strategies, or in other words update the data using logical functions (strats are the algorithms).
## Citadle.
- The Citadle language was first wrote for MEMSALab and then used for EBoP. The language is parsed to OCaml, using a custom parser that you can find in the `parser` folder.
### Strategy.
- A strategy is a type of transformations that operate on input expressions of type Expression.
- A strategy includes rewriting rules (type Rule) and the specification of how they are applied.
- A simple strategy generally consists in a navigation through the input expression followed by the application of rewriting rules.
- The application of a Strategy on an input expression either succeeds and in this case it returns the transformed expression, or it fails and the input expression is returned as the output expression.
- When a complete strategy fails, the program stops with the same message as for a failing Rule.
- During the application of a composite strategy, the input term is transformed in successive states, therefore it is refered to as the current term.
- The identity Rule allows to match the current term with a Pattern. The strategy will persue only if it matches, or if this match was in a condition like a left choice. It fails otherwise.
### Rule.
- A rewriting rule (Rule) consists of a sequence of Pattern Matching followed by a replacement of the matched term.
- Pattern matching consists of testing if a pattern and an expression are equal modulo replacement of the rewriting variables in the pattern by some subexpressions of the expression. When the equality holds, the pattern is said to match with the expression or vice versa.
- A rewriting rule transforms a pattern into another one, possibly under a condition.
# OCaml.
## Documentation Links.
### OCaml best libraries list.
- [Link to the community maintained list of the best libraries for the OCaml language.](https://github.com/ocaml-community/awesome-ocaml)
### Guidelines.
- [Link to the official OCaml Programming Guidelines.](https://ocaml.org/docs/guidelines)
- [Link to a shorter OCaml Programming Guideline used in CS3110 at Cornell University.](https://www.cs.cornell.edu/courses/cs3110/2011sp/Handouts/style.htm)
### Multipurpose documentation.
- [Link to OCamlverse](https://ocamlverse.net/)
---
## Libraries Survey.
### Standard Library.
When we refer to OCaml's Standard Library, we actually mean the association of the Core Library, the module Stdlib and a complementary list of standard modules.
#### OCaml Core Library.
- Automatically opened/linked **Library** when interpreting/compiling source code.
- Provides the built-in types and predefined exceptions.
#### OCaml Stdlib Module.
- Automatically opened/linked **Module** when interpreting/compiling source code.
- Provides basic operations over the built-in types.
- It loads and opens the list of complementary Standard Library Modules so that you can open them manually.
#### OCaml Standard Library Modules.
- This list of modules is loaded by the module Stdlib but none of them are opened by default.
- Contains modules like Array, Complex, Bytes, Filename, etc... [full list here.](https://v2.ocaml.org/api/index_modules.html)
### External Libraries.
#### Multi-purpose Libraries (Batteries vs. Core+Base).
The purpose of these libraries is to enhance the Standard Library. Their project started in a time where the Standard Library was not as complete as it is today. They are nowadays the most complete multi-purpose libraries available. Choosing one of the two today is only required if the Standard Library doesn't already provide what you need, which is not true for at least 50% of the features of these external multi-purpose libraries.
- [Batteries API link.](https://ocaml-batteries-team.github.io/batteries-included/hdoc2/)
- [Core API link.](https://ocaml.org/p/core/latest/doc/Core/index.html)
- [Base API link.](https://ocaml.org/p/base/latest/doc/Base/index.html)
##### Batteries:
- Pros:
* Provides a comprehensive collection of additional modules that extend the standard OCaml library.
* Covers a wide range of functionalities, including data structures, IO operations, concurrency, parsing, serialization, and more.
* Offers a large ecosystem of additional libraries built on top of Batteries.
* Designed to be compatible with various OCaml versions, making it suitable for different projects and use cases.
* Well-documented with extensive examples and tutorials.
- Cons:
* May introduce additional dependencies and increase the size of the binary.
* Some modules in Batteries may overlap with the standard OCaml library or other popular OCaml libraries, which may lead to confusion or duplication in code.
##### Core+Base:
- Pros:
* Provides a powerful and flexible foundation for building OCaml applications with Jane Street's Core library and Base library.
* Core library offers advanced functionalities, such as extended data structures, error handling, and logging, designed for building robust and scalable applications.
* Base library provides a modern and more efficient replacement for the standard OCaml library, offering improved performance and better APIs.
* Offers strong typing and rich module signatures, promoting safe and maintainable code.
* Well-documented with extensive examples and tutorials.
- Cons:
* May have a steeper learning curve due to the advanced and sophisticated nature of Core and Base libraries.
* Core and Base libraries are tightly integrated and designed to be used together, which may require additional effort to fully understand and utilize.
##### Batteries vs. Core+Base (in short):
- Batteries Pros:
* Provides a comprehensive collection of additional modules that extend the standard OCaml library, covering a wide range of functionalities.
* Compatible with various OCaml versions, making it suitable for different projects and use cases.
- Batteries Cons:
* May introduce additional dependencies and increase the size of the binary.
* Some modules in Batteries may overlap with the standard OCaml library or other popular OCaml libraries.
- Core+Base Pros:
* Provides a powerful and flexible foundation for building OCaml applications with advanced functionalities.
* Offers improved performance and better APIs compared to the standard OCaml library.
* Well-documented with extensive examples and tutorials.
- Core+Base Cons:
* May have a steeper learning curve due to the advanced and sophisticated nature of Core and Base libraries.
* Core and Base libraries are tightly integrated and designed to be used together, which may require additional effort to fully understand and utilize.
##### Summary.
- In summary, Batteries and Core+Base are two OCaml libraries for extended standard library functionalities. Batteries provides a comprehensive collection of additional modules covering a wide range of functionalities, while Core+Base offers a powerful and flexible foundation for building OCaml applications with advanced functionalities. Both libraries are well-documented but may have some trade-offs in terms of dependencies, size, and learning curve.
- Core and Base are professional and consistent libraries maintained by a company.
- Batteries is a community maintained library, which allows feature request while Jane Street's libraries don't. It aims for backward compatibility with the Stdlib but as a consequence is not as consistent as JS's libs.
- Core and Base are industry proved libraries while Batteries is more of an amateur endeavor, even though of quite the quality.
- Jane Street's Base and Core basically require full buy-in to their way of doing things. It's extremely opinionated in how it behaves and is structured, so anything you use from it will feel unusual compared to OCaml Stdlib, which is where Batteries is better.
- Jane Street has a lot of experience in libraries and tools design, they also created and are maintaining the famous *Dune* build system. Base+Core and Dune are the professional standard in the realm of OCaml.
**-> The key question when choosing between Batteries or Core+Base, in my opinion, is about choosing between consistency in a fully featured professional and extensible library or Stdlib retro-compatibility in a scattered community based library. I would go with Jane Street's approach, also based on the points generated by ChatGPT in the file *"Deep dive into Batteries vs Core and Base"*.**
#### Unit Testing Libraries (Alcotest vs. OUnit).
- [Alcotest API link.](https://mirage.github.io/alcotest/alcotest/index.html) (-> A good example of what odoc can do!)
- [OUnit API link.](https://ocaml.org/p/ounit2/2.2.3/doc/index.html)
##### Alcotest:
- Pros:
* Provides a simple and expressive API for writing unit tests in OCaml.
* Offers a rich set of built-in assertion functions for common test scenarios, such as equality, comparison, and floating-point numbers.
* Supports asynchronous testing with the ability to write tests that perform IO operations, making it suitable for testing concurrent or asynchronous code.
* Supports parameterized tests, allowing multiple inputs and expected outputs to be tested with a single test case.
* Supports test discovery and test filtering, making it easy to organize and run tests selectively.
* Integrates well with other OCaml build systems and tools.
* Well-documented with examples and tutorials.
- Cons:
* May lack some advanced features or integrations that are available in other testing frameworks.
* May require additional effort to set up and configure compared to some other testing frameworks.
##### OUnit:
- Pros:
* Provides a simple and lightweight framework for writing unit tests in OCaml.
* Offers a wide range of assertion functions for common test scenarios, such as equality, comparison, and regular expressions.
* Supports test discovery and test filtering, making it easy to organize and run tests selectively.
* Integrates well with other OCaml build systems and tools.
* Well-documented with examples and tutorials.
- Cons:
* May lack some advanced features or integrations that are available in other testing frameworks.
* May have a steeper learning curve for complex test scenarios or asynchronous testing compared to some other testing frameworks.
##### Alcotest vs. OUnit (in short):
- Alcotest Pros:
* Provides a rich set of built-in assertion functions, including support for floating-point numbers and asynchronous testing.
* Supports parameterized tests, allowing multiple inputs and expected outputs to be tested with a single test case.
* Integrates well with other OCaml build systems and tools.
- Alcotest Cons:
* May lack some advanced features or integrations that are available in other testing frameworks.
* May require additional effort to set up and configure compared to some other testing frameworks.
- OUnit Pros:
* Provides a simple and lightweight framework for writing unit tests in OCaml.
* Offers a wide range of assertion functions for common test scenarios.
* Supports test discovery and test filtering.
- OUnit Cons:
* May lack some advanced features or integrations that are available in other testing frameworks.
* May have a steeper learning curve for complex test scenarios or asynchronous testing compared to some other testing frameworks.
##### Summary.
- In summary, Alcotest and OUnit are both popular OCaml libraries for unit testing, offering simple and expressive APIs for writing tests. Alcotest provides a rich set of built-in assertion functions, supports asynchronous testing and parameterized tests, while OUnit is lightweight and straightforward. Both libraries integrate well with other OCaml build systems and tools, but may have some trade-offs in terms of features, learning curve, and configuration.
- OUnit seems to be more used and standard nowadays (version 2 of OUnit obviously).
**-> Both libraries are equivalent by I would give the advantage to OUnit because we see it being used more often.**
> [name=Michel Lenczner]J'ai remarqué que beaucoup de gens utilisent les 2 (ounit2 et alcotest). Je n'ai pas encore utilisé alcotest, il serait bien de savoir la complémentarité entre les deux.
#### Arbitrary-precision Arithmetic Libraries (Zarith vs. Num).
- [Zarith API link.](https://antoinemine.github.io/Zarith/doc/latest/index.html)
- [Num API link.](https://v2.ocaml.org/releases/4.05/htmlman/libref/Num.html)
##### Zarith:
- Pros:
* Provides arbitrary-precision arithmetic for integers and rational numbers.
* Offers efficient and high-performance implementations of arithmetic operations, such as addition, subtraction, multiplication, division, and modulo.
* Supports various integer representations, including big integers, signed integers, and unsigned integers.
* Includes advanced features like prime number generation, GCD computation, and modular arithmetic.
* Provides comprehensive documentation and examples.
- Cons:
* Primarily focuses on integer and rational number arithmetic, and may not be suitable for floating-point arithmetic or other advanced numerical computations.
* Requires understanding of arbitrary-precision arithmetic concepts and usage of Zarith's API.
##### Num:
- Pros:
* Provides support for arbitrary-precision arithmetic for both integers and floating-point numbers.
* Offers a wide range of numerical operations, including arithmetic, comparisons, rounding, and conversions.
* Supports various number representations, including big integers, fixed-point numbers, and floating-point numbers.
* Provides a simple and intuitive API for performing numerical computations.
* Offers good performance and extensive documentation.
- Cons:
* May not have some of the advanced features or optimizations available in other specialized numerical libraries.
* Requires understanding of arbitrary-precision arithmetic concepts and usage of Num's API.
##### Zarith vs. Num (in short):
- Zarith Pros:
* Focuses on efficient arbitrary-precision arithmetic for integers and rational numbers.
* Provides advanced features like prime number generation, GCD computation, and modular arithmetic.
- Zarith Cons:
* Primarily focuses on integer and rational number arithmetic, and may not be suitable for floating-point arithmetic or other advanced numerical computations.
* Requires understanding of arbitrary-precision arithmetic concepts and usage of Zarith's API.
- Num Pros:
* Provides support for arbitrary-precision arithmetic for both integers and floating-point numbers.
* Offers a wide range of numerical operations with a simple and intuitive API.
- Num Cons:
* May not have some of the advanced features or optimizations available in other specialized numerical libraries.
* Requires understanding of arbitrary-precision arithmetic concepts and usage of Num's API.
##### Summary.
- In summary, Zarith and Num are two OCaml libraries for arbitrary-precision arithmetic. Zarith focuses on efficient arithmetic for integers and rational numbers with advanced features, while Num provides support for both integers and floating-point numbers with a wide range of numerical operations and a simple API. Both libraries require understanding of arbitrary-precision arithmetic concepts and usage of their respective APIs.
- From Num official doc: *"This is a legacy library. It used to be part of the core OCaml distribution but is now distributed separately. New applications that need arbitrary-precision arithmetic should use the Zarith library instead of the Num library, and older applications that already use Num are encouraged to switch to Zarith. Zarith delivers much better performance than Num and has a nicer API."*
- It seems that Zarith API is closer to the Standard Library than Num is, which is why they mention a *"Nicer API"*. They also programmed the conventional operators of comparison (like = > < or <>) to work directly with their type, without the need to use dedicated functions. Also the big_int API of Num is kept in the Big_int module of Zarith, using their Z module under the hood, which is more powerful, and allow retro-compatibility.
**-> Zarith is the way to go in my opinion.**
#### About QCheck, QTest and qtest.
- **QCheck**: It is inspired from Haskell's QuickCheck property-based testing. It is a testing method that is relying on the creation of a generic test case based on constraints for a function and then, using the library, allows to procedurally generate edge cases within the given boundaries for that generic test case, to ensure a wider code coverage than a simple hand made unit test would reach. It is not a commonly used unit testing method for an application, as we usually prefer hand made procedural generation *inside* unit tests for dedicated usage (basically what we are right now doing in EBoP). This package is currently required in our opam installation (install_script_dev_once_V20).
- **QTest**: QTest is a lightweight testing framework that is part of the Jane Street Core library. QTest provides a simple and expressive syntax for writing test cases directly in OCaml code, and it has minimal dependencies. It focuses on providing concise and readable test cases, and it is often used in conjunction with other Jane Street libraries for building large-scale OCaml applications. QTest has a clear and simple syntax for defining tests, and it provides built-in support for test discovery, test categorization, and test reporting.
- **qtest**: A community effort to bring Jane Street's proprietary lightweight testing framework to Batteries. It is now an approximate of JS's QTest and is by default shipped with Batteries.
**-> They all provide a limited set of features for simple and quick testing but none of them are well suited for complete application unit testing.**
> [name=Michel Lenczner]Après avoir testé QCheck, je ne suis pas certain que l'on gagne beaucoup à l'utiliser. En tout cas, je trouve que la doc pour la partie la plus délicate (et utile) n'est pas assez développée. Personnellement, je n'ai pas pu utiliser les parties les plus sophistiquées. Ce module n'est utilisé dans quasi-aucun module de OPAM.
---
## OPAM.
### Switch.
- A switch is a separate opam environment that allows you to install different sets of packages and dependencies independently of each other. Each switch has its own isolated set of installed packages and dependencies, which can be useful for managing different projects or development environments.
### Sanbox.
- A sandbox is a feature that allows you to isolate the dependencies of a specific project or package within the same switch. This can be useful when you want to experiment with different versions of a dependency, or when you want to avoid conflicts with other packages or projects that may be using different versions of the same dependency.
---
## Language.
### Variables.
- 6 is an int but 6. is a float, in a same manner "+" is for int and "+." is for float.
- variables can only begin with _ or ' or a lowercase letter
### Constructors/Variants.
- OCaml constructors are used to create values of algebraic data types. They are different from object-oriented programming (OOP) constructors because they do not create objects or classes.
- In OCaml, an algebraic data type is defined using the type keyword. For example, the following code defines a simple algebraic data type color with two constructors: Red and Green.
```ocaml=
type color =
| Red
| Green
```
- The | symbol is used to separate different constructors. The color type can now be used to create values of either Red or Green. For example:
```ocaml=
let c = Red;;
```
- Here, c is a value of type color that has been created using the Red constructor.
- Constructors in OCaml can also take arguments. For example, the following code defines a new algebraic data type point with a single constructor Cartesian that takes two arguments of type float.
```ocaml=
type point =
| Cartesian of float * float
```
- To create a value of type point, we need to use the Cartesian constructor and provide two float values as arguments. For example:
```ocaml=
let p = Cartesian (3.14, 2.71);;
```
- Here, p is a value of type point that has been created using the Cartesian constructor with the arguments (3.14, 2.71).
- In summary, OCaml constructors are used to create values of algebraic data types. They can take arguments and are defined using the type keyword with the | symbol used to separate different constructors.
### Lists.
- Lists in OCaml are built-in types using a standard linked list approach. You can have nested list pretty easily, any type can be inserted in it.
- :: is the list constructor operator.
- The :: operator takes an element and a list, and returns a new list with the element added to the front of the original list. The \[\] operator is used to create an empty list.
- Here are some examples of creating lists in OCaml:
```ocaml=
(* Create a list of integers. *)
let lst1 = 1 :: 2 :: 3 :: []
(* lst1 is [1; 2; 3] *)
(* Create a list of strings. *)
let lst2 = "hello" :: "world" :: []
(* lst2 is ["hello"; "world"] *)
(* Create an empty list. *)
let lst3 = []
(* lst3 is [] *)
```
- Note that since OCaml lists are immutable, once a list is created, it cannot be modified. However, you can use functions such as List.append, List.rev_append, List.concat, etc. to create new lists by combining existing ones.
### Modules.
- A module is like a C++ namespace but can also have other features like creating a signature (type/interface).
- Module names always start with a capital letter.
### Conditional branches' return type must match.
- OCaml requires that conditional branches return the same type.
### Annotated functions.
```ocaml=
let sum_if_true (test : int -> bool) (x : int) (y : int) : int =
(if test x then x else 0) + (if test y then y else 0);;
```
### Unit functions with no args.
- In OCaml, functions that take no arguments are still required to take a single argument of type unit. unit is a built-in type that has only one value, also called unit, which is represented by (). This may seem counterintuitive, but it ensures that all functions in OCaml have a consistent interface and behave in a predictable manner.
```ocaml=
let my_function () = (* function body *);;
```
- This means that my_function takes a single argument of type unit. If you try to call this function without passing any argument, you will get a type error.
- When you call a function that takes no arguments, you still need to pass the unit value as the argument. So, to call my_function, you would write:
```ocaml=
let _ = my_function ();;
```
- This function can now perform side effects like printing to the console or updating data outside its scope.
### List vs Tuples.
- List is same type but infinite size.
- Tuple can be different type but finite size.
### Filenames naming convention.
- In OCaml, the naming convention for filenames is to use all lowercase letters and separate words with underscores. This convention is commonly known as "snake_case".
- For example, if you have a module called "MyModule", the corresponding filename should be "my_module.ml". Similarly, if you have a module called "MyNestedModule", the corresponding filename should be "my_nested_module.ml".
- It's important to note that the filename should always have the ".ml" extension, which is used to indicate that the file contains OCaml code.
# Programming.
## Outermost traversal.
The outermost traversal method is also known as the level-order traversal or breadth-first traversal. In this method, the nodes of a tree are visited level by level, starting from the root node and moving down to the leaves.
The outermost traversal method is useful for problems that require processing nodes at a given level of the tree before moving on to nodes at deeper levels. It is also useful for printing out the nodes of a tree in a level-by-level manner.
## Side effect.
Side effect in functional programming is when a function can modify a state outside its scope.
## Mutually recursive functions.
To write two mutually recursive functions in OCaml, you can use the `and` keyword to define both functions in the same `let rec` block. Here's an example of two mutually recursive functions that compute the nth even and odd numbers:
```ocaml=
let rec even n =
if n = 0 then 0 else odd (n-1)
and odd n =
if n = 0 then 1 else even (n-1)
```
In this example, `even` and `odd` are mutually recursive functions. The `even` function calls `odd`, and the `odd` function calls `even`. The `and` keyword is used to define both functions in the same `let rec` block.
Note that when defining mutually recursive functions in OCaml, you must use the `let rec` keyword instead of just `let`, because the functions call each other recursively. Additionally, you must define both functions in the same block using the `and` keyword, since they depend on each other.
This on the other hand will cause a compile time error:
```ocaml=
(* /!\ Forbidden /!\ *)
let rec even n = if n = 0 then 0 else odd (n-1)
(* /!\ Forbidden /!\ *)
let rec odd n = if n = 0 then 1 else even (n-1)
```
# Software Architecture.
## Module.proof
```
├── ListO
├── Variable
├── Power
├── Arithmetic
│ └── Num
├── Normalize
├── Verif
├── Simplify
│ ├── Brackets
│ ├── Mult
│ ├── AddOfMult
│ └── Fraction
│ ├── Mult
│ └── Add
└── Factorize
```
## Test.proof
```
├── Msg
├── Rand
├── Rule
│ ├── SimplifyArithmetic
│ ├── Distributivity
│ ├── SimplifyAddOfMult
│ ├── MissingTerm
│ ├── Factorize
│ └── Fraction
│ ├── Mult
│ └── Add
├── Data
├── Gen
│ ├── Expr
│ ├── SimplifyArithmetic
│ ├── Distributivity
│ ├── SimplifyAddOfMult
│ ├── MissingTerm
│ ├── Factorize
│ └── Fraction
│ ├── Mult
│ └── Add
└── Test
```
# Proof Files.
## Node.proof
- Most nodes are written in Citadle for now, we will the have to remove every Citadle code in the future.
- Some nodes are written in OCaml and points to Citadle nodes, but not all of them (Wrapping).
Syntax of a node: node(key,list)
The type of the data structure is "Index"
Key can be any expression, but in practice it is a Citadle string.
List is a Citadle of other nodes or terminals (leaves) which are Citadle strings again.
Every node declaration is of the type Expression.
Expression identifier : expression
so in the code "NodeName" : node(x,y)
### General Nodes.
notFound: The value is a string "Not Found". It seems to be the only one not calling the node constructor.
undefinedNode: A node type used to insert it as a child node, which will specify that it is not defined yet and can be searched easily to assign its value.
emptyNode: A node type that is the opposite of undefinedNode, the idea is to remain not assigned.
etc: A node used to truncate data when pretty printing (see the QA section for more information).
blank: A node used to parse blank lines from JSON (possibly the empty value in std JSON).
brackets(bool,sign,expr): The node is used to represent both parentheses and sign. If bool is true then it means expr is in parentheses, if false then it is not. Sign can be an empty string "" for the positive sign or "-" or ":-" for negative sign.
listNode(expr): Its a node used to represent an OCaml style list, that can contain sub-lists, which cannot be done with regular Citadle.
pair(expr0,expr1): Represents a pair of two expr.
jsonPair(expr0,expr1): it seems to also be a pair but for JSON parsing.
kind(type): A node to create an identity object, to further specifiy the entity of an expression/object.
rwWar(name): A node to build rewrite variables.
name(name0): A node used to specify a name, used for meta-rules.
error(msg_list): a node used to return an error when applying a strategy, with the feedback messages in the list msg_lsit.
parameterDeclaration(x,expr): allows to eventually assign expr to x. A node that can change its value along the way, but still pointing to the same identifier.
### Sets.
A set can either be defined by a finite set (A = {a,b,c,...,z}) or by a predicate.
setOfReal : The set of real numbers.
setOfInteger : The set of integers.
setOfNatural : The set of natural numbers.
setOfBoolean : The set of booleans.
elementOf(x,s): use to say that the variable x belongs to the set s.
setPredicate(name0,varXNameList,typeXList0,varYNameList,typeYList0,cond): node used to define a set by predicate. name0 is the name of the set.
{varXNameList : typeXList0 \| there exists varYNameList : typeYList0 such that cond(varXList,varYList,p)}.
varXList = a list of name of variables which type are in the list typeXList0
varYList = a list of name of variables which type are in the list typeYList0
p = an extra list of parameters.
cond is the condition that may depend on the variables varXList and varYList with names in varXNameList and varYNameList and in p as well.
### Numbers, Booleans and Variables.
The node variable is used for math variable like X or Y but also for declaring numbers (terminal leaves).
variable(name,sign,indList,set0,kind0):
sign can be "+" or "-" or ""
indList allows to write variables like x1,x2 and x3..
set is the set in which the variable belongs
kind can be number/variable/boolean
natural(val,sign): a node used to represent a natural number.
integer(val,sign): a node to represent an integer number.
real(val,sign): a node to represent a real number.
boolean(val): true or false.
minus_1: the integer -1.
zero: the integer 0.
one: the integer 1.
varInt(name,sign): use to represent an integer variable (like X or Y).
varReal(name,sign): same but for real numbers.
varOfLib(name,sign): used as data structure in the list listOfVarInLib.
### Algebraic and Boolean Operations.
add(expr0,expr1): The addition.
sub(expr0,expr1): The subtraction.
mult(expr0,expr1): The multiplication.
div(expr0,expr1): The division.
frac(expr0,expr1): The fraction.
power(expr0,expr1): expr0 to the power of expr1.
inv(expr): a node to replace div(a,b) or frac(a,b) to mult(a,inv(b)).
minus(expr): apparently not used anymore.
minusOfSub(expr): used to do sub(a,b) = add(a,minusOfSub(b))
orNode(expr0,expr1): OR.
andNode(expr0,expr1): AND.
notNode(expr): NOT.
### Equalities and Equations.
equality(expr0,expr1): expr0 = expr1.
greater(expr0,expr1): expr0 > expr1.
less(expr0,expr1): expr0 < expr1.
greaterOrEqual(expr0,expr1): expr0 >= expr1.
lessOrEqual(expr0,expr1): expr0 <= expr1.
notEqual(expr0,expr1): expr0 ≠ expr1.
equalNode(expr0,expr1): **TO BE DEFINED.**
lineEqual(): **TO BE DEFINED.**
lineNotEqual(): **TO BE DEFINED.**
equals(): **TO BE DEFINED.**
### Metarule and Verification.
A node metarule(...) is generated by the JSON of a rule, rule designed in the rule editor (rule edition interface).
concrete and abstract: This nodes represent the two types of metarule available in the interface.
left(x): x is the lhs of an expression of a rule (used in a metarule).
righ(x): x is the rhs of an expression of a rule (used in a metarule).
feedback(l): There is a feeback in the rule editor and this nodes transmits it.
metarule(name,kind,lhs,rhs,feedback,children): Represents a meta-rule and holds its data.
name is a name(name0) node used to specify the name of the rule.
kind is a Citadle strings (= to concrete or abstract).
lhs is a left(x) node for the left hand side of the rule.
rhs is a right(x) node for the right hand side of the rule.
feedback is a feeback(l) node for the feedback of the rule.
children isn't used yet.
positiveFeedback(expr): A node used to return positive feedback. Not used yet.
feedbackFormula(cond,msg):
Two cases are distinguished and evaluated by the strategy "evalFeedbackFormulaS0":
'cond' is a boolean expression to be evaluated with 'evalCond' into True or False. The expression 'msg' is returned in case of success.
'cond' is a node algorightm(name0,parameterList) to be executed which returns a feedback built from default expressions.
algorithm(name,parameterList):
name is the name of the algorithm.
parameterList is list of parameter that must be passed to the the algo pointed by name.
This is node is used for verification.
yes: A node returned in the node result(...) if the answer is right.
no: A node returned in the node result(...) if the answer is wrong.
noOnce: A node returned in the node result(...) if the answer is wrong but this kind of answer is only allowed once for this kind of operation (see overleaf doc for further understanding).
result(correctness,msg,graphCommand,position,negativeMark,msgTest):
The node holding the result of the verification.
crrectness can be a node yes/no/noOnce
msg is the feedback message.
graphCommand is a Citadle string to pass args to the graph command.
position is the the subexpression of 'i' where the error was located.
negativeMark is a integer in the range [0-5] with 0 being good answer and 5 the worst mistake.
msgTest is a node pair(string,listNode([pair(subI1,subO1),pair(subI2,subO2),...])) used in the tests.
resultBool(correctnessBool,msg,graphCommand,position,negativeMark):
Same as result but correctness is meant to be True or False.
test(name,io,result,isTodo,isSkipped):
A node used to build tests on input and output.
name is a string for the name of the test.
io is the pair(i,o).
result is a string representing the expected result.
isTodo is False if the test is ready to be used, true if it is still generated.
isSkipped is False if the test should be skipped and true if it must be done.
undefinedStepError: a kind of step error.
correctPair: a kind of step error.
correctPairButNotExpectedForm: a kind of step error.
errorInPairWellIdentified: a kind of step error.
errorInPairWellIdentifiedSingleErrorAllowed: a kind of step error.
errorInPairNotIdentified: a kind of step error.
applicableStrategyNotFound: a kind of step error.
stepError(stepErrorKind,algorithmName,algorithmCaseName,left,right):
A node to store the error type at the given verification step.
stepErrorKind can be any of the kind of error listed above.
algorithmName is the Citadle string for the name of the algorithm where an error or a correct result was detected.
algorithmCaseName is the Citadle string for the name of the case in the algo 'algorithmName' where an error or a correct result was detected.
left and right are the subexpressions of i and o where and error was identified.
The node stepError is stored in GlobalVar("stepError") and is initialized with stepErrorDefault.
stepErrorDefault: A default node with default param for stepError.
---
## Case.proof
*hashTableOfCaseStrategy* is the HashTable, or map, that holds every strategy that were created. The table is created at the beginning, before every strategy is declared.
### Cases for Verification Algorithms.
The creation process of a strategy is as follow:
Expression caseKey : "nameOfTheStrategy" -> Declared an identifier for the strategy.
Strategy strat(verification) : verifyForm(...) -> see function.proof
Expression z : addCaseStrategy1(caseKey,strat,hashTable) -> Insert the strategy in the data structure.
First listing of strategies:
> [name=Michel Lenczner]Attention, il y a des règles anciennes et des nouvelles. Et quand on a écrit ces règles, cela ne dit pas ce qu'elles permettent de vérifier (du à la prise en compte de $\Phi$).
- i = a + b $\times$ c $\blacktriangleright$ o = d $\times$ c
- i = a $\times$ b + c $\blacktriangleright$ o = a $\times$ d
- i = a $\times$ (b + c) $\blacktriangleright$ o = d + c
- i = (a + b) $\times$ c $\blacktriangleright$ o = a + d
- i = a $\times$ b + a $\times$ c $\blacktriangleright$ o = a $\times$ (b + c)
- i = a $\times$ c + a $\times$ d + b $\times$ c + b $\times$ d $\blacktriangleright$ o = (a + b) $\times$ (c + d)
- i = a $\times$ c + b $\times$ c $\blacktriangleright$ o = (a + b) $\times$ c
- i = a $\times$ (b / c) or (a / b) $\times$ (c / d) $\blacktriangleright$ o = d / e
- i = a + b / c or a / b + c / d $\blacktriangleright$ o = d / e
- i = a $\times$ (b + c) $\blacktriangleright$ o = a $\times$ b + a $\times$ c
- i = (a + b) $\times$ (c + d) $\blacktriangleright$ o = a $\times$ c + a $\times$ d + b $\times$ c + b $\times$ d
- i = (a + b) $\times$ c $\blacktriangleright$ o = a $\times$ c + b $\times$ c
- identity
- two different numbers
- Same fraction
- wrong modification of a fraction
- multiplying the numerator and the denominator by different numbers
- divising the numberator and the denominator by different numbers
- add or substract 2 fractions with different denominators
- denominators from the sum and the result are different
- wrong fraction addition or subtraction
- a op b -> wrongEval(a op b)
- o = variable(...)
- eval(i) = o = variable(...)
- simplify addition of multiplication
- missing term
- eval(i) = eval(o)
- a + b -> wrongEval(a + b)
- failure as success
---
## Function.proof
### Algorithms of Verification.
#### VerifyForm.
verifyForm(
algorithmCaseName,
stepErrorKind,
preStrategy,
patternI,
patternO,
condPattern,
stratCondPattern,
preStrategyForPrettyPrint,
patternLeftIForPrettyPrint,
patternLeftOForPrettyPrint,
patternRightIForPrettyPrint,
patternRightOForPrettyPrint)
algorithmCaseName: A Citadle string used to identify the verification strategy. It is used to find the error message corresponding to the strategy in an associative table.
stepErrorKind: It can take the following values:
- undefinedStepError
- correctPair
- correctPairButNotExpectedForm
- errorInPairWellIdentified
- errorInPairWellIdentifiedSingleErrorAllowed
- errorInPairNotIdentified
- applicableStrategyNotFound
patternI: A pattern corresponding to the first line in the pair of lines.
patternO: A pattern corresponding to the second line in the pair of lines.
#### VerifyFormWithCond.
It is a wrapper arround VerifyForm with 'stratCondPattern' set to 'mySuccess'.
#### VerifyFormDelay.
It is a wrapper arround VerifyForm but using a delayed evaluation in 'ruleIdCond'. This allows to use functions in the condition 'condPattern'.
---
## Test.proof
Need to understand what g and r are.
Normalization is achieved by pre-strategy in the r function.
In testing, the generated expressions by the function g are not normalized.
- g generates i and is not normalized
- r transforms an expression i so that the pair (i,r(i)) is verified with phi(s) for a verification strategy s.
- r transforms i into o
---
## Module.proof
### Normalize module.
#### Type Data.
Used for normalization (inside the module?).
Booleans to enable/disable normalization on specific node types.
var/brackets/mult/frac/pow
#### flattenOP opName expr
- Takes an operation node name (opName) and a tree (expr) and returns a flatten list for that operation.
- Example: opName = "add" and expr = add(add(1,1),add(add(2,3),3)) (= 1+1+2+3+3)
- Result: [1;1;2;3;3]
- Example: opName = "add" and expr = add(add(1,1),add(2,mult(2,sub(2,2)))) (= 1+1+2+2x(2-2))
- Result: [1,1,2,2×2-2]
#### sign sign0
- Takes a string representing the sign as a parameter (sign0) and returns the normalized form of the sign.
#### var data node
- Takes the data preset and a node, if the node is a variable then it applies the `sign` function, otherwise returns node.
#### prodSign sign0 sign1
- Takes two strings representing signs of two members of a product and returns the normalized sign that you should get after the product is applied.
#### prodSignList l
- Takes a list of signs and calls prodSign. Returns the final sign of the list. The idea is to extract the sign of all variables of a multList to check what is the sign of the overall product.
#### brack data expr
- Takes the data preset and a tree (expr) and normalizes the brackets recursively.
#### frac data mul expr
- Takes in:
* the data preset.
* the function that normalizes multiplication (apparently there are multiples so you need to pass the one you need).
* the tree (expr).
- Normalizes every frac and div node into multiplications (a/b -> a x b^(-1))
#### pow data mul expr
- Takes in:
* the data preset.
* the function that normalizes multiplication (again, multiple?).
* the tree (expr).
- Normalizes the powers of expr. To see the exhaustive list of all modifications, consult chapter 3.4.2 on Overleaf.
(Notes: pow could be optimized, if data for pow is set to false then the whole function is interpreted for nothing.)
#### powInList data l
- Takes in the data preset and a list. Normalizes the pow in the entire list (using map function).
#### productOfSamePower l
- Takes in a list of products of power(x,n) with all elements of the list sharing the same base (x). Returns the power(x,m) which is the sum of all powers reduced to one power (m).
#### minus expr (deprecated)
- Takes in a tree (expr) and if it finds a node minus(subexpr) then normalizes it. It must be already normalized regarding multiplications.
# ChatGPT.
## LLM documentation links.
- [Prompt Engineering Guide.](https://www.promptingguide.ai/)
- [Prompt example list.](https://prompts.chat/)
---
## Exchanges.
### The reason why you must use english with ChatGPT.
- **Question: Let's pretend that a piece of information is released on a french website and is only available/published on that website in the entire world. Nowhere else this information can be found. If I ask you about a related subject but I ask it in English, will you be able to answer me using that content that uses a foreign language?**
As an AI language model, I am trained on a diverse range of data, including text in multiple languages, including French. However, my responses are generated in English, and I do not have the ability to directly access or retrieve information from specific websites, including foreign language websites, as I do not have browsing capabilities. I can provide general knowledge and information based on my training data, including information related to the topic you ask about, but I would not be able to provide specific details from a piece of information published on a French website or any other website. My responses are generated based on the patterns and information present in my training data up to September 2021.
- **Question: When you say that your answers are generated in English, what do you mean?**
As an AI language model, I generate responses in English, which means that the text I produce, including my answers to your questions, will be in the English language. I have been trained on a large dataset that consists mostly of text written in English, which includes a wide variety of topics and domains. My responses are generated based on patterns, associations, and language structures learned from the training data, and I generate text in English as that is the language in which I have been primarily trained.
- **Question: In conclusion, would say that English is the best language to interact with you?**
As an English-language AI language model, I am most proficient in generating responses in English. Interacting with me in English would allow me to provide the most accurate and relevant responses based on my training data. However, I can also understand and generate text in other languages to some extent, including French, although my proficiency may be lower compared to English. If you are more comfortable communicating in English, it would be ideal for interacting with me to receive the most accurate and comprehensive responses.
---
### About Complex Numbers in the french program (12th grade/Terminale).
- **Question: I want to know about complex numbers, can you give me an exhaustive list of every competence regarding that math domain that a student of "Terminale" level must have at then of the year?**
Certainly! In the French school math program for "Terminale" level, which corresponds to the final year of high school (often the equivalent of Grade 12 in other countries), students typically cover complex numbers as part of the curriculum. By the end of the year, students are expected to have acquired the following competencies related to complex numbers:
1) **Understanding the concept of a complex number:** Students should be able to define and understand the concept of a complex number, which is a number that consists of both a real part and an imaginary part, typically written as a + bi, where a and b are real numbers, and i represents the imaginary unit (√-1).
2) **Representing complex numbers in different forms:** Students should be able to represent complex numbers in different forms, including rectangular form (a + bi), trigonometric form (r(cosθ + isinθ)), and exponential form (re^(iθ)), where r is the modulus or absolute value of the complex number, and θ is the argument or angle of the complex number.
3) **Performing operations with complex numbers:** Students should be able to perform basic operations with complex numbers, such as addition, subtraction, multiplication, and division. They should also understand the geometric interpretation of these operations, such as addition corresponding to vector addition and multiplication corresponding to rotation and scaling in the complex plane.
4) **Understanding properties of complex numbers:** Students should understand the properties of complex numbers, including the distributive, associative, and commutative properties of addition and multiplication, as well as the properties of conjugates, absolute value, and argument of complex numbers.
5) **Solving equations involving complex numbers:** Students should be able to solve equations involving complex numbers, including linear and quadratic equations, as well as equations involving absolute values and arguments of complex numbers.
6) **Applying complex numbers in other areas of mathematics:** Students should be able to apply complex numbers in other areas of mathematics, such as solving problems in geometry, calculus, and physics that involve complex numbers.
7) **Understanding applications of complex numbers in the real world:** Students should understand real-world applications of complex numbers, such as in electrical circuits, signal processing, and control systems, and be able to apply complex numbers to solve problems in these contexts.
It's important to note that the specific curriculum and competencies may vary depending on the educational institution and the exact math program followed in France, so it's always best to consult the relevant curriculum documents or check with your teacher for the most accurate and up-to-date information.
---
### Deep dive into Batteries vs Core+Base.
#### Functionality:
"Batteries Included" is a philosophy followed by many software libraries, where the library aims to provide a comprehensive set of features and functionalities out of the box. It aims to be a one-stop-shop for various common tasks and provides a wide range of tools and utilities. On the other hand, "Core" and "Base" are two separate libraries developed by Jane Street, which provide different sets of functionality.
#### Modularity:
"Core" and "Base" libraries are designed to be modular and composable, allowing users to pick and choose the specific components they need. They are meant to be used together as building blocks for developing complex applications in OCaml. In contrast, "Batteries Included" libraries tend to be more monolithic, providing a larger set of functionality in a single library.
#### Focus:
"Core" and "Base" libraries are developed by Jane Street, a prominent financial technology company known for its expertise in functional programming and OCaml. These libraries are specifically designed and optimized for building financial systems and applications. On the other hand, "Batteries Included" libraries are not tied to any specific company or domain and are intended to provide general-purpose functionality for a wide range of applications.
#### Extensibility:
"Core" and "Base" libraries are designed to be easily extensible, allowing users to add custom functionality and adapt them to their specific needs. They provide a flexible and extensible foundation for building sophisticated applications. "Batteries Included" libraries may provide a wide range of functionality, but they may not be as easily extensible or customizable.
#### Documentation and Support:
"Core" and "Base" libraries are well-documented and actively maintained by Jane Street, with dedicated support channels available for users. Jane Street provides regular updates and bug fixes, and users can rely on the company's expertise and support. "Batteries Included" libraries, on the other hand, may have varying levels of documentation and support, depending on the specific library and its community.
#### Dependencies:
"Core" and "Base" libraries are designed to have minimal dependencies on external libraries, and they aim to provide a self-contained set of functionality. This helps ensure stability, performance, and ease of integration. "Batteries Included" libraries, on the other hand, may have more dependencies on external libraries, which can increase the complexity of managing dependencies in a project. "Core" and "Base" are separate libraries that can be used independently or together. "Core" is a lower-level library that provides foundational functionality for building reliable, high-performance systems in OCaml, while "Base" builds on top of "Core" and provides additional higher-level utilities and tools for building applications.
#### Licensing:
"Core" and "Base" libraries are released under open-source licenses, allowing users to use, modify, and distribute the libraries freely. "Batteries Included" libraries may also be released under open-source licenses, but this can vary depending on the specific library and its licensing terms.
#### Community and Ecosystem:
"Core" and "Base" libraries are part of the OCaml ecosystem and are widely used in the functional programming community, particularly in the finance and trading domains. They have an active user community and benefit from the expertise and contributions of the Jane Street team. "Batteries Included" libraries, on the other hand, may have a broader user base and community, covering a wider range of application domains.
#### Complexity:
"Core" and "Base" libraries are known for their rigorous design and focus on correctness and performance. They are often used in complex and performance-critical systems, and they may require a deeper understanding of functional programming concepts and OCaml language features. "Batteries Included" libraries, on the other hand, may provide a higher-level abstraction and be more accessible to users with varying levels of functional programming expertise.
#### Purpose:
"Batteries Included" is a term often used to refer to programming languages or libraries that come with a large standard library that includes a wide range of functionality, covering a diverse set of use cases. It aims to provide a comprehensive set of tools and utilities for various tasks without requiring additional external dependencies. On the other hand, "Core" and "Base" are libraries developed by Jane Street, a financial technology company, and they are primarily focused on providing functional programming utilities and tools for building high-performance, reliable, and scalable systems in OCaml, a statically-typed functional programming language.
#### Contents:
"Batteries Included" typically includes a wide range of modules, libraries, and tools that cover areas such as file I/O, networking, regular expressions, data serialization, date/time handling, text processing, logging, and more. It provides a large collection of ready-to-use functions and utilities that can be used directly in a variety of applications. "Core" and "Base", on the other hand, focus on providing functional programming tools, data structures, and utilities such as lists, maps, sets, options, results, and other functional programming concepts. They also include modules for error handling, logging, and other common functional programming patterns.
#### Focus on Functional Programming:
"Core" and "Base" are designed with a strong focus on functional programming principles, which are based on immutability, higher-order functions, and data transformations. They provide a set of tools and abstractions that are well-suited for functional programming paradigms, such as map, fold, filter, and other higher-order functions, and they encourage writing code in a more functional style. "Batteries Included", on the other hand, may include a mix of imperative and functional programming utilities, as it aims to cover a wider range of use cases and may not be as tightly aligned with functional programming principles.
#### Community and Support:
"Batteries Included" is a term that is often used more broadly and may refer to different libraries or frameworks in different programming languages. The specific contents and support for "Batteries Included" libraries may vary depending on the language or ecosystem. "Core" and "Base" libraries, on the other hand, are developed and maintained by Jane Street, a well-known financial technology company that has a strong presence in the OCaml community. They are actively maintained and supported, and users can rely on the expertise and resources of Jane Street for assistance and updates.
#### Scope:
"Batteries Included" libraries are often designed to be extensive and cover a wide range of functionality, aiming to provide a comprehensive set of tools for various tasks. "Core" and "Base", on the other hand, have a more focused scope, primarily providing utilities for functional programming and high-performance systems in OCaml. They may not cover as wide a range of functionality as "Batteries Included" libraries, but they are designed to be modular and composable, allowing users to build their own tools easily on top of them.
---
### OUnit and Alcotest.
- **Question: I have to write unit tests for an application written in OCaml, what is the best way to do it?**
There are several ways to write unit tests for an OCaml application, depending on your needs and preferences. Here are a few options:
1. OUnit: OUnit is a popular unit testing framework for OCaml. It provides a simple and expressive API for defining and running unit tests. You can use OUnit to test individual functions or entire modules, and it includes features like assertions, test fixtures, and test discovery. OUnit is included in the standard OCaml distribution, so you don't need to install any additional packages to use it.
2. Alcotest: Alcotest is another unit testing framework for OCaml that offers more advanced features than OUnit, such as test parameterization, timeouts, and parallel testing. Alcotest is also designed to be easy to use and has a clear syntax for defining tests. Like OUnit, Alcotest is included in the standard OCaml distribution.
3. Inline testing: OCaml has a built-in facility for testing individual functions using assertions. You can include test code directly in your module files, alongside the functions you're testing. This can be a quick and easy way to test small functions, but it can become unwieldy for larger projects.
4. Property-based testing: Property-based testing is a technique that generates random inputs to test the behavior of functions. There are several property-based testing frameworks available for OCaml, including QCheck and Crowbar. Property-based testing can be useful for testing complex functions or catching edge cases that might be missed with traditional unit testing.
Overall, the choice of testing framework depends on your project's needs, size, and complexity. OUnit and Alcotest are great options for most projects, while inline testing and property-based testing can be useful for specific scenarios.
- **Question: Are there any benefits to use OUnit and Alcotest at the same time?**
Yes, there can be benefits to using both OUnit and Alcotest together in an OCaml project.
OUnit and Alcotest have different strengths and features, and using both frameworks can provide a more comprehensive and robust set of tests for your application. For example, OUnit is simple to use and provides basic assertion testing, making it a good choice for testing individual functions. On the other hand, Alcotest has more advanced features like parameterized testing, timeouts, and parallel testing, making it a good choice for more complex and comprehensive testing.
By combining the two frameworks, you can write simple tests with OUnit and more complex tests with Alcotest, using each framework where it makes the most sense. You can also take advantage of the different features and options provided by each framework to create a more comprehensive and thorough test suite.
Additionally, using both frameworks can help you write better tests by providing a broader range of testing options and approaches. This can lead to more reliable and accurate test results, ultimately improving the quality of your application.
- **Quesiton: Can you show me basic example of OUnit and Alcotest in use?**
Sure! Here are some basic examples of using OUnit and Alcotest for testing simple functions in OCaml:
#### OUnit Example
Let's say we have a simple function that adds two integers together:
```ocaml
let add x y = x + y
```
To test this function with OUnit, we can define a test suite using the `OUnit2` module, like so:
```ocaml
open OUnit2
let test_add _ =
assert_equal 3 (add 1 2)
let suite =
"Test Suite" >::: [
"test_add" >:: test_add
]
let () =
run_test_tt_main suite
```
This defines a test suite called "Test Suite" that contains a single test case called "test_add". The `test_add` function uses `assert_equal` to check that calling `add 1 2` returns the expected result of 3. Finally, we call `run_test_tt_main` to run the test suite.
#### Alcotest Example
Now let's say we have a similar function that multiplies two integers together:
```ocaml
let multiply x y = x * y
```
To test this function with Alcotest, we can define a test module that uses the `Alcotest` module, like so:
```ocaml
open Alcotest
let test_multiply () =
let result = multiply 2 3 in
check int "multiply 2 3 = 6" 6 result
let suite = [
"test_multiply", `Quick, test_multiply;
]
let () =
run "Test Suite" suite
```
This defines a test module called "Test Suite" that contains a single test case called "test_multiply". The `test_multiply` function calls `multiply 2 3` and checks the result using `check int` to ensure that it equals 6. Finally, we call `run` to run the test suite.
Note that in this example we use `check int` instead of `assert_equal`, and we use the `run` function instead of `run_test_tt_main`. These are specific to Alcotest and reflect the differences between the two frameworks.
I hope these examples help you get started with writing tests in OCaml using OUnit and Alcotest!
- **Question: Now that I understand the basics, can you show me advance cases where using both OUnit and Alcotest would be interesting?**
Certainly! Here are a few examples of advanced test cases where using both OUnit and Alcotest could be useful:
#### 1. Testing a module with both simple and complex functionality
Suppose you have a module that contains both simple functions, like the ones we've seen in the previous examples, as well as more complex functions that require more advanced testing. In this case, you could use OUnit to write simple unit tests for the simple functions, and use Alcotest to write more comprehensive tests for the more complex functions.
For example, let's say you have a module that contains a simple function to calculate the sum of a list of integers, as well as a more complex function that sorts the list using a custom sorting algorithm. You could use OUnit to test the sum function with basic assertions, and use Alcotest to test the sorting function with more advanced tests, like checking that the list is sorted in ascending order and that the function is stable (i.e. preserves the order of equal elements).
#### 2. Parameterized testing
Parameterized testing is a technique where you run a test function multiple times with different input values. This can be useful for testing functions that have a large input space or complex behavior. Alcotest supports parameterized testing out of the box, but OUnit does not.
To use parameterized testing with OUnit, you could combine it with a library like QCheck or Crowbar, which provide support for property-based testing and parameterized testing. You could write simple unit tests with OUnit for functions with a smaller input space, and use parameterized testing with QCheck or Crowbar to test functions with a larger or more complex input space.
#### 3. Running tests in parallel
Running tests in parallel can be a useful technique to speed up test execution, especially for large test suites or complex applications. Alcotest supports parallel testing out of the box, but OUnit does not.
To use parallel testing with OUnit, you could use a tool like OUnit2-parallel, which provides support for running OUnit tests in parallel. You could use OUnit to write simple unit tests, and use Alcotest with parallel testing to test more complex functionality in parallel.
I hope these examples help illustrate some of the ways that using both OUnit and Alcotest together can be useful for testing advanced functionality in OCaml!
Google Drive
Gist
Clipboard
Sign in with Wallet
