Yes, 2AM on Saturday... May you please share Gautam's representation video after the call?
Cheers, Kuien Liu On Wed, Jan 13, 2016 at 6:36 PM, Greg Chase <g...@gregchase.com> wrote: > As I said, our next call is not China-friendly: > http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201601.mbox/%3CCAMg1VtnKB-WoyVqCstfMNCcJVOn2HKQQ6wNfqdovhgnB7zd5cw%40mail.gmail.com%3E > > This is this Friday, 10AM Pacifc Standard Time which is 2AM Saturday > Beijing time. > > We will arrange a next call in a couple weeks at an Asia friendly time to > support contributors in Asia. > > However, if you make the next call, we will make time for you to talk :) > > Regards, > > -Greg > > On Wed, Jan 13, 2016 at 2:18 AM, Kuien Liu <k...@pivotal.io> wrote: > >> Great, I would like to join it, please send me an invitation if possible. >> >> Cheers, >> Kuien Liu >> >> On Wed, Jan 13, 2016 at 6:10 PM, Greg Chase <gch...@gmail.com> wrote: >> >>> Perhaps ChenLiang would like to join a call with the MADlib community >>> and discuss his contribution? >>> >>> We have a call this Friday 10AM PST which is not a friendly time for >>> China, but we can schedule a next call at a friendlier time. >>> >>> This email encrypted by tiny buttons & fat thumbs, beta voice >>> recognition, and autocorrect on my iPhone. >>> >>> > On Jan 13, 2016, at 1:53 AM, Ivan Novick <inov...@pivotal.io> wrote: >>> > >>> > Cool! >>> > >>> >> On Wed, Jan 13, 2016 at 5:52 PM, Kuien Liu <k...@pivotal.io> wrote: >>> >> >>> >> Got it, I think I can have a (f2f) talk with Chenliang Wang, as he was >>> >> graduated from an institute of CAS which is not far from our Beijing >>> >> office, and I am familiar with his supervisor and lab director. So I >>> think >>> >> it is highly possible to find him directly in Beijing. >>> >> >>> >> Cheers, >>> >> Kuien Liu >>> >> >>> >>> On Wed, Jan 13, 2016 at 3:05 PM, Ivan Novick <inov...@pivotal.io> >>> wrote: >>> >>> >>> >>> Hello ChenLiang, >>> >>> >>> >>> I have read your description of the interface and to my understanding >>> >>> this is a supervised machine learning algorithm that supports >>> geometry >>> >>> data. Am I correct? >>> >>> >>> >>> What could be a good industrial use case for this model for some >>> >>> examples? Could you train a system based on locations and weather >>> to find >>> >>> bad signals for cell phone? Can you provide any real world example >>> >>> scenario where this type of model will be useful for end users? >>> >>> >>> >>> Also I am adding CC to some of my colleagues at work. Kuien, Max, >>> >>> Yandong can you provide any feedback on this proposal from your >>> Point of >>> >>> View? >>> >>> >>> >>> >>> >>> >>> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201601.mbox/%3cblu175-w72199bca72716d8c1a99bf4...@phx.gbl%3E >>> >>> >>> >>> Cheers, >>> >>> Ivan >>> >>> >>> >>> >>> >>> On Wed, Jan 13, 2016 at 11:20 AM, WangChenLiang <hi181904...@msn.com >>> > >>> >>> wrote: >>> >>> >>> >>>> Sorry, the link of attachment (http://1drv.ms/1ZjAiCg) is lost in >>> the >>> >>>> previous letter. >>> >>>> >>> >>>>> From: hi181904...@msn.com >>> >>>>> To: dev@madlib.incubator.apache.org >>> >>>>> Subject: RE: How to contribute a spatial module to MADlib >>> manipulating >>> >>>> objects from PostGIS >>> >>>>> Date: Wed, 13 Jan 2016 11:09:17 +0800 >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Hi ,Caleb and Ivan! >>> >>>>> Thanks for your attention and help. I reviewed the previous draft >>> >>>> and find >>> >>>>> something inappropriate. The archive containing the new draft and >>> >>>> example code >>> >>>>> is attached in the letter which would be more reasonable than the >>> >>>> earlier edition. >>> >>>>> Please go over the manuscript and give suggestion again . >>> >>>>> The following are my answers to Caleb's questions. >>> >>>>> - Does this function require PostGIS to also be >>> >>>>> installed? If yes, it would be better >>> >>>>> if we disable the function if >>> >>>>> PostGIS is not present rather than introduce PostGIS >>> >>>>> as a dependency. (Similar >>> >>>>> to what we do with our requirement on the xml module with our PMML >>> >>>> export >>> >>>>> functionality). >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> A:Yes. I am trying to avoid >>> >>>>> input any spatial datatypes in the interface of GWR. >>> >>>>> But I have no >>> >>>>> idea if it is necessary to provide simple alternative when PostGIS >>> is >>> >>>> not >>> >>>>> available. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> - What are the exact datatypes in the function >>> >>>>> definition for regression_location >>> >>>>> and prediction_location? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> A:I changed the datatype >>> >>>>> to TEXT as the name of POINT or MULTIPOLYGON >>> >>>>> (centroid of >>> >>>>> each polygon for estimation for GWR). >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> - In the description it describes >>> >>>>> regression_location as "The length of >>> >>>>> regression_location must be equal to the length of >>> >>>>> source_table", which signals to me that it is likely intended to >>> be a >>> >>>>> column of the source table? If not then how is >>> >>>>> this length represented? >>> >>>>> >>> >>>>> >>> >>>>> A: In the previous >>> >>>>> interface, I was trying to input a geometry field which could be >>> >>>>> from another >>> >>>>> table having different row number. Now, I alter the argument >>> >>>>> definition and make it >>> >>>>> to TEXT. It must be the name of geometry field in the >>> >>>>> source table. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> - You didn't mark regression_location as >>> >>>>> (optional). Due to the way Postgres >>> >>>>> functions work all optional arguments >>> >>>>> must come after all required arguments, >>> >>>>> so having a non-optional argument in >>> >>>>> the middle of the optional list must be >>> >>>>> avoided. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> A:Thanks for >>> >>>>> reminding me of this mistake. It is really my fault. The order of >>> >>>>> argument is changed in this edition. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> - I haven't read through the literature, but it is >>> >>>>> not immediately clear to me why >>> >>>>> prediction_location is a parameter to >>> >>>>> gwregr_train() rather than gwregr_predict(). >>> >>>>> Can you provide a brief >>> >>>>> description to the way that prediction_location is used in >>> >>>>> the model and its >>> >>>>> relationship to training and prediction. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> A: Actually, >>> >>>>> there are three kinds location data including location of sample >>> data, >>> >>>>> regression and prediction in the modeling of GWR. >>> >>>>> >>> >>>>> Locations of sample data indicate where is sample >>> >>>>> data. Locations of regression >>> >>>>> indicate where regression should be conducted. If >>> >>>>> it is identical to data location >>> >>>>> (in most instances),diagnostic information can >>> >>>>> be calculated. >>> >>>>> >>> >>>>> Locations of >>> >>>>> prediction indicate where coefficients should be predicted. It >>> should >>> >>>> be a >>> >>>>> parameter for a predict function. Putting regression_location into >>> >>>> training >>> >>>>> function is just for omitting kernel arguments and maybe not >>> >>>> appropriate. In the process of >>> >>>>> training, GWR estimates weight and coefficients with distance >>> >>>>> between data_loctions and regression_loctions. Then, diagnostic >>> >>>> information are >>> >>>>> estimated when these two locations are identical. We can treat >>> >>>> data_locationas regression_location to simplify the process not >>> taking >>> >>>> different locations from >>> >>>>> data location in the training step. >>> >>>>> >>> >>>>> In the process of >>> >>>>> prediction , there are two new information including new >>> >>>>> independent variables and new locations. Therefore, coefficients >>> and >>> >>>> weight >>> >>>>> vector must be estimated >>> >>>>> again. GWR can >>> >>>>> estimate coefficients in any positions >>> >>>>> using independent variables of sample data. >>> >>>>> If we also provide independent >>> >>>>> variables in any positions,we can also obtain >>> >>>>> dependent variable in any position. So if we treat coefficients at >>> >>>> prediction_location as a training result to put >>> >>>>> coefficients into prediction >>> >>>>> directly, it is reasonable to put it into training function. But >>> if we >>> >>>> treat it as a part of prediction, it is appropriate to set >>> >>>> predicton_location within predict function. And then, prediction >>> function >>> >>>> must require kernel >>> >>>>> parameters in addition to new data and locations for prediction. >>> Maybe >>> >>>> this way >>> >>>>> is more clear >>> >>>>> and reasonable, and is similar with others GWR packages in R. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> I >>> >>>>> rewrote the description of interface taking your suggestion into >>> >>>> account. I >>> >>>>> moved >>> >>>>> prediction_location into predict function and modified >>> >>>>> some mistake and >>> >>>>> unnecessary arguments. The new draft of interface design is >>> attached >>> >>>> in the >>> >>>>> letter. >>> >>>>> >>> >>>>> >>> >>>>> Regards, >>> >>>>> >>> >>>>> ChenLiang Wang >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> From: cwel...@pivotal.io >>> >>>>>> Date: Tue, 5 Jan 2016 10:31:20 -0800 >>> >>>>>> Subject: Re: How to contribute a spatial module to MADlib >>> >>>> manipulating objects from PostGIS >>> >>>>>> To: dev@madlib.incubator.apache.org >>> >>>>>> >>> >>>>>> Hi ChenLiang, >>> >>>>>> >>> >>>>>> Thanks for taking the next step to flush this out. >>> >>>>>> >>> >>>>>> As a whole: >>> >>>>>> - naming and basic interface seems consistent with existing >>> >>>> conventions. >>> >>>>>> - names are descriptive. >>> >>>>>> - references to the literature is provided. >>> >>>>>> - functionality is complementary to the library. >>> >>>>>> >>> >>>>>> What is not clear to me is: >>> >>>>>> - Does this function require PostGIS to also be installed? If >>> yes, >>> >>>> it >>> >>>>>> would be better if we disable the function if PostGIS is not >>> present >>> >>>> rather >>> >>>>>> than introduce PostGIS as a dependency. (Similar to what we do >>> with >>> >>>> our >>> >>>>>> requirement on the xml module with our PMML export functionality). >>> >>>>>> - What are the exact datatypes in the function definition for >>> >>>>>> regression_location and prediction_location? >>> >>>>>> - In the description it describes regression_location as "The >>> length >>> >>>> of >>> >>>>>> regression_location must be equal to the length of source_table", >>> >>>> which >>> >>>>>> signals to me that it is likely intended to be a column of the >>> source >>> >>>>>> table? If not then how is this length represented? >>> >>>>>> - You didn't mark regression_location as (optional). Due to the >>> way >>> >>>>>> Postgres functions work all optional arguments must come after all >>> >>>> required >>> >>>>>> arguments, so having a non-optional argument in the middle of the >>> >>>> optional >>> >>>>>> list must be avoided. >>> >>>>>> - I haven't read through the literature, but it is not immediately >>> >>>> clear to >>> >>>>>> me why prediction_location is a parameter to gwregr_train() rather >>> >>>> than >>> >>>>>> gwregr_predict(). Can you provide a brief description to the way >>> >>>> that >>> >>>>>> prediction_location is used in the model and its relationship to >>> >>>> training >>> >>>>>> and prediction. >>> >>>>>> >>> >>>>>> Regards, >>> >>>>>> Caleb >>> >>>>> ChenLiang 要与你在 OneDrive >>> >>>> 上共享一个文件。要查看该文件，请单击下面的链接。 >>> >>>> gwr4madlib.rar >>> >> >>> >> >> >
