shoneill

QUOTE (crelf @ Mar 3 2009, 03:41 PM) Can't you save a link to the file within the class and then have a class method to read the appropriate information on loading? Shane.

Adam, How about the entries for the NI coding challenges for one aspect. They're already more or less highly optimised so any changes in performance will reflect changes in how LV executes already optimised code. The danger in using less-then-optimally optimised code for benchmarks might be that a copy is avoided here or a type cast avoided there instead of measuring "real" improvements (or worsening) of performance.... We have a dictionary example, a prime number example (two very different approaches - one with the famous sieve of erastothenes which is a much-publicised benchmark) and other mathematical examples. Shane.

QUOTE (Aristos Queue @ Feb 25 2009, 05:15 PM) Ding! That's the right Idea I think, even though upwards expansion of property nodes still messes up wires but it'd be an improvement. It'd cause a stir and it'd take some getting used to though..... Shane

QUOTE (Ic3Knight @ Feb 25 2009, 04:18 PM) Since Property nodes are expandable imagine the mess which would be created if the error wire was dragged up and down with the lower edge of the property node..... If anything, the upper part (Refnum & Error connector) could be made larger to support the standard Connector wiring scheme spacing. Less error wire bends... Shane.

QUOTE (neBulus @ Feb 24 2009, 09:34 PM) Sounds a lot like Components to me..... Objects interact based on their interfaces... (possibly) seperate run-time instances for each item..... I like components but I don't see a clear distinction between them and "active objects". Anyone? Shane.

QUOTE (jcarmody @ Feb 24 2009, 04:07 PM) One think which has interested me for quite a while would be the old "Travelling Salesman" problem. Easy to understand, simple operations, extremely hard to optimise..... More on the topic HERE. Shane. PS Possible (n-1)!/2 solutions so.... 5 cities = 12 solutions 10 cities = 181 440 solutions 15 cities = 43 589 145 600 solutions (Ouch!) 20 cities = 60 822 550 204 416 000 solutions (more Ouch!)

QUOTE (jgcode @ Feb 23 2009, 11:26 AM) I've had great success with VirtualBox as long as the host isn't a windows machine. USB Passthrough is pretty flaky for a Windows host, but works great on Mac! I have a series of VMs (NI Licensing issued aside) with LV versions installed for different customers and I bring them with me on an external 2.5" HDD. I debugged and re-wrote a USB RAW driver for a spectrometer on Windows running as a guest on Macintosh. Worked flawlessly. I tried with Linux briefly (as host) and that worked too. I don't know about PCI (or PCI-E) passthrough, I don't think there is much going on in that direction but if you're using USB, Virtualbox should get you up and running. Shane.

QUOTE (Omar Mussa @ Feb 22 2009, 08:59 PM) I work a lot with user events and this kills me every time I change a typedef. It can get hairy sometimes trying to re-align the frames with the events on the dynamic terminals. Labelling sounds like a pretty good idea. Shane.

QUOTE (orko @ Feb 21 2009, 08:46 AM) Personally I think VISA USB RAW is quite buggy. I've got an issue open at the moment with NI support on some control transfers. Can you post an image of the code and a protocol analyzer example? Shane.

QUOTE (Aristos Queue @ Feb 12 2009, 04:48 AM) Well, yeah there are some things which are logically impossible, so manpower doesn't make any difference there. I think you are choosing to ignore the context of my comment but it's OK because you're right, not EVERYTHING is possible by throwing manpower at it. :worship: I think a limitation of the current system (Not meant in a judgemental way) is that the name is given the status of unique identifer, no? Why should it not be possible, for example, to have each and every LVClass (Or Object of a class more likely) have member data which is set by the current run-time as a unique ID upon loading. Could this not be used to differentiate between Classes of the same name? Perhaps there are really good reasons why an identifier must be static but I've unfortunately only enough knowledge to post questions on the subject, not answer them. This would extend to more than just LVClass I suppose, it's more a generalisation. Is this possible with LV today, probably no. Is it impossible to do, probably no. So while it might be impossible to prevent two classes having the same name, just as it is impossible to stop two classes containing a U32 called "Index" and set to zero, there are always possibilities to prevent this leading to the problems mentioned prevoiusly in the thread. I'm not trying to be a smart-###### ( ) but I don't see why something like this should be labelled impossible. Difficult, sure. Unlikely to ever be implemented, perhaps. Impossible? I don't like the word.... Shane. PS On mature recollection I reckon inheritance could be very difficult if a child class is dynamically loaded where more than one possible parent is in memory.....

QUOTE (Aristos Queue @ Feb 11 2009, 11:40 PM) I can also see need for something like this. The ability to create extensible frameworks with Objects (Loadable at run-time) which may have its origins well beyond our control means we cannot be sure that name collisions don't take place. I don't know the internals to LabVIEW but surely there must be a way to do this. But as I tell my customers quite often, everything's possible, it's just a question of manpower..... While I personally haven't (yet) run into this problem, I see it being an issue in the near future (for some apparently it's an issue already). Shane.

QUOTE (crelf @ Feb 9 2009, 04:38 PM) I was allergic to the auto tool in the beginning, but after using it for a while, it has become second nature. I miss it when it's not turned on..... One of those "just try it" things. Shane.

QUOTE (Bab @ Feb 6 2009, 10:40 PM) Doesn't the ROI continue to be modified after the mouse has "left the building" so to speak? This prevents being able to use the "Mouse leave" as an interaction termination. Shane.

QUOTE (Antoine Châlons @ Feb 6 2009, 02:27 PM) Ah Ok. I see where I misinterpreted this. The "mouse up" event problem when the mouse has left the control is a general problem, not just for this application. I really wish there was an easier way to manage this. It's a real pain to try to compensate for. Some functionality is basically impossible to implement (forcing a "mouse up" event to fire in LV. Shane.

What version of LV (or is it Vision?) has the "ROI Change Event"? I'm using 8.2 at the moment and I don't seem to be able to find it..... Sounds like a neat idea, but if it doesn't work then..... :headbang: Shane.

QUOTE (Antoine Châlons @ Feb 6 2009, 11:11 AM) The mouse up event works fine for me unless you want to do some work WHILE resizing the ROI. Shane.

QUOTE (nicolasB @ Feb 5 2009, 02:14 PM) The User Event takes the name of whatever control or constant used to type it on creation AFAIK. I personally would prefer a NAME input for the creation of user events, but that's currently not how it's implemented. The current situation basically prevents creating user events in a loop because they than all have the same name. Shane.

QUOTE (Aristos Queue @ Feb 3 2009, 12:06 AM) Just wanted to point out the execution time differences between a "proper" median search and a sort. There be no dragons here.... Shane.

QUOTE (Aristos Queue @ Feb 3 2009, 02:08 AM) Most I know had the same issues. It's nice to know that NI Employees aren't totally immune to these problems either..... Congrats Shane.

QUOTE (Aristos Queue @ Feb 2 2009, 09:03 AM) For 1 million DBL values, the NI Median implementation is 4 times faster than an array sort (According to my quick test). My median implementation is around 12-15 times faster than a sort. You need a lot of cores to make up that difference. I still maintain however that the index of a median position is in upwards of 90% of the time a non-existent entity. Shane.

QUOTE (Aristos Queue @ Feb 2 2009, 09:03 AM) Ooh, but that's not correct. Set the LabVIEW median routine to do that, and there'll be huge trouble trust me. I went into medians a bit deeper a few years ago during the Median Machine coding challenge on NIs site. I won by the way Finding the median required (at least) accessing every single element of the array. A single value in the array can shift the value of the median. How the 50% mark (from a value point of view, not an index point of view) is then a bit more complex. I used an old algorithm from Wirth (IIRC) which essentially did a sub-array bubble sort with special stop criteria. Have a look http://forums.ni.com/ni/board/message?board.id=170&message.id=103750&query.id=82589#M103750' target="_blank">HERE for my example. Shane.

QUOTE (Anders Björk @ Feb 1 2009, 06:05 PM) Please re-read my post: A median index normally does not exist! By far the majority of arrays being "medianed" are of even length. As such, the median value is not actually present in the array, therefore it can't have an index.... What you are requesting is impossible. Shane.

QUOTE (Anders Björk @ Feb 1 2009, 01:19 AM) If the array has an even number of elements, the median is the average of the two points just below and above the 50% value (top 50% and bottom 50%). This may of course result in a median being returned which is not, in itself, part of the array. Thus searching for this median will (almost always) be unsuccessful. You MAY luck out and have exactly the same value for the two respective values.... Only if the array has an odd number of elements will the Median returned actually be a member of the array. Shane.

Wow, quite a few posts since I left.... My personal take is that NI needs to address both "camps" of programmers with LV. Power programmers are the ones who can show off what's REALLY possible with LV, whereas the ease-of-use is a double-edged sword. I can appreciate the "bread and butter" aspect of things. No company is stupid enough to isolate themselves from their main customer base. But looking at longer-term adoption of LV, making people aware from the get-go that there's a lot more to LV than "ease of use" or "no programming experience required" will simply put those people in a different frame of mind. I think when many people take their first steps in LV, the "easy" thing lets them easily forget the two words "software engineering" and anything associated to it. Even the idea that there might be more to it might push more people to investigate the boundaries of LV instead of putting it down as a "nice toy". By all means market the "ease of use" but please just spare a few words for us poor misiunderstood "power progammers". I don't know HOW to do it, but hey, that's what maeketing people get paid for right? Shane.

QUOTE (Val Brown @ Jan 30 2009, 09:17 PM) I chimed in too. Man I really wish NI would do something about this "easy to use" and "no programming required" marketing guff. I mean WTF? It's hardly surprising these people have these opinions, they're being forced down their throat by NI.... Shane.