'delta-test' failures #133
Comments
Closed
|
Commit cefa352 fixes 1, 2, and 5. |
|
There are the following new This seems to be some kind of overflow as The |
|
There's a similar failure now in the The failing test is |
|
Ditto in the |
|
Francis Sergeraert => Gerd Heber.
==================================================
/> There are the following new delta-test failures.
This seems to be some kind of overflow as 4611686018427387903 is the
largest fixnum on my machine. The simplest test that fails is in
soft-delta where d3
is (cat:soft-delta 3) and the failing line is:
(cat:face d3 1 2 (cat:d 21))
/
This comes from a mixture of tests of some previous version and more
recent implementations.
More precisely, the matter is the coding of strictly increasing
sequences of small integers.
Let's take for example, the standard simplex \Delta^3 of dimension
3, spanned by the vertices 0 1 2 3. It is constructed by (soft-delta
3). A simplex of dimension 2 is for example spanned by the vertices 0
2 3. *Internally*, such a sequence 0 2 3 is coded as the integer 13,
for 2^0 + 2^2 + 2^3 = 1 + 4 +8 = 13. The form (0 2 3) is the
"external" form, whereas 13 is the "internal" form. This notion of
binary internal form for the increasing sequences of small integers is
essential and is one of the strong differences between Kenzo and the
very old implementation, quite different, called EAT (= Effective
Algebraic Topology).
In some previous version of Kenzo, the user had to compute himself
the internal form, for example, if he intended to work with the
simplex 0-2-3, he had to compute himself the binary implementation is
13, so that he had to introduce (d 13). Not very convenient.
So that I decided later for better comfort to implement the
conversion external-internal inside the body of the macro "D", see
this macro in macros.lisp.
Taking account of this, the appropriate tests for soft-delta
becomes:
#|
()
(cat-init)
(setf d3 (soft-delta 3))
;; the following test is incorrect but does not generate an error:
;; (cmpr d3 (d 2) (d 4))
;; OLD(cmpr d3 (d 2) (d 4)) = NEW (cmpr d3 (d 1) (d 2))
;; the correct test is in fact
(cmpr d3 (d 1) (d 2)) ;; with the same result !
(basis d3 1)
;; (dgnl d3 3 (d 15)) ;; 15 = 2^0 + 2^1 + 2^2 + 2^3, the correct test :
(dgnl d3 3 (d 0 1 2 3))
;; with a different and correct result.
;; The next test is incorrect for two reasons:
;; (face d3 1 2 (d 21))
;; 1) In the old version, 21 = 2^0 + 2^2 + 2^4, so that in the
;; new version, the correct equivalent test is:
(face d3 1 2 (d 0 2 4))
;; which gives a result. 2) But in fact this test is also incorrect
;; for 4 is not a vertex of d3 ! Such an error would be detected
;; by Sphynx which systematically checks the membership with respect
;; to the object above. Here 4 \notin d3.
;; Finally the right test could be:
(face d3 1 2 (d 0 2 3))
;; (? d3 2 (d 13)) ;; incorrect
(? d3 2 (d 0 2 3))
|#
OK ?
Bien cordialement.
|
|
Francis Sergeraert => Gerd Heber.
==================================================
The same kind of incoherence is at the origin of these errors. I've
explained this morning the difference between OLD:(d 13) = NEW(d 0 2
3). I observe now that in examples and programming, there is a still
older version where a simplex of a standard simplex is simply an
integer. This means :
STILL-OLDER:13 <=> OLD:(d 13) = NEW:(d 0 2 3)
but there is a difference: The functions designed for work on delta
objets cannot work on integers, generating other bugs seeming a
type-error.
Now this incoherence generates errors for the tests of the COBAR
file. Programming COBAR and the satellites of cobar, namely
LOOP-SPACES, LP-TWISTED-SPACES, LP-SPACE-EFHM, and maybe others,
programming these files was very hard, so that I designed powerful
tests generated by functions such as RANDOM-ALLP = random-algebraic-
loop. These loops being based essentially on standard simplices and
their derivatives.
It seems a real taskfor you to find out all the modifications to be
done; of course I can do it.
What do you prefer : I independently do a new version of kenzo-8
replacing the previous one I sent you. Or I clone the Github current
state of Kenzo-8, do the modifications on a new branch for later
merging? Or maybe you prefer to do it yourself? Once this matter of
implementation of simplices in a standard simplex is understood, it is
not really difficult, but needs some time.
As you like.
I add these questions around delta, soft-delta, soft-delta-infinity,
random-allp, etc. do not concern the "interesting" examples of use of
Kenzo, such as those in the file test.lisp I sent you. Anyway these
bugs must be fixed if we pretend to distribute this program.
Bien cordialement.
|
|
Fixed in fe7f3d6 |
|
Francis Sergeraert => Gerd Heber.
==================================================
/> Closed #133.
/
Seems all the "easy" problems around the delta file are solved,
correct ? There remains the error #131 which is raised when a
"wrong-cmbn" (erroneous order of the generators) is detected during
"chain-complexes-test" but where?
Bien cordialement.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: