ShaunR

RTree just gives you a bounded nearest neighbour search. How you come up with those bounds is not within that scope.

"Just". Without it, it would be a debugging nightmare and if I was coming up with that method, I would "just" think it wasn't working.

Yup. On first glance I thought something could have been done with bytearraytostring etc. But the handle created isn't an array (in the LabVIEW sense) so a Moveblock would be needed to copy into another array to dereference it (double the memory required-not what we want). The really devious bit of your code is the sequence structure. That's some voodoo I probably would never have thought of.

One of the requirements for 3d feature extraction is extracting datapoints in the neighbourhood of the feature. RTree is a good solution for that. RTree would give you the datapoints around your "finger", "elbow" and "shoulder" and you could draw lines between the centroid of those (giving you the lengths). Given you have three centroids you can then calculate the angle between the shoulder/elbow and finger/elbow.

I have done this for VIP, and Zip packages for an installer I've had on the back burner for a while.

I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.

Been there. Done that. Wouldn't a DSNewHandle suffice?

There is DSMaxMem and DSMemStats which aren't much use. Do you have any info on DSMemStatsSlow and DSMemStats2?

Did this today (and any other day I write C). for (int i=0; i < len; i++){ The big question is .. should it have been "a" instead of "i"?

I think you answered your own question there and used the two term method that I described. This is exactly why I said:

I don't think it's that hard. You just have to use two words, one of which describes the domain. Learning complexity, system, complexity, code complexity, network complexity et. al. They all adequately describe what's being talked about. I only had an issue with "accidental" complexity. When using non-domain terminology (like "accidental", "inherent" etc) it needs more defintion in the statement, for example "the inherent complexity of the code". The inherent complexity of the system, etc. This is mainly a grammatical problem rather than semantic.

Thanks.It worked great but I don't think I'm going to go through the other 13 versions and installing it.

Hmm. No 64 bit versions for 2009-2015. Thanks for the info.

I've got it in 2019 but not in all the other versions. Is there a separate test install for each version?

Potato, Potato Like i keep saying (and you agreed earlier) the Priority Queue is ordered PRIORITIES, not necessarily the elements (we disagree on this bit). The underlying implementation is irrelevant the name-it could even be a linked list.

Moderator comment: Discussion started here. Nice. However this is mine.

I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.

Perhaps in the AF case. However it's also fairly common for the underlying implementation to be a stack (LIFO). That is effectively what the DQMH implementation is. Like "accidental"? You understimate the power of a marketing department, my friend

Huh? I never said anything about an elderly person. Are you in the right thread?

Well. My supermarket obviously isn't as isn't classy as yours. Flashing a Platinum Amex and then moving to the front would probably get you a bop on the nose.

Yes. A Priority Queue orders priorities.

This I can get behind! 2&3 also map onto Whitebox and Blackbox testing. There is a test for 1 that I have seen (can't remember off hand what it was called) but it was mainly for c/c++ and counted things like the number of if/else or entries in Case statements to arrive at a figure for "complexity"

Yes. I'm saying the "concept" of priority queues doesn't.

As far as I'm aware. There is no guarantee (or expectation) that priority queues enforce ordering, only that higher priority messages will be executed before lower priority messages. I'm not familiar with the internal workings of the AF but if what you say is true (that order, at the same level, is guaranteed) then more of what you term "complexity" happens when that isn't required. An emergency stop springs to mind where you may not want the previous buffered messages to be executed, just the E-Stop. With the AF (based on your description) the user has to categorise different messages to different levels and I would suspect you woud also argue that is a "complexity". I wouldn't, however. Neither would I for the DQMH. I take your point about debugging and difficult to diagnose for the DQMH under certain conditions but it is a limitation of the design, and probably adequate for most scenarios if you don't make the guaranteed order assumption. The AF code also means practical debugging complexity due to the code paths which doesn't exist in the DQMH. So it's all 6 of one and half-a-dozen of the other to me. I expect the reverse order is more surprising to most people but it probably compiles and executes significantly faster than the AF one (just a hunch) so the limitations may have been a compromise to that. If you need a priority queue that guarantees order then that feature in the DQMH is not for you but I go back to my original statement that "here is no guarantee (or expectation) that priority queues enforce ordering, only that higher priority messages will be executed before lower priority messages." (this is a discussion that crops up in task schedulers too, by the way).

OK. But good or bad wasn't the question. I was after the definition of "Accidental Complexity" and what you've just said brings me back to what I said originally Here I am saying that the underlying complexity of the framework is a necessary evil that has been "accepted and considered" rather than "accidental". What you seem to be confirming from my interpretation of your suggestion is that any hidden complexity is "accidental" in the context of the meaning and therfore a Framework is accidental complexity. Anyway. I've pretty much come to the conclusion that it's just more of a woolly buzz phrase like "Synergy" and "The Cloud". It obviously means different things to different people and I've a sneaking suspicion that it's meaning depends on where blame will be apportioned