From 0.3 to 0.4
2012/10/04 : Decided to release the current version as 0.4
2012/05/01 : The two little things are done now. Wondering if the big change about private/public fields writing will be done for 0.4 or only for 0.5 (after september 2012).
2012/04/30 : Improved the presentation again (exercises' texts printed twice separated by a dashed line ; underlined results). Two little things to achieve : 1. choose randomly if the number must be rounded in question a. or b. && 2. take care where the autotest will put the euk & eps files (maybe use a path for graphic files, defined in mathmaker.cfg ?) One big thing, before releasing 0.4 ? : 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).
2012/04/29 : Worked and corrected the most important part of the new sheet. Looks quite nice. Some details still to decide (underline the last result, print the subject twice because there is still some place left on the first page etc.).
2012/04/26 : Corrected some latex stuff (unexpected newline ; display text in maths formula correctly...)
2012/04/25 : Worked on this normalize() result problem. Finally found the solution in the python doc...
2012/04/24 : Testing and debugging the new sheet... A kind of annoying bug : decimal.normalize() turns 10 in 1E+1, 40 in 4E+1, 100 in 1E+2 etc. and this leads to problems of compilation by euktoeps. Have to check decimal.normalize()'s result and substitute these E+x by x zeros (simple string manipulation). [alternative : i was advised on irc to try this : if isinstance(Decimal('10.1').to_integral_value(), (int, long)): print "%d", thedecimal; else: print "%f"] [OR print "%s" % 10.1, print "%s" % 10] There is still some work to do on the presentation of the sheet's text and answers... just check the examples !
2012/04/23 : Wrote machine.LaTeX.insert_picture() and used it in Q_RightTriangle.text_to_str() and Q_RightTriangle.answer_to_str(). Created the X_RightTriangle class and the PythagoreanTheoremShortTest sheet. Everything seems ready to be tested.
2012/04/22 : Finished the script. Worked with it but finally found a better solution. Took a long time ! So, finally finished to write Q_RightTriangle.__init__() (without much options with the units, but it is open), began to write text_to_str(). Have to complete core.geometry.RightTriangle.into_pic() to let it create the .eps file (with euk2eps...). Certainly have to add a method to create the string allowing to insert a picture... in the Machine ? (M.insert_picture(Drawable)) in order to put the picture in the text (or answer).
2012/04/20 : Only two small errors to correct and it works, mathmaker is able to create and resolve a pythagorean Equation from any RightTriangle knowing the lengths of two sides. Yu hu :o) Writing the first question using a RightTriangle and the pythagorean theorem. A difficulty is to be sure to create a triplet which is NOT a pythagorician triplet when desired (to be sure the result must be rounded). Writing a script to check if using a pythagorician triplet to create a triplet which is not pythagorician just adding a fixed number (for instance, 10) to the smallest leg is possible (or if there are pairs of triplets that differ exactly from that number... which would be sad...)
2012/04/18 : Wrote the portion of core.calculus.Equation.__init__() method to take a SubstitutableEquality to create an Equation. Next step : test it !
2012/04/09 : Changed the type of label in Segments (using Values). Added the unit directly as a field of a Value, displayable only on demand (option : display_unit='yes' in into_str()). Modified the Segment and RightTriangle classes consequently. Also made MARKUP a global. It is useless and boring to have to pass it as an option or argument from time to time. Now it's more practical. Especially the method 'into_str()' doesn't need it anymore. Began to write RightTriangle.pythagorean_equality() Tested the first pythagorean SubstitutableEquality created from a right triangle :o) Still have to check and certainly debug the substitution process till the creation of the Equation !
2012/04/08 : Working on... Made all Calculables iterables. Should have done this since the begining... Don't forget that the iteration has nothing to do with the length of the Calculable. It will iter over all elements including the exponent, which isn't taken into account as the rest in many display algorithms. This change broke the core a little bit, had to repair it. Finished to write the required methods to be able to substitute numeric Values to literal ones in any Calculable and SubstitutableEquality. Check if it works ! Write core.geometry.RightTriangle.pythagorean_equality() and core.geometry.RightTriangle.pythagorean_equation() and check them... don't forget to turn a substituted SubstitutableEquality (having only 2 elements : ... = ...) into an Equation when all but one literal Values have been substituted (maybe use a field in SubstitutableEquality and check how to transform such an object into an Equation... this doesn't seem complicated).
2012/04/05 : Finished working on the transformation of the global core structure of mathmaker. Creating SubstitutableEquality in core.calculus ; began to rewrite the __init__() method. Writing the method to check if a given substitution dictionnary matches the given SubstitutableEquality
2012/04/04 : Finished to check the right triangle tests. Added a .normalize() to some Decimals to have integer-like displays (7 instead of 7.0 for instance). Transforming the global core structure of mathmaker...
2012/03/27 : Hunting the last bug discovered. Seems to be corrected. Didn't introduce any weird behaviour in the current series of tests, so it should be OK. Finish this by validating the result in autotest-mathmaker (so far it expects "", just fill it with the right answer)
2012/03/21 : Made it impossible to have a binomial identity like (-3-4x)² (double minus sign doesn't make sense to train pupils... makes the thing uselessly too complicated). Hunting another displaying bug. Reproduced in autotest-mathmaker -u expansion_and_reduction_test -V (check the 2d line : there's a "+" missing)
2012/02/29 : Hunting the bug ! Done ! Back on #55 Generated the pythagorician triplets.
2012/02/28 : Working on a new sheet (algebra mini-test : 2 expansions, 2 factorizations)
New : bug : problem in this first line : $C=(6+x)^{2}12(2+11x)$\newline $C=6^{2}+2\times 6\times x+x^{2}+12\times 2+12\times 11x$\newline $C=36+12x+x^{2}+24+132x$\newline $C=36+24+(12+132)x+x^{2}$\newline $C=60+144x+x^{2}$\newline Reproduced in autotest-mathmaker (sums)
Next time : hunt this bug !!
2012/02/27 : Working on #55 Thinking about the first question related to pythagorean equations. Need to write some pythagorician triplets either.
2012/02/26 : Working on #55 Wrote the into_pic() method
2012/02/25 : Working on #55 Added the computing of a rotated RightTriangle (computed the box... had to change the produced euk because the rotation command doesn't provide the exact rotation, it's translated somehow ; well successfully tested the result in four cases).
2012/02/24 : Working on #55 Wrote a first attempt of into_euk(), tested it, corrected some syntax errors and small structural errors Successfully tested the first RightTriangle with 3 labels on right positions (computed). :)
2012/02/23 : Working on #55 Tests on the position and angle of the label of leg1 Determined that the function giving the scale factor according to the length (x) of the side is just 1.6*x and the function giving the angle can be : for 1 <= x <= 3 : 8x - 33 for 3 <= x : -1.1/(1-0.95ℯ^(-0.027 x))
2012/02/20 : Working on #55 Tests on the position and angle of the label of leg1 New : #55' : think to check euktoeps at the beginning : if it's here, and the version number
Next to do/finish : #55 & 55', #57, #E', #NR1, #NR2, #NR3, #?1[structural], #?2[structural]
2012/02/18 : Working on #55 Trying to build a model of right_triangle.euk that compiles well. After some hours of searching, finally I found the right call of euktoeps (version 1.5.4) to have extra LaTeX packages + the eukleides specific directives : BUT THIS IS ONLY A BUG FIX, IT MAY LEAD TO SMTH NOT WORKING WHEN THE BUG IS CORRECTED euktoeps --include="\usepackage{eukleides, graphicx}" file.euk This works with the file : box -3, -3, 7, 7
A B C right 4, 6
G=isobarycenter(A.B.C)
A'=rotation(A, G, 30 deg) B'=rotation(B, G, 30 deg) C'=rotation(C, G, 30 deg)
draw
(A'.B'.C') G cross "$\rotatebox{30}{4cm}$" A' 30 - 7 deg 7end
label
A', B', C' right A' 30 + 200 deg B' 30 - 45 deg C' 30 + 65 deg G 0 degend
Now, still to find the way to work out the box dimensions to fit the picture (in the case of a rotation angle especially !! this will be done by computing the coordinates of the 3 vertices of the triangle) ; and to work out the scale factor for the segment label (some tests to do yet) ; in the rotatebox, found out that the written angle should be (in python) : alpha < 90 ? alpha | alpha + 180 Wrote RightTriangle.into_euk() but still to write : the rotatebox part. I think all necessary fields are already defined in init() at least for the simple case I want to test in right_triangle_test.py Once the rotatebox part is written, test the output of into_euk() with autotest-mathmaker !!!
2012/02/17 : Working on #55 Creating the fields for the right triangle... added a segment class and an angle class. Thought that these geo objects won't be used to draw, so maybe let them be only printables ? Or just objects ? Well finally, I need to be able to copy them deeply, so I added a class at the top of the hierarchy which just implements deep_copy() and from which all other objects I use do inherit. So, Point & Segment are just Copiables now. Tested further the new eukleides syntax.
2012/02/16 : Changed the str that are used to write debugging versions of the objects to dbg_str(). Maybe here and there it will cause some errors when raising an error or when debugging ; which can be corrected later when necessary, no problem. Also want to change the into_str() in a simple str()... problem is, into_str() requires an argument that str() doesn't have (and it's not possible to let it accept one argument apparently). Well this may be done, but it requires to transform the many possible options in into_str() as fields of the objects that would be set just before the call of str would be done. I keep this for later, I'm tired of these many structural improvements. Don't find them especially urgent neither. Also another idea : numeric Items and literal Items should be two classes inheriting from Item : NumericItem and LiteralItem. They should just reimplement some methods, not all... and the Item would become abstract itself. (Maybe use a 'derived' trick to factorize the factorizable code of Item.init()
New : #?1[structural] turn the into_str() in str() New : #?2[structural] NumericItem and LiteralItem
Now back to #55 Well had to compile gs to have it work... tested the new eukleides syntax. Made a kind of model .euk file for a right triangle. Thought about the RightTriangle init possibilities ; wrote a simple Point class too.
Next to do/finish :
- 55, #57, #E',
- NR1, #NR2, #NR3,
- ?1[structural], #?2[structural]