Looks like the x-range you require from bpf-extract (0.0 20.0) isn’t available in the provided bpf’s. I guess bpf-extract should issue a warning in this case.
But there’s more to this. #'bpf-extract seems to rely on looking up exact numeric matches (=) on a bpf’s x-points (low-level), so you’ll have to do all the arithmetic for intermediate values manually! Not sure why this is so.
Maybe you could file a bug-report, then we can fix things and check it doesnt break other things.
Dear Anders [Vinjar, and not Torsten Anders, like I erroneously thought for a moment!],
as you can see from my first screenshot, OM doesn’t ask me to write a log for the bug report, so I don’t know how to provide you more informations on the issue besides the patch. But if Jean, like you, can reproduce the error, then maybe it’s possible to create a fix – or so I hope…
Best,
Francesco
Seems you’re confusing names here 
There’s no need for more information, i’ve noted this as a bug now. Thanks.
-anders (Vinjar)
Sorry for my lapsus calami, Anders: if I’m not mistaken, both Torsten Anders and you had something to do with NoTAM, and worked extensively on OM, so this explains my momentary confusion!
Best,
Francesco Vitale
Hello.
The bpf-extract algo oes not lookup only with exact match (=) but behaves differently if the exact x-values are found or not in the initial BPF.
Then, as anders noted, the problem here is that both x1 and x2 are far below the lower x-point in the BPF.
I have fixed this (attached lisp file, put in OM 6.8/patches/) so that in this case, a BPF is returned with two points (at the two x1 and x2 bounds) and y = the closest y-point in the BPF. I am not sure this is the best choice to make but at least it makes no more error.
This fix will be included in the forthcoming release.
bpf-extract.lisp (1005 Bytes)
Thanks Jean.
Is there any chance to have also a 3dc-extract function? That would be very useful.
Best,
Francesco Vitale
Dear Jean,
I was working with your fixed function, and, until this evening, I had no problems. In fact, with the patch here attached, I encountered again an error (see the screenshot). What is wrong now? Thanks as always for your kind attention.
Best,
Francesco
error2.pdf (91.3 KB)
Dear Jean,
here’s another error that I encountered with your fixed function. As always, I attach here the patch that shows the error. I really hope that this annoying bug(s) will be fixed!
Best,
Francesco
error3.pdf (29.2 KB)
Hello Francesco.
Please first notice (for future reports) that this problem (as well as the previous ones) have nothing to do with the loop.
You can quite easily find where they come from, for instance using a FORLOOP box + print inside your OMLOOP. In this case you will see that the loop works well until BPF #14.
Indeed, BPF-extract (0 5) on this BPF generates an error because the whole BPF is outside the [0 5] range.
I can prevent the error to happen, as in the previous case, but it is better to know that the operation, even if it does not crash and returns a BPF, may not be very consistent.
j.
Thanks Jean,
I didn’t think at all of the FORLOOP box + print approach. But why bpf-extract, if the bpf is outside the range does not simply return “nil” instead of displaying an error? In this way, using bpf-extract in a loop, if the bpf in the bpf-lib is outside the required range, the resulting bpf-lib would simply have one less bpf.
Best,
Francesco
In this case you would have some NIL at some points in your BPF list, which will need to be filtered before to build the BPF-lib
But that’s an option.
Another option I was thinking about is to return a BPF with the required ranges (x1 x2) whatever happen, with y-values of the closest point before or after
This ensures that the returned BPF has always the required x1 and x2 range (see below).
Attached = the new bpf-extract.lisp file
That’s great Jean. Unfortunately I can’t see your screenshot (the attachment is replaced by a blue icon with a question mark: could you post it again?). Moreover, I see that I’ve created a double post with my last reply: sorry for that, and please delete one of the two messages, if you can do so (I can’t)
Anyway, even with the new bpf-extract (see the screenshot), when you use values that are outside the x range of the bpf, you get the same error. Maybe it would be preferable to have nil values to be filtered out if you have to build a bpf-lib!
I am pretty sure you should not see this error anymore now… except if this is another special case.
Can you attach the patch ?
I suspect you did not load my lisp file or still have the previous one at the same time.
Here it is. Tell me if you have the same error. I’m pretty sure that I’ve loaded your lisp file.
bpf-lib-extract-14-2.omp (40.8 KB)
I believe that the error is still there because you fix allows to have only x-min or x-max to be outside the x range of the bpf. If both x-min and x-max are outside that range (like in my example patch), the error will appear again.
no problem here.
can you check the sources of BPF-EXTRACT ? (press key ‘e’ on the selected box).
This should lead you to two definitions, one in the OM sources, one in the patches folder.
can you tell/show me what you see ?
In order do avoid conflicts between functions, since your first fix I didn’t put the lisp file in the patches folder, but I’ve simply pasted the code replacing the old bpf-extract function in 01-basicproject/functions/functions-lisp. So and pressing “e” I have only one definition, which is the one contained in the bpf-extract2.lisp you gave me yesterday. Maybe I shouldn’t have done so? Moreover, I’m on OM 6.7.
No, you shouldn’t
Modifying the sources a has no effect on the running environment.
Just put the file in the “patches” folder as advised
In fact, that was the issue! Now it works perfectly fine. Many thanks Jean.