Re: Database madness
David Scherfgen via Maxima-discuss <[email protected]> Sun, 2 Aug 2026 11:47:26 +0200
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <CAMTHLKiFFrUwHSkmaFxFAa7UB1boEXawXjiRhwapou_-jJu-PQ@mail.gmail.com> |
--===============4357287024701006091== Content-Type: multipart/alternative; boundary="0000000000007ba1d206580d5159" --0000000000007ba1d206580d5159 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gunter, I think there's a misunderstanding. There is no caching of is() results or other database queries in Maxima. I experimented with that once, but it's bug-prone, because lots of things can change what is() would answer, and we have to account for all of them, or otherwise risk returning incorrect cached answers. Best regards David Am So., 2. Aug. 2026 um 10:59 Uhr schrieb Gunter K=EF=BF=BDnigsmann < [email protected]>: > Currently Maxima can automatically add assumption database entries that > cache information that answering directly might take less time than looki= ng > them up in the assumption database. > > If every lisp provided us with a high resolution stopwatch we could decid= e > to cache only is() results that took less than 100 microseconds to answer > or similar.. > > Kind regards, > > Gunter > > > On 27 July 2026 13:27:58 CEST, David Scherfgen <[email protected]= m> > wrote: > >> What do you mean by nontrivial questions? >> I don't understand your other question. >> >> Gunter K=EF=BF=BDnigsmann <[email protected]> schrieb am Mo., 27. Juli= 2026, >> 13:16: >> >>> I still wonder if there is a way to add only answers to nontrivial >>> questions to the assume database. >>> >>> Next question: if you redefine f[a](x): Will that result in >>> hard-to-understand decisions of if, currently? >>> >>> Kind regards, >>> >>> Gunter. >>> >>> >>> On 27 July 2026 12:26:11 CEST, David Scherfgen < >>> [email protected]> wrote: >>> >>>> It's really easy to trigger this with innocent code: >>>> >>>> Define a family of functions: >>>> >>>> f[a](x) :=3D abs(sin(x)-a)$ >>>> >>>> Say you want to analyze or plot the function for different values of a= : >>>> >>>> Do something with f[10](x) ... >>>> Do something with f[11](x) ... >>>> ... >>>> >>>> Each time, new entries in *NOBJECTS* will be created because the abs >>>> simplifier tries to determine the sign of its argument. In fact, *two*= new >>>> entries are created: one for e.g. 100 and one for the float 100.0. Thi= s is >>>> a separate bug. There's also another bug where the chain of numbers in >>>> *NOBJECTS* becomes a DAG because the database forgets to remove existi= ng >>>> edges when inserting a new number node that sits between two already >>>> existing ones. Also a separate bug. >>>> >>>> As I said, there is no way to reverse the permanent slow-down caused b= y >>>> growing *NOBJECTS*. >>>> >>>> It's OK and expected if performance degrades with growing number of >>>> assumptions in the system. But pure queries ("What's the sign of >>>> sin(x)-100?") should never affect, let alone permanently degrade, >>>> performance of future queries. >>>> >>>> Claude and me are working on a solution. >>>> >>>> Gunter K=EF=BF=BDnigsmann via Maxima-discuss < >>>> [email protected]> schrieb am Mo., 27. Juli 2026, >>>> 09:07: >>>> >>>>> Actually I encounter that slowness frequently when trying to make >>>>> Maxima deal with real-life oscillograms. >>>>> >>>>> Kind regards, >>>>> >>>>> Gunter. >>>>> >>>>> >>>>> On 27 July 2026 06:45:09 CEST, Robert Dodier <[email protected]= > >>>>> wrote: >>>>> >>>>>> On Sun, Jul 26, 2026 at 3:36=E2=80=AFPM David Scherfgen via Maxima-d= iscuss >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> In this extreme case, maybe it's pathological. But comparisons happ= en all the time in the general simplifier, via sign, csign, mgrp, etc., and= in integration, limits, equation solving, ... >>>>>>> >>>>>> >>>>>> Right, it is not pathological, it is not hard to encounter it. I hav= e >>>>>> bumped into it via an implementation of a piecewise interpolating >>>>>> function which produces functions which look like >>>>>> >>>>>> if x < 0.5 then ... elseif x < 1.2 then ... elseif x < 5.3 then ..= . >>>>>> >>>>>> which ends up creating database items for 0.5, 1.2, 5.3, etc. >>>>>> Obviously this becomes a problem if the number of pieces in the >>>>>> piecewise function is large. >>>>>> >>>>>> FWIW >>>>>> >>>>>> Robert >>>>>> ------------------------------ >>>>>> Maxima-discuss mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >>>>>> >>>>>> _______________________________________________ >>>>> Maxima-discuss mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >>>>> >>>> --0000000000007ba1d206580d5159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Gunter,<div><br></div><div>I think there's a misund= erstanding.</div><div>There is no caching of is() results or other database= queries in Maxima.<br>I experimented with that once, but it's bug-pron= e, because lots of things can change what is() would answer, and we have to= account for all of them, or otherwise risk returning incorrect cached answ= ers.</div><div><br></div><div>Best regards</div><div>David</div></div><br><= div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g= mail_attr">Am So., 2. Aug. 2026 um 10:59=C2=A0Uhr schrieb Gunter K=EF=BF=BD= nigsmann <<a href=3D"mailto:[email protected]">[email protected]</a>= >:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div = dir=3D"auto">Currently Maxima can automatically add assumption database ent= ries that cache information that answering directly might take less time th= an looking them up in the assumption database. <br><br>If every lisp provid= ed us with a high resolution stopwatch we could decide to cache only is() r= esults that took less than 100 microseconds to answer or similar..<br><br>K= ind regards,<br><br>=C2=A0 Gunter<br></div><br><br><div class=3D"gmail_quot= e"><div dir=3D"auto">On 27 July 2026 13:27:58 CEST, David Scherfgen <<a = href=3D"mailto:[email protected]" target=3D"_blank">d.scherfgen@go= oglemail.com</a>> wrote:</div><blockquote class=3D"gmail_quote" style=3D= "margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex"> <div dir=3D"auto"><div>What do you mean by nontrivial questions?</div><div = dir=3D"auto">I don't understand your other question.<br><br><div class= =3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">Gunter = K=EF=BF=BDnigsmann <<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>> schrieb am Mo., 27. Juli 2026, 13:16:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir=3D"aut= o">I still wonder if there is a way to add only answers to nontrivial quest= ions to the assume database. <br><br>Next question: if you redefine f[a](x)= : Will that result in hard-to-understand decisions of if, currently?<br><br= >Kind regards, <br><br>=C2=A0=C2=A0 Gunter. </div><br><br><div class=3D"gma= il_quote"><div dir=3D"auto">On 27 July 2026 12:26:11 CEST, David Scherfgen = <<a href=3D"mailto:[email protected]" rel=3D"noreferrer" target= =3D"_blank">[email protected]</a>> wrote:</div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"> <div dir=3D"auto">It's really easy to trigger this with innocent code:<= div dir=3D"auto"><br></div><div dir=3D"auto">Define a family of functions:<= /div><div dir=3D"auto"><br></div><div dir=3D"auto">f[a](x) :=3D abs(sin(x)-= a)$</div><div dir=3D"auto"><br></div><div dir=3D"auto">Say you want to anal= yze or plot the function for different values of a:</div><div dir=3D"auto">= <br></div><div dir=3D"auto">Do something with f[10](x) ...</div><div dir=3D= "auto">Do something with f[11](x) ...</div><div dir=3D"auto">...</div><div = dir=3D"auto"><br></div><div dir=3D"auto">Each time, new entries in *NOBJECT= S* will be created because the abs simplifier tries to determine the sign o= f its argument. In fact, *two* new entries are created: one for e.g. 100 an= d one for the float 100.0. This is a separate bug. There's also another= bug where the chain of numbers in *NOBJECTS* becomes a DAG because the dat= abase forgets to remove existing edges when inserting a new number node tha= t sits between two already existing ones. Also a separate bug.</div><div di= r=3D"auto"><br></div><div dir=3D"auto">As I said, there is no way to revers= e the permanent slow-down caused by growing *NOBJECTS*.</div><div dir=3D"au= to"><br></div><div dir=3D"auto">It's OK and expected if performance deg= rades with growing number of assumptions in the system. But pure queries (&= quot;What's the sign of sin(x)-100?") should never affect, let alo= ne permanently degrade, performance of future queries.</div><div dir=3D"aut= o"><br></div><div dir=3D"auto">Claude and me are working on a solution.</di= v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr= ">Gunter K=EF=BF=BDnigsmann via Maxima-discuss <<a href=3D"mailto:maxima= [email protected]" rel=3D"noreferrer" target=3D"_blank">maxima= [email protected]</a>> schrieb am Mo., 27. Juli 2026, 09:07= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir= =3D"auto">Actually I encounter that slowness frequently when trying to make= Maxima deal with real-life oscillograms.<br><br>Kind regards, <br><br>=C2= =A0 Gunter. </div><br><br><div class=3D"gmail_quote"><div dir=3D"auto">On 2= 7 July 2026 06:45:09 CEST, Robert Dodier <<a href=3D"mailto:robert.dodie= [email protected]" rel=3D"noreferrer noreferrer" target=3D"_blank">robert.dodier@= gmail.com</a>> wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex"> <pre><div dir=3D"auto">On Sun, Jul 26, 2026 at 3:36=E2=80=AFPM David Scherf= gen via Maxima-discuss<br><<a href=3D"mailto:[email protected]= forge.net" rel=3D"noreferrer noreferrer" target=3D"_blank">maxima-discuss@l= ists.sourceforge.net</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin-bottom:1ex"><div dir=3D"auto"><br>In this extreme case,= maybe it's pathological. But comparisons happen all the time in the ge= neral simplifier, via sign, csign, mgrp, etc., and in integration, limits, = equation solving, ...<br></div></blockquote><div dir=3D"auto"><br>Right, it= is not pathological, it is not hard to encounter it. I have<br>bumped into= it via an implementation of a piecewise interpolating<br>function which pr= oduces functions which look like<br><br> if x < 0.5 then ... elseif x &= lt; 1.2 then ... elseif x < 5.3 then ...<br><br>which ends up creating d= atabase items for 0.5, 1.2, 5.3, etc.<br>Obviously this becomes a problem i= f the number of pieces in the<br>piecewise function is large.<br><br>FWIW<b= r><br>Robert<hr>Maxima-discuss mailing list<br><a href=3D"mailto:Maxima-dis= [email protected]" rel=3D"noreferrer noreferrer" target=3D"_blank"= >[email protected]</a><br><a href=3D"https://lists.sourc= eforge.net/lists/listinfo/maxima-discuss" rel=3D"noreferrer noreferrer" tar= get=3D"_blank">https://lists.sourceforge.net/lists/listinfo/maxima-discuss<= /a><br></div></pre></blockquote></div></div>_______________________________= ________________<br> Maxima-discuss mailing list<br> <a href=3D"mailto:[email protected]" rel=3D"noreferrer n= oreferrer" target=3D"_blank">[email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/maxima-discuss" rel= =3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.sourc= eforge.net/lists/listinfo/maxima-discuss</a><br> </blockquote></div> </blockquote></div></div></blockquote></div></div></div> </blockquote></div></div></blockquote></div> --0000000000007ba1d206580d5159-- --===============4357287024701006091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4357287024701006091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Maxima-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maxima-discuss --===============4357287024701006091==--