Python Port to Swiss Ephemeris (swe_houses) Bug Report/Workaround

[John Roth]

The problem appears to be in the _wrap_swe_houses
function.

In the following routine (about halfway down the function)

        if (myhsys==71) ohcusps=PyList_New(37);
        else ohcusps=PyList_New(13);
        for (i = 0; i < myhsys; i++)
        {
            PyObject *otmp = PyFloat_FromDouble(myhcusps[i]);
            PyList_SetItem(ohcusps,i,otmp);
        }

the if statement is incorrect. It will iterate 71 times,
while it should iterate either 13 or 37 times, depending
on the value of the house system paramter.

This will overlay memory, causing all kinds of not
very interesting problems.

You need to report this to the author.

John Roth

"Dave" <bluheaven2 at yahoo.com> wrote in message
news:734b753f.0309081421.1a1e180 at posting.google.com...
> ========================================================
> 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