This contains recent discussion about a patch for the fricas-aldor-interface due to changes in the Aldor compiler. -----------------
The conditions for the exports can obviously be extracted from the database. At least I see these ifs in the .ap file with the ax.boot that we currently have. The main problem is to get the conditions for default implementations. Since fricas generates lisp, I'm pretty sure that even if they are deep in compiled code, at the time a function is needed at runtime, there must be some piece of code to actually find which domain (or default package) that function actually implements. Unfortunately, I have no idea, where this code is how to translate the information into an .ap format. Ralf On 07/19/2018 12:22 AM, Waldek Hebisch wrote: >> >> Oh, I think I either need Peter's or Waldek's help. >> >> I've browsed throught ax.boot and looked into the category defaults. >> >> https://github.com/fricas/fricas/blob/master/src/interp/ax.boot#L466 >> >> For DIRPCAT the code then executes >> >> defaultingOps('DirectProductCategory) >> >> but then $infovec is set to (see end of mail). >> Most importantly, I cannot see any if's. >> Is the information that the category defaults are conditional in >> DirectProductCategory actually somewhere available in FriCAS? How can I >> this information? > > Well, there are two conditions involved: > - condition under which operation is exported from category, > this one is stored in category, but AFAICS absent from default package > - condition under which operation is defined. AFAICS this > information is only contained in generated code. > >> PS: Shouldn't this conversation be on fricas-devel instead of being >> private? > > Probably. We are now discussing specific patches so it would be > better to do this in public. > > -------- Forwarded Message -------- Subject: Re: Aldor interface Date: Wed, 18 Jul 2018 07:05:57 +0100 From: Peter Broadbery <[email protected]> To: Waldek Hebisch <[email protected]> CC: Ralf Hemmecke <[email protected]>, Kurt Pagani <[email protected]> The aldor compiler checks that the add body implements all the operations in the with, allowing for defaulted definitions. So 'X: Ring == add' is an error. This also checks conditions - the condition on the definition must imply the condition on the declaration. On Wed, 18 Jul 2018, 00:06 Waldek Hebisch, <[email protected]> wrote: > Peter Broadbery wrote: > > On 17 July 2018 at 23:22, Ralf Hemmecke <[email protected]> wrote: > > > > > >> ================== > > > >> You've hardcoded the files DIRPCAT.ap and FS.ap under fixed_ap. > > > >> Can you say why this is necessary? > > > > > > > The reason for these is that the patch removes all the pretendTo's, > but > > > > this breaks some default definitions. > > > > In DIRPCAT.spad there is something like: > > > > > > > > add > > > > if R has Ring then > > > > default reducedSystem(m: Matrix %): Matrix R == ... > > > > > > > > which was translated to > > > > default reducedSystem(m: Matrix(% pretend AbelianMonoid)): > Matrix (R > > > > pretend AbelianMonoid) == ... > > > > > > > > But the new changes mean that this becomes > > > > default reducedSystem(m: Matrix(%): Matrix R == ... > > > > without the condition on R, which is of course an error. > > > > > > Ah... In fact, I don't know if here we have a difference between Aldor > > > and SPAD. AFAIK if in Aldor something appears as a default > > > implementation in a category, then automatically the respective > > > signature is exported. Is this the same for the "add" part of a > category > > > definition in SPAD? > > > > > > Anyway, in this particular case, we have > > > > > > if R has Ring then > > > DifferentialExtension R > > > FullyLinearlyExplicitOver R > > > > > > and reducedSystem is exported from LinearlyExplicitOver. > > > > > > So, theoretically, the compiler should be able to check whether the > > > default definition corresponds to an explicit export with the same > > > condition. > > > > > > > The fixed_ap simply removes this definition - ideally the generator > > > should > > > > insert an appropriate condition before the definition, > > > > but it wasn't immediately obvious how to do it. > > > > > > You certainly know better than me, but why cannot the Aldor compiler > from > > > > > > if R has Ring then > > > ... > > > reducedSystem(m : Matrix %) : Matrix(R) == > > > empty? m => new(dim*nrows(m), ncols(m), 0) > > > reduce(vertConcat, [equation2R row(m, i) > > > for i in minRowIndex m .. maxRowIndex m])$List(Matrix > R) > > > > > > simply generate > > > > > > if R has Ring then reducedSystem: Matrix % -> Matrix R > > > > > > ? > > > > > > > > We already generate that for signatures. Defaults are handled slightly > > differently, and I've not > > had time to really figure out what's needed. "simple" may be a relative > > term here. > > Silly question: do we need to do anything at all for defaults? > At first glance defaults are needed only by runtime system and > of course FriCAS runtime knows about defaults for FriCAS > categries. Why Aldor need to know that there are any defaults? > > -- > Waldek Hebisch > -------- Forwarded Message -------- Subject: Re: Aldor interface Date: Wed, 18 Jul 2018 23:12:17 +0200 From: Ralf Hemmecke <[email protected]> To: Peter Broadbery <[email protected]> CC: Waldek Hebisch <[email protected]>, Kurt Pagani <[email protected]> Oh, I think I either need Peter's or Waldek's help. I've browsed throught ax.boot and looked into the category defaults. https://github.com/fricas/fricas/blob/master/src/interp/ax.boot#L466 For DIRPCAT the code then executes defaultingOps('DirectProductCategory) but then $infovec is set to (see end of mail). Most importantly, I cannot see any if's. Is the information that the category defaults are conditional in DirectProductCategory actually somewhere available in FriCAS? How can I this information? Thanks Ralf PS: Shouldn't this conversation be on fricas-devel instead of being private? On 07/18/2018 12:40 PM, Peter Broadbery wrote: > On Wed, 18 Jul 2018, 11:34 Ralf Hemmecke, <[email protected]> wrote: > >> On 07/18/2018 08:05 AM, Peter Broadbery wrote: >>> The aldor compiler checks that the add body implements all the operations >>> in the with, allowing for defaulted definitions. So 'X: Ring == add' is >>> an error. >>> This also checks conditions - the condition on the definition must imply >>> the condition on the declaration. >> >> Oh, but here we don't have a problem with the Aldor compiler. The input, >> i.e. the generated .ap file is wrong. The .ap file, however, is >> generated by src/aldor/gendepap.lsp "generate-ax-file". >> >> Peter, do you think that simply adding the respective if's into the >> default block. >> >> Maybe we have to change makeAxExportForm in src/interp/ax.boot to make >> the Aldor compiler happy (I haven't yet looked deep). >> >> Ralf >> > > Yes, we would have to make changes there.. I couldn't quickly see what the > right code was, so decided to simply edit the generated file. Obviously > with more time a better solution is possible. Value = (#(NIL NIL NIL NIL NIL NIL (|local| |#1|) (|local| |#2|) (|local| |#3|) #1=(|Integer|) (0 . |coerce|) (5 . |coerce|) (10 . |coerce|) #2=(|NonNegativeInteger|) (15 . |characteristic|) (19 . |characteristic|) (|Mapping| 8 8) (23 . |map|) (29 . |differentiate|) (35 . |Zero|) (|Matrix| 8) (39 . |maxRowIndex|) (44 . |maxColIndex|) (49 . |qelt|) (|Boolean|) (|Matrix| 6) (55 . |empty?|) (60 . |vertConcat|) (66 . |maxRowIndex|) (|Vector| 6) (71 . |row|) (|Mapping| 20 20 20) (|List| 20) (77 . |reduce|) (|Matrix| $) (83 . |reducedSystem|) (88 . |empty?|) (93 . |coerce|) (98 . |reducedSystem|) (|Vector| 8) (103 . |column|) (|Record| (|:| |mat| 20) (|:| |vec| 39)) (|Vector| $) (109 . |reducedSystem|) (115 . |inv|) (120 . *) (126 . /) #3=(|CardinalNumber|) (132 . |coerce|) (137 . |dimension|) (141 . |size|) (145 . |size|) #4=(|PositiveInteger|) (149 . |index|) (154 . |setelt!|) (161 . |directProduct|) (166 . |index|) (171 . |elt|) (177 . |lookup|) (182 . |lookup|) (|Fraction| 9) #5=(|OutputForm|) (|List| 64) (|List| 13) #6=(|Symbol|) (|Record| (|:| |mat| 66) (|:| |vec| (|Vector| 9))) (|Matrix| 9)) #(|size| 187 |reducedSystem| 191 |lookup| 202 |index| 207 |dimension| 212 |differentiate| 216 |coerce| 222 |characteristic| 227 / 231) NIL (#*0 #(NIL) #((|Join| (|mkCategory| (LIST '((|coerce| (|#1| |#3|)) T) '((|coerce| (|#1| (|Fraction| #1#))) T) '((|coerce| (|#1| #1#)) T) '((|coerce| (#5# |#1|)) T) '((|differentiate| (|#1| |#1| #7=(|Mapping| |#3| |#3|))) T) '((|differentiate| (|#1| |#1| #7# #2#)) T) '((|differentiate| (|#1| |#1| #8=(|List| #6#) (|List| #2#))) T) '((|differentiate| (|#1| |#1| #6# #2#)) T) '((|differentiate| (|#1| |#1| #8#)) T) '((|differentiate| (|#1| |#1| #6#)) T) '((|differentiate| (|#1| |#1| #2#)) T) '((|differentiate| #9=(|#1| |#1|)) T) '((|characteristic| #10=(#2#)) T) '((|reducedSystem| (#11=(|Matrix| |#3|) #12=(|Matrix| |#1|))) T) '((|reducedSystem| ((|Record| (|:| |mat| #11#) (|:| |vec| #13=(|Vector| |#3|))) #12# #14=(|Vector| |#1|))) T) '((|reducedSystem| ((|Record| (|:| |mat| #15=(|Matrix| #1#)) (|:| |vec| (|Vector| #1#))) #12# #14#)) T) '((|reducedSystem| (#15# #12#)) T) '((|size| #10#) T) '((|index| (|#1| #4#)) T) '((|lookup| (#4# |#1|)) T) '((|coerce| #9#) T) '((/ (|#1| |#1| |#3|)) T) '((|dimension| (#3#)) T) '((|coerce| (#13# |#1|)) T)) (LIST) NIL NIL))) . #(1 8 0 9 10 1 6 0 8 11 1 0 0 9 12 0 8 13 14 0 0 13 15 2 6 0 16 0 17 2 0 0 0 16 18 0 8 0 19 1 20 9 0 21 1 20 9 0 22 2 6 8 0 9 23 1 25 24 0 26 2 20 0 0 0 27 1 25 9 0 28 2 25 29 0 9 30 2 32 20 31 0 33 1 0 20 34 35 1 29 24 0 36 1 25 0 29 37 1 6 20 34 38 2 20 39 0 9 40 2 0 41 34 42 43 1 8 0 0 44 2 6 0 0 8 45 2 0 0 0 8 46 1 47 0 13 48 0 0 47 49 0 8 13 50 0 0 13 51 1 8 0 52 53 3 39 8 0 9 8 54 1 6 0 39 55 1 0 0 52 56 2 6 8 0 9 57 1 8 52 0 58 1 0 52 0 59 0 0 13 51 2 0 41 34 42 43 1 0 20 34 35 1 0 52 0 59 1 0 0 52 56 0 0 47 49 2 0 0 0 16 18 1 0 0 9 12 0 0 13 15 2 0 0 0 8 46)) |lookupComplete|) -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
