blob: f0a4ff6ad43cd871e5b2d378af6956bcc3340015 (
plain) (
blame)
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
|
# azimuth
a new computer algebra system
## goals
our first goal for azimuth is that it should be able to compute
the antiderivative of an arbitrary function at least as fast as
[rubi](https://rulebasedintegration.org/).
ideally, we should be able to do this faster and maybe (?) produce better
antiderivatives because:
- we are writing our own software (not just using mathematica)
- we are using a different technique that we hope produces better
antiderivatives (e-graphs)
- this will hopefully allow us to aggressively parallelize the process
where this provides performance benefits
## technical requirements
these are some rules we've outlined. they aren't intended to be general
software guidelines, they are strict because we feel they are achievable
given our scope.
- unnecessary serial computation is a bug
- if it can be done in parallel it should be if the overhead does not
outweigh the benefit
- unnecessary memory usage is a bug
- excessively slow computation is a bug
- any instance of a computation slower than any peer is a bug
- unclear code is a bug
- code should be readable by anyone familiar with the language and
the domain
- bad abstractions are a bug
- defined as:
- having more requirements than necessary to enclose their interface
- trying to hide away details that aren't all that well hidden or
make sense to hide
- not doing only one thing where this is a reasonable constraint
- unspecified pre/post-conditions or invariants are a bug
- undocumented code is a bug
- requiring more than `cargo build` to build in most circumstances is a bug
- crate dependencies other than `std`/`core`/`alloc` or code vetted in
its entirety are a bug
## why
why not?
|
