**2012/02/15** :
Changed some names (make_string -> into_str for the objects ; -> type_str for the machine)
Reorganized the multiple files that hang around in the main directory : have put them in a new /utils directory. Caused recursive importation problems which didn't occur before, very strangely. Solved.
Wanted to add a kind of safe mode too, but I don't see how it can be used. I mean, in order to present the error result in a viewable form, mathmaker needs to produce an output in a specific format (LaTeX or odt or whatever). But if this would be easy to do with LaTeX, it isn't the case with other (non ML) formats, like odt, because the error could exactly come from the process of creating the output. Or maybe I can decide to let mathmaker produce only LaTeX error reports, but then when calling it from a webpage needing an odt result, it will be necessary to anticipate, in case of an error, that the next operations to do are the ones of LaTeX whatever the first call was about ; this doesn't make much sense. So I would say, no safe-mode included in mathmaker itself ; in case of an error of mathmaker (or any of the following programs), then the caller has to decide what it does with the error.

So, this will do the 0.3 (alpha)

Working on #55 Wrote some basic stuff. First geometrical object. Installed the last version of eukleides (on my platform it was still eukleides 0.9.2 !)

**2012/02/14** :
Working on #B
Finished all sheets. Added some new features to LaTeX.write_table to let it draw borders of the table etc.
Ran successfully an autotest-mathmaker --short-test-run
Re-run each sheet and compiled it (latex) and corrected some changes that occured in some layouts between the first and the last sheet worked on.
Finished : #B !!!
Working on #59
Finished : #59
Note : this will shorten the Fractions' simplifications (the 'n/1' step will be skipped directly to 'n')
Working on : #54(the pythagorean mode trick and internationalization)
Done : #54(the pythagorean mode trick and internationalization)
Note : the tests are already all in english, so I don't change it ; the translation of the "or" word seems to be done
already. If I find this isn't done somewhere I haven't seen yet, I'll change it, it'll be done quickly anyway.

Next to do/finish :

- 55, #57, #E', #NR1, #NR2, #NR3 ; also wish to rename make_string of obj/
**init**.py to 'to_str' and the**str**() should be turned into something like 'dbg_str' ; still wondering if putting some stuff in a utils directory wouldn't be better...

**2012/02/13** :
Working on #B
Corrected bugs and stuff, finally brought algebra-test-2 to work again ! Now going on with other sheets.
Done all sheets till fraction-simplification ; so three sheets left and it will be done...

**2012/02/07** :
Working on #B
Corrected some minor bugs and 1 syntax error :o)
Now have to modify LaTeX.write_document_header() to let it return a str instead of writing to the output.
(Just change all self.out.write() in result += and at the end, either self.out.write(result) or return result, depending on the value of self.redirect_output_to_str )

**2012/02/04** :
Working on #B
Wrote the X_Structure.**str**() method inspired by the current S_Structure.write_(). Note that only X_Structure has a write method now (turned into **str**()), no other exercise needs to have it anymore. Changed the **init**() to make the machine of the exercise also always redirect to str, like in Q_Structure. X_Structure.**str**() doesn't need to have any option, only the argument ex_or_answers. So, deleted this redirect option which also shortened the code... Remember the questions (neither exercises) don't write themselves now, but they can be called through str(q, ex_or_answers)
Also adapted the write_() of S_Structure (turned into texts_to_str()) to let it use str(exercise)... and renamed several methods, including write_whole_sheet (to **str**()) and adapted the calls of mathmaker and autotest-mathmaker.

**2012/02/03** :
Working on #B

**2012/02/02** :
Working on #B
Now I think about another great change that could be done : the questions AND exercises shouldn't have write*() methods. Only the machine should be able to write. So it would be better to let all questions & exercises have a **str**() method (that could call a machine to create things) that would all return strings. After that, the machine can write it. It would make all the stuff more simple then, especially to write the X_Structure.write_() method which should become... X_Structure.**str**().
So, changed all questions' write methods so as to let them only return a str and not write themselves to the output. The given machine's field set_redirect_output_to_str set to True in **init**() from Q_Structure.
Now, no question writes itself to the output, but is able to return a str of itself (provided argument 'exercises' or 'answers')

**2012/01/31** :
Working on #B
Transformed all sheets.
Begining to work on the transformation of exercises.
Included a "all" and a "all_left" possible value after None in the SHEET_LAYOUT (and then also X_LAYOUTS...) to avoid determining exactly how many exercises/questions are to write when none is concerned by special layouts (so the default values can be None, 'all_left' or None, 'all')
Then changed all sheets that do not require any layout...
Back to exercises : transforming all exercises to make them use the X_LAYOUTS global. Not easy, because some of the exercises have very special write_answers() methods. Not done for Fatorization & Calculation yet. Inspiration from Equation ? (with the '?' to mean 'refer to a given max number'... ; for factorization there is a max/page either...)
Finally thinking that the number of equations in each column is anyway fixed by "self.max_number..." so, maybe just take this value as the number of equations (e.g. questions) to put in each column. Then use the '?' for the previous multicolumn layout. I mean, with the LaTeX machine it will lead to multicolumn usage whereas with other languages it may lead to use something else.
Changed the key type to a tuple (x_kind, x_subkind) in order to avoid having problems later with two subkinds having the same name but from two different kinds.
Changing everything for factorization is too complicated to anticipate now. So, when checking and debugging, just add all the necessary layouts in X_LAYOUTS. Commented out the write_answer().
Put the '?' in exercise/Calculation.py X_LAYOUTS. This could be handled by multicolumns, but check if it is really necessary.

**2012/01/30** :
Working on #D and #B

- D can be considered finished !

So, back to #B : have rewritten the sheet/Structure.py and renamed it S_Structure.py ; it contains now everything needed. So StructureShortTest and StructureEquations were put to the garbage.
Modified things in the different Structure.py files, all renamed (X_ or Q_...)
Now mathmaker is certainly pretty much broken.
Check sheet/AlgebraTest2 and bring it back to work (means certainly adapting exercise.AlgebraExpressionExpansion and exercise.Factorization ; and first maybe, create a global EXERCISE_LAYOUT inspired by SHEET_LAYOUT, this new global should be used by the exercises instead of them rewriting the write_texts/answers methods with lots of (deprecated) tabular methods. /!\ this global should be able to be different according to the x_kind/x_subkind. Maybe define it with a default value for this sort of exercises and modify it in the **init**() depending of self.x_kind/x_subkind
Maybe also remember that all write_text and _answers of exercises (at least) are deprecated.
Also note that the exercises don't have a answers_text field ; the text field now contains a dictionnary : {'exercises' : **("...."), 'answers' : **("....")}

Next to do/finish :

- 54(the pythagorean mode trick and internationalization), #55, #57, #59,
- B, #E', #NR1, #NR2, #NR3

**2012/01/29** :
Working on #D and #B
Successfully wrote and tested (with algebra-test-2) the algorithm in StructureShortTest.write_texts() to create the exercises arranged according to the given global SHEET_LAYOUT.
Had to change the exercises.write_text() and questions.write_text() methods of Factorization and AlgebraExpressionExpansion to take the required "redirection to str" in account. Still many changes to do... (the same in other exercises/questions).
Proceed with the StructureShortTest.write_answers() method ; note that it is exactly the same code as in write_texts() so maybe factorize this portion of code ? Anyway, StructureShortTest should definitely be merged with Structure, using a field as I wrote on 23rd january.
Still to do in #D : maybe add a write_layout() method to the machine and use it instead of directly write_table() in order to have other means to define a sheet layout in other machines. In LaTeX.py, write_layout() would do nothing but call write_table() with the same args.

**2012/01/26** :
Working on #D
Changed some other names to more appropriate ones.
Wrote the write_table() method. Don't know how to test it directly (write a new test sheet ? ; best would certainly be to modify the sheet/StructureShortTest.py and test it with AlgebraTest2
Reported the modifications to machine/Structure.py ; now the machine Structure is independant from LaTeX !

**2012/01/25** :
Working on #D
Tested the change for multicolumns, seems to work well :o)
Changed some names.
Suppressed the "expression_begins" field of the Machine, seemed completely useless (obj.calc objects use a global expression_begins)

**2012/01/24** :
Working on #D
Quite transforming the LaTeX.py ; at the end, adapt the Structure.py
Tried to suppress the two multicolumns-related methods, replaced them by an option in the write() method.
Needed to add a 'output' field indicating if the output must be redirected to an str. Maybe this name is bad, because there is already an 'out' field which contains things like sys.stdout... Also added to (set & reset) methods allowing to change the value of this output field. The idea is to be able to concatenate different results of the machine usually sent to the std output. This allows to avoid having two multicolumns-related methods. But then I also needed to add a "write_text_to_str()" in a question py file to concatenate several questions strings before the resulting string is sent to a write(resulting_string, multicolumns=2)
The transformation needs to be tested (see Calculation.py exercise & question where it has been implemented)
The changing the tabular-related methods will certainly be similar (but more complicated since there are more methods)

**2012/01/23** :
About #B : I think it would be better to add also a layout_type field (self.layout_type) in the sheets ; it would be equal to "standard_training", "short_test", "test", or "mini_test" etc. and it could be used in Structure to determine which kind of layout will be used, instead of using so many different files (StructureShortTest.py, StructureEquation.py could disappear, be absorbed in Structure.py).
I also think that it is time to rewrite the code of machine/Structure.py and hence machine/LaTeX.py in order to be really independant from the LaTeX format. This should be done before the #B can be finished. So I let #B aside for the moment and begin to work on #D.

Next to do/finish :

- 54(the pythagorean mode trick and internationalization), #55, #57, #59,
- B(work on the LAYOUT global for sheets and after that, for exercises ; generalize it ; include sheet/StructureEquation.py and sheet/StructureShortTest.py in sheet/Structure.py thanks to a self.layout_type field in the sheets),
- D, #E', #NR1, #NR2, #NR3

**2012/01/22** :
Working on #B.
Added the global TEXT_SIZE_OFFSET = 0 in all sheets (and the Model.py) + the matching line to use it.
Now thinking about the new LAYOUT global.
Began to define a model for this LAYOUT about the sheets only so far (still to think and do for the questions' layout inside exercises). Written to Model.py and began to try to test it with AlgebraTest2.py : added the SHEET_LAYOUT and now, try to change the StructureShortTest.write_texts() and ~answers()

**2012/01/17** :
Working on #B.
Done for all the current sheets and exercise/*.py
Now go one with adding the FONT_SIZE_OFFSET global. In each... sheet ?
For instance see self.machine.set_ref_text_size(-3) in sheet/AlgebraFactorization03
After that, think about the LAYOUT global to define and program !

**2012/01/16** :
Working on #B.
Job done for all the Algebra* sheets.
Now go on with the Equations sheets. The exercise/Equation.py needs to be transformed according to exercise/Model.py

**2012/01/15** :
Working on #B : transforming the options' system of the exercises.
Most of the transformation to do is :

- in the sheets (preformatted='yes' becomes x_kind='preformatted' ; matching x_kind=... becomes x_subkind=...

- in the used exercises : add the AVAILABLE_X_KIND_VALUES (copy from Model.py), put there the different available subkinds... ; add x_kind='default_nothing', in the
**init**() ; change the call of Structure.Structure.**init**() according to the one of Model.py ; then change the structure of the different if elif elif else (if self.x_kind == '': if self.x_subkind == '...':)

Progression is made throughout the sheets. All done entirely till AlgebraFactorization03.py, go on from AlgebraShortTest.py should be easy ; note that : the "short_test = 'yes'" maybe leads to something bypassing the exercise.py : use the "bypass" option then. Possibly check the old version to find which exercises/options were called if not clear.

**2012/01/13** :
Working on #B
Changes also done in MentalCalculation
Now begining with the exercises classes.
Done for the change : kind -> x_kind
Still to do : change the rules for the exercises' kinds options (the short_test='yes' and its specific subtype option are weird ; thinking about changing this to x_kind='short_test' and then x_subkind='...' ; maybe also put a AVAILABLE_X_LIST global which would list all kinds of exercises implemented yet and their matching "sub-options" ; something like
AVAILABLE_X_KIND_VALUES =

)

**2012/01/12** :
Working on #B
Changes made for all questions except MentalCalculation still to do.

**2012/01/10** :
Working on #B
Also will change the 'kind' variable of the questions in q_kind to distinguish it from the 'x_kind' (of the exercises). The same with subkind : q_subkind & x_subkind.
Now the change of question.Model.py and question.Structure.py has been done in order to factorize the code in question.Structure.**init**().
The renaming of the kind & subkind in q_kind has been done for the question.AlgebraExpressionExpansion, question.AlgebraExpressionReduction and matching sheets & exercices. AVAILABLE_KINDS_LIST was also renamed AVAILABLE_Q_KINDS_LIST.
Now proceed with question.Calculation.py etc. and after that, with the exercises sheets.

**2012/01/09** :
Working on #B. autotest-mathmaker --short-test-run was successfully run after some additions to the AVAILABLE_KINDS_LIST of question.AlgebraExpressionExpansion. Also done : question.AlgebraExpressionReduction
Idea : try to put all these many lines into the question.Structure.**init**() (inspiration from the exercises...)
Still to do !

**2012/01/08** :
Working on #B (relifting the sheets and exercises and questions Structures & Models according to the best implemented so far) : generalize the use of AVAILABLE_KINDS_LIST ; put the right stuff to have the tabulars in each sheet/exercise ; put the right stuff to have control over the size of characters.
Began with the (almost finished) work on the AVAILABLE_KINDS_LIST of question.AlgebraExpressionExpansion
(next time check that the sheets still work, that there is no option-checking problem)

**2011/12/30** :
Finished the layout for the test sheet for level 'hard' (3e). Some bugs to fix, not too bad : some lines are duplicated in the answers (I think it's the same as #59). French translation done.

- 58 can be considered as done. Even though some other sheets on the same theme could be written.

Also changed Calculable in Exponented and Basic in Calculable

Next to do/finish :

- 54(the pythagorean mode trick and internationalization), #55, #57, #59, #B, #D, #E', #NR1, #NR2, #NR3

**2011/12/28** :
Wrote the new algebra test sheet for level 'hard' (3e). Still to fix the display (a missing newline between the first & second line in correction of exercise 2 ; put the corrections of 1 & 2 in two columns to spare space... just look at the result. Notice that the layout of the exercises is chosen in the matching sheet (and the layout of the questions is chosen in the matching exercise)). + FRENCH translation ! Name : algebra-test-2

**2011/04/07** :
Wrote the new algebra test sheet routines [pour les 4èmes]. Now activate it and test it !

**2011/02/22** :
Work on the new algebra test sheet continued.
Wrote the matching routines for the reduction exercise. Now, have to write the expansion exercise.

**2011/02/21** :
Began the work on a new algebra test sheet, harder than the first one.
Wrote the matching routines for the factorization exercise of this sheet. (3 questions, among them one is not factorizable...)
Began to write the routines for the reduction exercise (I wish to have 2 "normal" questions, where one contains a single "x" or "-x" ; plus one containing -(...) and/or +(...) ; plus one not reducible). So, have to finish to write the matching kind in sheet.exercise.question.AlgebraExpressionReduction.py and in the sheet.exercice.AlgebraExpressionReduction.py
Also have to put some more expansions (2 singles, one double, one sum of 2 of them)

**2011/02/20** :
Created a new Equations test sheet.

New :

- 59 There's a little bug (see autotest equations #47). Maybe check if it doesn't disturb the fractions' unit tests to change the result of Fraction.simplified() in the case of a denominator being equivalent to a single 1 from a product having the numerator (Item) as single factor to the numerator (Item) itself. This should solve the bug. Check also if my guess about Fraction.simplified() is right.

Next to do/finish :

- 54(the pythagorean mode trick and internationalization), #55, #57, #58, #59, #B, #D, #E', #NR1, #NR2, #NR3

**2011/02/13** :
Working on #58
Finished writing the code for the "fake" cases. Seems to work perfectly well.
Now I would like to have smaller fonts in the output, and to be able to change the font size for each sheet at least. So I'm changing a little bit the LaTeX machine in order to do that. By the way, I try to make the rest of the code less LaTeX dependant doing this (at the end it should be completely LaTeX independant). This change is now done.
Finished the algebra-factorization-03 sheet ! (for binomial identities !)
Next to do in #58 : algebra-factorization-04 (or relift the 3rd sheet...) for both binomial- and common-factor-factorizations. + factorization-short-test

**2011/02/11** :
Working on #58
Abandoned the last idea, could be good but long to do now.
Began to write the code for the "fake" cases.

**2011/02/09** :
Working on #58
Corrected the last problem. Was a bug in the "core" code !
All the "true" cases are ready. Next to do : the fake ones. Think about factorizing the code to avoid creating the same ax and b and (ax)² and b² many times in many places...

**2011/02/08** :
Working on #58
Still correcting the bugs. Had to create a new obj.Equality class to let display things like "Let a = 3x and b = 3 then 2×a×b = 2×3x×3" etc.
Working at the end of level_03() to use these objects to have a right displaying in the latex sheet.
The first cases are done (square sums and differences).
Working on the squares differences. Have a problem with the 2-exponented Monomials displaying. Check the sheet...

**2011/02/07** :
Working on #58
Began to write the method. Just had to change the way the steps are created in the __init__() method. Check if the first factorization exercises sheets still work fine.
Later : still seems to work fine.
Wrote the first kinds of questions and the first draft of the new training sheet. Still debugging it !

**2011/02/06** :
Working on #58
Next time on #58 : write the level_03 method in ~/mathmaker/sheet/exercise/question/Factorization.py

New :

- 57

Found a small "bug" in algebra-factorization-02. Check the last of these lines : $ D=(-4x+18)(17x-3)+4x(17x-3) $\newline $ D=(17x-3)\times (-4x+18+4x) $\newline $ D=(17x-3)((-4+4)x+18) $\newline $ D=(17x-3)(0x+18) $\newline $ D=(17x-3)18 $\newline $ D=(17x-3)\times 18 $\newline $ D=18(17x-3) $\newline Same kind of bug : $ A=(5x+10)\times 6x+(-20-5x)\times 6x $\newline $ A=6x\times (5x+10-20-5x) $\newline $ A=6x((5-5)x+10-20) $\newline $ A=6x(0x-10) $\newline $ A=6x\times (-10) $\newline $ A=6x\times (-10) $\newline $ A=-60x $\newline

- 58

Creation of a better training sheet for factorizations, including binomial identities factorization

Still to do : #54(the pythagorean mode trick and internationalization), #55, #57, #58, #B, #D, #E', #NR1, #NR2, #NR3

**2010/12/25** :
Working on #54
The displaying of a unit at the last line is being added as an option to pass to auto_resolution(). Like eq.auto_resolution(unit='cm').
Done and tested on a pythagorean Equation only, so far.
Thinking about the feature of returning the solution(s) along with the complete detailed resolution. auto_resolution() should return a tuple of two elements, the first one being the usual string containing the complete resolution, the second one being a list containing either nothing if there are no solutions, or one or two objects being the solution(s).
Still to do : the pythagorean mode trick and internationalization.

**2010/12/24** :
Working on #54
Added the unit field to an Item plus the matching methods (set_unit and added the option 'display_unit' to the Item's make_string).
After thinking about it, it would be good to add it directly to the Equation object. Only problem : to discover which is the last line to display...
It would be also good to add the feature of returning the solution(s) of an Equation to let the Exercise using it display them in a phrase for instance.
Still to do : the pythagorean mode trick and internationalization.

**2010/11/26** :
Working on #54
Found the bug. Still some little things to correct :

- in autoresolution, the dummy empty \[\] line (just check there is something to display before adding these marks).
- the needs_to_get_rounded() doesn't work well with integers. Correct this !

Both problems corrected. Added a pythagorean mode. Still to do in #54 : internationalization + add the unit field to an Item (displaying it if required) & the option unit="cm" (for instance) in the equation to let it display at the end. And just correct the trick with pythagorean_mode=latex.MARKUP maybe rather write pythagorean_mode='yes', use_markup=latex.MARKUP would be better, so change the matching portion of solve_next_step().

Still to do : #54, #55, #B, #D, #E', #NR1, #NR2, #NR3

**2010/11/25** :
Working on #52 and then #54
Wrote the basic methods.
Wrote the matching unit tests, plus the first equations tests using square roots.

- 53 is done.

Thinking about #54 : resolving an Equation like x² = 4. Problem is, this must split in 2 equations... Maybe a solution is to return a tuple containing these two Equations from solve_next_step and add the right algorithm in auto_resolution to handle with such cases. Must implement also a "pythagorean mode", which will mention the negative solution is ignored (for instance as a string stored as eq_aux2 in the tuple instead of the negative solution). Also think about the case the two new Equations don't use the same amount of lines to finish the resolution (then store any useful information to display a last line like "The solutions are..."). Will certainly be required when solving things like (2x - 1)(3/4 x + 5) = 0, so maybe don't implement it right now... This should be done in auto_resolution, anyway. Also think about the internationalization of the small linking word "or". In the methods plus in the unit test. Stopping for tonight ! Well the last equation tested doesn't resolve well, it introduces a bug, most probably in auto_resolution. Just add some debugging features in auto_resolution and turn True the debug.ENABLED flag and begin to work on cleaning this bug ! Then add some more tests (like resolving x²=16 with decimal_result=2 ; x² = 5 without decimal_result ; x² = 5 with decimal_result = 3 for instance, then an almost pythagorean equation : x² = 3² + 4² ; then...).

**2010/11/24** :
Working on #52
Writing the first SquareRoots methods inspired from Item's methods (I mean, the kind of required methods).
Resume at line 2142.

**2010/11/23** :
Working on #51
That's done. Maybe the management of locales could be better (mathmaker.cfg, default.py...). Maybe in the unit test, the check function could handle the locales itself, instead of. No, bad idea, the strings are given to check "as are", it can't guess how it can be changed. No, use the locale module in the tests is correct. So, #51 is done ! Plus #53, actually.

**2010/11/22** :
Working on #51
Found out that the correct function seems to be locale.str() to display the numbers in their locale variant. There are 23 tests not working now, which seem to be exactly the cases where decimals are expected. So now, just change the test to let it accept the locale displaying and all should be fine. (Then #51 would be finally done !)

**2010/11/21** :
Working on #51
Added the new Equations in the matching test unit.
Made all of them work fine [added the feature of displaying a decimal result to solve_next_step and Fraction.calculate_next_step + added a new has_been_rounded field in Value + the matching contains_a_rounded_number method in all the Calculables classes].
Now, to achieve the #51, just finish with the localization problem (of the decimal_point) [maybe check if this couldn't be done by latex itself ?].
So, checked it and almost implemented it : lot of the Values' test are now wrong (displaying 3,14 instead of 3.14 now : not bad, just correct the test : this should be done by replacing the '.' in the test string by the default.DECIMAL_POINT). BUT the Equations still display stuff like 2.38 instead of 2,38 in the autotest, and *that* is not good, they should also give errors in the test, they don't. To do : find why and correct this. [It seems to come from the Item.make_string() which directly uses the value field instead of calling the self.value_object.make_string(), but this could also cause problems, so think about it, check if it would be OK to just replace self.value by self.value_object.make_string()...]

**2010/11/20** :
Working on #51.
Conclusion :

- Added some features to Item (initializing it from a Value, plus methods round, digits_number, needs_to_get_rounded). All also added in the unit test.
- There is a need for implementing a new feature to Equation.solve_next_step() : the ability to either give an exact or a rounded result. This should be given as an option to the Equation.auto_resolution() method. And this should be handled by other objects too, through calculate_next_step() and expand_and_reduce_next_step(), which should at least transmit the option and change their behaviour in some cases : 1°) for a Sum or a Product, when nothing should be done and the last term/factor is a single Item, for instance, then if the option "decimal_result" is activated and the result needs_to_be_rounded, then round it ; 2°) for a Fraction or a SquareRoot, if "decimal_result" is required, then don't simplify it but possibly round them 3°) the solve_next_step should transmit the option but not at each step, only when necessary : when a recursive call occurs or when the solution is reached. The default behaviour should be the same as before (give an exact result).

The equations to test are : 2x = 1 which gives either x = 1/2 ; None OR (same result in the two cases of the option activated to decimal_result=1 and 2) x = 1/2 ; x = 0.5 ; None. Second equation to test : 3x = 1 which gives either x = 1/3 ; None OR (in the case of the option activated to decimal_result=2) x = 1/3 ; x <sign for approximatively equal to> 0.33 ; None. Third Equation to test : 8x = 6 which should give as a result (in the case of the option activated to decimal_result=2) : x = 6/8 ; x = 0.75 ; None. Fourth Equation to test : x = 3² + 4² which should give the same result as when the option is not activated (x = 9 + 16 ; x = 25 ; None). Fifth Equation to test (with option activated to decimal_result=2) : x = 1/4 + 1/8, which gives as a result : x = 2/8 + 1/8 ; x = 3/8 ; x <sign for approximatively equal to> 0.63 ; None. Sixth Equation to test : AB = 3² + 4². Cause also noted that the Item is not thought to display literal strings longer then one char, which is not practical for displaying things like AB²... so check if giving this possibility doesn't breack everything (that shouldn't be). Finally, there must be also an option in the Value.make_string() to use the locale for displaying number, for instance in english 2.5 gives 2,5 in french. Test this in Values' unit test. (Most probably last thing to do to achieve #51 : use of decimals will be fully possible then !)

**2010/11/19** :
Working on #51. Conclusion : Implemented the new methods Value.round(precision), Value.digits_numbers() and Value.needs_to_get_rounded(precision) plus matching tests. Should also implement the equivalent methods for numeric Items whose exponent is equivalent to a single 1.

**2010/11/13** :
Conclusion of 11/12 :
Currently working on #50 and #E. See last comments here + autotest-mathmaker -V !!! (the autotest_output.txt file contains the last interesting informations to investigate, around the # 12 of Equations...). There might be a need for putting more debug stuff in the soft... and long time and clear spirit, not tired, to kill this bug...
Still to do : #51, #52, #53, #54, #55, #B, #D, #NR1, #NR2, #NR3

Working on #E, #50, #51

New :

- E' : Implement Quotient's expand_and_reduce_next_step()
- 56(bug) : Long test run has given a new bug :

Bug is reproduced in autotest-mathmaker. A guess : an Equation has been built or changed improperly so that one member is not a Sum anymore.

Done :

- 50
- 56(bug)
- E partially (Quotient still needs to have an expand_and_reduce_next_step() method)

Still to do : #51, #52, #53, #54, #55, #B, #D, #E', #NR1, #NR2, #NR3

**2010/11/12** :
Working on #37
Bug of yesterday is reproduced. Working on it.
Trying to correct the bug in this way : I think the put_term_in_lexicon function is responsible for it. This creates systematically a Sum and embbeds numeric Items, even alone, in a Sum. This could actually be put in a list, to let the calling method do what it want with the list, possibly turning it into a Sum. But well, I don't see any other usage of it than putting it in a Sum after the call of put_term_in_lexicon. So, let's just put an Object alone in the lexicon and if there is another one coming, then put them in a Sum. Right in put_term_in_lexicon. Let's see if it will not cause new bugs !!!
Well, it does. This is not a good solution, because when a method calls get_terms_lexicon, it doesn't know if each element of the result if either a Sum or anything else. And it is used in several places, so it would lead to change and enlarge the code everytime get_terms_lexicon is called. So, back to previous version.
So the bug is to correct in the intermediate line : just depack every single-term-Sum.

Done :

- 37

Reorganization :

- 49bis is renamed #D
- 50 becomes # RELEASE NEW VERSION
- 51, #52, #53 are renamed #NR1, #NR2, #NR3 (Next Release...)

New (or reminder) :

- B : Generalize the use the AVAILABLE_KINDS_LIST to all exercices & questions Classes (from the example of Factorization question). Also adapt the comments about it. Put it in the Model.py
- D : reorganize the Machine class and Machine's subclasses so as to become totally independent from LaTeX format and welcome other formats easily.
- E : reorganize the relations between expand_and_reduce_next_step & calculate_next_step (the first calling the second when called from a numeric object and the second calling the first when called from a non numeric object ; all Classes heriting from Calculable, including Quotient, should redefine these two methods)

- NR1 : Strange behaviour when adding the simplification of fractions in the case of randomly chosen num & deno in the product and quotient sheet of fractions. Have to inquire it...
- NR2 : Check if uniting AlgebraExpressionExpansion & AlgebraExpressionReduction in one question/Algebra.py and exercise/Algebra.py is possible (maybe not because of the different results outputs)
- NR3 : (ex-#49) create a new algebra sheet (replace a variable by a given value)

+ Trying to prepare the Pythagorean Theorem Exercise, so :

- 50 : Check if an Equation like x = 4² + 5² is well solved. Check if it is possible to solve the Equation without writing its name, or introduce the feature.
- 51 : Introduce the Decimals and Rounding them well.
- 52 : Add a new obj.calc Class : SquareRoot and the basic functionnalities to use a square root in the resolution of a pythagorean Equation (which means also the matching unit tests)
- 53 : Add the feature to Equations to give an exact answer or approximate answer.
- 54 : Add the feature of an Equation to solve when the last literal term is squared (e.g. Equations terminating with x² = n)
- 55 : Prepare the first simple geometrical Objects (Point ? Segment ? Triangle ? RightAngledTriangle)

- RELEASE NEW VERSION (ex-#50, not numbered yet, will be done later)

So, working on #50. It resolves the Equation, but a) skips one step, plus b) the present algorithm won't be well suited to Pythagorean Equation resolution. So either write source code specifically for Pythagorean Equations, or adapt the one existing to work also well on Pythagorean Equations. Done : #50 b) and I guess the #50 a) requires first #E to be done to get solved.

So, working on #E. Changed the beginning of Sum. & Product.expand_and_reduce_next_step() & calculate_next_step(). Plus added an inoffensive patch in Operation.evaluate() to let a Monomial of degree 0 be evaluated. Plus added a patch in Sum.get_terms_lexicon() to handle with Monomials before the Products. Plus added a patch in Sum.calculate_next_step() to replace the 0-degree-Monomials by equivalent Items/Fractions

Now there are still three kinds of bugs :

- some lines repeat twice or the calculation is made in too many steps in Equations
- the Fractions in Equations are not well handled any longer (sign, simplification is not done) [problem is probably they are built as Quotients instead of Fractions]
- the last test of Expansion & Reduction section fails.

**2010/11/11** :
Working on #37
Managed to resolve the problems, plus improve the management of fractions. All tests pass successfully. Yu-hu :o)
Now working on resolving the bugs in the corresponding sheets. Got them "all"... all sheets seem to work... Long test run gives a new bug :

as well as $ (E_{4}): 3(-5-2x)+2=8 $\newline as well as $ (E_{3}): -7-2(x+9)=2 $\newline as well as $ (E_{3}): 3(-9+6x)-8=9 $\newline as well as $ (E_{4}): 6(-2-2x)-1=3 $\newline all result in : [...]

File "/home/nico/mathmaker/obj/error.MethodShouldBeRedefined: The method expand_and_reduce_next_step has just been called by this type of object <class 'obj.calc.Quotient'> that should have redefined it in order to use it.

But these ones don't get the bug : $ (E_{0}): 4(-x+9)+8=5-2x $\newline $ (E_{1}): -5+9x=7(-x+2)-9x $\newline $ (E_{2}): 2=-3(5-3x) $\newline $ (E_{3}): -6x=-(-7-5x) $\newline $ (E_{1}): -(5x-3)=-3x $\newline $ (E_{2}): -7(-5+8x)=-7x $\newline $ (E_{2}): -4-7(-5x-4)=2x $\newline

... check it ! (Maybe defining the expand_and_reduce_next_step in Quotient would resolve the problem, but check if this case doesn't lead to a bug (unsolved Equation, or a line repeated twice...)) Idea of expand_and_reduce_next_step in Quotient would be calling it on numerator and denominator and if nothing happened, check if self cannot turn into a Fraction (Item/0-degree-Monomials Products) and call expand_and_reduce_next_step of Fraction...

**2010/11/10** :
Working on #37
Trying to change the signs handling during Fractions' calculation/simplification. Managed to have the frac{-1}{-6} not the last of the simplification, but frac{1}{6} instead of that ; BUT now when reducing to the same denominator, this adds a step : 1/6 + -1/9 becomes 1/6 - 1/9 instead of beginning with (1×3)/(6×3) + (-1×2)/(9×2). This is not wrong but adds a quite useless step. Don't really know if pupils do that step or not, anyway I don't think they do it just for the sign... So, let's explore the fractions-sums unit test with Sum.calculate_next_step on !

**2010/11/09** :
Working on #37
Checked the "failed" results, they all seem actually ok, the only point to change is relative to the fractions simplification (the signs). So check this !

**2010/11/08** :
Working on #37
Chose to write two new methods in Sum : get_numeric_terms and get_literal_terms
Corrected a bug (the "depacking" at the beginning of solve_next_step was wrong).
Finally got the test passing entirely without any bug.
But there's a need to think about the test to enter the second case in solve_next_step (the case of a Sum of 1 term being literal at the right had to be treated in this case, check if the symetric problem (1 numeric term at the left) should be never done...)
Next step, check if the produced by the new algorithm "failed" resolutions are actually correct... and if not, correct them !
There seem to be a need for correcting something in the process of fraction simplification (the signs "inside" might be treated first ?).

**2010/11/07** :
Working on #37
Rewrote the resolve_next_step almost entirely. Trying to let it run through the autotest-mathmaker. Had to rework on the 2d Case (collecting the numeric terms from the left to put them on the right and the literal terms from the right to put them on the left) and changed the method (1st round and 2d round). Now this method doesn't work well (tried to use the Sum.get_terms_lexicon method, which I apparently don't use well with Monomial in the Sum...). Maybe write a method in Sum that would be more simple than Sum.get_terms_lexicon (we don't need as much as get_terms_lexicon does, in the present case) and use it in resolve_next_step (2d case) instead of get_terms_lexicon. Note that moreover, the situation to deal with here is very simple... The problem that lead me to change the 2d case algorithm was caused by a Sum imbricated in one another (this one :
[[< {+7^.1.} × {+x^.1.} > + < {+5^.1.} > ] ]
). In this case, the sum [< {+7^.1.} × {+x^.1.} > + < {+5^.1.} > ] was caught entirely to be put on the left (as it is not entirely numeric, it is treated as literal). So a simple method collecting right (e.g. diving recursively into the problem) would be sufficient to solve this case.
The other option is to adapt get_terms_lexicon in order (or maybe the use of it ?) to avoid getting this problem :
Traceback (most recent call last):

error.UnreachableData: Can't find : {+7^.1.} in << {+1^.1.} × X ^1>> , << {+7^.1.} ×(..)

**2010/11/05** :
Working on #37

**2010/01/02** :
Working on #37

**2009/12/25** :
Working on #37
The __init__() method of obj.Equation has been checked, it creates Equations that are of the model Sum = Sum. Two places could be secured, though it's not really useful. That's written in comments (TO DO ?)

**2009/09/20** :
Worked on the improvement of the factorization sheet #1. The first 'basic' exercise produces actually too many 'difficult' questions. It needs to be more controlled, not totally randomly created. It is finished and satisfying.

Working on #37 (rewriting the Equation.solve_next() method). Simplified the 1st CASE. Deleted the 2d CASE (changing the resolution method : we won't swap the sides if the left one is only numeric). Thinking about the reorganization using the new methods available. Decided that the two sides of an Equation object must be Sums and nothing else. This should make everything much more simple : the 1st CASE becomes useless, several cases can merge together etc. But I have to change the __init__() method slightly. Rewrote on paper the algorithm in __init__() to be sure to avoid strange constructions like imbricated one-term Sums or one-factor Products. Rewrote on paper the algorithm of Equation.solve_next()

**2009/02/28** :
Working on #A & #C.

Done :

- C, #A

Still to do : finalize the current new factorization sheet, #37, #49bis, #B & #50

**2009/02/27** :
Working on the new factorization sheet. Exercices "easy" & "intermediate" are quite ready. Still a "difficult" and a "hard" exercise to do.

New :

- A If the last Product of a factorization is reducible (like in C=(-17+20x)\times (-4)-4(9x+17), which leads to -4×29x), then it has to be reduced ! Tried to fix it, but the Product.is_reducible() method recognizes non-reducible Products as reducible ! So, the last line is displayed twice at many occasions. Still to fix.
- B Generalize the use the AVAILABLE_KINDS_LIST to all exercices & questions Classes (from the example of Factorization question). Also adapt the comments about it. Put it in the Model.py
- C Create a debug.py where to put all debugging-related stuff, instead of default.py

Still to do :

- A, finalize the current new factorization sheet, #37, #49bis, #B, #C & #50

**2009/02/26** :
Working on the correction of bug new_factorization_sheet[1], related to the Monomial's patch in the displaying of (external) brackets of a factor inside of a Product.

New :

- new_factorization_sheet[2] : 15 × 3x displayed 15 × (3x), or 15(3x) (if compact) (related to the Sum 0 + 3x whose length is 2...)
- new_factorization_sheet[3] : 15 × 3x displayed 153x (if compact)
- new_factorization_sheet[4] : the sheet created this : A=(-19x-14)(-10x^{2}+9x-10)+-10x^{2}+9x-10 [problem in Sum.make_string(), re-created in sums_test]

Done :

- new_factorization_sheet[1]
- new_factorization_sheet[2]
- new_factorization_sheet[3]
- new_factorization_sheet[4]

Still to do : finalize the current new factorization sheet, #37, #49bis & #50

**2009/02/25** :
Working on the correction of bug new_factorization_sheet[1], related to the Monomial's patch in the displaying of (external) brackets of a factor inside of a Product.

**2009/02/19** :
Finished the restructuration of autotest in sub-units. Fixed the problem with AVAILABLE_UNITS (both a list and a dictionnary are created using AVAILABLE_UNITS). Finished to reproduce the tests from the old autotest script. This new structure is more practical and flexible, it's easy to add new options to the main script and new units to test (so real unit tests are possible to write now).
Coming back to the new factorization sheet.

new_factorization_sheet[1] has been reproduced in obj_test/calc_test/product_test.py with the object : Item(-1) * Product([Monomial, Monomial]) displaying then -1×-7x instead of -1×(-7x). Later : the error is still here with the object : Item(-1) * Product([Monomial]) so it has nothing to do with equivalent-to-1 objects ; it obviously comes from Product.make_string() which seems to ignore that Monomial is not at the first position. Investigating this.

Done :

- new_factorization_sheet[0]

**2009/02/16** :
Still working on the restructuration of autotest in sub-units. Slightly changed & factorized some code and remade monomials, products' reduction, sums, sums' reduction, quotients, fraction simplification, fractions products, fractions quotients, fractions sums and equations. Have to modify again the structure used for AVAILABLE_UNITS, since a dictionnary seems to fit best... it's necessary to use it to get the right units more simply than with a list, but then I must try to build the names of the units from the strings (or vice-versa).

**2009/02/11** :
Still working on the restructuration of autotest in sub-units. Finally found a solution for this problem ! Remade item & product test sections. Have now to build all the other old sections.

**2009/02/08** :
Still working on the restructuration of autotest in sub-units. Looking for a solution for a problem with global variables used in the tests.

**2009/02/07** :
Still working on the restructuration of autotest in sub-units. Looking for a solution for a problem with global variables used in the tests.

**2009/02/01** :
Still working on the restructuration of autotest in sub-units. Currently testing it with autotest-mathmaker -u item

**2009/01/31** :
obj/calc/__init__.py : Monomial.__init__() : corrected the attribution of lib.ZERO_POLYNOMIAL_DEGREE to Value(lib.ZERO_POLYNOMIAL_DEGREE) to the exponent of factor[1]

Testing the new factorization sheet : two new bugs to correct :

- new_factorization_sheet[0] : sometimes a reducible Polynomial is created, that shouldn't be possible
- new_factorization_sheet[1] : after reduction of the non common factors, when coming to a single negative Monomial, this can be displayed without brackets. Like in : B=-(13x^{2}-17x-1)(20x+13x)+(13x^{2}-17x-1)\times 14x

Beginning to restructure the autotest module to make it modular and more usable.

**2009/01/30** :
Factorization.py : the steps are put in the right order directly in level_01() instead of __init__()
Factorization.py : the solution is now returned by level_01() and level_02() included in steps

Finished the first try of Factorization's question object (level_02() is ready to be tested !)

Still to do :

- 37, #49bis + the current new factorization sheet and #50.

**2009/01/29** :
test 1 has been done and autotest and autotest --short-test-run work properly.
test 2 has been tried but leads to bugs related (at least, after short inquiry) to Monomials' displaying, so I gave up.

**2009/01/23** :
test 2 : managing 1-exponent Products differently in Product.__init__() in case of a list of Calculables
? maybe add the Values (treated as numbers) in Sum.__init__() and Product.__init__()
test 1 : eliminating __add__() and __mul__() from Calculables and Basics. putting times() and plus() higher in the hierarchy. replacing all direct operations on object.exponent by operations on object.exponent.evaluate()

**2009/01/21** :
Decided to keep the names of times() and plus() functions to represent the functions creating a Product or a Sum from their arguments. Decided not to use __add__() and __mul__() because then, the notations obj1 + obj2 or obj1 * obj2, even if shorter, can be confusing, letting the reader think something numerical is being calculated there, instead of the simple creation of an object. So the two functions should be simple return Sum([self, arg]) and return Product([self, arg]) and implemented in a Class like Basic or Calculable. There's no need to code more than that. So (almost ?) all other __add__() and __mul__() and times() and plus() functions should be deleted. This change is still to be done.

Decided to delay #49 to next release.

New :

- 49bis : reorganize the Machine class and Machine's subclasses so as to become totally independent from LaTeX format and welcome other formats easily.
- 53 : (ex-#49) create a new algebra sheet (replace a variable by a given value)

Still to do :

- 37, #49bis + the current new factorization sheet and #50.

**2009/01/18** :
Working further on the new factorization sheet.
Beginning to re-think the roles of plus(), times(), __add__() and __mul__() methods. The __add__() and __mul__() were thought to be used in cases the result is needed, like Item(1) + Item(2) whould return Item(3) ; whereas plus() and times() were thought to be used only to create Sums and Products, like Item(1).plus(Item(2)) would return Sum([Item(1), Item(2)]). So far, the __add__() and __mul__() methods are useless. The aim of mathmaker is not to compute anything rapidly, it will always create the different steps to the solution like a human being would. So, I'm trying to get rid of useless methods.

**2009/01/14** :
Working on another factorization sheet

**2009/01/10** :
Added a factorization sheet and a factorization exercise in the algebra short test sheet.

**2008/11/05** :
Done :

- #47
- #48

Still to do :

- #37, #49, #50

For next release : #51 & #52

**2008/11/04** :
Done :

- #32 It's really difficult to have at the same time irreductible fractions and not too simple calculation. So, I let it like it is now, it's not too bad but can be improved.

**2008/11/03** :
New :

- #51 Strange behaviour when adding the simplification of fractions in the case of randomly chosen num & deno in the product and quotient sheet of fractions. Have to inquire it...
- #52 Check if uniting AlgebraExpressionExpansion & AlgebraExpressionReduction in one question/Algebra.py and exercise/Algebra.py is possible (maybe not because of the different results outputs)

Done :

- #46 this is "coprime", correction done
- #42

Still working on #32. It's hard to get various interesting results, not too complicated, not too simple. 11 comes much too often for now ; sometimes an interesting simplification could be proposed but isn't and we get a "big" result (like 35/12 * 4/19 instead of * 4/5)

So, still to do :

- #32, #37, #47, #48, #49, #50, #51

**2008/11/02** :
Won't be done :

- #38 because maybe I already done this and I don't see what I can improve for now.

New :

- #46 Check the translation of "nombre premier avec..." in english
- #47 Turn all SpecialIdentities occurences in BinomialIdentities
- #48 Reorganize the names of the Sheets per category
- #49 If time enough, create a new algebra sheet (replace a variable by a given value)
- #50 Finalize the tests and release the new version !

Working on #32. Created a function returning randomly a number coprime to a given number, chosen in a given range. Still have to test it + in exercise/Calculation.py, to add the modifications to the creation of the fractions.

Still to do :

- #32, #37, #42, #46, #47, #48, #49, #50

**2008/10/26** :
New :

- #44 : equation -1 -4x = -9 doesn't solve correctly
- #45 : equation 3 + 10x = 10x resolves correctly but forgets to display that there's no solution.

Fixed :

- #43
- #44 : stupid bug, the neutral element of Polynomial was defined to Item(1) ! so now it's correct.
- #45 : a parenthesis was at a wrong place in the 11th Case test of solve_next of the Equations !

Still to do :

- #32, #37, #38, #42

**2008/10/25** :
New :

- #41 : fractions having a minus sign and without brackets although in second position of a Quotient (fraction ÷ fraction)
- #42 : don't forget to translate the "Sum of fractions" in french before releasing
- #43 : a squared product followed by a positive term prevents this next positive term to display its '+' sign. Check it with the Sum : [<{3}>^2, {5}]

Fixed & done :

- #26
- #30 : lowered the frequency of high denominators ; adjusted the level of "-" signs
- #41

Working on #43 Still to do :

- #32, #37, #38, #42, #43

**2008/09/21** :
Working on #30. Maybe still put a lower probability of getting high seed numbers. Don't forget to check the other sheets pdf results.

**2008/08/06** :
Fixed :

- #40
- #39

Made a long test run (100×each sheet). The sheets need to be checked again (check the resulting pdf files). Next step when coming back from holidays : #30 & #32

Still to do :

- #26, #30, #32, #37, #38

**2008/08/05** :
New :

- #39 this : A=\frac{-3}{2}\times (-\frac{16}{3}) result in limitless frac 1 / 1 + check fraction 10/1 .calculate_next_step
- #40 IndexError: pop index out of range (from File "/home/nico/mathmaker/obj/calc/__init__.py", line 1972, in throw_away_the_neutrals). Made with the sheet fractions-product-and-quotient. try on E=\frac{14}{7}\times \frac{12}{12}

**2008/08/03** :
Finished correcting the bugs from #36

Fixed :

- #34
- #35
- #36

Still to do :

- #26, #30, #32, #37, #38

**2008/08/02** :
Still correcting the bugs from #36

**2008/07/26** :
Correcting the bugs from #36

**2008/07/25** :
Continuing on #34 & #36 : code reviewed & autotest phase (the changes engenders lots of failed tests in autotest, probably because the deep_copy makes some == tests return False instead of True, before...)

**2008/07/24** :
Doing #36 & #34

**2008/07/23** :
new :

- #31 quite a bug ! calculating a Product like 5/4 × 5/5 gives 1/4 as a result instead of 5/4 !
- #32 improve the choice of numerator & denominator in the case of fractions products|quotients
- #33 create Number_value, Integer_value & String_value classes ? this would allow #34 easier.
- #34 improve all constructors by making a DEEP copy of the objects (required to fix #35)
- #35 solve the bug "* When reducing a Product like 9/(-2) × (-8)/10, avoid the useless step 36/10"
- #36 implement the Operation class and factorize all Product & Sums problems
- #37 rewrite the Equation.solve_next() method ! which is a mess !
- #38 simplify the code thanks to #33 (required) new feature (and get rid of is_.py \[it finally doesn't look possible\])

fixed :

- #31
- #33 (creation of a Value class embedding strings & numbers)

still to do :

- #26, #30, #32, #34 - #38

**2008/07/22** :
new :

- #29 adding -18/5 - 2/5 produces the same line twice
- #30 improve the choice of denominators in the case of fractions addition

fixed :

- #27
- #29
- #28

still to do :

- #26 & #30

**2008/07/17** :
Implementing the "Sums of fractions" worksheet. Testing the algorithm.
new :

- #26 check the presentation of other sheets (especially the products & quotients of fractions) because a new_line had to be deleted in the sheet's Structure.
- #27 in the case of 25/10 + 1/10, improve the algorithm to let the computer directly add the two fractions without trying to simplify 25/10 first ! check source : obj/calc/__init__.py:3939
- #28 idem #27 but more complicated like 4 + 25/10 - 7 + 1/10

**2008/07/14** :
Improved the algorithm, it works on the first general tests.

**2008/07/13** :
Wrote the first version of the algorithm to get the calculation steps of a sum of fractions.
Still to be improved...

**2008/07/09** :
Begining to write code to get the calculation steps of a sum of fractions.

**2008/05/21** :
fixed|done :

- #25
- Harder equations sheet (with expandable Products)
- Equations short test

won't be done :

- #21 because Sums are created, not only an Expandable. maybe move that to Sum.__init__() ? moved some other things to Expandable.__init__() though.

**2008/05/20** :
new bugs :

- #24 resolving the equation 19+3x=2x causes a freeze of mathmaker
- #25 resolving the equation 5x=(2-5x)-2 causes File "mathmaker/obj/__init__.py", line 610, in resolve_next_step ------ return new_eq.resolve_next_step() ------ File "mathmaker/obj/__init__.py", line 843, in resolve_next_step ------ new_eq.right_hand_side.get_sign()]), ------ AttributeError: 'Product' object has no attribute 'get_sign'

fixed | done :

- done #22
- fixed #24

still to do !

- #21
- couldn't reproduce #23 ! maybe the computer was too hot ?
- #25 although it has been understood : the structure of the step 5x = -5x is such (product = another product) that it isn't recognised in the 6th case but improperly in the 7th case (which causes the error later). work to do is still to write the patch for that.

**2008/05/18** :
Fixed some bugs

- one preventing remove() from Product to raise an exception when not finding the researched factor
- one turning the Item to None objects when resolving an Equation (expand_and_reduce_next_step() returns None from an Item but in an Equation, the Item doesn't have to be replaced by None)
- some others...

Still to fix :

- #23 one of these two Equations cause mathmaker to stick somewhere $ (E_{2}): -x-2x+7=(7x+5) $\newline OR $ (E_{3}): 9x+9(-4-x)=8 $\newline actually most probably the second one because it leads to -36 = 8 or something like that

**2008/05/12** :
Tested AlgebraBalance01, corrected some bugs, beginning to create EquationsHarder sheet.
New bugs :

- #18 brackets displayed around Quotient - (+1/+2)div(+1/+3)
- #19 -(2x+9)(-3x-7)+4(-3x+9)+13 cause the following bug : File "mathmaker/obj/calc/__init__.py", line 3693, in remove ------ self.display_complete_writing.pop(i) ------ IndexError: pop index out of range
- #20 4x+x-2-2x^{2} cause : File "mathmaker/obj/calc/__init__.py", line 3917, in expand_and_reduce_next_step ------ copy.display_complete_writing[i]) ------ IndexError: list index out of range

To do :

- #21 move the sign expansion expressions creation to the __init__() of Expandable (like other creations)
- #22 develop the Equation.resolve_one_step() method further to let it manage Expandables correctly (debug to check where it fails for now...)

Fixed :

- fixed #15
- fixed #18
- fixed #17
- done #16
- fixed #19
- fixed #20

**2008/05/10** :
New bugs :

- #13 0x is displayed without any sign before, which produces false lines like in -2 -x + 8x² + x (the third line shoudn't be -20x + 8x² but -2 + 0x + 8x²)
- #14 -15 + (10 + 14x - 10x²) displays a line twice (can't reproduce this one... ? / finally reproduced...)
- #15 calculation of -1/2 ÷ 1/3 stops at -{1×3}over{2×1} (probably because it finds that this last step is not a simplifiable fraction...

New improvements :

- #16 complete the translation in french
- #17 in exercise 2 of the special-identity-expansion sheet, the answers are created using (a+b)² = a² + 2ab + b² instead of (a-b)² = a² - 2ab + b² and this error isn't done in the exercise 4 with the same kind of expression... check how the expressions are created

Fixed :

- fixed #9
- fixed #10
- fixed #11
- fixed #12
- fixed #13
- fixed #14

**2008/05/09** :

- Finished algebraic expansion & reduction "balance sheet" level 1 (without Binomial Identities)
- Improved the sheet/exercise/Model.py & Structure.py files and reshaped the exercise.ExpressionReduction and exercise.ExpressionExpansion classes
- reorganized the Equations sheets/exercises/questions

Still to fix :

- #9

New problem :

- #10 expand_and_reduce a special identity like (1+10x)(1-10x) displays the last line twice + displays a 1² at the end !!!

Improvements to do :

- #11 in the case of ±(2x + x³ - x), expand the ± sign first so the next line is (if sign was -) -2x -x³ + x instead of ±((2-1)x + x³) {NB general case is ±(sum) (whose exponent is equivalent to a single 1) and excludes ±(other expandable) }
- #12 reduce the amount of needed steps in the expansion and reduction of -11(5x-10) + (10x+3)(6x-5) + 14

**2008/05/08** :

- fixed #8

**2008/05/08** :
Implementing the first algebra balance sheet.
Adding a -(2x + 7) + (x + 3) reducing feature.
Problems :

- #8 when reducing 4x + (-15x + 8 - 5x), 4x - 20x + 8 is repeated twice
- #9 expand_and_reduce a special identity like (3+3x)(3-3x) displays the last line twice

**2008/05/07** :

- checked #7
- fixed #1

**2008/05/06** :

- fixed #5
- fixed #2
- fixed #6
- fixed #4
- fixed #3
- still to be checked|done : #1 & #7

**2008/05/06** :
Still to fix|do :

- #5 check the @todo at numeric_terms_require_to_be_reduced() (Sum class)
- #6 product 3 × (-x) (in a Sum ?) seems not to be checked as reducible
- #7 check if -30 + 80 + x² is well expand_and_reduce_next_step()'ed

**2008/05/05** :

- found and fixed a bug giving a positive result from "-\frac{9\times 3}{3\times 1}"

**2008/05/02** :

- concatenation of the different *reduction sheets done
- but problems appeared related to expand_and_reduce_next_step() and related methods.

still to fix :

- #1 in the reduction training sheet, if an expression given to reduce is not reducible, write that it isn't reducible (instead of doing nothing)
- #2 case of -2×(-6) - 1 + 3 × (-x) - 8x × (-3) : 12 - 1 - 3x + 24x should be reduced in 11 + (-3 + 24)x instead of 11 - 3x + 24x
- #3 case of 5x + 7x × 8x + 5x × (-1) + 7×8 displays a 0x at the end !!
- #4 too many newlines (after the texts)

**2008/04/23** :

- (fixed later) expand() of the class Expandable : problem (suspected) of imbricated Sums preventing the Expandable -(...) to get expanded (see autotest)

**2008/04/08** :

- expand_and_reduce_next_step() of the class Sum