Leaderboard

No. Organizers of the BBQ are exempt from the prize pool. Note: I am not helping organize the BBQ this year, so I guess should be mine, right?....right?

Use strings (the ultimate variant) and you won't have any problems either crossing the network boundary or language implementation. Don't straight jacket yourself with LabVIEW classes which are tedious for encoding and completely rubbish for decoding.

ISldWorks is an interface that does not actually implement any code and therefore has no functionality. You would have to implement that interface yourself in order to provide any functionality. Since that is the case, an implementation in LabVIEW is impossible (you cannot implement .NET interfaces in LabVIEW) This is an example in VB where you create an instance from SldWorks.Application which is an ActiveX object! In order to create an ActiveX instance use the function from following palette: Connectivity >> ActiveX >> Automation Open Create a constant as input and choose 'Select ActiveX Object'. You'll get a list of available ActiveX-Objects (this of course requires you to actually have them installed) You should definately look into that, but this has absolutely nothing to do with your .NET assemblies! Your basic approach is okay, but whenever you want to use an object, you have to create an instance of it (or have a function return it). You only provided a constant that defines the type and no instance. This is very difficult for me to describe, so here is an example: Try this out, it works EDIT: Before I forget, I found a link to a document which describes some detailes to the interface mentioned ealier: http://sw.fcsuper.com/index.php?name=UpDownload&req=getit&lid=157

Couple of obvious things to start with. The equation looks rather like a convolution, which is equivalent to a multiplication in the Fourier domain. So at the very least, you need to take the FFT of your image before multiplying it with your Exponential array, and then computing the Inverse. In your upper For loop (which I presume is the subVI with an arrow on it) it looks as though you're trying to compute the matrix corresponding to the first exponential. Your equation defines an N x N array (not k x l array) in which k and l vary from 0 to N-1 (effectively they are a frequency domain analog of your image pixel positions, and the image should also be of size N x N). Your code does something quite different. You can also move many of the constants (anything not changing during the loop iteration) outside the loop, including the final Exponential, which will work just as happily, and usually faster, on a 2D array.

Yes, yes, and after you've taken that semester of CS courses, you should attend shoneil's "RT is hell" masters course. :-) I didn't say DD was free. In the context of the discussion at hand, it isn't the expensive part.

Oh, yeah. But the crime isn't in making the accessors dynamic dispatch. The crime is not being organized enough to design the parent class. And that crime can have serious penalties for your code. Using dynamic dispatch for data accessors will generate massive data copies -- no inlining, no inplace memory optimizations. That does NOT mean you should never do it... it means you should do it ONLY if you truly need your child to define the data storage or get involved in the validation. Luckily, this is a situation that should almost never happen. Really? Really.... but that means you need to understand why you generally should not be doing it. You are violating the Liskov Substitution Principle. LSP says simply, "Any promise made by the parent class must be upheld by the child class." Having a child that *narrows* the definition of acceptable data values is an explicit violation of LSP. This rule must be maintained for most frameworks to work correctly. A child can accept a wider set of values, but it cannot accept a narrower set. Consider: I have a framework that calls your parent class. I read the documentation on your Write Value.vi. What does that documentation say? It says, "This VI accepts any positive real number and returns an error for negative numbers." Great! So I pass in 7.5. I have no idea your child class even exists. The documentation for the parent class says "any positive number". Now your child class gets created and gets passed into my framework, and it returns an error for any fractional value. WHAT? How could I possibly design for such undocumented behavior? A child is free to be *less* restrictive than its parent, but not more restrictive. For example, there are child classes that will happily handle NaN values but a NaN to the parent class returns an error. If I'm writing a framework that uses the parent class, I'm going to be careful to check for NaN up front to avoid the error, but if I am in a section of the code where I have the child directly, then I may pass NaN. So, when would it be acceptable for a child to get involved in validation? When you've documented that "the range of acceptable values varies based on the object in this wire, meaning callers cannot validate inputs ahead of time and must be prepared for an error from this function for any data value." LSP is not something that can be checked by a compiler. It is the contract that you write on the parent class that people who have never heard or seen your child class rely upon. Important safety tip: If you are the author of both the parent and the child, whenever you write code that calls the parent, you should pretend you've never heard of the child class. Write explicitly for only the parent class contract. If you do that then the bugs that come up are bugs in the child. Trying to factor into the calling code all the things you know your child classes might do will lead you to writing very poor performance code in the callers -- you will error check for things that shouldn't ever be possible, you will double check values that should already be validated, all because you cannot trust your children to uphold the promises. At the time you write your parent class, you should definitely be able to say whether or not a child is going to need to do additional validation. You might change your mind later -- and if you do, you can go change the terminals to be dynamic dispatch at that time. But don't pay the cost up front just because you might need it later. The dynamic dispatching is not expensive. The data copies can be. For most methods, dynamic dispatch is fine because the data passing across the border is inputs to some algorithm and outputs are computation results -- the outputs don't have to stay behind in the method VI. For property accessors, it's expensive because you're leaving a copy of the data back in the object, and no inplace sharing or other memory optimizations are possible across a dynamic dispatch call.