Hi Greg, Is the video replay available for guys outside Pivotal network to watch? I made a call with Chenliang Wang in 7:15pm~8:13pm yesterday evening, he explained his case in evaluating the property prices, he is thinking to implement this function (GWR) inner databases. I explain the usage of Madlib and how to enable PostGIS in GPDB. I think Gautum's presentation on BayesianAnalysis is a good tutorial for him to kick-off his plan.
Cheers, Kuien Liu On Fri, Jan 15, 2016 at 10:53 AM, Greg Chase <[email protected]> wrote: > We always share the presentation and post the video replay as well. > > You can also drink lots of coffee, and join us if you are crazy enough. > > We like crazy people. > > This email encrypted by tiny buttons & fat thumbs, beta voice recognition, > and autocorrect on my iPhone. > > On Jan 14, 2016, at 6:35 PM, Kuien Liu <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> > >>>> > Cool! >>>> > >>>> >> On Wed, Jan 13, 2016 at 5:52 PM, Kuien Liu <[email protected]> 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 <[email protected]> >>>> 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/%[email protected]%3E >>>> >>> >>>> >>> Cheers, >>>> >>> Ivan >>>> >>> >>>> >>> >>>> >>> On Wed, Jan 13, 2016 at 11:20 AM, WangChenLiang < >>>> [email protected]> >>>> >>> wrote: >>>> >>> >>>> >>>> Sorry, the link of attachment (http://1drv.ms/1ZjAiCg) is lost in >>>> the >>>> >>>> previous letter. >>>> >>>> >>>> >>>>> From: [email protected] >>>> >>>>> To: [email protected] >>>> >>>>> 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: [email protected] >>>> >>>>>> Date: Tue, 5 Jan 2016 10:31:20 -0800 >>>> >>>>>> Subject: Re: How to contribute a spatial module to MADlib >>>> >>>> manipulating objects from PostGIS >>>> >>>>>> To: [email protected] >>>> >>>>>> >>>> >>>>>> 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 >>>> >> >>>> >>> >>> >> >
