-
Notifications
You must be signed in to change notification settings - Fork 6
Expand file tree
/
Copy pathMaple 2018 Conversion Notes
More file actions
144 lines (108 loc) · 5.3 KB
/
Maple 2018 Conversion Notes
File metadata and controls
144 lines (108 loc) · 5.3 KB
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
Maple 2018 Conversion Notes
===========================
Working on grF_createSymFn
Using 2017 as a template:
grF_createSymFn(0,{},{}):
proc (objectName, root, calcFn) local gr_data; if grG_calc and assigned(calcFn) then gr_data[root, grG_metricName, grG_operands] := calcFn(objectName, []) end if; grF_symCore(objectName, [], root); RETURN() end proc
Want Maple 2018 to produce the same thing:
Friday Sept 21:
- Rupup calcFnParams are wrong (fixed)
Tues Sept 25
- display og G(dn,up,cdn) is not happening. Components are non-zero when do a grdata([Gdnupcdn_])
symmetry routines confuse me. Inside some loops there is a calcFn call in others a symCore call. Why?
- it is what does e.g. simplification if there is no need to calculate
- also does grF_component, so clears is zero flag for display
- if set grOptionVerbose, should see some stuff
- yep, not actually calling grF_symCore
**BUG**
- tried using grtensor:-grF_symCore
- tried exporting grF_symCore
- could look at providing it as an argument, since calcFn seems to work ok...
- other inert functions seem to do ok...
Sept. 26, 2018
Issue with overview. The RN section does something to screw up the calculation of Kerr killing. Get kt(dn,dn,dn) with unassigned gr_data.
- when trim the RN calc this does not happen
- need to look at the defintion and see if the issue is with construction?
- may be some variable previously unassigned that causes issues when run through subsequent grdefs...
Yep: gr_data[root, reisnord, grG_operands, a1_, a2_, a3_] := calcFn(objectName, [a1_, a2_, a3_])
The previous metric reisnord is being used in the defintion, not grG_metricName.
- either need to unassign it, or delay it's eval.
FIX: unassign grG_metricName at the start
TODO: Need to check every other inert case to make sure this issue cannot occur.
List of places that use FromInert():
contract.mpl
create.mpl
grdef.mpl
parse.mpl
Use grF_unassignMetricNames()/grF_restoreMetrics()
Sept 27, 2018
=============
Bug in symmetry routines. LSH is missing indices:
gr_data[root, grG_metricName, grG_operands] := gr_data[root, grG_metricName, grG_operands, a1_, a2_, a3_, a4_]
typo in sym create. FIXED
KN RiemSq is in a different form - although guessing it is equivilent. Odd that the form is different by might be Maple2018 vs 2017?
- need to prove they are equivilent
Maple 2017: Getting:
grcalc(RiemSq);
Error, (in grtensor:-grF_build_contractFn) incorrect number of arguments to _Inert_FORFROM
in Maple 2017 using the same lib.
OH - hell. Is the implementation of _Inert_FOR different in 2017 versus 2018?! That would be very annoying!
- this may have been the root cause all along!!
Maple 2018:
_Inert_FORFROM(
1 _Inert_LOCAL(1),
2 _Inert_INTPOS(1),
3 _Inert_INTPOS(1),
4 _Inert_INTPOS(4),
5 _Inert_NAME("true", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))),
6 _Inert_STATSEQ(_Inert_FUNCTION(_Inert_ASSIGNEDNAME("print", "PROC", _Inert_ATTRIBUTE(_Inert_NAME("protected",
_Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_EXPSEQ(_Inert_PARAM(1)))),
7 _Inert_NAME("false", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))))
Maple 2017:
_Inert_FORFROM(
1 _Inert_LOCAL(1),
2 _Inert_INTPOS(1),
3 _Inert_INTPOS(1),
4 _Inert_INTPOS(4),
5 _Inert_NAME("true", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))),
6 _Inert_STATSEQ(_Inert_FUNCTION(_Inert_ASSIGNEDNAME("print", "PROC", _Inert_ATTRIBUTE(_Inert_NAME("protected",
_Inert_ATTRIBUTE(_Inert_NAME("protected"))))),
_Inert_EXPSEQ(_Inert_PARAM(1))))
)
YEP. That's the deal.
Looks like I need to add a "false" as the final attribute for Maple 2018 in for loops.
(might even be able to keep the procmake stuff....)
Hmmmm. MIght be useful to modernize anyway. Ponder.
Inert_FOR occurs in only two places (contract and parse) - so relativly centralized.
not too hard to fix. (8 places prior to ToInert refactoring).
Ok, keep the ToInert() stuff as future proofing.
Add check for version() > 1265877 (with a define INERT_FOR_7ARGS)
- seems to work
TODO: supress version logging, or move to the init and assign to a global
Check the KN RiemSq result - still think form might be different than before.
Re-think
Make a wrapper for &for and see if that is all that is needed - greatly reduces the need for regression testing.
Sept 30
=======
regression:
Metric not showing ds on a qload(schw) or qload(kerr) [ qload(npschw) was ok]
Bug is a grdisplay of (x(up), ds) skips the ds
Actually a grdisplay of two things only displays the first one!
Is this in the production release?! Yep.
- this is a consequence of 7b83faeca2dfcdbd87b0e291cca65bf269cf5ddf the fix to allow mapping int.
Test Plan
=========
Get PDFs of output from the original running on 2017 so have a fixed reference of the output. Then can check versus re-runs
Make a list and put in a Google doc.
Unit tests for symmetric and asymmetric symmetry creation
Check some standard objects:
- definition of Chr1
- definition of Rabcd
- contraction to Ricci and Gab
- specify components of a vector
Working through the regression directory
- found & fixed a bug in parse.mpl in basis_book_regres
- RayEqn in the calc_book_regres is not defined. Did the name change? removed? bug?
* It is commented out
* commented out in 2017, since it "looked wrong"
- leave this for now