> Got it, but if other people don't agree then this is going nowhere.
Yes. As I wrote, I don't particularly care about functions like "is
point on line". I can prepare a patch to fix as many problems as
possible around those operators by preserving the current epsilon.
I though we were arguing
On Tue, Jan 31, 2017 at 1:06 PM, Emre Hasegeli wrote:
> This is what he wrote:
>
>> As I understand it, the key problem is that tests like "is point on line"
>> would basically never succeed except in the most trivial cases, because of
>> roundoff error. That's not very nice, and it might cascade
> Backing up a bit here, have we lost track of the problem that we're
> trying to solve? Tom gave his opinion here:
>
> https://www.postgresql.org/message-id/3895.1464791...@sss.pgh.pa.us
>
> But I don't see that the latest patch I can find does anything to fix
> that.
This is what he wrote:
> A
On Thu, Jan 26, 2017 at 5:53 AM, Emre Hasegeli wrote:
> Though, I know the community is against behaviour changing GUCs. I
> will not spend more time on this, before I get positive feedback from
> others.
As if on cue, let me say that a behavior-changing GUC sounds like a
terrible idea to me. I
On Thu, Jan 26, 2017 at 9:11 PM, Kyotaro HORIGUCHI
wrote:
>> Though, I know the community is against behaviour changing GUCs. I
>> will not spend more time on this, before I get positive feedback from
>> others.
>
> That's too bad. I'm sorry that I wasn't very helpful..
You make a constructive d
Hello,
At Thu, 26 Jan 2017 11:53:28 +0100, Emre Hasegeli wrote in
> > Even though I'm not sure but I don't see a "natural" (or
> > agreeable by many poeple) ordering of geometric types in
> > general. Anyway it's quite application (not application program
> > but the relationship with the real
> Even though I'm not sure but I don't see a "natural" (or
> agreeable by many poeple) ordering of geometric types in
> general. Anyway it's quite application (not application program
> but the relationship with the real world) specific.
We can just define it for point as "ORDER BY point.x, point.
Hello, Emre.
At Wed, 25 Jan 2017 12:24:18 +0100, Emre Hasegeli wrote in
> I am responding both of your emails together.
>
> > Perhaps I don't understand it. Many opclass are defined for
> > btree. But since (ordinary) btree handles only one-dimentional,
> > totally-orderable sets, geometric ty
I am responding both of your emails together.
> Perhaps I don't understand it. Many opclass are defined for
> btree. But since (ordinary) btree handles only one-dimentional,
> totally-orderable sets, geometric types even point don't fit
> it. Even if we relaxed it by removing EPSILON, multidimenti
Sorry, this is the continuation of the previous comment.
At Wed, 18 Jan 2017 17:36:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170118.173612.13506164.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> (I apologize in advance for possible inaccurate wording on maths,
> which might
Hello.
(I apologize in advance for possible inaccurate wording on maths,
which might cause confusion..)
At Wed, 11 Jan 2017 16:37:59 +0100, Emre Hasegeli wrote in
> > - Floating point comparisons for gemetric types
> >
> > Comparison related to geometric types is performed by FPeq
> > macr
> - Floating point comparisons for gemetric types
>
> Comparison related to geometric types is performed by FPeq
> macro and similars defined in geo_decls.h. This intends to give
> tolerance to the comparisons.
>
> A
> FPeq: |<=e-|-e=>|(<= means inclusive, e = epsil
Hello,
At Fri, 18 Nov 2016 10:58:27 +0100, Emre Hasegeli wrote in
> > To keep such kind of integrity, we should deeply consider about
> > errors.
>
> My point is that I don't think we can keep integrity together with the
> fuzzy behaviour, or at least I don't have the skills to do that. I
>
Hello,
# Sorry for a trash I emitted before..
Perhaps you don't assume any calculations applied on stored
geo-type values. Please be patient to disucuss with me. (Sorry
for perhas hard-to-read English..)
At Fri, 18 Nov 2016 10:58:27 +0100, Emre Hasegeli wrote in
> > To keep such kind of integ
> To keep such kind of integrity, we should deeply consider about
> errors.
My point is that I don't think we can keep integrity together with the
fuzzy behaviour, or at least I don't have the skills to do that. I
can just leave the more complicated operators like "is a
point on a line" as it is,
Hello,
At Mon, 14 Nov 2016 11:41:52 +0100, Emre Hasegeli wrote in
> > What way to deal with it is in your mind? The problem hides
> > behind operators. To fix it a user should rewrite a expression
> > using more primitive operators. For example, (line_a # point_a)
> > should be rewritten as ((p
> What way to deal with it is in your mind? The problem hides
> behind operators. To fix it a user should rewrite a expression
> using more primitive operators. For example, (line_a # point_a)
> should be rewritten as ((point_a <-> lineseg_a) < EPSILON), or in
> more primitive way. I regared this t
Hello,
At Sun, 13 Nov 2016 22:41:01 +0100, Emre Hasegeli wrote in
> > We can remove the fuzz factor altogether but I think we also
> > should provide a means usable to do similar things. At least "is
> > a point on a line" might be useless for most cases without any
> > fuzzing feature. (Nevert
> We can remove the fuzz factor altogether but I think we also
> should provide a means usable to do similar things. At least "is
> a point on a line" might be useless for most cases without any
> fuzzing feature. (Nevertheless, it is a problem only when it is
> being used to do that:) If we don't
> The reason for that is that you forgot to edit an alternative
> exptect file, which matches for en_US locale.
Now I understand. Thank you for the explanation.
> But the test doesn't for collation and the only difference
> between the alternative expect files comes from the difference of
> coll
Hello,
> Aside from that, I'd like to comment this patch on other points
> later.
The start of this patch is that the fact that most of but not all
geometric operators use fuzzy comparson. But Tom pointed out that
the fixed fuzz factor is not reasonable but hard to find how to
modify it.
We can
Hello,
> > Returning to the issue, the following query should give you the
> > expected result.
> >
> > SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2;
>
> Yes, I have worked around it like this. What I couldn't understand is
> how my patch can cause this regression. How is it p
> Returning to the issue, the following query should give you the
> expected result.
>
> SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2;
Yes, I have worked around it like this. What I couldn't understand is
how my patch can cause this regression. How is it passes on master
withou
Hello,
At Thu, 29 Sep 2016 10:37:30 +0200, Emre Hasegeli wrote in
> > regression=# select 'I- 580Ramp' < 'I- 580/I-680
> > Ramp';
> > ?column?
> > --
> > t
> > (1 row)
>
> on the Linux server I am testing, it is not:
>
> > regression=# selec
> Well, those two results are not contradictory -- notice that you
> switched the order of the values in the comparison. I don't think
> you've really found the explanation yet.
I am sorry I copy-pasted the wrong example:
"select_views" test runs:
> SELECT name, #thepath FROM iexit ORDER BY 1,
On Wed, Sep 28, 2016 at 2:04 PM, Kevin Grittner wrote:
> Will take a look and post again.
I am moving this patch to the next CF. You'll be hearing from me
sometime after this CF is closed.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
On Wed, Sep 28, 2016 at 12:02 PM, Emre Hasegeli wrote:
>> `make check` finds differences per the attached. Please
>> investigate why the regression tests are failing and what the
>> appropriate response is.
>
> I fixed the first one and workaround the second with COLLATE "C". I
> have how my ch
> Emre, are you going to address the above? It would have to be Real
> Soon Now.
Yes, I am working on it. I found more problems, replaced more
algorithms. That took a lot of time. I will post the new version
really soon. I wouldn't feel bad, if you wouldn't have enough time to
review it in th
On Fri, Sep 9, 2016 at 4:25 PM, Kevin Grittner wrote:
> On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote:
> These patches apply and build on top of 5c609a74 with no problems,
> but `make check` finds differences per the attached. Please
> investigate why the regression tests are failing and
On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote:
>> The first patch fails to apply due to bit-rot. That's easy enough
>> to correct, but then it runs into warnings on make:
>
> Rebased and fixed.
These patches apply and build on top of 5c609a74 with no problems,
but `make check` finds diffe
On Mon, Jul 18, 2016 at 3:54 PM, Emre Hasegeli wrote:
> My progress so far is attached as 2 patches. First one introduces an
> header file for adt/float.c. Second one refactors the geometric
> operations.
The first patch fails to apply due to bit-rot. That's easy enough
to correct, but then it
On Wed, Jun 1, 2016 at 10:27 AM, Tom Lane wrote:
> As I understand it, the key problem is that tests like "is point on line"
> would basically never succeed except in the most trivial cases, because of
> roundoff error. That's not very nice, and it might cascade to larger
> problems like object-c
Paul Ramsey writes:
> One of the things people find annoying about postgis is that
> ST_Intersects(ST_Intersection(a, b), a) can come out as false (a
> derived point at a crossing of lines may not exactly intersect either
> of the input lines), which is a direct result of our use of exact math
> f
On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby wrote:
> On 6/1/16 10:03 AM, Paul Ramsey wrote:
>>
>> We don't depend on these, we have our own :/
>> The real answer for a GIS system is to have an explicit tolerance
>> parameter for calculations like distance/touching/containment, but
>> unfortunately w
On 6/1/16 10:03 AM, Paul Ramsey wrote:
We don't depend on these, we have our own :/
The real answer for a GIS system is to have an explicit tolerance
parameter for calculations like distance/touching/containment, but
unfortunately we didn't do that so now we have our own
compatibility/boil the oc
On 06/01/2016 07:52 AM, Jim Nasby wrote:
> On 6/1/16 9:27 AM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas
>>> wrote:
>> Figuring out what to do about it is harder. Your proposal seems
to be
>> to remove them except where we need the
On Wed, Jun 1, 2016 at 7:52 AM, Jim Nasby wrote:
>
> I suspect another wrinkle here is that in the GIS world a single point can
> be represented it multiple reference/coordinate systems, and it would have
> different values in each of them. AIUI the transforms between those systems
> can be rathe
On 6/1/16 9:27 AM, Tom Lane wrote:
Kevin Grittner writes:
> On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
>> Figuring out what to do about it is harder. Your proposal seems to be
>> to remove them except where we need the fuzzy behavior, which doesn't
>> sound unreasonable, but I don't
Kevin Grittner writes:
> On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
>> Figuring out what to do about it is harder. Your proposal seems to be
>> to remove them except where we need the fuzzy behavior, which doesn't
>> sound unreasonable, but I don't personally understand why we need it
>>
On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
> On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote:
>> There are those macros defined for the built-in geometric types:
>>
>>> #define EPSILON 1.0E-06
>>
>>> #define FPzero(A) (fabs(A) <= EPSILON)
>>> #define FPe
On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote:
> There are those macros defined for the built-in geometric types:
>
>> #define EPSILON 1.0E-06
>
>> #define FPzero(A) (fabs(A) <= EPSILON)
>> #define FPeq(A,B) (fabs((A) - (B)) <= EPSILON)
>> #define
There are those macros defined for the built-in geometric types:
> #define EPSILON 1.0E-06
> #define FPzero(A) (fabs(A) <= EPSILON)
> #define FPeq(A,B) (fabs((A) - (B)) <= EPSILON)
> #define FPne(A,B) (fabs((A) - (B)) > EPSILON)
> #define
42 matches
Mail list logo