User talk:Grr

From Wikipedia, the free encyclopedia
Jump to: navigation, search

This is the talk page for Greg Reddick.

My main interests are revolve around history, particularly Mesoamerican. I am an expert on the Maya Calendar, having written the calendar program that many prominent Maya scholars such as Michael Coe use. I have attended the Maya Meetings in Austin almost every year since 1994. I have also done considerable research on the Dresden Codex Venus Pages.

What program is it? Where can I get it? What OS does it run on? Have you seen this: http://www.macupdate.com/info.php/id/25773/chac I use a Mac at home so I use it. I've checked it by doing the calculations manually with a calculator and checked it against astronomy programs and other maya calendar programs. It does the calculations correctly as far as I can tell. Where have you published your research about the Venus almanacs?23:08, 5 June 2008 (UTC)Senor Cuete —Preceding unsigned comment added by Senor Cuete (talkcontribs)
A Mac application has a help menu with documentation about the program. In the help file the author of this one really blasts the proleptic Gregorian calendar and refuses to support it. He also comes down on the Thompson, astronomical, Lounsbury correlation. He allows the user to use any correlation but says not to. He does provide good arguments for both of these positions. I see from your posts on the talk pages about the calendars that you might have an opinion about this.Senor Cuete (talk) 00:23, 6 June 2008 (UTC)Senor Cuete
Well, it's now six years later. I'm still interested in your opinion. The guy that wrote Chac has made a lot of changes to it. Recently he added the ability to calculate the heliacal and cosmical risings and settings of Venus. Your site shows that you are interested in the Venus almanac in the Dresden Codex. This program could be used to study this. Senor Cuete (talk) 16:16, 11 June 2014 (UTC)
The program is Xoc Maya Calendar. It is available from https://mayacalendar.xoc.net. Currently only available for Windows, but I'm looking into how to support Mac. Does pretty much everything you'd want in a calendar program. Grr (talk) 19:41, 11 June 2014 (UTC)
There really isn't any cross-platform development environment to port your program to the Mac easily. The Mac GUI is programmed using the Cocoa framework. The preferred language for doing that is Objective C, but also I think it can be done in Java (using a third party IDE) C++, Python and maybe something else. Apple just introduced a new language for this called Swift. A lot of writing a modern program is the GUI. The math in your program is probably simple and can be included in a Mac application if it's written in C. The Mac program that's available (Chac) does a lot of astronomical calculations like the moon phase (using either system), lunation length, which of the six lunations is current (using any one as the first) and the heliacal phenomena of Venus. If you don't have the source code for that it would be a lot of work to develop it. Senor Cuete (talk) 22:33, 11 June 2014 (UTC)
I've got several avenues that I can use. The math for the Maya Calendar may seem simple, but there are a lot of special cases. For example, handling dates in the last creation causes problems with the Long Count. The calculation library can be ported using Mono, but the UI is a different issue. I handle all of the Supplementary (Lunar) Series information. I currently do not handle Venus, mainly because doing it right (so it's actually accurate) requires a separate library for astronomical information. It's pretty easy to get it sort of right, but I won't do that. I have written such a library before, but not for use in this program, yet. It will happen at a future point.
As far as my program goes, I avoid the whole issue of Gregorian versus Julian by always showing both. I think it is a stupid argument. What does he do with dates before 46 BCE? Those are proleptic Julian dates, which have exactly the same problem as proleptic Gregorian dates. What does he do when a date is being compared to a document in 1590, but it is in a non-Catholic state that is still using Julian? The U.S. didn't switch until 1752, and China didn't switch until 1949. In general, in comparing Maya dates to Western dates, there are few instances where the day in the year matters; in most cases all you care about is the year. But in the case of astronomical events, it does matter, and what is important is getting the right calendar system for whatever you are comparing it to. The easy solution is to always show both. In a paper or wikipedia article where stating both is awkward, use Julian or Gregorian, whichever is most appropriate, and state what you are doing.
On correlations, I am certain that the right correlation is about 584283. But it could be off by a couple of days. Every time I try to pin it down to an exact correlation, there is just enough slop that it becomes difficult. For example, the D and E glyphs (moon age) should be able to pin it. Except we don't know when they started counting moon ages. Was it last appearance (as Bruce Love thinks), new moon, or first appearance? There is about two days of slop there, which makes it hard. On the Dresden Venus pages there is as much as four days of variability, depending on which lub of the Venus tables you are working with. The post-conquest documents all have that kind of few days of variability that can be argued. I don't think any of the monuments with "eclipse" glyphs on them are definitive, since they could be stating that 9.17.0.0.0 happened *just after* an eclipse instead of on the day of it. Simon Martin and Joel Skidmore published a paper recently arguing for 584286 (I'm pretty skeptical). I used to use 584285, but I now use 584283 for my writing and make it the default in my program. However, my program allows you to use *any* correlation. I provide a couple, but you can enter any others you like (in the Pro version).
For that matter, I make virtually every setting able to be changed. You want the 819 day count on the Maya epoch to be something besides 3, just knock yourself out. Want to study epi-Olmec dates according to Justeson and Kaufman (I'm also skeptical about their reasoning, but haven't looked into it enough), go for it. Want to call the days by their name in Chorti? It can do that too. The program works forward and backward 10 trillion years. Good enough to handle everything except David Stuart's trying to roll back an octillion years for the date on the Coba monuments. (I'm skeptical about this too--I'm pretty sure the Maya meant there to be a 13 in *all* higher order digits on the Maya epoch, not just the 20 shown; they have to stop writing 13s somewhere and 20 was enough to get their point across.) Grr (talk) 01:01, 12 June 2014 (UTC)
The arguments against the proleptic Gregorian Calendar are 1. That it's fiction and 2. That it's unknown outside the Mayanist community. Why revise all of your dates to an imaginary calendar that will confuse for example, astronomers? Regarding the correlation question: If there was any doubt about the GMT correlation it should have been resolved when Susan Milbrath and the Tedlocks discovered that hundreds of ethnic groups have maintained the Tzolk'in and in many cases, the Haab', to this day and they all use the GMT correlation. If you note that some groups used the disappearance of the waning moon and some used the appearance of the new moon as day zero in the lunar cycle, the GMT correlation works almost perfectly. Also as you note on your site, trying to prove the correlation using the Venus almanac in the Dresden codex is hopeless because the cycles are so irregular and not conducive to prediction using Mayan mathematics. Also Finley's page: http://www.bibliotecapleyades.net/ciencia/dresden/dresdencodex04.htm links to a table of heliacal phenomena, which were apparently used for these studies: http://user.online.be/felixverbelen/vnhltbl.htm. This table appears to have been created using a rule of thumb, such as the heliacal rising is x days after conjunction. The values in this table vary from those calculated by Chac, by as much as three days. This is probably due to the difference in declination between Venus and the Sun, which can cause the arcus visionis of Venus at rising or setting to be plus or minus several degrees at conjunction. So if anyone wants to study the Venus almanac he should go back to fundamental assumptions and write a program that will calculate the heliacal phenomena correctly using rigorous methods. Senor Cuete (talk) 14:29, 12 June 2014 (UTC)
You say: "The calculation library can be ported using Mono,". I'm not familiar with it. What is it? Senor Cuete (talk) 14:33, 12 June 2014 (UTC)
Mono is a Linux/Mac version of the .NET framework. However, it is not a complete implementation. So while they do all the stuff necessary to support the calculation engine, they don't support WPF which is what the calendar program's UI is written in. This precludes an easy port of the UI. There is a version of Wine (the Windows emulator for Linux/Mac), but it is buggy. There is a company that will patch it to make your program work, but it is cost prohibitive for me. I could patch Wine myself, but that's going to be a lot of work. I can write a new UI in Objective C (with all its learning curve). I can possibly get it all to work in Silverlight, which works on the Mac. I can also just do a web interface. I could probably do a reasonable job using HTML 5 and calculations on the server side...not as good as a program, but in the ballpark...however it would require an Internet connection to do calculations. That isn't practical for many Maya in rural Guatemala, or archaeologist in the field.
Any argument you make against the proleptic Gregorian calendar also apply to the proleptic Julian calendar. Proleptic Gregorian is not unknown...it is just infrequently used. Take the Microsoft date libraries...they use the proleptic Gregorian calendar back to January 1, year 1. There is no cutoff at 1582, or 1752, or whatever. (There is a separate way to calculate Julian dates that also have no cutoff.) My point is that particularly in the date range between 1582 and whenever *your country* adopted the Gregorian Calendar, you need to have both dates available. And dates before 46 BCE are just as arbitrary, since they use the proleptic Julian calendar. That having your program switch at some arbitrary year is not necessarily helpful. If you are looking at a date in 1590, but it is an English document (maybe something related to this paper: http://www.mesoweb.com/pari/publications/RT07/Xoc.pdf), you need to use Julian dates because English didn't switch to Gregorian until 1752, but the program will have switched to Gregorian dates in 1582. This is just dumb. You need both types of dates in a calendar program, not switching dates at some arbitrary point. In a paper or a web site, I don't care which one you use because I can convert from one to the other. Just make it clear either somewhere in the paper what you use throughout, or on each individual date.
To get an exact handle on the Arcus Visionis of Venus, I use this program: http://www.alcyone-ephemeris.info/planetary_lunar_and_stellar_visibility.html. It is enough until I write a new astronomy program using the formulas in Explanatory Supplement to the Astronomical Almanac.
Most programmers use Astronomical Algorithms by Jean Meeus - http://www.willbell.com/math/mc1.htm. I highly recommend it for its complete algorithms, explanations, examples and some pseudocode. Most ephemerides are based on this book. One caveat is chapter 15. Rise and Set, which could use improvement. Meeus uses an abridged version of the VSOP 87 theory with enough terms for pretty good accuracy but I would download the complete theory with its 5,000 or so terms from the 'net, or get it from some source like the JPL ephemerides CD. Today's computers are fast enough to calculate the heliocentric lambda, beta and radius vector of a planet in about a millisecond, which is good because you will have to do this a lot of times before you have the Julian date of the geometric rising on the day with a sufficient arcus visionis for visibility. I've looked at source code sites for implementations of the necessary algorithms and found them to be written in a bunch of of languages, many of which are not very useful and often in an abstruse style. I wrote my own in C which has the advantages of being portable and running very fast. I wouldn't write these in an object oriented language because the overhead in typing and performance would be significant. You will have to write implementations of most of the algorithms in Meeus to calculate the alt az of a planet, this is a lot. Also you would have to write a routine to find the heliacal rising and settings. Senor Cuete (talk) 18:52, 12 June 2014 (UTC)

ArbCom elections are now open![edit]

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 13:52, 23 November 2015 (UTC)

ArbCom Elections 2016: Voting now open![edit]

Scale of justice 2.svg Hello, Grr. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)