Re: Database madness

--===============6919096969690283854==
Content-Type: multipart/alternative; boundary="00000000000066242006579527b2"

--00000000000066242006579527b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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. This 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 existing
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 by
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]=
rge.net>
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-discu=
ss
>> <[email protected]> wrote:
>>
>>>
>>> In this extreme case, maybe it's pathological. But comparisons happen a=
ll 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 have
>> 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
>

--00000000000066242006579527b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">It&#39;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&#39;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&#39;s OK and expected if performance deg=
rades with growing number of assumptions in the system. But pure queries (&=
quot;What&#39;s the sign of sin(x)-100?&quot;) 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 gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">Gunter K=EF=BF=BDnigsmann via Maxima-discuss &lt;<a=
 href=3D"mailto:[email protected]">maxima-discuss@lists.=
sourceforge.net</a>&gt; schrieb am Mo., 27. Juli 2026, 09:07:<br></div><blo=
ckquote 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">Actual=
ly I encounter that slowness frequently when trying to make Maxima deal wit=
h 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 27 July 2026 06:45=
:09 CEST, Robert Dodier &lt;<a href=3D"mailto:[email protected]" targ=
et=3D"_blank" rel=3D"noreferrer">[email protected]</a>&gt; wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;borde=
r-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>&lt;<a href=3D"mailto:[email protected]=
forge.net" target=3D"_blank" rel=3D"noreferrer">[email protected]=
forge.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin-bottom:1ex"><div dir=3D"auto"><br>In this extreme case, maybe it=
&#39;s pathological. But comparisons happen all the time in the general sim=
plifier, via sign, csign, mgrp, etc., and in integration, limits, equation =
solving, ...<br></div></blockquote><div dir=3D"auto"><br>Right, it is not p=
athological, it is not hard to encounter it. I have<br>bumped into it via a=
n implementation of a piecewise interpolating<br>function which produces fu=
nctions which look like<br><br>  if x &lt; 0.5 then ... elseif x &lt; 1.2 t=
hen ... elseif x &lt; 5.3 then ...<br><br>which ends up creating database i=
tems for 0.5, 1.2, 5.3, etc.<br>Obviously this becomes a problem if the num=
ber of pieces in the<br>piecewise function is large.<br><br>FWIW<br><br>Rob=
ert<hr>Maxima-discuss mailing list<br><a href=3D"mailto:Maxima-discuss@list=
s.sourceforge.net" target=3D"_blank" rel=3D"noreferrer">Maxima-discuss@list=
s.sourceforge.net</a><br><a href=3D"https://lists.sourceforge.net/lists/lis=
tinfo/maxima-discuss" target=3D"_blank" rel=3D"noreferrer">https://lists.so=
urceforge.net/lists/listinfo/maxima-discuss</a><br></div></pre></blockquote=
></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>

--00000000000066242006579527b2--


--===============6919096969690283854==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6919096969690283854==
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

--===============6919096969690283854==--