Re: Database madness
David Scherfgen via Maxima-discuss <[email protected]> Mon, 27 Jul 2026 00:34:24 +0200
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <CAMTHLKgq8nDPkuTWm-83eoNia9ZTSAJzDOf1FAwb1EtBagkocQ@mail.gmail.com> |
--===============0878396627682830692== Content-Type: multipart/alternative; boundary="000000000000def10506578b3550" --000000000000def10506578b3550 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In this extreme case, maybe it's pathological. But comparisons happen all the time in the general simplifier, via sign, csign, mgrp, etc., and in integration, limits, equation solving, ... Over a Maxima session, these number nodes accumulate irreversibly and keep slowing down Maxima more and more. Or maybe someone uses random numbers in expressions for some fancy algorithm, that would be the absolute "killer". Yes, Claude proposed a hash table. It can speed up some parts of this. Also, I think the database should only create nodes for numbers that actually appear in facts, and not as soon as they're used in a pure query. Raymond Toy <[email protected]> schrieb am Mo., 27. Juli 2026, 00:04: > On 7/26/26 2:29 PM, David Scherfgen via Maxima-discuss wrote: > > Hi all, > > Something funny to try: > > run_testsuite(tests=3D[rtest_limit_extra]); > for i : 1 thru 10000 do is(f(x) > i); > run_testsuite(tests=3D[rtest_limit_extra]); > > The second test run takes about 15 times as much time as the first one. > > Why? Because when asking is(f(x) > i), a database node for the number i i= s > created (if there's none yet) in the variable *NOBJECTS*. This slows down > subsequent sign queries, because Maxima has to search in a list that gets > longer and longer. > > Kinda funny, but certainly a rather pathological case. This doesn=E2=80= =99t seem > like something anyone would do on purpose. (Maybe I lack imagination.) > > Could it be replaced by a hash table? I suppose that might break lots of > code? > ​ > _______________________________________________ > Maxima-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > --000000000000def10506578b3550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">In this extreme case, maybe it's pathological. But co= mparisons happen all the time in the general simplifier, via sign, csign, m= grp, etc., and in integration, limits, equation solving, ...<div dir=3D"aut= o"><br></div><div dir=3D"auto">Over a Maxima session, these number nodes ac= cumulate irreversibly and keep slowing down Maxima more and more. Or maybe = someone uses random numbers in expressions for some fancy algorithm, that w= ould be the absolute "killer".</div><div dir=3D"auto"><div dir=3D= "auto"><br><div dir=3D"auto">Yes, Claude proposed a hash table. It can spee= d up some parts of this. Also, I think the database should only create node= s for numbers that actually appear in facts, and not as soon as they're= used in a pure query.</div></div></div></div><br><div class=3D"gmail_quote= gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Raymond Toy &= lt;<a href=3D"mailto:[email protected]">[email protected]</a>> s= chrieb am Mo., 27. Juli 2026, 00:04:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex"><u></u> =20 =20 =20 =20 =20 <div> <div> <p style=3D"margin-bottom:19.2px;margin-top:0px">On 7/26/26 2:29 PM, David Scherfgen via Maxima-discuss wrote:<br> </p> <blockquote type=3D"cite" style=3D"border-color:rgb(119,119,119) rgb(= 119,119,119) rgb(119,119,119) rgb(114,159,207);border-left-width:2px;border= -left-style:solid;color:rgb(119,119,119);column-rule-color:rgb(119,119,119)= ;margin:19.2px 0px;outline-color:rgb(119,119,119);padding-left:16px;padding= -right:16px;quotes:none;text-decoration-color:rgb(119,119,119);text-emphasi= s-color:rgb(119,119,119)"> <div dir=3D"auto">Hi all, <div dir=3D"auto"><br> </div> <div dir=3D"auto">Something funny to try:</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">run_testsuite(tests=3D[rtest_limit_extra]);</di= v> <div dir=3D"auto">for i : 1 thru 10000 do is(f(x) > i);</div> <div dir=3D"auto">run_testsuite(tests=3D[rtest_limit_extra]);</di= v> <div dir=3D"auto"><br> </div> <div dir=3D"auto">The second test run takes about 15 times as much time as the first one.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Why? Because when asking is(f(x) > i), a database node for the number i is created (if there's none yet) in the variable *NOBJECTS*. This slows down subsequent sign queries, because Maxima has to search in a list that gets longer and longer.</div> </div> </blockquote> Kinda funny, but certainly a rather pathological case. This doesn=E2=80=99t seem like something anyone would do on purpose. (Mayb= e I lack imagination.) <p style=3D"margin-bottom:19.2px;margin-top:0px">Could it be replaced by a hash table? I suppose that might break lots of code?</p> </div> <div style=3D"height:0px;width:0px;max-height:0px;max-width:0px;overflo= w:hidden;font-size:0px;padding:0px;margin:0px" aria-hidden=3D"true" title= =3D"MDH:PGJyPjxicj48ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDcvMjYvMjYgMjo= yOSBQTSwgRGF2aWQgU2NoZXJmZ2VuIHZpYSBNYXhpbWEtZGlzY3VzcyB3cm90ZTo8YnI+PC9kaX= Y+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBTVRITEtnYU9QZk9yMXNEQUo4M= ys3TURoOWY3bnNtY1V6Yy1leEQ0M2VuRlN6WDU9UUBtYWlsLmdtYWlsLmNvbSI+CjxtZXRhIGh0= dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyAiPjxkaXYgZGlyPSJ= hdXRvIj5IaSBhbGwsPGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+U2= 9tZXRoaW5nIGZ1bm55IHRvIHRyeTo8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2Pjxka= XYgZGlyPSJhdXRvIj5ydW5fdGVzdHN1aXRlKHRlc3RzPVtydGVzdF9saW1pdF9leHRyYV0pOzwv= ZGl2PjxkaXYgZGlyPSJhdXRvIj5mb3IgaSA6IDEgdGhydSAxMDAwMCBkbyBpcyhmKHgpICZndDs= gaSk7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPnJ1bl90ZXN0c3VpdGUodGVzdHM9W3J0ZXN0X2xpbW= l0X2V4dHJhXSk7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0b= yI+VGhlIHNlY29uZCB0ZXN0IHJ1biB0YWtlcyBhYm91dCAxNSB0aW1lcyBhcyBtdWNoIHRpbWUg= YXMgdGhlIGZpcnN0IG9uZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGl= yPSJhdXRvIj5XaHk/IEJlY2F1c2Ugd2hlbiBhc2tpbmcgaXMoZih4KSAmZ3Q7IGkpLCBhIGRhdG= FiYXNlIG5vZGUgZm9yIHRoZSBudW1iZXIgaSBpcyBjcmVhdGVkIChpZiB0aGVyZSdzIG5vbmUge= WV0KSBpbiB0aGUgdmFyaWFibGUgKk5PQkpFQ1RTKi4gVGhpcyBzbG93cyBkb3duIHN1YnNlcXVl= bnQgc2lnbiBxdWVyaWVzLCBiZWNhdXNlIE1heGltYSBoYXMgdG8gc2VhcmNoIGluIGEgbGlzdCB= 0aGF0IGdldHMgbG9uZ2VyIGFuZCBsb25nZXIuPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPktpbm= RhIGZ1bm55LCBidXQgY2VydGFpbmx5IGEgcmF0aGVyIHBhdGhvbG9naWNhbCBjYXNlLiZuYnNwO= yBUaGlzIGRvZXNuJ3Qgc2VlbSBsaWtlIHNvbWV0aGluZyBhbnlvbmUgd291bGQgZG8gb24gcHVy= cG9zZS4mbmJzcDsgKE1heWJlIEkgbGFjayBpbWFnaW5hdGlvbi4pPGJyPjxicj5Db3VsZCBpdCB= iZSByZXBsYWNlZCBieSBhIGhhc2ggdGFibGU/Jm5ic3A7IEkgc3VwcG9zZSB0aGF0IG1pZ2h0IG= JyZWFrIGxvdHMgb2YgY29kZT88YnI+PGJyPjx1bCBjbGFzcz0iZHJvcGRvd24tbWVudSB0ZXh0Y= 29tcGxldGUtZHJvcGRvd24iIHN0eWxlPSJkaXNwbGF5OiBub25lOyBwb3NpdGlvbjogYWJzb2x1= dGU7IHotaW5kZXg6IDEwMDA7IiBjb250ZW50ZWRpdGFibGU9ImZhbHNlIiBwb3BvdmVyPSJhdXR= vIj48L3VsPg=3D=3D">&#8203;</div> </div> _______________________________________________<br> Maxima-discuss mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank" r= el=3D"noreferrer">[email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/maxima-discuss" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://lists.sourceforge.net/= lists/listinfo/maxima-discuss</a><br> </blockquote></div> --000000000000def10506578b3550-- --===============0878396627682830692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0878396627682830692== 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 --===============0878396627682830692==--