On Sat, Jan 11, 2025 at 12:14:14PM -0500, Camm Maguire wrote:
> Greetings, and thank you so much! This appears to have removed the
> practical problem for the moment -- great!
>
> Your extremely helpful earlier exposition however indicates the
> potential need for large argument lists in the future. Please forgive
> me as I have not yet examined the code in any detail, but the naming
> seems to indicate that some of these functions might satisfy a property
> like
>
> (fn a b c) == (fn (fn a b) c)
>
> (e.g. '|Join|, '|Union|...) You also indicate that you aggressively
> 'flatten' '|Join| calls, which is also suggestive that '|Join| might
> have this property. This was the thinking about suggesting reduce on a
> list, which may very well be equivalent to the algorithm of
> '|JoinInner|. If there is such flattening going on, one might very
> well limit it to call-arguments-limit at that point.
'Union' is not associative. 'Join' logically is associative, but
internally FriCAS depends on flat form. Also, 'JoinInner' is
rather expensive and trying to do it as a sequence of say binary
calls would lead to redoing much of work, so significantly
worse performance.
> I am experimenting with a list macro at the moment to take care of that
> function, which seems to be working. You might be interested to know
> that when we were working out similar problems with ACL2, now finished,
> the author introduced a list$ macro:
>
> (defmacro list$ (&rest args)
>
> ; The logical definitions agree for this macro and list. But in raw Lisp, a
> ; macro call of list$ expands to a nest of cons calls, which allows GCL
> version
> ; 2.7.0 (and presumably later versions) to avoid causing an error when list is
> ; called on too many arguments.
ATM for 'LIST' I prefer shadowing 'LIST' from "COMMON-LISP" package
(FriCAS uses are in BOOT package). There are several cases where
FriCAS uses variation of Common Lisp functions under changed name
and while workable they cause some maintainence burden. It looks
for me that shadowing can give needed effect with least effort.
BTW: I have added a test for file operations and currently there
are several failures in GCL based FriCAS. One issue is that
FriCAS creates specialised array with element type '(UNSIGNED-BYTE 32)'.
GCL reports element type of the array as 'FIXNUM' and type
tests that FriCAS uses consider 'FIXNUM' as different from
'(UNSIGNED-BYTE 32)'. When reading from files FriCAS needs to
re-create array type, so currently writing of such arrays
fails. I can add 'FIXNUM' to the list of array element types
considerd by FriCAS, but I a bit worried if this does not lead
to wrong code somewhere else: FriCAS type machinery "knows"
that element type is '(UNSIGNED-BYTE 32)' and uses this type
for in declarations passed to Lisp. If I re-create the array
with element type 'FIXNUM', then formally types do not match
and there is potential for miscompilation. So, the question
is if specialized array having 'FIXNUM' as element type
is the same as specialized array having '(UNSIGNED-BYTE 32)'
as element type.
The second problem is that apparently GCL does not flush file
buffers on 'CLOSE'. Do I need to call 'FINISH-OUTPUT' before
'CLOSE'?
The third problem is that apparently GCL writes wrong thing
which it can not read back. The Lisp expression is somewhat
complex, one can reproduce this from recent FriCAS using:
kf := open("ts_kaf", "output")$KeyedAccessFile(None)
a3 : EXPR(INT) := exp(x) - 1
kf("a3") := a3 pretend None
After that file 'ts_kaf/index.KAF' contains apparently wrong
S-expression. Reading it back via:
kr3 := kf("a3") pretend EXPR(INT)
gives:
>> System error:
SIMPLE-ERROR: #2= multiply defined
and '#2' indeed seem to be multiply defined.
I wrote "recent" FriCAS because there were changes on FriCAS
side which fixed some probles (and potentially may introduce
new bugs). However this problem is also present in GCL
compiled FriCAS 1.3.11.
--
Waldek Hebisch
--
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 view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/Z4L62ohOg73mI_Sf%40fricas.org.
