Astrologie und Computerpower

Jetzt kann ich es mir nicht verkneifen. Es gibt VBA = Visual Basic f. Application. Hier kann man das umdichten:
VBA = Visual Basic f. Astrologie

(Visual-, ereignisorientiertes, objektorientiertes Programieren liegt mir nich!)

Der Autor von Morinus bezichnet sich als AAA (armer alter Astrologe) :LOL:

Rein vom Gefühl würd ich auch VB-Script nicht nehmen. "Kleinweich" hat mich zu oft frustiert. Obwohl das Windows 10 gefällt mir. Hab das Update sogar umsonst bekommen. Anscheinend hat Billy doch langsam genug Milliarden... :)
 
Werbung:
Ich habe eher den Eindruck, die Mehrzahl könnte kein Horoskop (egal nach welcher "Schule") ohne Computer erstellen. Einfach nur mit Papier und Stift (und gegebenenfalls ein paar Tabellen). Nur mein Eindruck... bin schon wieder still.

Du wirst lachen, ich habe damals noch in den Siebzigern mit einer Anleitung und Ephemeriden im Buch gemacht. So schwer ist das auch wieder nicht. :)
 
Ich habe eher den Eindruck, die Mehrzahl könnte kein Horoskop (egal nach welcher "Schule") ohne Computer erstellen. Einfach nur mit Papier und Stift (und gegebenenfalls ein paar Tabellen). Nur mein Eindruck... bin schon wieder still.

Ich finde dies als interessanter Hinweis.

Natürlich bin ich glücklich, daß ich nicht wie früher alles mit Papier, Stift und Tabellen erledigen muß und ich möchte es auch nicht missen. Ich bin auch der letzte, der jemand mit erhobenen Zeigerfinger verdonnern will, mal sein Radix selbst zu erstellen. Jedoch durch die Einfachheit des Computer geht Wissen und Kreativität verloren!

Wissen über den Prozeßablauf wie ein Radix entsteht.
Kreativität in dem Sinne mal vom üblichen Weg abzuweichen.
(Bei Aspekte statt die üblichen, mal mit Primzahlenzerlegung probieren.)

Wenn ein neues Objekt dazu kam, hat man sich die Eph. besorgt und einfach dazugemalt.
Ohne PC hätte man Lehrbücher, sowie Bracht, Rushman, Lilly einfach auf Papier nachvollzogen. Mit PC,das ist viel zu aufwendig. Gerade hier liegt viel Computerpower brach.
Man braucht sich nur mal ein Lehrbuch für Stundenastrologie anzuschauen. Der Prozeß wird vorgezeigt, es kommen jede Menge Zuweisungen. Der Mondlauf könnte grafisch vorbereitet werden. Bei Terminwahl könnten Solver ins Spiel kommen. ....

Die meisten heutigen Astrologe beginnen bei Pkt. 3 Deutung. Verweist al einer auf Pkt. 2 Regelwerk, kommen ungläubige Blicke: Was hat der denn?
 
Rein vom Gefühl würd ich auch VB-Script nicht nehmen. "Kleinweich" hat mich zu oft frustiert.
Ich hab bottom up programmiert. Aber mit Visual ist das genau andersrum. Erst wirdes buntund dann kommt die Funktion.
Obwohl das Windows 10 gefällt mir. Hab das Update sogar umsonst bekommen.
Solange die Geschichte mit dem Abo nicht geklärt ist, bleibt Win10 bei mir weg vom Computer.
 
Die meisten heutigen Astrologe beginnen bei Pkt. 3 Deutung. Verweist al einer auf Pkt. 2 Regelwerk, kommen ungläubige Blicke: Was hat der denn?

Wirklich? Also ich deute auch heute noch immer mit meinen eigenen Regelwerken. :unsure:

Ich hab bottom up programmiert. Aber mit Visual ist das genau andersrum. Erst wirdes buntund dann kommt die Funktion.

Was hältst du von Qt? Da hat man alles was wir hier besprochen haben unter einer Haube in einem Framework:

http://stupa.unija.ac.id/IT/en/free-journal-2649/Qt 4_3731_stupa-unija.html


Das Komplettpaket belegt allerdings 20-30 GB. Zum Anfang reicht erstmal der Qt Creator:

http://www.heise.de/download/qt-creator-1163227.html


:)
 
Da ich mit Python liebäugle um wieder zum programmiren zu kommen, habe ich C´t mitbekommen, daß Python über PySide auf Qt als GUI zugreifen kann. Jedoch nur objektorientiert, womöglich weil Qt in C++ geschieben ist.
Morinus, in Python geschrieben, verwendet gtk. Außerdem gibt es auch pyswisseph.

Was dafür spricht, wieder stäker in das Programmieren einzusteigen, zeigte mir dieser Faden, wieviel Computerpower im Bereich Astrologie brach liegt. Daß die möglichen Ideen, die bei mir Kopf rumschwirren, überwältigend sind.

Was dagegen spricht ist, daß für den heutigen Stil des Programmierens mein Wissen total veraltet ist. Visual, ereignis- und objektorieniert zu programmieren kann ich und liegt mir nicht. D.h. alles alte vergessen, Neubeginn. Wenn ich mir die Entwicklungen im Bereich OS, egal ob Windows o. Linux anschaue, vergeht mir auch der Spaß. Im Hardware-Bereich ist es z.Zt besonders UEFI. Und noch einiges andere mehr. ...

Zur Zeit ist eher mein Trend, dies alles an den Nagel zu hängen und ein ganz gewähnlicher DAU zu werden.

Also
Pluto: Stirb-Werde
Uranus: Neubeginn
 
Was dagegen spricht ist, daß für den heutigen Stil des Programmierens mein Wissen total veraltet ist. Visual, ereignis- und objektorieniert zu programmieren kann ich und liegt mir nicht. D.h. alles alte vergessen, Neubeginn. Wenn ich mir die Entwicklungen im Bereich OS, egal ob Windows o. Linux anschaue, vergeht mir auch der Spaß. Im Hardware-Bereich ist es z.Zt besonders UEFI. Und noch einiges andere mehr. ...

Das kenne ich. Objektorientiertes Programmieren entspricht nicht der menschlichen Denkweise. Doch bei Windowsprogrammierung und GUI's kommt man nicht darum herum. Die Zeiten wo man mit dem "Peek & Poke"-Heft auf den Knien auf dem Bildschirm zaubern konnte sind vorbei. Heute muss man erst tagelang die vorhandenen Objekt-Strukturen studieren bevor man ein paar Zeichen eingeben kann.

Ein bisschen habe ich das alte Feeling zurückgeholt bei der Programmierung mit ANSI-C. Das Einfachste ist noch immer das Schnellste. Die Beispielprogramme von Swiss Ephemeris sind ja auch in C.

Immerhin kann man sehr viel Zeit sparen, wenn man sich in ein Framework wie Qt einfummelt. Wenn man erstmal mit deren Denke und Stil vertraut ist kann man schnell viel erreichen. Anstatt sieben oder acht verschiedene Libraries jedesmal neu zu lernen und einzubinden, wobei man im schlimmsten Fall irre wird, ist alles im selben Stil gehalten.

:)
 
Die Zeiten wo man mit dem "Peek & Poke"-Heft auf den Knien auf dem Bildschirm zaubern konnte sind vorbei.
Ich bin sogar damals mit goto nach gosub gesprungen. Das habe ich dem Comodore -OS abgeschaut.
Heute muss man erst tagelang die vorhandenen Objekt-Strukturen studieren bevor man ein paar Zeichen eingeben kann.
Davor graust es mir - als reine IST-Betrachtung, weil wie du selbst schreibst:
Das kenne ich. Objektorientiertes Programmieren entspricht nicht der menschlichen Denkweise.
Obwohl es so propagiert wird.

Python kann struktuiert und OOP. Interessant ist es für mich auch aus einem anderen Grund: Himbeerkuchen (raspberry pi). Aber das ist ein ganz anderes Interessengebiet. Darunter fällt auch Arduino,welcher in einem C-Dialekt programmiert wird. Und so kommt man zum Mikrocontroller und da spricht einiges für ANSI-C (und ASM).

Nostalgie ist eher etwas für den Biergarten. Die Frage bei mir ist eher, wie geht es weiter?

Wenn ich Zeit habe, schaue ich mir den Quelltext von swetest an. Vielleicht traue ich mir zu darauf aufzubauen.
Ebenso berachte ich mir den Quelltext von Morinus (hoffentlich nicht zu opjektorientiert).

Astrolog 6.0 möchte ich mir auch mal anschauen. Daß es dies gibt, ist an mir vorbeigegangen. Nicht den Quelltext, der ist C++. (Schon lange her, als ich mit 5.4 experimentierte. ) Nur mal so vorsontiert. Kennst du dich aus bei asttrolog mit Parameteraufruf? Wäre womoglich eigener Faden wert.
 
Python kann struktuiert und OOP. Interessant ist es für mich auch aus einem anderen Grund: Himbeerkuchen (raspberry pi). Aber das ist ein ganz anderes Interessengebiet. Darunter fällt auch Arduino,welcher in einem C-Dialekt programmiert wird. Und so kommt man zum Mikrocontroller und da spricht einiges für ANSI-C (und ASM).

Ja, ANSI-C ist ein Dauerbrenner. Auch heute noch kann man damit alles machen, und schnell. Der Linux-Kernel ist wohl auch immer noch in C, ohne ++. Man kann auch eine Mischung nehmen, also eine Modularisierung des Programmes, innerhalb der Module C. GCC sollte das abkönnen. Habe viel mit MINGW und Allegro 4.4 gearbeitet. An der Kommandozeile und mit Codeblocks. Codeblocks nervt aber.

Wenn ich Zeit habe, schaue ich mir den Quelltext von swetest an. Vielleicht traue ich mir zu darauf aufzubauen.
Ebenso berachte ich mir den Quelltext von Morinus (hoffentlich nicht zu opjektorientiert).

Ich glaube zu viel Zeit in Python zu investieren lohnt nicht. Ist auf die Dauer nicht schnell genug.

Astrolog 6.0 möchte ich mir auch mal anschauen. Daß es dies gibt, ist an mir vorbeigegangen. Nicht den Quelltext, der ist C++. (Schon lange her, als ich mit 5.4 experimentierte. ) Nur mal so vorsontiert. Kennst du dich aus bei asttrolog mit Parameteraufruf? Wäre womoglich eigener Faden wert.

Ich wollte damals für Astrolog eine neue Grafikausgabe erstellen. Stellte aber fest, dass es ein fürchterlicher Spaghetticode ohne jeden Kommentar ist (5.4). Nein, das würde ich lieber alles neu machen. Und den Compiler, den der benutzt hat gibts wohl gar nicht mehr. Habe es mit verschiedenen C-Compilern versucht den Code zu kompilieren, ging nicht. :)
 
Werbung:
Das schwierige ist, der Aufsetzpunkt ist swisseph, egal mit welcher Programmiersprache man aufsetzt. Zwischen swisseph und auf Schulen fixierte Programme gibt es eine Lücke von Möglichkeiten um sich Regeln aufstellen zu können und Computerpower zu nutzen.

Ich sehe es jetzt wieder im Faden "Aspekte". Man kann schön theoretisieren und mehr oder minder sich darüber in die Wolle kriegen - grins. Man sollte es ausprobieren können. Funkioniert das überhaupt. Prinzip: Versuch und Irrtum. Solange es nicht ausprobiert bzw. ausprobiert werden kann, bleibt´s in der Schwebe!

Wo von ich träume,wäre eine eigene Computersprache der Astrologie. Ich nenne sie mal fantasielos: AstroBasic. Sie könnte es in den Versionen light bis hypersuperprofessional geben. Sie sollte (verhältnismäßig) einfach handhabbar sein.

Dazu greife ich mal auf den Faden "Aspekte" zurück.

Definiere, siderischer Bezugspunkt folgender Sternbilder (Name, Anfangspunkt)

Da die Sternbilder unterschiedlich groß sind, kann man wie bei API Häuserhoroskop diese gleichgroß umrechnen.

Transformiere Sternbilder gleichgroß.

Ebenso könnte der Kreis von 360 auf 2520 Grad umtransformiert werden.
 


Schreibe deine Antwort....
Zurück
Oben