-
Notifications
You must be signed in to change notification settings - Fork 0
/
changelog.txt
130 lines (82 loc) · 3.48 KB
/
changelog.txt
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
# phystricks changelog
## More deterministic 'PointGraph.coordinates', June 21, 2017
### Problem
A non-deterministic numerical approximation occurred :
```
a=7.73542889062775*cos(11/9*pi + 1.30951587282752) - 7.55775391156456*cos(5/18*pi) + 2.5*cos(2/9*pi)
print(numerical_approx(a))
print(numerical_approx(a,digits=5))
```
The first print is deterministic, while the second is not.
Thus the invocation of `PointGraph.coordinates(numerical=True,digits=5)` is
not a good way to get deterministic end-user '.pstricks' file.
### Solution
* Remove the argument `numerical` from `PointGraph.coordinates`. It is now
always numerical
* I created my own function `Utilities.number_to_string`. It cuts
```
str( numerical_approx(x) )
```
to `digits` characters (+1 for the decimal dot).
- This is more deterministic to the expense of precision.
- There are some rules for adding zeros to the end if one needs more digits
(like x=20.3 and digits=7).
### Side effect
- have to remove the given argument `numerical` everywhere it is invoked.
- many '.recall' files to be redone.
## Better test recall, June 19, 2017
The module 'TestRecall' is improved and furnish
- a way to know if the difference between two files are only small move
of points
- a way to check all '.pstricks' of a directory at once.
## Point coordinates precision, June 15, 2017
### Problem
I found too many cancellation errors here and there in the code. This leads to
non-deterministic final '.pstricks' file : there is some variation like on the
12th decimal of the coordinates of some points.
The last one I found is in `AngleMeasure.measure :`
```
return AngleMeasure(value_degree=self.angleF.degree-self.angleI.degree)
```
In the picture FBTC the difference is
`206.565051177078- 341.565051177078` which leads to problems.
### Solution (partial)
Make write only 5 digits in the coordinates of the central point of a mark.
### Side effect
Many `.recall` files to be redone.
## Polygon parameters, June 15, 2017
### Problem
There are three different things in a polygon : its edges, its filling and its
hatching.
From now on a polygon had only its `parameters` attribute (from
`GraphOfAnObject`), and we were making some complicated guessing.
Also the attribute `segment_model` was not really sexy.
### Solution
Now we have three attributes :
* edges_parameters
* hatch_parameters
* fill_parameters
### Side effects
Have to rewrite the functions in which the color of a polygon is customosed.
Also the ones in which a polygon is hatched or filled.
## Non deterministic function evaluation, June 15, 2017
### Problem
The test picture `XOLB` had a non-deterministic behaviour. This was probably
due to a cancelation error: we were substracting two numbers of order of
magnitude 22000 with a differences like 0.01. The 12th decimal was
non-deterministic (change when restarting Sage).
This was impacting the computation of the bounding box of the function and
then the axes.
### Solution.
When computing the X and Y coordinates of the representative points of a
curve, we consider a numerical approximation with `prec=30` in order to get
less digits than the correct ones.
See `GenericCurve.get_minmax_data`.
### Side effects
The 6th or 7th decimal of some bounding boxes are changed. So the axes of some
pictures are changed (not visible).
The `recall` files of these pictures have to be recreated to take that into
account.
### See also
See the question here :
https://ask.sagemath.org/question/37946/undeterministic-numerical-approximation/