From: Richard F. <fa...@gm...> - 2023-01-24 20:29:19
|
It would, of course, be nice to have a much much smaller example to demonstrate this problem. Here's a guess about how it might appear in GCL and ECL both! Common lisp's standard was defined mostly by people at MIT, Stanford and CMU. They rejected my suggestion that characters should have 8 bits as in UNIX and insisted that lower-case characters should be treated as UPPER CASE. This made sense for the PDP-10 computers from DEC, where characters were packed into 36 bit words. This decision did not wear well, I think. When 8 bits is not enough! Anyway, it could be that some Common Lisps don't properly treat the upper/lower case requirements in Maxima and get confused by your use of both w1 and W1. So my suggestion, if you have the energy and a handy editor, is to change your data so that you have variables like W1 rewritten as wu1 (that is to remind you that it is w_upper_case_1).. etc. etc. And see if that works. RJF On Tue, Jan 24, 2023 at 12:11 PM Andrii Sokolov <and...@gm...> wrote: > Both ratsimp(eq2) and factor(eq2) spit out the PQUOTINENT > error. However, rat(eq2,B10) provides a result. > > Regarding the possibility to reproduce this bug, I have found an online > web interface to Maxima that behaves just like the Maxima on my machine > http://maxima.cesga.es/index.php?c=56av4icbo5uzn3routiuo&n=7 The site > prints "Programming error detected. Check your input.» for my input with > orderless, but I guess it gives it for any maxima error. Unfortunately they > block calls to build_info() but, well, my first guess was that it’s GCL > that is used. > > And more than that. Actually there is this very bug in SAGE, at least in > the CoCalc service that uses it. You can find my worksheet demonstrating > that bug and play with it by the link > https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe And… > wait a minute—that uses ECL! > > And well, I know it is ECL which is also used in the Android port of > Maxima. Unfortunately, I do not have an Android device to check that bug. > > Andrii > > > > 23 січ. 2023 р. о 17:24 Richard Fateman <fa...@gm...> написав(ла): > > It is difficult for us to debug a problem that we can't reproduce! > On an SBCL lisp on my computer, I tried once.. > the time for solve is 5.9 sec with orderless, and 3.9 without orderless. > > I suggest that you try this: > eq2: rhs(eq)-lhs(eq)$ > ratsimp(eq2)$ > factor(eq2)$ > rat(eq2,B10)$ > > > See if you get the pquotient message for these programs. > > Maybe narrow the problem with this: > :lisp (trace ratf pfactor solve1a) > solve(eq2,B10)$ > > On Mon, Jan 23, 2023 at 1:30 AM Andrii Sokolov <and...@gm...> > wrote: > >> Thanks for feedback and some testing. >> >> Created a bug report https://sourceforge.net/p/maxima/bugs/4084/ >> >> >> > |