Posts by Christoph_Sitte


    Tut es ein Y-Kabel nicht? Der Strom aus zwei unabhängigen(!) USB-Anschlüssen zusammen müsste ausreichen.
    EDIT: zum Beispiel http://www.amazon.de/USB-Mini-…B000TG3H2S/ref=pd_cp_ce_2


    Bitte obigen Post nicht zu frei interpretieren. Zwei Unabhängige (was auch immer das heißen mag) USB-Anschlüsse müssen unbedingt von einem Rechner kommen. Sonst werden die Massen zweier verschiedener Rechner verbunden, was zu großen Ausgleichsströmen führen kann. Ich habe von einem Fall in der mittelbaren Bekanntschaft gehört, der hat sich auf diese Art mindestens ein Mainboard geröstet : :augenzu: : Er wollte eine Wechselplatte mit einem Y-USB-Kabel an zwei Rechnern gleichzeitig betreiben.


    zur Vorsicht mahnende Grüße
    Christoph

    Meine USB-Abdeckung (Plastik-Deckel an dünnem Halteseil) ist vor langer Zeit abgegangen, ohne dass ich davon Einschränkungen gespürt hätte. Jetzt, wo ich es genauer anschaue, geht von der Buchse ein Haarriss zum Display. Aber ich sehe dabei keinen Zusammenhang zum Vorhandensein der USB-Abdeckung, es ist auch nicht der einzige Haarriss.


    Ich habe bisher diesbezüglich keinen Support aktiviert.


    Gruß-Christoph

    Das nenne ich mal eine sauber recherchierte Meldung. Ganz großen Respekt an die "Journalisten" die für diesen Artikel verantwortlich sind.


    Wenn man das so interpretiert, dass ab sofort auch der Kalender integriert ist, sozusagen ab WebOS 2.0 Kontakte mit Terminen verknüpft werden können, empfände ich dies tatsächlich als Fortschritt. Hätte allerdings nicht allzuviel mit Synergy zu tun. Allgemein stimme ich dir zu, jemand hätte dem Journalisten sagen sollen, dass Synergy bereits seit WebOS 1.0 dabei ist. Aber der Name der Quelle, MacNews, klingt nicht so, als wäre eine objektive oder gar WebOS-freundliche Berichterstattung zu erwarten.


    MfG-Christoph

    Öhm, was sind eigentlich microflops ? :verwirrt:


    FLOPS: Floating-Point Operation per Second; Maßeinheit für die Geschwindigkeit von u.a. Supercomputern und Clustern. Aktuell sind Supercomputer im Peta (10^15) - Flops-Bereich. => Ein microFLOPS ist eine Fließkommaoperation in einer Million Sekunden (etwa 2 Wochen...), soll wohl leicht sarkastisch auf eine eher unwesentliche Mehrleistung eines Prozessors gegenüber einem anderen hindeuten.


    Erklärende Grüße - Christoph

    Das beschriebene Vorgehen hätte zur Konsequenz, dass



    • alle Bilder bei dir auf dem Server landen und
    • ich zum Abspeichern meines Bildes, dieses zuerst hoch, und anschließend wieder herunterladen muss?


    Der erste Punkt stört mich nicht wirklich, es sind ja keine sensiblen Daten. Der zweite Punkt erfordert eine aktive Datenverbindung und braucht Zeit. Sehr schade, vor allem wenn man für sein System den fstab-bug gefixt hat und ein lokales Abspeichern funktionieren sollte.


    Unschön, aber anscheinend momentan nicht vermeidbar. Hoffentlich ist dieses Problem mit dem nächsten WebOS-Update Geschichte.
    MfG Christoph

    Ich vermute, ich habe da noch ein Verständnisproblem. Soll das Bild wirklich auf deinem Server gespeichert werden? :verwirrt: Ich hatte ja auf eine lokale Lösung auf dem Pre gehofft.


    MfG Christoph

    MetaView: auch die 1000 Iterationen sind schon viel besser als 200 :thumbup: aber für ausgedehnte Zoomfahrten, zu denen das Programm regelrecht einläd, immernoch zu wenig ;( . Gibt es einen zwingenden Grund, die Maximale Iteration zu beschränken, außer, den Anwender vor Wartezeiten zu schützen?


    @OWL: Hast du dein altes Fraktalprogramm gefunden?


    Diskussion am Laufen haltende Grüße - Christoph

    Ich müsste mir für die schon berechneten Punkte aus der vorherigen Zoomstufe nicht nur den Iterationswert, sondern halt auch den Ergebniswert abspeichern.

    Diese Maßnahme bringt nur etwas für schwarze Punkte, wenn jemand die maximale Iterationszahl erhöht. Für diesen Fall wäre die Ersparnis an Rechenzeit erheblich. Fürs Zoomen bringt das IMO nichts.

    Jetzt versuche ich erstmal das Abspeichern zu erledigen. Das ist dank des Schreibberechtigungs-Bugs im 1.4.5 nicht so trivial.


    Das wäre wirklich schön. Um so mögliche Desktop-Hintergrundbilder zu erhalten, müsste vor dem abspeichern der Bildbereich vergrößert (und dementsprechend teilweise neu berechnet) werden.


    LG Christoph

    Jetzt hast Du mein Klugscheissergen meinen Ehrgeiz geweckt. Ich suche mal nach den Sourcen meines Eigenbau-Mandelbrotprogramms - dort hab' ich das so gemacht.
    Am Outline-Algorithmus hab' ich mir damals die Zähne ausgebissen und war hinterher vom Geschwindigkeitsgewinn eher enttäuscht. Naja, vielleicht war da meine Erwartungshaltung zu hoch...


    Ich bin gespannt auf den Algorithmus. Hoffentlich sind deine Disketten noch lesbar. Mein Programm finde ich mit Sicherheit nicht mehr.


    Ich bin mir nicht sicher, ob dieses Thema noch sicher, dass das Thema nicht mehr von allgemeinem Interesse ist. Sollte man da Konsequenzen ziehen?


    MfG Christoph

    Ich muss als diabetiker nach dem essen den zuckerwert messen. Wenn ich immer zu genau festgelegten zeiten essen würde, wäre das einfach mit den pre-alarms einzustellen. Da das nicht der fall ist, hätte ich gerne einen onscreen-button, der mich automatisch zwei stunden später weckt.


    Das Programm T-Minus (ein einfacher Countdown-Timer aus dem offiziellen Katalog für 1€ wenn ich mich recht erinnere) sollte das Problem lösen. Bei mir weckt er allerdings bereits nach zwei Minuten, dann muss der Tee wieder raus aus der Kanne. Ist aber einfach konfigurierbar, auch auf zwei Stunden.


    MfG Christoph

    Beim ersten Bild einer Zoomreihe muss natürlich jede Iteration durchgerechnet werden. Bei darauf folgenden Zooms kann aber davon ausgeganen werden, dass die niedrigste erfolgreiche (also nicht konvergierende) Iterationstiefe des Ursprungsbildes auch im Zoom mindestens die niedrigste erfolgreiche Iterationstiefe ist.


    Der von Dir noch angesprochene Outline-Algorithmus ist sehr schick und sieht auch cool aus, wenn man ihm beim Rechnen zusieht - bei hohen Rechentiefen bringt er aber keinen Gewinn mehr, wenn die Flächen auf einer Iterationsstufe immer kleiner werden.


    Ich muss in beiden beiden Punkten klar widersprechen.


    • bitte den ersten Abschnitt meines vorherigen Posts nochmals genau lesen. Kurz: Du hast Recht mit der Aussage, aber es nützt nix bei der Berechnung.
    • Alle mir bekannten Ausschnitte des Apfelmännchens haben Farbflächen. Auch beim Reinzoomen. Und bei Iterationstiefen von 800 oder mehr lohnt der Aufwand, festzustellen, ob ich ein Pixel berechnen muss oder nicht auf jeden Fall, selbst wenn die Farbflächen kleiner sind.


    MfG Christoph

    Auch wenn die beschriebenen Gesetzmäßigkeiten richtig sind, kann ich nicht erkennen, wie ich im Programm einen Nutzen daraus ziehen kann. Die Berechnung muss für jeden Punkt von Anfang an stattfinden, da das Ergebnis jeder Iteration als Basis für die folgende Iteration ist. Der Anfang ist eben der Punkt in der Komplexen Zahlenebene. Allein aus dem Wissen, dass ich über 800 Iterationen benötige, kann ich nicht auf das Ergebnis der Berechnung nach 800 Iterationen schließen um dort fortzufahren.


    Was ich mir vorstellen könnte ist eine Ausnutzung der Tatsache, dass in einfarbigen Flächen keine Überaschungen zu erwarten sind. Wenn ich also in ein Fraktal hineinzoome könnte ich mir vorstellen, die Berechnung für alle die Punkte, die im vorhergehenden Bild die gleiche Farbe wie alle ihre Umgebungspunkte haben, wegzulassen. Damit würden nur Grenzen zwischen Farbflächen neu berechnet und es könnte erheblich Rechenzeit gespart werden. Das gilt sogar für die schwarzen Flächen (Konvergenzbereich) es sei denn die Iterationstiefe wurde geändert.


    Ich weiß nicht, ob MetaView bereits auf irgendeine Weise die Berechnung optimiert, oder ob im aktuellen Programm jedes Pixel berechnet wird.


    MfG - Christoph

    Das Update ist toll, danke dafür :thumbup:


    Es gibt noch ein paar Möglichkeiten, das Berechnen zu optimieren. Neben anderen Algorithmen, die nicht stur einen Punkt nach dem anderen durchrechnen wäre es gut, statt nur die maximalen Iterationen festzusetzen, auch das Minimum abzufragen und Berechnungen darunter nicht durchzuführen. Gerade bei großen Zoomtiefen macht es einen großen Unterschied, ob man zB von 0 bis 1000 bis zur Konvergenz durchrechnen muss oder nur von 800 bis 1000...


    Nanu? Das überascht mich. In meinen Fraktalprogrammen (vor 15 Jahren, mit Turbo-Pascal ^^ ) musste ich für jeden Punkt alle Iterationen durchrechnen. Ich wüsste nicht, wie man die ersten 800 einsparen kann. Kannst du mir da eine Quelle nennen, in der ich nachlesen kann, wie ein solcher Algoritmus funktioniert?


    LG Christoph

    Neues Update zu Palm geschickt:
    * Seitenverhältnis angepasst
    * max. Iterationsanzahl auf 1000 erhöht


    Initial ist das Bild etwas aus der Mitte geschoben, dadurch kann man aber gleich weit reinzoomen ohne im Schwarzen zu landen.


    Ich habe das Update gerade heruntergeladen, das Programm hat dadurch erheblich gewonnen und macht noch mehr Spaß. Vielen Dank an MetaView :thumbup:


    MfG - Christoph

    ein ketzerischer Vorschlag: Ist schon darüber nachgedacht worden, mit dem Preforum zusammenzuarbeiten? Nach meiner Beobachtung überschneiden sich die Themenbereiche sehr stark (zumindest alles was Pre, Pixi und WebOS betrifft), und beide Foren haben ein überschaubares Potenzial an regelmäßigen Schreibern. Ich als hauptsächlicher Leser schaue regelmäßig beide Foren durch.


    Ich könnte mir vorstellen, dass mit einer Zusammenlegung der Foren sowohl finanziell als auch inhaltlich Synergieeffekte erreicht werden können.


    LG-Christoph


    Ok, aufgrund von heftigem Gegenwind ziehe ich den Vorschlag mit sofortiger Wirkung zurück und behaupte sofort das Gegenteil. :pfeift: Die Forenatmosphäre ist hier tatsächlich angenehmer als anderswo und sollte in dieser Form erhalten und nicht durch die Zusammenlegung mit einem anderen Forum gefährdet werden.



    Asche auf mein Haupt. - Christoph

    ein ketzerischer Vorschlag: Ist schon darüber nachgedacht worden, mit dem Preforum zusammenzuarbeiten? Nach meiner Beobachtung überschneiden sich die Themenbereiche sehr stark (zumindest alles was Pre, Pixi und WebOS betrifft), und beide Foren haben ein überschaubares Potenzial an regelmäßigen Schreibern. Ich als hauptsächlicher Leser schaue regelmäßig beide Foren durch.


    Ich könnte mir vorstellen, dass mit einer Zusammenlegung der Foren sowohl finanziell als auch inhaltlich Synergieeffekte erreicht werden können.


    LG-Christoph

    Na dann :)


    ...und ich hoffe, dass es wenigstens 1000 weitere Nutzer gibt, die dies auch tun. :) Es gibt so viele Programme, die keinen wirklich praktischen Zweck verfolgen sondern einfach nur Spaß machen, und die auch für wenig Geld ihre Abnehmer finden. Ich denke, ein richtig gutes Fraktalprogramm kann da problemlos mithalten, vor allem wenn es als Hintergrundbildgenerator funktioniert und entsprechend beworben wird.


    Dass sich die Änderungen nicht für 2€ (d.H. in weniger als einer Viertel Stunde) realisieren lassen, ist mir durchaus klar.



    Ich wollte nur meine Ideen einbringen. Mir ist schon klar, dass dies schnell als Kritik verstanden werden kann, ;( was nicht meine Absicht ist. Darum: ein herzliches Danke schön :thumbup: an alle Programmierer, die uns mit ihren Programmen, anscheinend ganz ohne Eigennutz, Spaß aufs Pré bringen.



    LG


    Christoph

    @Autor


    Vielen Dank für das schöne Programm, es lässt sich einfach bedienen und zeigt schöne Fraktale an. Trotzdem drängen sich mir sofort mehrere Änderungswünsche auf:


    • Das Fraktal wird leicht verzerrt dargestellt. Der Eindruck wird durch eine exemplarische Rechnung gestützt: Verhältnis Realteil/Imaginärteil = 1,37, Verhältnis x/y des Bildes auf dem Bildschirm =1,11; Ein unverzerrtes Fraktal sieht einfach noch schöner aus, darum wäre dies mein erster Wunsch.
    • Die Begrenzung der Iterationen auf 200 beendet die Fahrten in die Tiefe des Fraktals nach sehr kurzer Zeit. Ich weiß, dass mehr Iterationen mehr Rechenzeit brauchen, aber bei 200 ist die Berechnung noch schnell genug (1GHZ - Kernel :pfeift: )
    • Dem vorher geäußerten Wunsch nach Fullscreen-Fraktalen schließe ich mich an. Für mich sieht ein optimales User-Interface so aus, dass es nur einen Knopf für Einstellungen (Bildbereich, MaxIter) gibt und das Zoomen mit der Fingergeste realisiert werden kann.
    • Perspektivisch wäre auch eine Integration anderer Fraktaltypen (Julia-Mengen, Newton) interessant.
    • Eine Speichermöglichkeit für fertig berechnete Bilder wäre klasse.


    für eine Pro-Version, die diese Änderungen berücksichtigt, bezahle ich gern 2€.



    Freundliche Grüße


    Christoph