-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
197 lines (179 loc) · 8.95 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
In order:
* BEFORE ADVERTISING IT TO THE PUBLIC:
** move all initialization code in modules into functions
(that is for code like downloading currency data) [done]
*** currently still automatically called when importing psciclib
** call that code when starting the UI (and when running tests,
although with download disabled!)
** make the currency download optional and ask the user (data
protection and privacy reasons)
*** ship a .xml file, so that the currency at least exists?
*** when the currency data is out of date, show a hint which
gives you the options: a) auto-download data, b) update data now,
c) ignore this hint forever. That way we don't need a modal dialog
or something when the user first starts the app. If the user never
converts currencies, they never have to deal with that stuff. And
if they do care, they will have to deal with it at the exact
moment they care about it with one click.
** the above needs a config file and preference dialog
** busy-cursor! [done]
*** perhaps a way to cancel long-running calcs!
* actually implement different printing styles for floats (norm, sci,
eng, time, ...)
** norm: as now
** sci: 1.233e5
** eng: 123.3e3
** simple: 123300 (even if precision for the last places is not given!
perhaps warn in that case)
** time: see below, basically 12days 03:12:13
or 12days 3h 12min 13s (better?)
* Instead of copy-paste mode:
** When marking (and/or ctrl-c-ing) actually copy the appropriate
signs and parentheses that were omitted! I think Qt5 can do it.
Do it in ASCII-mode if possible?
This would mean copy-paste works automagically!
Perhaps needs a switch for ^/** as this is the most annoying and
frequent issue that will come up (see next point)!
* quick buttons:
** see quickbuttons-overhaul.png (image for "as-is" should be the green
one, for "best" the engineeringy one, for "base" something sciency
dunno yet)
** show current mode also in modeline (as-is: "", best: "BEST", base: "BASE")
** perhaps remove "RAD" from the modeline.
* Roman numerals:
** perhaps do not give an error if impossible to convert, but just
leave at default output...
** nicer literals for roman numerals
*** r{IV} / roman{MMLXI}
*** can't think of something nicer and it works for other weird input
formats, too. Can also do 0xFF = x{FF}, 0o455 = o{455}, and
0b1001 = b{1001} then (although the 0xFF thing stays canonical).
** there is unicode for extended roman numerals (> 5000), perhaps use that???
* improve startup time:
https://files.bemusement.org/talks/OSDC2008-FastPython/
* support functions
** write tests!!!!
** also "negative" tests, where we expect failure
* solving:
** if we can't solve analytically, try to solve numerically! [DONE]
*** needs input of the starting value x0 (a simple field that reads
reals, complex numbers, an some constants)
*** needs to deal with units.
*** If (seemingly) unsolvable, still provide the x0 field, as the
algorithm might have more luck from another starting point.
This is for example the case for sin(x) = exp(x), where starting
from 1.0 does not converge, while starting from -3 finds a root!
* SYMPY may be the solution to a lot of stuff, it uses mpmath and can be exact.
Just need to get it to play nice with pint
** mostly DONE
** DOES NOT YET PLAY NICE WITH UNITS! sympy unit support is not up to
scratch with regard to pint, so we need to hammer those together
ourselves!
*** solving equalities with units is icky. often the solution
seems OK, but is not evaluated!
*** Also missing: unit conversion for solutions.
** assumptions for x would be nice!
** using <expr>.atoms(sympy.Symbol), we can find all variables in an
expression. This may be of some use for the solver/plotter, e.g.,
if both x and y are in there, plot 3D.
** float-precision on parsing should match what the user put in! No
loss until pretty-printing!
*** this works, but the precision should be at least equal to what is
requested in the output! Better higher!
*** for a (not-so-nice, but workable) solution, see
operators.process_float's TODO comment!
*** float-precision doesn't work nicely with pint which uses python
floats :-( No idea yet on how to fix this :-( Need to make a
string roundtrip when dealing with this, perhaps a sympy.Float
subclass can help
*** !!! In the end, all floats need the same precision when doing
calculations !!! The test-suite must then be adapted to check
for _exact_ float equality in the cases where we can require
it (negation; noops, like the unary +; addition?; ...)
*** So: actually use output precision + 10 for calculations (+10
configurable, test it) and then change to the actual precision
when printing. Maybe best compromise between speed and accuracy?
Test this against the current scheme of just using precision=100
in terms of accuracy and speed!
* support constants (a bunch of letters instead of numbers)
** physical constants are still missing
** write tests!
* support units [should work in general, see below]
** temperature (non-K) may be harder to get right in a nice way
(semantics are not always clear).
*** make °C / °F special syntax that immediately converts to kelvin
*** write a warning, because the semantics of 12°C+1°C are not clear!
*** make extra units (degC/degF) that are temperature differences and
are converted to ΔK (no offset); also warn about this because it is
not intuitive!
*** The warning stuff can be implemented by passing a "Hint" object around
when evaluating the expression. The return value will then be a tuple
of the actual results plus some informational data that can be displayed
to the user
** Parse multiplied units like Js = J*s; this may be ambiguous! Be careful!
** get a list of all supported unit strings: ureg._units.keys()
** some short units are bad special case them:
*** h is planck, not hour (that should maybe be a user option, given
that h for planck makes sense and I have gradually gotten used to
hr for hour); perhaps make a hint when using "h": this hint should
contain a button to disable this hint in the future.
*** pt is pint not point
*** ...
** optionally(?) auto-apply prefixes (1200m -> 1.2km)
** 12 km/m does not yet give 12000 and 1 in/cm does not auto-resolve
to dimensionless
** a "time" output format (besides scientific, engineering, ...) which
will use prefixes for values smaller than 1s, otherwise it will use
HH:MM:SS.ss for times < 24h.
At times greater 24h it will prepend the number of days, weeks+days,
years+weeks+days. (think if months make sense, but they are so
ill-defined) years will be 365 days in this format to make nice even
numbers.
*** maybe also parse something like that as input.
** In the end, the precision for pint (64bit float) is not satisfactory,
and rolling my own unit support is probably preferable in the long run.
At least that gives full control.
** units that are words should have plurals. limitation of pint: it
parses, e.g., "2 days" but outputs "2 day".
* hints:
** when they are disabled by the user, still expose a preference to
enable them again!
* a ° postfix operator, which converts to radians
* support plots
** plot expressions with variables in them (2D plots only for now), auto(?)
** plot lhs and rhs of equations as input, not auto(?)
* GUI
** a panel which shows stored custom variables for the session (also one
should have the ability to define their own variables/functions)
** variables for past answers (history):
ans - last answer
ans1, ans2, ans3 - past answers, numbered in order
ans1.1 - for solutions and similar, reference a specific solution
*** a solution for the command line would be nice, too! Easy to print
these things before the answer even!
** a unit/constant/function/symbol selector (instead of a keypad-thingy)
** document every function, unit, symbol, variable and (optionally) show
this somewhere.
** to best units / to base units should be toggle-buttons (mutually
exclusive!)
* support variables (x,y,z only perhaps?) [sympy does all the work]
** calculate everything except them [sympy]
** really useful when introducing the = sign, to solve a Dreisatz etc.
*** needs to auto-solve for equalities (and inequalities) [equalities done]
*** if we introduce y/z, always auto-solve for x! the others are just
used as placeholders
** auto-plot, see above
* matrices/vectors
** parsing is done
** sympy can handle it
** but: there are no vectors, only row matrices
this is not user-friendly, as we need to transpose those sometimes
so: auto-transpose them on evaluation!
** this has the problem, that we may want to do [u;v;w] * [x,y,z] which is
[ux, uy, uz; vx, vy, vz; wx, wy, wz]. so maybe only auto-transpose
[u,v,w] * [x,y,z]-style! When the user explicitly uses ";" they know
what they are doing! Document this, of course!
** needs more support and error checking
* test:
** fuzzer: create random valid and invalid expression en masse and try
to parse/evaluate them