jyotisham / jyotisha Goto Github PK

View Code? Open in Web Editor NEW

84.0 84.0 52.0 620.03 MB

Python tools for the astronomical / astrological vedAnga of Hindus

License: MIT License

Python 26.20% TeX 73.77% Shell 0.03%

jyotisha's People

Contributors

Stargazers

Watchers

Forkers

namaljayathunga vedic-astrology 44444uttam rahulyhg amet123 skkulkarni vedatemple il-mattone krishnavemuri babawhitehat ssppravin angstormnet ittechsathish ondrocks hareeshbabu82ns nikhilpinapati angstormtn karthikraman karthik666manjunath krishnakanthpps baskar-yahoo jparajuli dmrmoney astrorigin thakkaha abhisheks108 mjsignup prabhakaran-cbe cosmok solegaonkar battyone parmeet-97637 renayo ramakrishnamekala129 prasoonthakur8 topwebmaster kowunnako shaktee jeganad passionfusion man455 ankushsingh 01010010-01010011 jilakarasaisreenivas nitingautam kartik-2 apuravchauhan bytemyst vineetp6 indic-astrology binrebin

jyotisha's Issues

Move data from json to toml

YAML is a superset of JSON and generally cleaner and more readable.
See https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json

test_annual failing

First, dumping panchanga object to string with sorted keys is failing. (None key somewhere?)
Even if the above is fixed by skipping stringification and resorting to dict comparison (with an update to the sanskrit_data package - see Chennai 2018 test) - there is still a failure.

What's going on? Seems unrelated to today's changes. For all I know, tests were failing before today.

I just came across https://github.com/dhoomakethu/panchanga-cli and https://github.com/webresh/drik-panchanga . I wanted to invite both of you to contribute to this library (started by @karthikraman ) - the code needs to undergo a lot of cleanup and simplification - but pooling our resources together will get stuff done a lot faster. The particular advantages this package brings to the table are:

A lot of festival data (which will grow further) - resulting in rich and user friendly ics and pdf output you see in https://github.com/karthikraman/panchangam .
A growing REST API - http://api.vedavaapi.org/jyotisha/jyotisha/docs#!/default/get_daily_calendar_handler
A couple of people (I and @karthikraman ), who are quite familiar with the code and intricacies involved.

aparAhNa as second half of the day (rather than 4/5th)

Veda-s and sUtra-s speak of aprAhNa in two contexts:

Two fold division of day
- "वसन्तो ग्रीष्मो वर्षा - ते देवा ऋतवः। शरद्+हेमन्तः शिशिरस् - ते पितरः। य एवापूर्यते ऽर्धमासः - स देवा, योऽपक्षीयते स पितरो, ऽहर् एव देवा, रात्रिः पितरः, पुनरह्नः पूर्वाह्णो देवा, अपराह्णः पितरः। ...... स यत्र उदगावर्तते देवेषु तर्हि भवति। देवांस् तर्ह्य् अभिगोपायस्य्, अथ यत्र दक्षिणावर्तते पितृषु तर्हि भवति, पितॄंस् तर्हि गोपायति ।" śatapatha Brāhmaṇa (ii. 1. 3, 1-3)
5 fold division of the day - "दे॒वस्य॑ सवि॒तुᳶ प्रा॒तᳶ प्र॑स॒वᳶ प्रा॒णः । ....मि॒त्रस्य॑ सङ्ग॒वः । ... बृह॒स्पते॑र्म॒ध्यन्दि॑नः । ... भग॑स्यापरा॒ह्णः ।"

Proper disambiguation

In the context of muhUrta-s, the 5 fold division is to be taken.
In the context of pitRkArya-s (used in contrast with pUrvAhNa rather than sAngava etc.., and in juxtaposition with other two fold divisions like ayana, day-night etc.. ), the 2-fold division is to be taken.

The bug

Currently, the 5-fold division is assumed indiscriminately; whereas generally 2-fold division makes more sense (shrAddha, pitRkarma, sannyAsi-ArAdhanas etc..). This messes up vyApti decisions (besides making the logic complicated), besides giving ridiculous times for regions with very long/short day lengths.

It is possible that later shiShTa-s support this wrong practice (like their "uttarAyaNa"), in which case, I'd be interested in seeing the pramANa-s. In that case, it might make sense to make to make this a computation option.

संस्कृतपञ्चाङ्गे व्याकरणदोषा निवारणीयाः

योगम् -> योगः
करणं ->‌ करणम्
शुक्लँ, कृष्णँ

Add ICS unit tests

First create an ICS file for say 2019
This should be fairly simple
load 2019 panchangam from JSON
convert to ICS
check if the ICS text matches previously created ICS text from the same json.

Times showing in negative, DST bug?

./gen_daily_cal.sh Orinda 37:51:38 -122:10:59 'America/Los_Angeles' 2019 devanagari

Must be a simple bug, but can't track it easily :(

Separate repository for festivals

I believe we can have a separate repo for festivals, which can be located in the legacy folder as a git module(?). I think it would be helpful to have festivals categorised in multiple json files, like temple-festivals-tn.json etc. We just need to run a script to update the separate jsons, which I guess will be efficiently used for the online API etc. Of course, these jsons can be modified to accommodate all the schema changes you've suggested --- just that I want a much smaller set of files, to keep track of festivals and make changes...

Delete write_events_ics if deprecated by write_panchangam_ics

Help with profiling

Just ran some simple profiling

In [15]: cProfile.run('panchangam = annual.Panchangam(city=city, year=2019, script=sanscript.DEVANAGARI, ayanamsha_id=swe.SIDM_LAHIRI, compute_lagnams=False)')
         285667 function calls in 102.599 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.001    0.001  102.599  102.599 <string>:1(<module>)
      411    0.001    0.000    0.103    0.000 __init__.py:121(get_solar_rashi)
      370    0.003    0.000    0.007    0.000 __init__.py:126(timezone)
    32048    0.311    0.000   16.699    0.001 __init__.py:142(get_angam_float)
      370    0.001    0.000    0.002    0.000 __init__.py:186(_unmunge_zone)
     8077    0.035    0.000    3.963    0.000 __init__.py:252(get_angam)
       16    0.001    0.000    0.265    0.017 __init__.py:302(get_angam_span)
     3707    0.096    0.000   20.390    0.006 __init__.py:384(get_angam_data)
      370    0.001    0.000    0.002    0.000 __init__.py:46(ascii)
     6239    0.008    0.000    0.008    0.000 __init__.py:525(get_kaalas)
      370    0.007    0.000    0.047    0.000 __init__.py:67(get_timezone_offset_hours_from_date)
      370    0.002    0.000    0.051    0.000 __init__.py:88(local_time_to_julian_day)
        1    0.000    0.000  102.598  102.598 annual.py:1495(add_details)
        1    0.001    0.001    0.369    0.369 annual.py:185(assignLunarMonths)
        1    0.000    0.000  102.598  102.598 annual.py:28(__init__)
        1    0.010    0.010  102.229  102.229 annual.py:48(compute_angams)
        1    0.000    0.000    0.000    0.000 annual.py:76(<listcomp>)
      371    0.000    0.000    0.000    0.000 common.py:175(get_wire_typeid)
      371    0.002    0.000    0.003    0.000 common.py:198(set_type)
      371    0.001    0.000    0.004    0.000 common.py:89(__init__)
      369    0.006    0.000    0.217    0.001 daily.py:107(compute_solar_month)
        1    0.000    0.000    0.035    0.035 daily.py:139(compute_solar_day)
      367    0.009    0.000    0.017    0.000 daily.py:243(get_kaalas)
      370    0.007    0.000   51.056    0.138 daily.py:30(__init__)
      739    0.041    0.000  101.846    0.138 daily.py:66(compute_sun_moon_transitions)
      740    0.004    0.000    0.008    0.000 tzinfo.py:179(fromutc)
      740    0.003    0.000    0.012    0.000 tzinfo.py:189(normalize)
      370    0.011    0.000    0.033    0.000 tzinfo.py:244(localize)
     1480    0.001    0.000    0.001    0.000 tzinfo.py:382(utcoffset)
     4126    0.024    0.000   12.869    0.003 zeros.py:330(brentq)
     4126    0.004    0.000    0.004    0.000 zeros.py:53(results_c)
     1480    0.002    0.000    0.002    0.000 {built-in method _bisect.bisect_right}
        1    0.000    0.000  102.599  102.599 {built-in method builtins.exec}
      737    0.001    0.000    0.001    0.000 {built-in method builtins.hasattr}
     4126    0.004    0.000    0.004    0.000 {built-in method builtins.isinstance}
      370    0.000    0.000    0.000    0.000 {built-in method builtins.len}
     1480    0.002    0.000    0.002    0.000 {built-in method builtins.max}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.round}
      371    0.000    0.000    0.000    0.000 {built-in method builtins.setattr}
     8816    0.011    0.000    0.011    0.000 {built-in method math.floor}
     4126    0.048    0.000   12.837    0.003 {built-in method scipy.optimize._zeros._brentq}
    68195   20.176    0.000   20.176    0.000 {built-in method swisseph.calc_ut}
        1    0.000    0.000    0.000    0.000 {built-in method swisseph.day_of_week}
    68195    0.211    0.000    0.211    0.000 {built-in method swisseph.get_ayanamsa}
        2    0.000    0.000    0.000    0.000 {built-in method swisseph.julday}
      369    0.001    0.000    0.001    0.000 {built-in method swisseph.revjul}
     4436   81.488    0.018   81.488    0.018 {built-in method swisseph.rise_trans}
    44572    0.047    0.000    0.047    0.000 {built-in method swisseph.set_sid_mode}
      370    0.001    0.000    0.001    0.000 {built-in method swisseph.utc_time_zone}
      370    0.001    0.000    0.001    0.000 {built-in method swisseph.utc_to_jd}
      740    0.003    0.000    0.003    0.000 {method 'add' of 'set' objects}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
      370    0.001    0.000    0.001    0.000 {method 'encode' of 'str' objects}
     4093    0.004    0.000    0.004    0.000 {method 'extend' of 'list' objects}
      370    0.000    0.000    0.000    0.000 {method 'isoweekday' of 'datetime.date' objects}
      370    0.000    0.000    0.000    0.000 {method 'pop' of 'set' objects}
     3700    0.007    0.000    0.007    0.000 {method 'replace' of 'datetime.datetime' objects}
      740    0.001    0.000    0.001    0.000 {method 'replace' of 'str' objects}
      370    0.000    0.000    0.000    0.000 {method 'upper' of 'str' objects}

Any thoughts on how to make the codes faster? Unclear to me what the bottlenecks are... Do you find any surprises @vvasuki ?

Switch to using geocode API and library in REST API

Sunset computation broken beyond polar circle - raise exception.

The code was working yesterday - #10 . After I did some non-functional changes (renaming functions, reformatting code and the like), I faced a brentq error, which I fixed. But now I get the below:

No precomputed data available. Computing panchangam... DEBUG: 2017-12-15 15:03:57,622 {spatio_temporal.py:161}: 0.0 
DEBUG: 2017-12-15 15:03:57,622 {spatio_temporal.py:162}: 10 
DEBUG: 2017-12-15 15:03:57,623 {spatio_temporal.py:163}: -0.634040778754029 
DEBUG: 2017-12-15 15:03:57,623 {spatio_temporal.py:164}: 0.5376589639327491 
ERROR: 2017-12-15 15:03:57,769 {spatio_temporal.py:246}: 11 
[2017-12-15 15:03:57,770] ERROR in app: Exception on /jyotisha/v1/calendars/coordinates/80:16:12/13:05:24/years/2017 [GET]
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.6/dist-packages/flask_restplus/api.py", line 313, in wrapper
    resp = resource(*args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/flask_restplus/resource.py", line 44, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/home/vvasuki/jyotisha/jyotisha/rest_api/api_v1.py", line 40, in get
    panchangam = scripts.get_panchangam(city=city, year=int(year), script=args['encoding'])
  File "/home/vvasuki/jyotisha/jyotisha/panchangam/scripts/__init__.py", line 32, in get_panchangam
    panchangam.compute_angams(computeLagnams=computeLagnams)
  File "/home/vvasuki/jyotisha/jyotisha/panchangam/spatio_temporal.py", line 247, in compute_angams
    raise (ValueError('Dec 31 does not appear to be Dhanurmasa!'))
ValueError: Dec 31 does not appear to be Dhanurmasa!

I fancy that karthik may be able to deduce what went wrong faster. In the meantime, I'll try to shift from doctests to pytest so as to enable continuous automated testing.

Command line operation

is it not possible to kind of tweak this to run it for a command line that gets us the data we need based on date and location?

Error when running gen_daily_txt.sh

The gen_daily_txt.sh (and other scripts) have an invalid reference to the modules from the jyotish project. I made the following correction to the script for testing:

< python3 -m jyotisha.panchangam.scripts.write_daily_panchangam_txt $city_name $lat $lon $tz $y $script $fmt $lagna
---
> python3 -m jyotisha.panchaanga.writer.write_daily_panchaanga_txt $city_name $lat $lon $tz $y $script $fmt $lagna

This fixes the script execution. But now, there is another error from one of the modules. I will post an update if I can resolve it.

Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/writer/write_daily_panchaanga_txt.py", line 465, in <module>
    main()
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/writer/write_daily_panchaanga_txt.py", line 452, in main
    panchaanga = annual.get_panchaanga_for_civil_year(city=city, year=year)
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/spatio_temporal/annual.py", line 72, in get_panchaanga_for_civil_year
    return load_panchaanga(fname=fname, fallback_fn=fn) 
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/spatio_temporal/annual.py", line 30, in load_panchaanga
    panchaanga.update_festival_details()
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/spatio_temporal/periodical.py", line 250, in update_festival_details
    applier.MiscFestivalAssigner(panchaanga=self).assign_all(debug=debug)
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/temporal/festival/applier/__init__.py", line 338, in __init__
    super(MiscFestivalAssigner, self).__init__(panchaanga=panchaanga)
  File "/usr/local/lib/python3.7/dist-packages/jyotisha/panchaanga/temporal/festival/applier/__init__.py", line 21, in __init__
    self.rules_collection = rules.RulesCollection.get_cached(repos=tuple(panchaanga.computation_system.options.fest_repos))
  File "/usr/local/lib/python3.7/dist-packages/methodtools.py", line 72, in __call__
    return self.__call__(*args, **kwargs)
TypeError: unhashable type: 'RulesRepo'
error!

Fixing local cached data and packages following upgrade

namaste kArtik,

I just tested and committed changes so as to use daily.Panchanga.get_kaala method when possible. Since I'm now automatically computing kaala-s and storing them in the local json, you will need to clear away or replace those local json files.
Along the way I noticed a transliteration problem (non-retention of roman numerals in tamil) with latest sanscript and fixed it. So please update your sanscript package.

Please close this issue once you've checked and adjusted.

Slight changes in `jd_midnight`, `jd_sunrise` and bigger changes in `jd_moonrise` etc. to be reconciled

and validated for correctness.

Separate panchangam computation and PDF/ICS creation

I'm thinking that panchangam computation (json) and a date-wise table (maybe in csv) can happen in the jyotisha module. The actual tex, pdf, ics stuff can all happen inside the "panchangam" submodule. What do you think?

Make annual use periodical panchANga.

namaste kArtika,

I like the fact that you've generalized annual Panchanga computation to arbitrary periods! Good.
But you have copy pasted and made the code all the harder to cleanup and fix. Bad!

Just today I felt like seeing if I could have another go at fixing stuff like eliminating legacy festival data, moving over more computation to daily - but was deflated by the sight of yet another complication to take care of (2x code to fix, 2x code to test). Increasing code ugliness just motivates procrastination and neglect.

Annual Panchanga should be a subclass of Periodic Panchanga, and should only include additional methods and variables not covered within Periodic panchanga. Could you make it so, please?

What makes code slower?

Defining anga objects and specifying their algebra/ arithmetic would make things simpler - but would it be slower?

Command line in all of the below

pytest -k test_panchanga_chennai_18 --log-cli-level 0

For the anga obj branch:

FAILED                                                                   [100%]timebudget report...
            compute_angas: 83355.05ms for      1 calls
  update_festival_details: 40451.83ms for      2 calls
assign_festivals_from_rules: 35678.10ms for      2 calls
          assign_festival:    0.14ms for  500780 calls
assign_tithi_yoga_nakshatra_fest:    1.55ms for  43848 calls
                   __eq__:    0.00ms for  943794 calls
             dump_to_file:  590.65ms for      1 calls
           set_rule_dicts:  514.62ms for      1 calls
                   __lt__:    0.01ms for  37364 calls
                  __sub__:    0.00ms for  78473 calls
                  __add__:    0.00ms for  59969 calls
                   __gt__:    0.00ms for   5095 calls
timebudget report...

Takes 2 min 53 seconds = 173 seconds.

Master branch for comparison:

  update_festival_details: 6447.73ms for      2 calls
assign_festivals_from_rules: 3847.77ms for      2 calls
            compute_angas: 7575.29ms for      1 calls
          assign_festival:    0.01ms for  500780 calls
           set_rule_dicts:  513.87ms for      1 calls
             dump_to_file:  401.62ms for      1 calls
  assign_festival_numbers:    2.13ms for      2 calls
timebudget report...
         Loading the file:  847.15ms for      1 calls

Time taken without timebudget use : 21.x seconds, with timebudget: 23.x seconds

Setup auto-build and auto-test on every push

Motivation: No more pushing broken code and leaving tests failing for ages.

Currently blocked by - astropy/astropy#10752 .

how to calculate pada of a Nakshatra?

is there any way to calculate pada of a nakshatra ?
or is there any way to calculate the nakshatra angle ?

Transliteration of E and O messed up

decouple script and pickle

Currently, pickled data includes script. Further, some text does not change even after forcing script. Quick fix would be to save script-wise pickle, but a better solution would be to do a deeper fix.

Better festival database structure.

Desiderata

Festival data should be version controlled.
It should be easy to peruse and edit online.

So, it should not be in one or two giant files.

Where possible one should be able to look up a (non-relative) festival in a constant-time operation just by using one of the following event specs:

the lunar month + day.
the solar month + day
some other planetary transit or conjunction.

Festival data shouldn't need to be all stored in the memory (which may be limited) when the program is running (either as a web service or as a script)

Current status

Currently we're using giant files - especially https://github.com/sanskrit-coders/jyotisha/blob/master/jyotisha/panchangam/data/festival_rules.json .

Drawbacks

This violates [3], [4] and [2] to varying degrees.

Proposed improvement

Let's have this festival data structure -

lunar_day/05_15/rules.json would have rules for all festivals for month 5, pUrNimA.
solar_day/10_01/rules.json would have rules for all festivals for solar month 10, day 1.
solar_day/10_01/relative_rules.json would have rules for all festivals inferred from solar month 10, day 1.

@karthikraman - किमभिप्रैसि?

PDF generation - include font in package

Context: #10 (comment)

Insulate code from swisseph changes

Motivation: #40 illustrates the problem with depending on an external library.

So, best insulate our code from swisseph by adding a layer inbetween. Eventually, we should move to using NASA ephemerides data directly - thereby simplifying installation and distribution. Even ayanAMsha calculations can be done purely in python - not that hard.

Merge old_code with master

मित्र,@karthikraman - old_code and master are diverging farther and farther - we might as well be working on entirely different repos. I know you are fond of quick fixes, but if you are seriously interested in getting good jyotisha python code out there, you should spend some time merging these two branches. Else, master lacks all those panchanga fixes you're making in old_code.

Festival-day Tie-breaking - same anga occuring twice in a month.

Consider the below festival:

id = "vAyilAr nAyan2Ar (49) gurupUjai"
tags = [ "NayanarGurupujai",]
jsonClass = "HinduCalendarEvent"

[timing]
default_to_none = true
month_type = "sidereal_solar_month"
priority = "paraviddha"
month_number = 9
anga_type = "nakshatra"
anga_number = 27
kaala = "praatah"

naxatra 27 occurs twice in sidereal_solar_month 9 in 2018. This is not uncommon due to the difference between lunar and solar sidereal months. Which day to pick? What's the pramANa?

(Previous code picked just the ~~first~~ (second) occurance, but was buggy so as to omit certain festival instances such as ~~poygaiyAzhvAr tirunakSattiram~~, mAn2akkaJcAr2a nAyan2Ar (11) gurupUjai, ~~toNDaraDippoDiyAzhvAr tirunakSattiram~~ in 2018. Newer code fixes this problem, but simply marks both occurances as potential festivals. Refer to ddd906e )

Default ayanamsha?

We have been using swe.SIDM_LAHIRI as default ayanamsha. Should it remain so? I've been reading some arguments for using swe.TRUE_CITRA. I know it doesn't matter much, since you've embedded the ayanamsha into every function, and it's easy to change.

But just wondering what you would recommend as a default @vvasuki ...

Reinstate URLs in festival_rules.json

URLs are important to have, for some of the other things I am doing with the JSON file. For example, I've been tinkering with https://karthikraman.github.io/adyatithih/ by pulling information from the JSON and using the URLs. The URLs figure in the ICS and are part of automated tweets by https://twitter.com/stotrasamhita -- this is still very very sloppy, hence haven't shared widely. If you want you can change the URL field to "roman_title" or something like that.

Accommodating an alternate adhikamAsa computation

In my daily sankalpa-s I have been following http://indiafacts.org/vedic-system-of-chronology/ , which advances months by 1. We must have some option of supporting and publish panchAnga-s according to it.

Verify and correct festival computation call order

Just reorganized festival code - moved it out to a separate module. Call order slightly altered - needs verification (and possible correction).

ग्रहणानि दर्शनीयानि पञ्चाङ्गे

fix transliteration - remove str, utf8

https://github.com/sanskrit-coders/jyotisha/blob/30e2c86fc6045234d12f01298f4a3a2ac1a8019c/jyotisha/panchangam/panchangam.py#L1946

JsonObject.read_from_file error?

Perhaps because of some wrong version?

ERROR: 2019-04-15 07:46:26,182 {common.py:170}: Error reading /home/karthik/Documents/Chennai-2018.json :
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 162, in read_from_file
    obj = cls.make_from_dict(jsonpickle.decode(fhandle.read()))
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 133, in make_from_dict
    recursively_set_jsonpickle_type(dict_without_id)
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 124, in recursively_set_jsonpickle_type
    some_dict[JSONPICKLE_TYPE_FIELD] = json_class_index[wire_type].__module__ + "." + wire_type
KeyError: 'Panchangam'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./update_test_json.py", line 19, in <module>
    panchangam_actual = JsonObject.read_from_file(filename=os.path.join(ORIG_DATA_PATH, fname))
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 171, in read_from_file
    raise e
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 167, in read_from_file
    obj = cls.make_from_dict_list(jsonpickle.decode(fhandle.read()))
  File "/usr/local/lib/python3.6/dist-packages/sanskrit_data/schema/common.py", line 144, in make_from_dict_list
    assert isinstance(input_dict_list, list)
AssertionError

Latest pyswisseph (2.8.0) breaks computations

Need to update codes. For example calc_ut now returns some additional flags etc.

`List` error

karthik@nu:bin$ ./gen_monthly_cal.sh Chennai 13:05:24 80:16:12 'Asia/Calcutta' 2019 devanagari
Computing 2019 monthly panchangam for Chennai (13:05:24,80:16:12) - Asia/Calcutta in devanagari script...
***
DEBUG: 2019-04-17 18:48:48,388 {common.py:860}: {'SchemaError': <class 'jsonschema.exceptions.SchemaError'>, 'Text': <class 'sanskrit_data.schema.common.Text'>, 'ScriptRendering': <class 'sanskrit_data.schema.common.ScriptRendering'>, 'JsonObject': <class 'sanskrit_data.schema.common.JsonObject'>, 'TargetValidationError': <class 'sanskrit_data.schema.common.TargetValidationError'>, 'UllekhanamJsonObject': <class 'sanskrit_data.schema.common.UllekhanamJsonObject'>, 'ValidationError': <class 'jsonschema.exceptions.ValidationError'>, 'NamedEntity': <class 'sanskrit_data.schema.common.NamedEntity'>, 'JsonObjectNode': <class 'sanskrit_data.schema.common.JsonObjectNode'>, 'Target': <class 'sanskrit_data.schema.common.Target'>, 'DataSource': <class 'sanskrit_data.schema.common.DataSource'>}
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/karthik/GitHub/jyotisha/jyotisha/panchangam/scripts/write_monthly_panchangam_tex.py", line 15, in <module>
    import jyotisha.panchangam.spatio_temporal.annual
  File "/home/karthik/GitHub/jyotisha/jyotisha/panchangam/spatio_temporal/annual.py", line 79
    daily_panchaangas: List[daily.DailyPanchanga] = [None] * temporal.MAX_SZ
                     ^
SyntaxError: invalid syntax
error!

If I change to:

        daily_panchaangas = [None] * temporal.MAX_SZ

it works fine...

उत्तरायणसमयदर्शने समीकरणम्

उत्तरायणप्रारम्भः परिष्करणीयः।

मम पारिवारिकसमूहे चर्चा जाता काचित्-

For example, texts like vedAnga jyotiSha clearly define what "uttarAyaNa" is, and how it is to be identified. That's when the the sun starts moving north, days start growing, midday shadows start growing northward. This happens around Dec 22, yet - like retards most people keep saying dakShiNAyana. There is no excuse for this other than the fact that the same mistake was made in late medieval manuals.

Among traditional scholars of worth (who tend to be deeply interested in timing shrauta rituals exactly as specified - think of those that build jantar mantar and author pieces like http://indiafacts.org/vedic-system-of-chronology/ ), such discrepancies are clearly noted and corrected.

केषुचिद् अन्तर्जालसमयदर्शिकासूभयधापि दर्श्यते। अस्माभिरपि तथा करणीयम् इति मन्ये।

Summarising festivals --- autogenerated README.md?

Could we summarise festivals -- perhaps an auto-generated README.md in each of the folders, e.g. (https://github.com/sanskrit-coders/jyotisha/tree/master/jyotisha/panchangam/temporal/festival/data/lunar_month/tithi) listing a table with the festivals therein??

Something like https://gist.github.com/karthikraman/c4b9fbbcd1ea4dbc393beef582b7714b?

pip installation fails to get festival/data submodule

Refer comment #10 (comment)

Finer categorisation of festival folders

Could we have sub-folders month-wise/nakshatra wise, like 00/15/ instead of 00__15/?

This will be particularly nice for summarisation... it will be possible to look at all festivals in a month in one go.. as discussed in #24

festival rules json: No field-names with space.

The spaces in the json field names mess up the ability of python (eg jsonpickle), js and other libraries to parse them into python/ js and other objects . Any json field name should also be a valid variable name in other programming languages. Hence, we need to get rid of those spaces in field names, for example - https://github.com/sanskrit-coders/jyotisha/blob/master/jyotisha/panchangam/data/kanchi_aradhana_rules.json Doing so will let us use such libraries to significantly simplify code.

An example in other styleguides - https://google.github.io/styleguide/jsoncstyleguide.xml#Property_Name_Guidelines

@karthikraman - You're ok with this? I suggest that we take to the "other_names" instead of "Other Names".

We'll also need to make stuff like "kAJcI 1 jagadguru zrI Adi~zaGkara bhagavatpAda ArAdhanA" values rather than field names.

Renaming temporal/spatio_temporal

@jamadagni suggests that spatio_temporal and temporal should be renamed to geocentric and topocentric per standard astronomy terms. Agree?

Drop script prefixes like ta

ta__zrI~jayantI should be zrI~jayantI .
Use script_priority field to force tamil script for tamil sanskrit bilingual users instead.

jsonClass = "HinduCalendarEvent"
default_to_none = true
id = "ta__zrI~jayantI"
script_priority = "ta"
tags = [ "Dashavataram", "CommonFestivals",]

[timing]
jsonClass = "HinduCalendarEventTiming"
default_to_none = true
month_type = "sidereal_solar_month"
month_number = 5
anga_type = "nakshatra"
anga_number = 4
kaala = "nishita"

Festival computation: gajachChAyA computation broken.

Just discovered it when running tests today. Cause unknown. Disabled for now with 5587235 .

NAMES dict: undo quick&dirty fixes for zero indexing

mitra, With 1452561 and 862beef , I thought I had fixed the zero indexing problems caused by removing custom parsing code. But I now realize that I had missed some, looking at 149a2d9 . It would've been better to fix the indexing in those files which I'd missed. Could you replace this quick n dirty fix with proper indexing?

2009 November 17-Dec 16 is wrongly shown as adhika masa
- Weird, since there is no normal मार्गशीर्ष that is calculated, only adhika!
Previously thought to be fixed!