Different behavior of internal patches (aka “Strange behavior by x-intersect”)

[neo]

Hello everyone, dear OMers.

I’m writing to report a problem I encountered using internal patches. The attached patch essentially contains an internal patch that applies the x-intersect function to two input lists, then performs some minor analysis with conditional operators (which I believe are irrelevant to the issue).

The problem is that for operations where the two numeric sets are equal or the second contains the first, the internal patch’s result is incorrect. It immediately occurred to me that I might have made a mistake in my programming, but I’m suspicious that if I insert the input lists from within the internal patch (by creating data boxes directly within the internal patch editor), the result I get is correct.

A small anomaly I also noticed is that if I customize the input arguments to evaluate the internal patch (double-click the green arrow icon - in the internal patch - representing the input, then insert a list to test the algorithm into the "default value” slot, and press apply), after two exact x-intersect evaluations, the list for one of the two inputs is reduced to a list containing the first element of the original list.

I’m using OM 7.6 and a MacBook Pro with an M1 chip with MacOS Sequoia 15.6.

I hope I haven’t posted a topic that’s already been addressed and resolved, in which case I apologize. Thank you in advance for your time and availability, and best wishes and a continued happy summer (at least for those in the Northern Hemisphere).

neo

outside-inside.omp (60.3 KB)

[haddad]

Dear neo,

The problem comes from the intern evaluation of x-intersect and its multiple connection with the conditional box. The graphic programing here is at its maximum challenge.
To keep this “unsure” behavior, you should put x-intersect box in eval-once mode:

there all your red patches will work correctly.

Best
K

[neo]

Dearest M° Haddad,

Thank you for your prompt response.

However, as you can see in the patch attached to this reply, setting x-intersect to “eval once mode” didn’t solve my problem, although inserting the arguments from within the internal patch didn’t cause any problems.

So I recomposed the patch, combining the idea of using “eval once mode” with a reformulation — perhaps with room for improvement — of the algorithm, and now I’ve achieved what I was looking for.
As you can see, it’s different from the previous version of the patch with only x-intersect in “eval once mode.”

I’m a bit unsure why “Graphic programming here is at its maximum challenge”. Is it because I compiled the algorithm in a way that wasn’t very fluid and clear?
In any case, I don’t mean to bore you with empty questions, and I thank you for your valuable contribution.

Best regards,

your neo

new patch.omp (95.8 KB)

[rc0]

Hello,

I don’t know if it is related but it seems that there’s a problem with x-intersect. I can reproduce it this way:

1. create new patch
2. double click in new patch to create a new object and write: x-intersect (1 2 3 4) (1 2 3 4)
   this will create an x-intersect object with the two lists hidden on each input respectively
3. evaluate the x-intersect pressing v on keyboard. The result in listener is (4 3 2 1)
4. evaluate again pressing v on keyboard. The result in listener is now (1)
5. check the first input of x-intersect. Now the list will be (1) instead of the original (1 2 3 4)

Is this an expected behavior?

best
rc

[neo]

Dear rc0,

I confirm: I’m getting the same x-intersect behavior you described. It’s essentially what I reported when I discussed custom inputs in the internal patch I presented this morning.

I haven’t installed the latest version of OM yet, so I don’t rule out the possibility of this, but I’d never noticed this problem before.

Regards everyone,

neo

[haddad]

Dear RC,

Yes, there seems to be a HUGE bug in x-intersect. In fact the value of the first input (l1?) changes after the first evaluation.
Since i’ve been maintaining OM, haven’t touch this method. So it seems to be there for quite a while. I will ASAP fix this .

Thanx to you both for reporting

Best
K

[haddad]

Ok got the bug. Just testing for the time being. Will release very soon a corrective patch.
Will let you know ASAP.

Best
K

[haddad]

Ok checked around, the bug was there before the sources were on Github so before 2018. Maybe was there since OM was created

Thank you for pointing this out.

Here is the patch for testing:
patch_190825b.lisp (240 Bytes)

Tell me if this works for you, so i can release it officially:

Reminder:

1. quit OM
2. put the patch in the init folder
3. relaunch and do some testing.

Thank you again both of you.

Best
K

[rc0]

Dear K,

Thanks for the quick solution. The patch works. And many thanks and credits to @neo for finding this!

(afair x-intersect was working ok on om6 but that was long time ago : )

best
rc

[neo]

Dear Mr. Haddad and rc0,

Thank you for your helpful contribution, it is a real privilege to be able to count on a forum of this level. I tested the x-intersect fix and it works perfectly. The first version of the patch I submitted this morning also works now, without having to make any changes.

Good continuation,

neo

[haddad]

Dear rc, dear neo,

Thanks to rc’s mentioning old OM version:

I looked up the code of version OM 5.2. and indeed, no changes there.
So I inspected the faulty method. And it appears it is due to nreverse function who is destructive (meaning operates changes upstream as a setf). And that is why it changes the internal input of x-intersect.

Explanation: This destructive behavior appears to be the nreverse LispWorks version, which by the way is compliant with CLOS (common lisp object system). The former versions of OM using MCL and Franz Allegro common Lisp didn’t have this side effect.

So sorry, this is an updated patch (although the first one will work. But this gets to thingd more accurately right - I hope at least

patch_190825b-2.lisp (2.0 KB)

If you can test it (take your time, no need to rush). But first remove the former patch)

Thank you again both of you. Your feedback is very precious and i am very grateful for this.

Best
K

[neo]

Dear Sir,

It’s very interesting to delve into the subject in this way. Thank you, as I would never have had the opportunity to come up with such an explanation.

I’ve tried a few patches with the new fix and I’d say I have nothing problematic to report. Thank you so much for your invaluable knowledge and helpfulness.

Best regards,

neo