Recent changes to Autotest-mathmaker

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Fri, 31 Jan 2014 21:51:54 -0000

--- v6
+++ v7
@@ -13,5 +13,5 @@

 Debugging features can be used in combination with `autotest-mathmaker`.

-    `autotest-mathmaker --help`
-will show you all useful options.
+    $ autotest-mathmaker --help
+-> will show you all useful options.

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Fri, 31 Jan 2014 21:51:13 -0000

--- v5
+++ v6
@@ -11,6 +11,7 @@
 * While hunting for a bug, check regularly which changes bring the modifications in autotest-mathmaker. Sometimes it will prevent from adding a bug elsewhere.
 * Be sure to check that autotest-mathmaker is all OK before pushing a new commit to origin

-Debugging features can be used in combination with autotest-mathmaker.
+Debugging features can be used in combination with `autotest-mathmaker`.

-`autotest-mathmaker --help` will show you all useful options.
+    `autotest-mathmaker --help`
+will show you all useful options.

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 22:11:40 -0000

--- v4
+++ v5
@@ -1,10 +1,10 @@
-The script `autotest-mathmaker` contains many many tests to check if the core objects behave the way they should.
+The script `autotest-mathmaker` contains many many tests to check if the core objects behave the way they should. This script is in the main directory and the tests are in maintenance/autotest.

-You can either perform the whole set of tests or choose one or several tests.
+By default, it will perform the whole set of tests, but it is possible to let it perform only certain units.

 For each wrong test, it can display the wrong result and the expected one.

-`autotest-mathmaker` should be used in many ways :
+It can be used in many ways :

 * Before adding any new class or method, write the matching tests. Once the tests are written, so we know what we'll expect from the new code, then we can begin to write this new code
 * When finding a bug, the first step is to reproduce it as a supplementary test, which of course will be OK when the bug is gone ; then work on the code until the bug is gone.

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 22:06:37 -0000

--- v3
+++ v4
@@ -1,8 +1,8 @@
 The script `autotest-mathmaker` contains many many tests to check if the core objects behave the way they should.

+You can either perform the whole set of tests or choose one or several tests.
+
 For each wrong test, it can display the wrong result and the expected one.
-
-You can either perform the whole set of tests or choose one or several tests.

 `autotest-mathmaker` should be used in many ways :

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 22:05:53 -0000

--- v2
+++ v3
@@ -1,77 +1,16 @@
 The script `autotest-mathmaker` contains many many tests to check if the core objects behave the way they should.

-It should be used in many ways :
+For each wrong test, it can display the wrong result and the expected one.
+
+You can either perform the whole set of tests or choose one or several tests.
+
+`autotest-mathmaker` should be used in many ways :

 * Before adding any new class or method, write the matching tests. Once the tests are written, so we know what we'll expect from the new code, then we can begin to write this new code
 * When finding a bug, the first step is to reproduce it as a supplementary test, which of course will be OK when the bug is gone ; then work on the code until the bug is gone.
-* While hunting for a bug, check regurlarly which changes bring the modifications in autotest-mathmaker. Sometimes it will prevent from adding a bug elsewhere.
+* While hunting for a bug, check regularly which changes bring the modifications in autotest-mathmaker. Sometimes it will prevent from adding a bug elsewhere.
 * Be sure to check that autotest-mathmaker is all OK before pushing a new commit to origin

-Usage :
+Debugging features can be used in combination with autotest-mathmaker.

-> $ autotest-mathmaker --help
-> Usage: autotest-mathmaker [options] arg
-> 
-> Options:
->   --version             show program's version number and exit
->   -h, --help            show this help message and exit
->   -l LANGUAGE, --language=LANGUAGE
->                         will check if LANGUAGE is available and if yes, will
->                         produce the output in LANGUAGE.
->   -v, --verbose         will turn on verbose mode (more details will be
->                         written to the output.)
->   -V, --superverbose    will turn on superverbose mode (much more details will
->                         be written to the output.)
->   --short-test-run      will start a short test run (writes once each of the
->                         available sheets on the std err output) instead of a
->                         unit test.
->   --long-test-run=LONG_TEST_RUN
->                         will start a long test run (writes n times the
->                         available sheets on the std err output) instead of a
->                         unit test. This option will be ignored if --short-
->                         test-run is specified.
->   -F N, --fraction-simplification-coverage=N
->                         will start a special test to check the simplification
->                         of fractions. It will test all fractions from 1/1 to
->                         N/N
->   -u UNITS, --unit=UNITS
->                         will test only the given unit, instead of all ofthem
->                         (default behaviour). This option can be repeated to
->                         test several units, for instance : autotest-mathmaker
->                         -u item -u product will check only these two units :
->                         item_test and product_test
->   --units-list          will write the list of available units and exit.
-
-
-
-
-
-
---> Turn ENABLED to True in debug.py will let mathmaker write debugging informations to stderr. The methods that give output informations can be chosen among the different variable below (into_str_in_item, into_str_in_product etc.). All objects have a special (small) method called dbg_str() which is used to clearly identify the objects and their classes. (I can see in your snip : {+1^.1.} and {-0^.1.}, which represent Item(1) and Item(0), so there was some debugging stuff enabled there)
---> The autotest-mathmaker executable in the main directory uses the tests present in maintenance/autotest
-These tests have been written either before writing the code (unit tests) or after a bug has been found.
-Some uses of autotest-mathmaker :
-- without options, will provide a short summary after having executed all the tests.
-- autotest-mathmaker -v will give more informations (but not really useful, maybe it should be deleted)
-- autotest-mathmaker -V will give alot of informations (number of the test which failed, plus which result was expected and which result was found instead)
-- You can also use autotest-mathmaker on some units instead of them all
-- autotest-mathmaker short-test-run will execute each sheet once. Just to check there's no big bug somewhere.
-- autotest-mathmaker long-test-run=n will execute each sheet n times. (warms the processor...). to detect more rare bugs.
-- autotest-mathmaker --help will give you some more hints
-
-Now, here are some details about the core :
-* The most important thing is that mathmaker is not a software intended to *compute* mathematical stuff, but to *display* it. This is the reason why the core is quite complex : the human rules we use to write maths are full of exceptions and strange details we don't notice usually because we're familiar to them. To re-create these writing rules on a computer is not really simple !
-* So, all objects of the core are mathematical objects which can be represented, either as figures or as mathematical formulas
-* Hence, all objects are not conceived according to their mathematical properties first, but according to their "displaying rules"
-* base.py contains the most abstract classes :
-- Copiable, mother class of all objects. Provides a deep_copy() method which ensures to create a new object completely identical to the given one
-- Drawable, mother class of all geometrical objects. Provides the into_pic() method, which creates a picture of the object. All geometrical objects must implement a into_euk() method, which will create the eukleides file (.euk) to draw them. This method is used by Drawable.into_pic() to create the picture.
-- Printable, mother class of all calculus objects. They all must implement the into_str() method, which tells how to display them (independently from the output's format). Note that Drawable was thought to be a Printable too, so that geometrical objects would have to implement into_str() as well. But this feature does not seem to be useful. So probably Drawable will only inherit from Copiable.
-* 
-
-
-
-
-
-
-I should certainly also update the documentation (I use doxygen), this would be of help...
+`autotest-mathmaker --help` will show you all useful options.

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 21:40:28 -0000

--- v1
+++ v2
@@ -7,7 +7,40 @@
 * While hunting for a bug, check regurlarly which changes bring the modifications in autotest-mathmaker. Sometimes it will prevent from adding a bug elsewhere.
 * Be sure to check that autotest-mathmaker is all OK before pushing a new commit to origin

+Usage :

+> $ autotest-mathmaker --help
+> Usage: autotest-mathmaker [options] arg
+> 
+> Options:
+>   --version             show program's version number and exit
+>   -h, --help            show this help message and exit
+>   -l LANGUAGE, --language=LANGUAGE
+>                         will check if LANGUAGE is available and if yes, will
+>                         produce the output in LANGUAGE.
+>   -v, --verbose         will turn on verbose mode (more details will be
+>                         written to the output.)
+>   -V, --superverbose    will turn on superverbose mode (much more details will
+>                         be written to the output.)
+>   --short-test-run      will start a short test run (writes once each of the
+>                         available sheets on the std err output) instead of a
+>                         unit test.
+>   --long-test-run=LONG_TEST_RUN
+>                         will start a long test run (writes n times the
+>                         available sheets on the std err output) instead of a
+>                         unit test. This option will be ignored if --short-
+>                         test-run is specified.
+>   -F N, --fraction-simplification-coverage=N
+>                         will start a special test to check the simplification
+>                         of fractions. It will test all fractions from 1/1 to
+>                         N/N
+>   -u UNITS, --unit=UNITS
+>                         will test only the given unit, instead of all ofthem
+>                         (default behaviour). This option can be repeated to
+>                         test several units, for instance : autotest-mathmaker
+>                         -u item -u product will check only these two units :
+>                         item_test and product_test
+>   --units-list          will write the list of available units and exit.

Autotest-mathmaker modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 20:13:50 -0000

The script autotest-mathmaker contains many many tests to check if the core objects behave the way they should.

It should be used in many ways :

Before adding any new class or method, write the matching tests. Once the tests are written, so we know what we'll expect from the new code, then we can begin to write this new code
When finding a bug, the first step is to reproduce it as a supplementary test, which of course will be OK when the bug is gone ; then work on the code until the bug is gone.
While hunting for a bug, check regurlarly which changes bring the modifications in autotest-mathmaker. Sometimes it will prevent from adding a bug elsewhere.
Be sure to check that autotest-mathmaker is all OK before pushing a new commit to origin

--> Turn ENABLED to True in debug.py will let mathmaker write debugging informations to stderr. The methods that give output informations can be chosen among the different variable below (into_str_in_item, into_str_in_product etc.). All objects have a special (small) method called dbg_str() which is used to clearly identify the objects and their classes. (I can see in your snip : {+1^.1.} and {-0^.1.}, which represent Item(1) and Item(0), so there was some debugging stuff enabled there)
--> The autotest-mathmaker executable in the main directory uses the tests present in maintenance/autotest
These tests have been written either before writing the code (unit tests) or after a bug has been found.
Some uses of autotest-mathmaker :
- without options, will provide a short summary after having executed all the tests.
- autotest-mathmaker -v will give more informations (but not really useful, maybe it should be deleted)
- autotest-mathmaker -V will give alot of informations (number of the test which failed, plus which result was expected and which result was found instead)
- You can also use autotest-mathmaker on some units instead of them all
- autotest-mathmaker short-test-run will execute each sheet once. Just to check there's no big bug somewhere.
- autotest-mathmaker long-test-run=n will execute each sheet n times. (warms the processor...). to detect more rare bugs.
- autotest-mathmaker --help will give you some more hints

Now, here are some details about the core :
The most important thing is that mathmaker is not a software intended to compute mathematical stuff, but to display it. This is the reason why the core is quite complex : the human rules we use to write maths are full of exceptions and strange details we don't notice usually because we're familiar to them. To re-create these writing rules on a computer is not really simple !
So, all objects of the core are mathematical objects which can be represented, either as figures or as mathematical formulas
Hence, all objects are not conceived according to their mathematical properties first, but according to their "displaying rules"
base.py contains the most abstract classes :
- Copiable, mother class of all objects. Provides a deep_copy() method which ensures to create a new object completely identical to the given one
- Drawable, mother class of all geometrical objects. Provides the into_pic() method, which creates a picture of the object. All geometrical objects must implement a into_euk() method, which will create the eukleides file (.euk) to draw them. This method is used by Drawable.into_pic() to create the picture.
- Printable, mother class of all calculus objects. They all must implement the into_str() method, which tells how to display them (independently from the output's format). Note that Drawable was thought to be a Printable too, so that geometrical objects would have to implement into_str() as well. But this feature does not seem to be useful. So probably Drawable will only inherit from Copiable.
*

I should certainly also update the documentation (I use doxygen), this would be of help...