Hi Rowan,
I would not use RATIONAL_NUMBERS_WANTED=yes
in the context of linear algebra even though
I don't think it makes a difference. Its probably just slower.
I am getting this:
68.64208074 ¯28.28427125 ¯4.478949969E¯15
¯9.827502707E¯15 2.737380805E¯15
0 ¯3.642080737 ¯5.573380404E¯16 ¯1.508040844E¯15
3.558371050E¯16
0 0 ¯9.190591996E¯16 ¯1.708771971E¯17
3.594337453E¯16
0 0 0.000000000E0 4.132084299E¯16
2.453537944E¯16
0 0 0.000000000E0 0.000000000E0
¯3.088077991E¯17
⌹[⎕CT]yy
1 0 0 0 0 68.642080737002189 ¯28.284271247461849
¯4.4789499693386752E¯15 ¯9.8275027072133962E¯15
2.7373808045404955E¯15 0.014568322948009649
0.11313708498984769
¯0.0023885168387308391
0.066518309540373144 ¯0.56858532876428267
0 ¯1 0 0 0 0 3.6420807370024026
5.5733804042156851E¯16 1.5080408441474691E¯15
¯3.5583710502840566E¯16 0
0.2745683229480095
0.16650436787857926
0.99517588642565933 ¯9.1326867152187798
0 0 1 0 0 0 0
¯9.1905919960774138E¯16 ¯1.7087719706038831E¯17
3.5943374532205272E¯16 0
0
¯1088069191219460.7
44995745519819.392
¯13021972329283451
0 0 0 ¯1 0 0 0
0.0000000000000000E0 ¯4.1320842994244806E¯16
¯2.4535379437658151E¯16 0
0
0
¯2420086153952088.8
19228054549359863
0 0 0 0 1 0 0
0.0000000000000000E0 0.0000000000000000E0
¯3.0880779907613713E¯17 0
0
0
0 ¯32382601831680033
Maybe your GNU APL is a little too old, I did some
changes lately.
To serialize qq put it in quotes (2 ⎕TF wants a variable
name, not a value):
2 ⎕TF 'yy'
yy←(5 5⍴6.8642080737002189E1 ¯2.8284271247461849E1
¯4.4789499693386752E¯15 ¯9.8275027072133962E¯15
2.7373808045404955E¯15 0 ¯3.6420807370024026
¯5.5733804042156851E¯16 ¯1.5080408441474691E¯15
3.5583710502840566E¯16 0 0 ¯9.1905919960774138E¯16
¯1.7087719706038831E¯17 3.5943374532205272E¯16 0 0 0
4.1320842994244806E¯16 2.4535379437658151E¯16 0 0 0 0
¯3.0880779907613713E¯17)
Dito for 10 ⎕CR:
10 ⎕CR 'yy'
yy←5 5⍴0 ⍝ prolog ≡1 (,yy)[⍳3]←68.642080737002189
¯28.284271247461849 ¯4.4789499693386752E¯15
(,yy)[3+⍳3]←¯9.8275027072133962E¯15 2.7373808045404955E¯15 0
(,yy)[6+⍳2]←¯3.6420807370024026 ¯5.5733804042156851E¯16
(,yy)[8+⍳4]←¯1.5080408441474691E¯15 3.5583710502840566E¯16 0 0
(,yy)[12+⍳2]←¯9.1905919960774138E¯16 ¯1.7087719706038831E¯17
(,yy)[14+⍳5]←3.5943374532205272E¯16 0 0 0 4.1320842994244806E¯16
(,yy)[19+⍳6]←2.4535379437658151E¯16 0 0 0 0
¯3.0880779907613713E¯17
Not sure what;s wrong with your qt (character ?) since I don't have
it.
The Internal precision of floats is 64 bit, == standard C/C++
double.
Best Regards,
Jürgen
n 4/19/20
8:12 PM, Rowan Cannaday wrote:
Greetings again,
This question is more about decimal precision and internal
storage of numeric data in APL, but in the context of
these linear algebra solutions.
So far I've implemented Householder reflection, Hessenberg
decomposition, & Wilkinson shift. I am very close (I
think!) to having a general solution to the eigenvalue
problem in APL, but I am running into some problems.
The below tests were done with
`RATIONAL_NUMBERS_WANTED=yes` & `⎕CT ← 1E¯13`, however
the results were the same without this compilation flag. Let
me know if I should recompile without the flag to aid
debugging.
I am also unable to serialize these values to share, as noted
below.
While decomposing arrays, I am left with numbers that seem
to be outside the system limits for decimals.
See below:
yy
6.8642080737002189E1 ¯2.8284271247461845E1
¯4.4789499693386752E¯15 ¯9.8275027072133962E¯15
2.7373808045404955E¯15
0.0000000000000000E0 ¯3.6420807370024026E0
¯5.5733804042156851E¯16 ¯1.5080408441474686E¯15
3.5583710502840566E¯16
0.0000000000000000E0 0.0000000000000000E0
¯9.1905919960774138E¯16 ¯1.7087719706038831E¯17
3.5943374532205272E¯16
0.0000000000000000E0 0.0000000000000000E0
0.0000000000000000E0 4.1320842994244806E¯16
2.4535379437658151E¯16
0.0000000000000000E0 0.0000000000000000E0
0.0000000000000000E0 0.0000000000000000E0
¯3.0880779907613713E¯17
⌹[⎕CT] yy
DOMAIN ERROR
⌹[⎕CT]yy
^ ^
2 ⎕TF yy
RANK ERROR
2 ⎕TF yy
^ ^
10 ⎕CR yy
RANK ERROR
10 ⎕CR yy
^ ^
qt
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000
2×qt
DOMAIN ERROR
2×qt
^ ^
In another calculation, I am left with this (seemingly)
bizarre result:
{(⌈/⍳0) > ⍵} qt
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
I'd be happy to generate some functions, but I'll have to
clean up (& properly attribute) my workspace to do so. I
have not found a trivial example to demonstrate what is
happening, but I thought I'd reach out in meantime to see if
there is a workaround.
Thank you,
- Rowan
On Mon, Apr 13, 2020 at 6:32
PM Rowan Cannaday < address@hidden> wrote:
Another deficiency I've noticed in my above solution is
that it does not converge for complex eigenvalues.
- Rowan
On Mon, Apr 13, 2020 at
6:07 PM Rowan Cannaday < address@hidden>
wrote:
Here is a quick solution to the eigenvalue
problem. Should be refined and extended to calculate
eigenvectors.
{0~⍨∈⍵×∘.=⍨⍳≢⍵}({r+.×⍉qt⊣(qt r)←⌹[⎕CT]⍵
;qt;r}⍣{(|⍺)≡|⍵}) 3 3 ⍴ ⍳9
16.11684397 ¯1.11684397 ¯3.625973215E¯16
As a quick note, my ⎕CT was 1E¯13, however it doesn't
seem to zero out the ¯3.625973215E¯16. I suspect this
is due to it being a negative number. Its not that big
of a hurdle, it can be easily worked around with an
extra function. Worlframalpha for example rounds it to
0 in their solution.
Many thanks,
- Rowan
The paper you referred to was a huge epiphany
for me.
Having previously worked in the business world
using COBOL and FORTRAN
the beauty and elegance of APL blew me away. It
still does.
At IPSA we used to model proposed changes
(mostly algorithms) to the interpreter in APL
first.
And then wrote the Assembly code to implement.
That
was my point. If we could establish APL as
a language for describing algorithms. I
was thinking
along
the lines of Iverson's "Notation as a tool
of thought" which is also free now:
https://dl.acm.org/doi/10.1145/358896.358899
|