Skyscript Astrology Forum

Hi Joao

I've sent you some messages by PM, this doesn't seem like the best place to discuss such technicality in depth.

In short though, the problem is not complicated. The swiss ephemeris allows a mode to enable the sidereal option (with a parameter to detail which ayanamsha). You can then simply store this client side like you say and send it as part of every request to the API, which is simple if you keep your API requests in one place on the client-side. This would mean very little code change and would technically accomplish the problem of adding a sidereal option programmatically fairly easily.

The next problem would be more about UX and design, deciding where and how to convey these options and which option has been chosen and whether you want to display the chart in a new manner to reflect the sidereal zodiac in use, or else of course keeping it the exact same.

As I say, I don't think this is all that complex, it may be a little time consuming on the client side to alter them all in this manner, and there's some small refactor work server side. See my PM for more specifics.

Include the fact that 30? (which is the sum I've got from selling Android charts so far) is about half an hour of work considering my usual freelance rate, and you start to understand what Curtis is saying about making a living out of selling astrology software.

Right, one place I certainly don't disagree with Curtis is that making astrology software is a lucrative business and will make you rich. It won't, but my disagreement was more that this was technically very challenging to accomplish because I really don't think it is.

Of course you could say the same for any number of other features. What's obvious is that you have coded the software, unconsciously, with a recognition that the concept of a house system is something for which options occur. The only real problem here is that you didn't think to do the same with the zodiac, which is fine, it just means there's going to be some refactoring, and I actually don't think it will be too much.

Edit:
Only saw zoidsoft's comment about thread safety, according to the documentation, swiss ephemeris is indeed thread safe, so this shouldn't be a problem.

zoidsoft wrote: I'm sorry.

Apology accepted, I just don't like the idea that if someone disagrees the only rationale must be that they don't know anything about the subject. Sometimes legitimate disagreement exists and people can always just agree to disagree.

I need a vacation. Delphic Oracle is now at 480,000+ lines of code (believe it or not that is refactored OOP code with over 50 custom IDE components on the palette for astronomical calculations, collision avoidance, etc...). Despite doing the best work of my life by far, people appreciate it less and less (and expect more and more).

Well I can understand that and I can believe how many lines of code there is. I think that's the nature of software development, especially in a world where most people don't understand what goes into creating a piece of software. We see a world in which software technology changes so quickly and improves so rapidly that there's an assumption that this software must be very easy to do, when it probably isn't the case - creating software is not like creating a spreadhseet or a word document, and it's much harder to account for change.

And the field continues to fracture into an endless array of techniques for astrologers looking for good "hits". I ask you again, when does it end? Software never does, but astrology just might if it keeps going on without some underlying standards to pull it together.

The thing is though, if we write software to be as modular as possible, this problem is really not so big. New feature? Add a new module. The hardest part may well then be more in how to handle this from a UX and design point of view. The problem with software development is often that the thing is old or requires refactor or change even before it's properly released - again, an agile or agile-like approach from the beginning is not just realistic, but useful.

As for astrology, astrology software is a new field. As we learn more of our history we learn more about techniques otherwise lost to us. This will likely balance out a little bit, and in fact I think it already is doing so. There will always be some new feature, even if that new feature is actually a very old lost feature in astrology, but that's ok.

Without a unifying foundation, the "logic" in "astrologic" eventually becomes contradictory.

Just like many other fields, including physics and psychology. We have "running theories" and that is all. We start always from a certain position and carry forward as through that position or philosophy was true - the first one we all make is that the planets actually can correlate or describe human or mundane affairs in some way. After that we instantly diverge either in conclusion or philosophical methodology.

Within each strand, there is very often a nice consistent internal logic, mostly with some small inconsistency or something which cannot be fully accounted for, or, as for astrology, statistically backed up. So it is for modern psycholgoical astrology just as much as Hellenistic or Babylonian omen astrology. Even if that logic isn't always evident.

It's one of the reasons why I like Schmidt's work so much because he's one of the few doing this careful kind of philosophical work, but others say he's making stuff up.

The problem when you have one voice is that you have one angle on an issue or problem, and even if it's a very good one, if nobody is in a position to critique or offer other perspectives, nobody is in a position to offer nuance of disagreement. When nobody can disagree, that one voice can sound very compelling.

Paul wrote:

It's one of the reasons why I like Schmidt's work so much because he's one of the few doing this careful kind of philosophical work, but others say he's making stuff up.

The problem when you have one voice is that you have one angle on an issue or problem, and even if it's a very good one, if nobody is in a position to critique or offer other perspectives, nobody is in a position to offer nuance of disagreement. When nobody can disagree, that one voice can sound very compelling.

You make it sound like I've never heard any other opinions besides Schmidt's, but that's far from the case. When I first started out studying astrology seriously Dane Rudhyar just came out with his "Astrological Mandala". I've spoken to practically all the top names in the field personally such as Rob Hand, Robert Zoller (I had a room just down from Zoller at Hindquarters in 2007 for most of the year), James Holden and countless others. I still find Schmidt's arguments far more compelling in a number of areas. As for his recent Eudoxus announcement, he hasn't said anything like Bablyonian astrology wasn't important or that only Greek astrology matters as you've implied in other places on this forum. He just said that Eudoxus took a good idea and made it better and more "systematic" on multiple levels. I've not seen this level of consistency in any other "system" of astrology. Now the argument has shifted to Schmidt making things up. But I remind you that all things have to be "made up" at some point. To me, it doesn't matter as much whether it's made up, but it matters highly how carefully things are made up and whether Eudoxus did it or Schmidt did (or some combination in between because nobody is perfect) is secondary because it's the realm of the intelligibles that makes astrology useful and meaningful. But I'll also say that I don't think Schmidt has made this up. The whole situation smacks of an old world cover up of history on a massive scale and a disinformation agenda carried out by certain classical authorities (to put it in modern conspiracy theory jargon). It's my personal belief that astrology had to be put down as it was at one time a major threat to authority (when it had higher status as Valens himself said).

I've seen many astrological theories put forth that practically nobody questions (the rule of 3, 12th house as immediate past life, etc... but Bob puts forth something much more carefully thought out based upon Platonic metaphysics and actual research of the texts in their original languages and everybody says it's nonsense without taking the requisite time to investigate more carefully.

zoidsoft

I'm not sure why we're discussing Schmidt here. It may be better to create a new thread to discuss his ideas and your critiques of my criticisms of what he has said.

Paul wrote:In short though, the problem is not complicated. The swiss ephemeris allows a mode to enable the sidereal option (with a parameter to detail which ayanamsha). You can then simply store this client side like you say and send it as part of every request to the API, which is simple if you keep your API requests in one place on the client-side. This would mean very little code change and would technically accomplish the problem of adding a sidereal option programmatically fairly easily.

Hi again Paul,

unfortunately the problem is still complicated, as even for the swiss ephemeris the sidereal option is an afterthought. The fact that you have to set the "ayanamsha" mode instead of sending it as parameter to a function shows that they decided to go with the second option I mentioned before, i.e., maintain a global state in the API. There's no real clean solution, and they went for the simpler one (and threw concurrency out the window).

You also talk about the API, but my problem is not about any external interfaces to the flatlib API. The problem is that all the functions that get the positions of objects, houses, angles and fixed stars have to be aware that there's this new thing called sidereal zodiac, and every function that needs planetary positions (solar returns, temperaments, primary directions, everything!) also. As I said, either I pass a new argument around (which is pure, but not cleaner) or I have to maintain a global state in the API (cleaner, but may have concurrency problems).

The UX and design are simple to implement: a list of ayanamshas and a call to an API middle layer with a new argument.. My real problem is to maintain the consistency throughout the flatlib API, while keeping interfaces simple.


Regards,
Jo?o Ventura

Jventura

I still don't think this is any great technical problem, but at this point I feel almost like I'm bullying you into including a sidereal option which really wasn't my intention when I first posted here

I appreciate there's some work involved, and I think how you've approached the code will mean there is some refactoring to do of course. But if you feel you don't want to include a sidereal zodiac, or it's still not a priority for you, that's okay. I wasn't trying to make you feel forced to include it - I think somehow feeling the need to defend my position that it's not a difficult task has escalated beyond the point that I had originally hoped to make - namely that perhaps a sidereal option would improve the application in general and there may be more sidereal users than you think. Of course I'm not focusing on cost-effectivness as I was assuming from your very first post here that this was a labour of love.

At some point a nice thing to do would be to have all access to the swiss ephemeris itself happen through one object/method. This would make the whole process much simpler in my opinion and would make this problem a relatively minor one - just like you require to send the JD with each request you could simply send either a zodiac ID, or else a settings object which contains all the information you need, including the jd and an id for the zodiac. This may seem like a lot of work, but your application is still, relatively, quite small in terms of what you have on github, so if you are ever going to want this kind of functionality, it's better to start early. Of course you can branch your work, and write unit tests to ensure code stability which would be a good idea whether you want to do this or not. Syntactically Python appears to be not dissimilar from many other languages - if I had more time I would refactor and include it myself as a pull request as starting point for what I mean.

But, ultimately I think everyone realises that this is a labour of love and you have to only focus on it in your free time. Only you can really determine what is complex or time consuming or what your time is worth, so if you don't feel it's worth it, that's ok.

zoidsoft wrote: The other problem that has plagued the industry of astrological software development is that every astrologer want's their own program in exactly their own way.

Well, having two expensive traditional astrology softwares, I will not say which- in order to have just a 4 wheel chart with: radix, year profection, solar return, transits, and the date of the progressed SR Ascendant (BEn Dykes method) I'm obliged to cast the charts with Solar Fire and then adding dates BY HAND.
Maybe it is not only an astrologer problem, I'm afraid.

margherita wrote:

zoidsoft wrote: The other problem that has plagued the industry of astrological software development is that every astrologer want's their own program in exactly their own way.

Well, having two expensive traditional astrology softwares, I will not say which- in order to have just a 4 wheel chart with: radix, year profection, solar return, transits, and the date of the progressed SR Ascendant (BEn Dykes method) I'm obliged to cast the charts with Solar Fire and then adding dates BY HAND.
Maybe it is not only an astrologer problem, I'm afraid.

I've done something very close to this in Delphic Oracle (depends upon what you mean by profection chart). But Ben Dykes did give me a variation on the method of Umar Al-Tabari back in 2012 (one using scaled ascensions instead of straight days) and one can cast SR's against it.

Time limited 50% discount on the Charts Android app. Get it now at https://play.google.com/store/apps/deta ... gle.charts

Just found this post and I would like to thank you for sharing the news about my Charts app!
I have been working on it, and it now includes other House systems and chart styles. I hope to keep adding more functionalities, as they appear relevant to users

john21wall wrote:Just found this post and I would like to thank you for sharing the news about my Charts app!
I have been working on it, and it now includes other House systems and chart styles. I hope to keep adding more functionalities, as they appear relevant to users

Hum? Are you my alter ego?!

jventura wrote:Time limited 50% discount on the Charts Android app. Get it now at https://play.google.com/store/apps/deta ... gle.charts

Back to normal price!