Home page Features Examples User documentation Contribute Contributors & acknowledgments

Current development

Currently being developed...

2014/01/21 : Moved back to the _fields instead of __fields. Changed all '== None' into 'is None' Finished the work with Product and Sum Next time, go on with Monomial !

2014/01/20 : I think the problem comes from the fact that fields are quite "too" private. If one initializes an object with it mother's class init method, the fields will disappear... very strange ! Don't forget to put all debugging print statements away ; check : nico@ometeotl:~$ cd mathmaker_dev/ nico@ometeotl:~/mathmaker_dev$ grep -Rn "print"

well, this __ thing just does not work as I want to, so going back

other thing : == None should be written : is None

2014/01/19 : Changing all the ._fields in .__fields, letter by letter (see doc on desktop) sed -i 's/\._c/.__c/g' */*.py */*/*.py */*/*/*.py */*/*/*/*.py

for compact_display, weirdly this creates a problem : sed -i 's/\._compact_display/.__compact_display */*.py */*/*.py */*/*/*.py */*/*/*/*.py

currently exploring it

fields that are still to be changed : grep -Rn "\.\_[^_]" *

2014/01/14 : Finished with Operation, Quotient, Fraction ; next time : CommutativeOperation, Sum, Product etc. List of core code to factorize :

  • Quotient.get_iteration_list() should be merged with Operation.get_iteration_list()
  • Quotient.evaluate() and CommutativeOperation.evaluate() should be common and written in Operation class (/!\ the 'sign' of CommutativeOperation is different from the one of other objects)
  • SquareRoot should be entirely rewritten reusing mostly the code of Function instead of its own (probably lot of things to factorize). First, write the code for Function, of course !

2014/01/13 : Reorganized the structure a little bit. Working on Operation, CommutativeOperation, Quotient (Factorizing code) Decided FunctionalItems will be replaced by Functions Trying to remove get_iteration_list() from Quotient (to use the one of Operation) but it is not simple because Fractions have their own init(), a little bit separated from the one of Quotient. So, see how all of this matches... (Maybe also unify the evaluate() of Quotient and of CommutativeOperation in Operation class)

2014/01/12 : Working on Item Note : will have to change SquareRoots, certainly On one side, there are used as Item with sqrt on them : these objects are only kind of "SquareRootItems" ; which could inherit from FunctionnalItems ; on another side I had planned to be able to write SquareRoots of Calculables not only Items. So they should inherit from a more general "Function" object. (which is not FunctionnalItem). But the Function object could share things with FunctionnalItems too. So... maybe there should be only a genral Function object, which would embrace everything : FunctionnalItems should not exist then at all ?

2014/01/11 : Job done with Value

2014/01/07 : Keeping on the work on Value. Next step, the unit field

2014/01/06 : Began changing Value.value field in ._raw_value, plus the associated getter and property. Maybe will have to create a matching setter. Already have put away all occurences in root_calculus.py Check this to go further : nico@ometeotl:~/mathmaker_dev$ grep -Rn "\.value" */*.py */*/*.py */*/*/*.py */*/*/*/*.py and check the comment on previous day (01/05) + change the inheritance of Drawable to Copiable instead of Printable (later, check if it works) + rename base_geometry.py into root_geometry.py, then geometry.py into base_geometry.py ; the future geometry.py should contain "composed" objects which would use several simple objects (RightTriangles, InterceptionsTheoremFigures etc.) ; base.py should be renamed root.py

2014/01/05 : Working on the Value class. Changed all get_letter() methods in get_first_letter(), which makes more sense In some cases for Values, the method get_raw_value() should be used instead ; or its associated property raw_value ; and the get_first_letter() rewritten. So, now, want to create this raw_value field. Difficulty is, Items have a value_object field already, so I can't rename all .value into .raw_value... Also have to give Value real methods for their sign, so that it is possible to consider them as Signed Finally, have to relocate is_positive() and is_negative() of Items in Signed class. Only the Value and the Monomial classes have reimplemented this methods. Maybe Operation too ? (not sure at all...)

2014/01/04 : Finished splitting base_calculus.py in two files (root_calculus.py & base_calculus.py) Have to check the classes of root_calculus.py : add a def get_iteration_list() in Calculable (raising error "method should be reimplemented..."") Have to rewrite the classes of these two files to finish enhance the code (private fields as properties...) beginning with Value and Item Maybe check again if it is possible to factorize the is_displ_as_a_single_neutral() code... At the end, make massive tests on mathmaker (long test runs ?)

2014/01/03 : Added the git repo in sourceforge At the moment, reorganizing the code of base_calculus.py Splitting it into two files, one for the 'lowest' classes, which I called root_calculus.py and the other one for usable elements, still called base_calculus.py Thinking about the problems it engenders... and especially about the is_equivalent_to_a_single_neutral, which I don't know where to put because it uses Items... so not possible to let it in root_calculus.Displayable class... Maybe this remark could help : nico@ometeotl:~/mathmaker_dev$ grep -Rn "\.is_displ_as_a_single_neutral core/base_calculus.py:2792: if not elt.is_displ_as_a_single_neutral(neutral_elt): core/base_calculus.py:3069: if self.element[i].is_displ_as_a_single_neutral(self.neutral): core/base_calculus.py:3325: return self.is_displ_as_a_single_neutral(Item(1)) core/base_calculus.py:5211: return self.is_displ_as_a_single_neutral(Item(0)) maintenance/autotest/obj_test/calc_test/monomials_test.py:52: check(monom_1.is_displ_as_a_single_neutral(Item(0)), nico@ometeotl:~/mathmaker_dev$ (check where it is used... determine where the source code containing Item should appear...) Have to go on splitting the file... (NB Value class can go to root_calculus)

2013/12/28 : As it is complicated to develop further without enhancing the base_calculus.py code, I decide to do it now. #65 will have a pause in the meanwhile. functional_items_test will be aside for a little while. So, I have turned .exponent into ._exponent ; added the property in Exponented and the getter & setter. All classes that inherit of Exponented begin their __init__() with a call to Exponented.__init__(self) which initializes the self._exponent field to Value(1). All exponent setters and getters in other classes are useless (redundant) and have been erased. Done the same kind of work with the sign... and then have to do this with other fields... try to gather them (like, add Operation.__init__(self) calls in Sum, Product etc. __init__() methods)

2013/12/22 : Working on #65 Writing the __init__() of FunctionalItem ; not finished yet

2013/12/21 : Working on #65 Finished Table_UP class tests Beginning to work again on FunctionalItem. Next step : write its __init__()

2013/12/16 : Working on #65 Beginning the tests... There is still an error in the init (giving None among the data given to Table.__init__(self, data))

2013/12/15 : Working on #65 Rewrote the tests ; rewriting the __init__(). Next time, go on from line 2165

2013/12/14 : Working on #65 Wrote some tests for Table_UP class + began to write the class itself. Realizing I forgot the case of having a column being entirely unknown... so, have to modify the tests and the __init__()...

2013/12/13 : Working on #65 Finished the tests of the CrossProductEquation class. This is satisfying so far, I don't think there's a need for more than that. Next step : the Table_UP class !

2013/12/12 : Working on #65 Finished writing the CrossProductEquation class Began the tests, the first ones are fine. Still have to modify the Equation.solve_next_step() method to allow it to skip fractions simplification and to choose between fractional or decimal result according to given options. using "decimal_result" is fine

2013/12/09 : Working on #65 Beginning to write the CrossProductEquation class

2013/12/08 : Working on #65 Wrote the CrossProductEquation tests

2013/12/05 : Working on #65 Added the possibility to reduce completely a Fraction at once ; and the possibility to determine whether a Fraction is a decimal number or not (e.g. having a denominator equal to 2³×5⁸, for instance) Next step, create the class CrossProductEquation !

2013/12/04 : Working on #65 Adding the multiplication of Fraction(s) by Item(s) ; done in only simple cases (no negative Fraction, no exponented Fractions) Now, need to be able to have not decimal numbers evaluated as Fractions instead of rounded decimals + need to add a method to get the irreducible version of a Fraction immediatly

2013/11/25 : Working on #65 Bug corrected ! Was in Product.calculate_next_step() in the case of only one factor being an Item, where the sign was not set to '+' if the exponent was even. The last test in products_test doesn't work because the case of Item×Fraction hasn't been implemented yet in Product.calculate_next_step()

2013/11/25 : Working on #65 Debugging... the failing line is probably the 1769 (in Item.calculate_next_step()) although this should work. Check if this line is the one that's used and find why it doesn't work...

2013/11/24 : Working on #65 Debugging... [evaluate in Operation] current Operation is : < {-10^.1.} >^{.2.} [evaluate in Operation] exiting, returning evaluate() called on : {-100^.1.}

  • > the bug is in Product.calculate_next_step() called on < {-10^.1.} >^{.2.} returning {-100^.1.}

check what happens after line 4221 (where < {-10^.1.} >^{.2.} should be calculate_next_step'ed as {-100^.2.} and apparently this is not the case)

2013/11/17 : Working on #65 Adding the capacity to Table class to fill the Table with a coefficient. Added a new way to evaluate in Quotient.evaluate() and Operation.evaluate() which calls calculate_next_step() before evaluating. Causes a bug, see autotest. Solution is probably in Product.calculate_next_step() => certainly inside get_factors_list(), have to inquire it deeper with debug enabled and some debug_write() to add in it

2013/11/15 : Working on #65 Writing the Table_UP class.

2013/11/13 : Finished creating the tickets and milestones on sourceforge. Will keep this text file as a memo. Began writing the Table_UP class. Good night !

2013/11/11 : Working on #65 Checked that the outputs of sheets were different and had to correct the bug.

2013/11/07 : Working on #65 Written this piece of code. Need to autotest it and then need to check if the layouts of the sheets are still the same !

2013/11/05 : Working on #65 Beginning the tests, correcting some bugs. Only one test still fails : have to modify the way translator.create_table gets its arguments. Should be possible to use either p{} or c or l or r to center or left|right justify the columns. Maybe an option. Default value (without option) could be 'c'. Will need to modify machine.LaTeX.write_layout() either.

2013/10/29 : Working on #65 Finished writing the unit test and the related code for Table objects. Thinking about the Table_UP objects.

2013/10/16 : Working on #65

2013/10/11 : Working on #65

Still to do :

  1. 58[bug] (redundant lines when expanding/reducing a litteral expression)
  2. 59[structural] transform all basic_calculus & calculus classes like the geometric ones (with "private" fields, matching setters and getters and properties to see the "public readable" fields)
  3. 60[bug] Equation 4x = 11/60, gives out x = 11/60 ÷ 4 and stops there
  4. 63[core-dev] add a FunctionalItem object
  5. 64[core-dev] add the ability to Equations of resolving the cases of cross-multiplications (through a CrossProductEquation object)
  6. 65[core-dev] add objects related to proportionality (tables...)

NOT SURE to do these :

  1. ?1[structural] turn the into_str() in __str__()
  2. ?2[structural] NumericItem and LiteralItem

These have been actually done :

  1. NR1, #NR2, #NR3

2013/04/17 : Working on #63. Writing the dedicated unit test. Also have to think about a detail : change the "raw" \textdegree into MARKUP['textdegree']

2013/04/16 : Problem corrected. So #62 is well finished. Also wrote this maths_lib.round() function which allows to write much nicer code to round Decimals. Beginning with #63. Throwing the bases for a FunctionalItem. Many methods of Item must be reimplemented...

2013/04/15 : Finished #62 but a test on a scalene triangle showed that the labels for sides are not all fine placed. Certainly the origin of this problem is related to the fact that I developed the right triangles first (looks like the misplacement is using a right angle that is not there in the general case). Have to correct this, then. See line 481 of geometry.py

2013/04/14 : Working on #62. Almost done. Still have to add a rotated scalene Triangle with angles' labels at all vertices. Also think about a maths_lib.round function, which would call the utils.correct_normalize blablabla and all the stuff instead of doing this every time something must be rounded.

2013/04/06 : Working on #62 Next time : check autotest-mathmaker + t5.euk

2013/04/05 : Working on #62

2013/03/29 : Working on #62 Changed the tests on right triangles. Found something weird : the coordinates of the rotated points have changed and they look actually right although the previous did not !! Very strange... Now all tests are fine and mathmaker produces clean sheets. Also added the right tests to check if the angles can be marked well.

2013/03/27 : Working on #62 Base coding for it seems ok, next step : check if the code still works now with normal sheets (related to Pythagoras used so far) (use the right triangle tests ! that have to be slightly modified because the __init__() has changed), and then add the different tests to check if adding the angle marks / labels do work fine.

2013/03/26 : Working on #62

2013/03/25 : Done #61. Working on #62. Have to put most of the stuff of RightTriangle.__init__() into Triangle.__init__() and call it from RightTriangle.__init__() and then add in RightTriangle.__init__() only what is related to Right Triangles. Probably the best is to write the Triangle.__init__() from scratch and then adapt RightTriangle.__init__() Next step : check if it is possible to display a label of the angle (e.g. its measure), and how. Check it also in weird cases (very acute angles like angle P in ~/mamk_misc/essais/geo/triangles/t1bis.euk ; check how acute it could be and how far from the vertex the label can be placed ; its size also ?).

2013/03/24 : Working on #61

2013/03/01 : Still to do :

  1. 58[bug] (redundant lines when expanding/reducing a litteral expression)
  2. 59[structural] transform all basic_calculus & calculus classes like the geometric ones (with "private" fields, matching setters and getters and properties to see the "public readable" fields)
  3. 60[bug] Equation 4x = 11/60, gives out x = 11/60 ÷ 4 and stops there
  4. 61[core-dev] add an Angle object + Ray object
  5. 62[core-dev] add the ability to Triangles to display angle values
  6. 63[core-dev] add a FunctionalItem object
  7. 64[core-dev] add the ability to Equations of resolving the cases of cross-multiplications (through a CrossProductEquation object)

NOT SURE to do these :

  1. ?1[structural] turn the into_str() in __str__()
  2. ?2[structural] NumericItem and LiteralItem

These have been actually done :

  1. NR1, #NR2, #NR3

2013/02/28 : NEW BUG ! Discovered a new bug : when having Equation 4x = 11/60, gives out x = 11/60 ÷ 4 and stops there. Hope it will be possible to reproduce it.

2012/10/30 : Done with the contrapositive and converse of pythagorean theorem short test. Could be a 0.4.1 version From now on, working on the website to make mathmaker available on-line

2012/10/26 : Adding a contrapositive and converse of pythagorean theorem short test Creation of a Triangle Class ; RightTriangle will inherit of it ; RightTriangle will be used to display the triangles of the new sheet

SourceForge.net Logo