D
Dave
========================================================
Python Port to Swiss Ephemeris (swe_houses) Bug Report/Workaround
========================================================
I don't know if anyone else has had programming problems with
the Python Port to the Swiss Ephemeris in the vault, but I have
just encountered an 'index error' bug caused by using the
swe_houses function. I did everything I possibly could think of
to figure out why I was getting an 'index error' in one of my loops
which happened to immediately follow the use of the swe_houses
function. After trying everything under the moon, I discovered that
when I deleted the house calculation that preceded the loop, it
worked fine. It didn't even matter whether the loop had anything
to do with the swe_house calculation or data that it returned.
The use of that function in the program completely disabled the
use of any loop following the use of the function by invoking an
'index error' saying the list assignment is not possible.
I wondered if it was a Python language bug, so I removed my
Python 2.2.2 and upgraded to 2.2.3, and the bug still existed.
Then I spent the better half of a day trying everything under
the sun to get around the error. The first very early on solution
to the problem was quickly discovered since the problem
apparently goes away as soon as you try to figure out what is
going wrong with your loop. Any programmer's first inclination
when debuging a loop would be to throw a few print statements
in there to view the values of the variables. Well, it turns out,
just the simple use of a print statement causes the bug to go
away in >IDLE<. I have no idea why, and it boggles my mind
why including the statement "Print '' " somewhere after the
swe_house calculation would stop the bug.
Anyway, so, the typical programmer using the Python Port
and IDLE will quickly solve this apparent 'index error' problem
when they go throwing in print statements to figure out what
is causing the problem.
BUT, if you however want to run your script at the command
prompt using the DOS window, the print statement won't solve
the problem, and you will continue getting an 'index error'
after your house calculation. After trying every possible
combination of things to do in a loop to try to work around
the bug for the command prompt, I discovered that there is
nothing you can do to reformat the loop to make it work like
a normal loop.
The immediate problem in an astrological program doesn't
have to do with the fact that it disables the use of a loop
after using the function. The immediate problem is shown
when you attempt to manipulate or compare the data returned
from the swe_houses calculation. Not only does it disable the
use of a loop after house calculation, but the data that it returns
appears 'corrupt' in that when you attempt to compare it to
values to determine the degrees & signs, it will give you the
same index error again.
For example, here is a simple house calculation:
HouZodDegs = swe_houses(julday, lat, lng, 'k')
<A loop after this statement will produce below error>
"IndexError: list assignment index out of range"
So, not only do you have problem with a loop after this
calculation, but when you try to evaluate the returned data,
you will also get this error (even if you're not manipulating
or evaluating any lists at the time).
I also found out that you CAN compare the apparently
corrupt house degrees returned in the function as long as
your comparison is LESS THAN the returned zodiac degrees.
Otherwise, it will give you the index error. For example,
if you put these statements after your calculation:
if HouZodDegs[0] < 0: Signs.append('ar')
if HouZodDegs[0] < 360: Signs.append('ar')
you won't get an error for the first one, but you will get
an error for the second. Why? *shrug* These are just
the facts I'm reporting, and it's up to someone else to
figure out what is causing the problem (if they want to
spend the time).
So, any statement evaluating the data returned from the
swe_houses function must be LESS THAN the zodiac
degrees returned. And since the results will vary from
anywhere within 360 degrees... some quite small and
some quite large, there is no way to evaluate the data
without getting the error.
So, where is the precious workaround you said you found?
Well, after a day of reformatting the loops and reformatting
the evaluations, I figured out there is no format that will
not produce the error. In order to calculate the houses
in a program, you will of course need to compare the
values of the results with other numbers, and in the course
of doing this, the results will always eventually be LESS
THAN a certain value you specify. There is no workaround
to this to prevent it from erroring.
SO, once I figured out that the error was inevitable, I started
experimenting with the TRY command... and trying to handle
the error as it happens in the program. I then figured out that
it was possible to figure out what sign the HouZodDegs was
in based upon where it errored in a list of evaluations. If
it errored on a certain interval, you could then determine
which sign was on the house cusp. It worked!
Then I found out that I don't even need to really use this loop
for the meat of what I was doing. I found out that the way
to "beat the bug" was to just acknowledge it, let it go, and
then go on with the program. So, I figured out that all you
need to do is put the following code after your house
calculation statement:
firstdegree = HouCspDegs[0]
try:
if firstdegree < 361: bug = 1
except: bug = 0
The above code assigns the first house cusp degree to the
variable 'firstdegree'. Then it trys to evaluate it against a
value which it most definitely will be less than (361). If it
can do this, it assigns 'bug' to 1, but if it can't do it (it won't
be able to do it!) then it will assign 'bug' to 0. Now that you
have assigned 'bug' to 0, you will not have any more index
errors, and you can manipulate/evaluate the rest of the
house results. This workaround works in both IDLE and the
command prompt. The print workaround only will work
in IDLE. As to why these workarounds work, I have no idea,
but they do. I would like to hear from anyone who have had
similar problems using the Python Port to the Swiss
Ephemeris... or anyone else who would like to explain why
these workarounds work. Or finally anyone who actually
knows a way to get rid of the bug altogether. Thanks,
and I hope I saved someone a day of debugging with
this post. -Dave
Python Port to Swiss Ephemeris (swe_houses) Bug Report/Workaround
========================================================
I don't know if anyone else has had programming problems with
the Python Port to the Swiss Ephemeris in the vault, but I have
just encountered an 'index error' bug caused by using the
swe_houses function. I did everything I possibly could think of
to figure out why I was getting an 'index error' in one of my loops
which happened to immediately follow the use of the swe_houses
function. After trying everything under the moon, I discovered that
when I deleted the house calculation that preceded the loop, it
worked fine. It didn't even matter whether the loop had anything
to do with the swe_house calculation or data that it returned.
The use of that function in the program completely disabled the
use of any loop following the use of the function by invoking an
'index error' saying the list assignment is not possible.
I wondered if it was a Python language bug, so I removed my
Python 2.2.2 and upgraded to 2.2.3, and the bug still existed.
Then I spent the better half of a day trying everything under
the sun to get around the error. The first very early on solution
to the problem was quickly discovered since the problem
apparently goes away as soon as you try to figure out what is
going wrong with your loop. Any programmer's first inclination
when debuging a loop would be to throw a few print statements
in there to view the values of the variables. Well, it turns out,
just the simple use of a print statement causes the bug to go
away in >IDLE<. I have no idea why, and it boggles my mind
why including the statement "Print '' " somewhere after the
swe_house calculation would stop the bug.
Anyway, so, the typical programmer using the Python Port
and IDLE will quickly solve this apparent 'index error' problem
when they go throwing in print statements to figure out what
is causing the problem.
BUT, if you however want to run your script at the command
prompt using the DOS window, the print statement won't solve
the problem, and you will continue getting an 'index error'
after your house calculation. After trying every possible
combination of things to do in a loop to try to work around
the bug for the command prompt, I discovered that there is
nothing you can do to reformat the loop to make it work like
a normal loop.
The immediate problem in an astrological program doesn't
have to do with the fact that it disables the use of a loop
after using the function. The immediate problem is shown
when you attempt to manipulate or compare the data returned
from the swe_houses calculation. Not only does it disable the
use of a loop after house calculation, but the data that it returns
appears 'corrupt' in that when you attempt to compare it to
values to determine the degrees & signs, it will give you the
same index error again.
For example, here is a simple house calculation:
HouZodDegs = swe_houses(julday, lat, lng, 'k')
<A loop after this statement will produce below error>
"IndexError: list assignment index out of range"
So, not only do you have problem with a loop after this
calculation, but when you try to evaluate the returned data,
you will also get this error (even if you're not manipulating
or evaluating any lists at the time).
I also found out that you CAN compare the apparently
corrupt house degrees returned in the function as long as
your comparison is LESS THAN the returned zodiac degrees.
Otherwise, it will give you the index error. For example,
if you put these statements after your calculation:
if HouZodDegs[0] < 0: Signs.append('ar')
if HouZodDegs[0] < 360: Signs.append('ar')
you won't get an error for the first one, but you will get
an error for the second. Why? *shrug* These are just
the facts I'm reporting, and it's up to someone else to
figure out what is causing the problem (if they want to
spend the time).
So, any statement evaluating the data returned from the
swe_houses function must be LESS THAN the zodiac
degrees returned. And since the results will vary from
anywhere within 360 degrees... some quite small and
some quite large, there is no way to evaluate the data
without getting the error.
So, where is the precious workaround you said you found?
Well, after a day of reformatting the loops and reformatting
the evaluations, I figured out there is no format that will
not produce the error. In order to calculate the houses
in a program, you will of course need to compare the
values of the results with other numbers, and in the course
of doing this, the results will always eventually be LESS
THAN a certain value you specify. There is no workaround
to this to prevent it from erroring.
SO, once I figured out that the error was inevitable, I started
experimenting with the TRY command... and trying to handle
the error as it happens in the program. I then figured out that
it was possible to figure out what sign the HouZodDegs was
in based upon where it errored in a list of evaluations. If
it errored on a certain interval, you could then determine
which sign was on the house cusp. It worked!
Then I found out that I don't even need to really use this loop
for the meat of what I was doing. I found out that the way
to "beat the bug" was to just acknowledge it, let it go, and
then go on with the program. So, I figured out that all you
need to do is put the following code after your house
calculation statement:
firstdegree = HouCspDegs[0]
try:
if firstdegree < 361: bug = 1
except: bug = 0
The above code assigns the first house cusp degree to the
variable 'firstdegree'. Then it trys to evaluate it against a
value which it most definitely will be less than (361). If it
can do this, it assigns 'bug' to 1, but if it can't do it (it won't
be able to do it!) then it will assign 'bug' to 0. Now that you
have assigned 'bug' to 0, you will not have any more index
errors, and you can manipulate/evaluate the rest of the
house results. This workaround works in both IDLE and the
command prompt. The print workaround only will work
in IDLE. As to why these workarounds work, I have no idea,
but they do. I would like to hear from anyone who have had
similar problems using the Python Port to the Swiss
Ephemeris... or anyone else who would like to explain why
these workarounds work. Or finally anyone who actually
knows a way to get rid of the bug altogether. Thanks,
and I hope I saved someone a day of debugging with
this post. -Dave