/
TODO
212 lines (133 loc) · 5.07 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
=====================
may 2015
presentation issue
diff(3x^2 * 2^(3x), x)
it doesnt clean up the e^( .. * ln(2) * ...) i bnthe final output.
========================
May 2015.
there's a new bug in the GUI edition!
x * arctan(x) - 1/2log(x^2 + 1)
hangs.
might uncover a family of bugs by cracking this one though
*** FIXED in 77dda1b3f7e837c0946f64d0bfcf708f9e4559e7
----------------------------------------------------------------------
Tue, May 13, 2014 at 4:34 AM
"I have just installed your app which is really good, but it didn't
solve the equations till the end. Example : cos(x)^2 + sin(x)^2 which
is simply equals to 1, but as your app try to solve it too which I
think is good should conclude with zero as it is not. I think you also
have to focus on arithmetic part of it."
---
I will probably just have to change the code so that negative signs
get moved to numbers. Differentiating "cos(x)^2+sin(x)^2" gives
"cos(x) * (2 * -sin(x) + 2 * sin(x))" as final result, but "cos(x)
(2sin(x) +-2*sin(x))" (with the sign moved) successfully simplifies
to 0.
DONE 2014-06-07
=====================================================================
Thu, May 22, 2014 at 11:48 AM
"lnx" (for "ln(x)") syntax expected, assumed and desired
support for e.g. sin^2(x) would also be nice
the grammar/parser would have to be reworked, perhaps something
like this:
expr := ...
| known_function [ '^' expr ] mul_expr
known_function := 'sin'
| 'cos'
| ...
The lexical analyser would also need to be adapted, so
it could deal with crazy typing like "lnx"
a separate pass using a trie to split function names out
then the tokenizer would use an identifiers table like in wannabe cc
then the parser would know about this crazy syntax and build the
AST's correctly
lnx
| shorthands.c
V
ln x
| tokenizer.c
V
TOK_KNOWNFUNC: ln
TOK_IDENT: x
| parser.c
V
(FUNC:ln
(VARIABLE:x))
lnx -> ln(x)
ln^2(x) -> ln(x)^2
goddamn it why don't people properly format their fucking inputs already
all this bullshit
=====================================================================
bug in CLI version: [FIXED; added to sanitychecks.txt]
diff((5*x^3 + 4*x^2) / (e^x + cos(x) * 3*x^2), x)
====================================================================
Fall 2015.
A customer in the United States complains that it can't do implict
differentiations. Which can be thought largely as an instance of
equation solving. Peter Norvig's PAIP shows a data-driven approach
where a small set of metalinguistic equations can be used to accomplish
general-purpose solving of simple algebraic equations. This can be
investigated in the future I presume.
PAIP also indicates that there are limits to rule/data-driven approaches
to symbolic algebra. Which is already being accounted for here with the
optimize.c stuff which is written in C. ;-)
Another nice thing to have which MAPLE has is to be able to backsubstitue
the last expression into a new one. So we could have something like this:
]=> diff(x^x, x)
x ^ x * (1 + log(x))
]=> diff(??, x)
x ^ (x - 1) + x ^ x * (1 + log(x)) ^ 2
The appropriate symbol could be, say, ?? or %% or something of that
nature.
Update: the tokenizer has an entry for ?? now.
Update: half-baked rule for ndiff written, doesnt work 100% with
interpreter yet
It is now working for some cases but not for some others, there is a sneaky
bug that has to be fixed somewhere... DONE 2016-01-02
This is a case that works
]=> ndiff(x^x, x, 3)
x ^ x * -1 / x ^ 2 + 2 * (1 + log(x)) * x ^ (x - 1)
+ x ^ (x - 1) * (1 + log(x)) + (1 + log(x)) ^ 3 * x ^ x
]=> ndiff(x^3, x, 3)
x ^ 2 * (-6 / x ^ 2 + 12 / x ^ 2)
This creates an interesting new case for simplifications!
(The foregoing should reduce down to 6 quite simply)
And by doing lots and lots of ndiff's I presume lots of candidates
for simplifications will arise
This way we can have easy N'th order differentiation.
Another nice operator would be something like this
]=> ndiff(x^x, x, 2)
x ^ (x - 1) + x ^ x * (1 + log(x)) ^ 2
To go with the foregoing of course.
]=> ndiff(x^3, x, 4)
x ^ 2 * (12 * x ^ -3 + -12 / x ^ 3 + -12 / x ^ 3 + 12 / x ^ 3)
That should cancel to zero... That's a pretty nasty one in fact..
Maybe we can have a rule to do
A*x^(#n < 0) = A/x^(n)
and then it would give
(12 * x ^ -3 + -12 / x ^ 3 + -12 / x ^ 3 + 12 / x ^ 3)
-> (12 / x^ 3 + -12 / x ^ 3 + -12 / x ^ 3 + 12 / x ^ 3)
which is correctly recognized as zero by current rules
Fixed 2016-01-05:
]=> ndiff(x^3, x, 4)
0
Some more weirdness
]=> ndiff(cos(3x^2), x, 3)
x * (6 / x * -6 * cos(3 * x ^ 2) * x + -6 * x * (cos(3 * x ^ 2) * 6 / x + -36 * sin(3 * x ^ 2) * x) + -6 * cos(3 * x ^ 2) * x * 6 / x)
]=> 6 / x * -6 * cos(3 * x ^ 2) * x
-36 * cos(3 * x ^ 2)
why doesn't it reduce it properly in the first case???
Maybe there is some ill-formed structure or something
yes
the pattern is:
(MULT
(DIV
(NUMBER:6)
(VARIABLE:x)
)
(NEGATIVE
(MULT
....
====================================================================
couldn't i use prufer codes to do some massive crazy exhuastive
testing ?