Hi Chenliang, Will we hear from you tomorrow at 10AM Pacific, or in a few weeks when the call is a better time for Asia-based callers?
-Greg On Thu, Jan 14, 2016 at 8:18 AM, chenliang wang <hi181904...@msn.com> wrote: > Cool! I'd like to join the next discussion. > > Best, > Chenliang Wang > > > On 01/13/2016 06:36 PM, Greg Chase 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 >>>>>>>> >>>>>>> >>> >
