<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18828"></meta>
</head>
<body>
<div align="left">I think the expected often is very important. As a user you don't even know always what is right and what is wrong but you learn the behavior of a software. </div>
<div align="left"> </div>
<div align="left">often analyzes is based on changes more than the real numbers.</div>
<div align="left">Questions like </div>
<div align="left">Is it a decreasing or increasing number of households in the bufferzone of a river</div>
<div>Is it a decreasing or increasing areas affected of clearcuts in forestry (assuming a buffer around the clearcut is affected)</div>
<div> </div>
<div>I don't find any better examples right know, but the point is that most analyzes based on changes over time is more sensitive to changed behavior than right or wrong behavior.</div>
<div> </div>
<div>Isn't that the reason why we don't push out bugfixes the same day as the bug is fixed. To keep the expected behavior even if it is wrong.</div>
<div> </div>
<div>The important thing then is to make people thinking over how the new behavior will affect their applications when the real functions gets released. Different function names would make it more obvious.</div>
<div> </div>
<div>/Nicklas</div>
<div align="left"> </div>
<div align="left">2009-11-03 Paragon Corporation wrote:<br />
<br />
></div>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Nicklas,</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Well actually we wouldn't change it in a micro release. Yes I agree changing output in the micro release is probably a no no.</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">We'd change it in a minor or major release (proably major in this case in 2.0). As far as naming goes yes that is the basic argument. That if we replace the function with a real one. The real one will do "more the right thing" than the old. So in essense it would be treated like a bug fix rather than a mere change of behavior.</span></div>>
<div align="left"> </div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">That does bring up the question of:</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Is the right answer the one you are expecting or the one you expect.</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">(are expecting meaning the one you are used to vs. you expect (without any prior expectations of behavior))</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">For example in SQL 1/2 => 0 (both PostgreSQL and SQL Server and a lot of relational databases behave this way by the way)</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">But if I change the behavior to suddenly return </span> <span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">0.5 (like MySQL does)</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Do people consider it wrong because it is no longer the expected answer of 0, but from a mathematical point of view, it is the one you expect.</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt"> </span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Thanks,</span></div>>
<div align="left"><span style="FONT-FAMILY: Arial; COLOR: #0000ff; FONT-SIZE: 10pt">Regina</span></div><br />
>>
<div align="left">
<hr />
<span style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"><b>From:</b> postgis-devel-bounces@postgis.refractions.net [mailto:postgis-devel-bounces@postgis.refractions.net] <b>On Behalf Of </b>nicklas.aven@jordogskog.no<br />
><b>Sent:</b> Tuesday, November 03, 2009 6:07 AM<br />
><b>To:</b> PostGIS Development Discussion<br />
><b>Subject:</b> Re: [postgis-devel] Geom/Geog Hack Plan<br />
></span><br />
></div>>
<div> </div>>
<div>Just a question for my understanding. </div>>
<div>What's the argument against a special prefix in function-name for those functions.</div>>
<div>If the argument is that we then can implement the "real" function in a micro-release, I don't think it is a good argument.</div>>
<div>Exchanging the hacked version with the real will cause a changed behavior of the function and is probably not what users expect from a micro-release, from the policy not to change functionality in micro-releases.</div>>
<div> </div>>
<div>/Nicklas</div>>
<div> </div>
<p align="left"><br />
><br />
>2009-11-03 Paragon Corporation wrote:<br />
><br />
>Paul and Kevin,<br />
>><br />
>>I'm in agreement with Mark too. I suppose one or 2 of these functions is<br />
>>not going to pollute our 1.5 that much.<br />
>><br />
>>So how about this as a plan:<br />
>><br />
>>Paul picks 1 or 2 more of these kind of functions. Note we already have<br />
>>buffer -- which is now documented. Though not sure if the documentation is<br />
>>clear enough -<br />
>>http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I think<br />
>>we need to revise our documentation template yet again -- though I'll put<br />
>>that in a separate note).<br />
>><br />
>>The rest of the functions get put in a wiki page and prominently linked from<br />
>>the documentation<br />
>><br />
>><br />
>> in geography index<br />
>>http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_GeographyF<br />
>>unctions<br />
>><br />
>>as well as geography description page<br />
>><br />
>> for easy access<br />
>>http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geography<br />
>><br />
>>Is everyone okay with that plan?<br />
>><br />
>>Thanks,<br />
>>Regina<br />
>><br />
>><br />
>>_______________________________________________<br />
>>postgis-devel mailing list<br />
>>postgis-devel@postgis.refractions.net<br />
>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>></p>
</body>
</html>