The video should be available for posting to Youtube soon. On Mon, Jan 18, 2016 at 10:37 PM, Kuien Liu <[email protected]> wrote:
> 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 >>>>> >> >>>>> >>>> >>>> >>> >> >
