(11.07.2013 18:45 )Holy schrieb: [ -> ]Wieso soll das unausgegoren sein? Du sagst doch selbst das die performanteren Lösungen alle nur für bestimmte Fälle funktionieren.
Das Äquivalent zum "bedingten Anhängen" hat schon immer seine Daseinsberechtigung gehabt und lässt sich dadurch nur schneller programmieren und es gibt mehr Überblick. Das die Performance dieser Lösung nicht optimal sein kann war nicht anders zu erwarten.
1. Behaupte nicht ein Experte zu sein, aber:
2. Die OpenG Lösung existiert schon ne Weile und man hätte die einfach als Vorbild nehmen können weil die
3. nur deswegen eingeschränkt funktioniert da man als Nutzer eben nur Polymorphe VIs machen kann und das wars - die erfassen natürlich nicht jeden Denkbaren Fall. NI kann dagegen eine Funktion bauen die eine Referenz auf ein beliebiges Objekt entgegennimmt und dann das macht was das OpenG VI für die einzelnen ausprogrammierten Fälle macht.
Und ja - ich erwarte schon von NI was besseres als die Minimallösung Build Array mit Case pro Durchlauf hat. Das is genauso eine Schluderei wie Einheiten einzuführen - was tatsächlich erstmal interesse weckt - nur um Elementare Funktionen wie Quadrieren etc. nicht richtig damit rechnen zu lassen...
Na ja egal...
Gruß Kiesch
(17.07.2013 08:54 )Kiesch schrieb: [ -> ]2. Die OpenG Lösung existiert schon ne Weile und man hätte die einfach als Vorbild nehmen können weil die
3. nur deswegen eingeschränkt funktioniert da man als Nutzer eben nur Polymorphe VIs machen kann und das wars - die erfassen natürlich nicht jeden Denkbaren Fall. NI kann dagegen eine Funktion bauen die eine Referenz auf ein beliebiges Objekt entgegennimmt und dann das macht was das OpenG VI für die einzelnen ausprogrammierten Fälle macht.
Und ja - ich erwarte schon von NI was besseres als die Minimallösung Build Array mit Case pro Durchlauf hat. Das is genauso eine Schluderei wie Einheiten einzuführen - was tatsächlich erstmal interesse weckt - nur um Elementare Funktionen wie Quadrieren etc. nicht richtig damit rechnen zu lassen...
Man kann sicher eine gewisse Erwartungshaltung haben aber sollte an der Stelle auch realistisch sein. Ein VI zu bauen welches nach der Schleife platziert wird und dann filtert ist kein Problem. Eine Primitive die alle Datentypen kann sollte für NI auch noch gehen. Aber hier gehts doch eher um eine Option eines Terminals und bei diesem sieht es dann bestimmt nichtmehr so trivial aus. Das Verhalten von Terminals wird prinzipiell ein anderes sein als das man ohne weiteres beim letzten Aufruf des Terminals speziellen Code ausführt. Denke nicht das dies mal so hop hop realisiert ist. Mal davon abgesehen ist NI hier nicht besser oder schlechter wie ihre Mitbewerber...
Bei dem Beispiel mit den Einheiten wurde wirklich viel verschlafen
Wobei das Problem hier genau andersrum ist. Die Einheiten kamen sehr zeitig. Ein Großteil der Mathematikfunktionen später. So mal als Randnotiz: Versuch mal generische Einheiten mit $1, $2 etc..
Meine Erwartungshaltung ist: Wenn NI schon ein Feature implementiert, dann sollte es auch funktionieren. Ansonsten soll mans doch bitte gleich rauslassen, dann weis ich auch das ichs selbst proggen muss wenn ich das haben will (und weis dann auch wie es genau funktioniert).
So wie jetzt gelöst ist das bedingte Einfügen in Arrays dysfunktional da einfach extrem langsam. Und bei zu filternden Arrays sind 1000 Elemente sicher keine Seltenheit.
Wenn das Feature nämlich drin ist - woher soll ich denn dann bitte ahnen, dass das SO extrem langsam ist. Hab auch erst hier erfahren dass NI das wohl "nur" über Build Array in jedem Durchlauf implementiert hat.
Aber es ist müßig das zu diskutieren. Also beenden wir das am besten
Öh hab die konkrete Neuerung die sich darauf bezieht iwie nicht gesehen / gefunden *kopfkratz*
Dafür einiges anderes was ich wirklich gut finde. Mal wieder mehr als nur bisschen Kosmetik ^^
Gruß Kiesch
*edit sagt*
doch noch gefunden im zweiten Webcast - sehr gut :-)
Warums nicht in der Featureliste stand versteh ich aber nicht
