|
OMG! it is so obvious now that you say it! 
|
|
|
|
|
Super Lloyd wrote: it describe 2 potatoes intersection
That explains it.
Your computer's got the wrong chips.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Ha! Forget 586!
Sour cream and chilly is the way of the future! 
|
|
|
|
|
|
haha, help us potato man! you are our only hope!
|
|
|
|
|
just wave a dead chicken over it. it works for me.
of course YMMV my computer is just an old head in a jar that i put a hex on - linux will run on anything these days.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Lots of good tips in here! 
|
|
|
|
|
in all seriousness, I just got done with tackling a similar debugging issue.
Sometimes the debugger just isn't enough. As another commenter pointed out, the algorithm doesn't usually make much sense to people once it's at the point where it breaks.
So you should write more code. I dumped intermediary LALR tables to CSV for example so i could visualize them. I also made symbols and grammar rules print out string representations of themselves to the debugger to help.
In the end, write MOAR CODE until the problem reveals itself.
Sometimes using graphviz can help, in extreme cases.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yeah I made (some tiny bit) of progress lately.. because I wrote plenty of tools and visualisation to make the issue more understandable...
I am getting close.. When it fails I got 3 intersection between 2 shapes (best understanding, so far, about the problem) now I just have to find out why! 
That can't be.. I guess I misdiagnosed a touch for an intersection.... That's a tricky one, since intersection are approximation though...
|
|
|
|
|
I'm building a parser generator right now, so if you know what that entails, you know I mean it when I say I feel your pain, neighbor.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I have used a few of them, they are good! 
They are also tricky beast!
Good luck with that! And thanks for the support!
|
|
|
|
|
In my past I did a lot of geometric programming. Something we had to be be very careful of was degenerate intersections and numerical tolerance. That is the first thing I thought of when you mentioned an odd number of intersections. If you are at or very close to the endpoint of a line segment, it might miss, or hit, when it really shouldn't.
Sometimes you have to catch them and handle them specially (*cough* hack *cough*). Like artificially extend the vector slightly to see if it intersects within the segment, or keep intersections that are questionable conditional until you can tell the count is right. For instance, imagine two line segments whose common endpoint is on or very close to the segment you are intersecting with. Really, there should be only one intersection there. But if you count each segment endpoint as colliding, then you get two intersections where you should have only one. Or vice versa, you might discard both because you think they are off the line, and have zero where you should have one.
Sorry, this is off the top of my head remembering stuff we had to deal with a long time ago.
|
|
|
|
|
Hey I am pretty sure it is such error.. it only happen (so far as I know) with 2 almost parallel shape and one with 1 very small edge...
Anyhow can't do anything more about this week, preparing a table top RPG adventure..
But gods this is so frustrating...
For the record to get around such issue I merge many point that I found close to each other, nudging them slightly.. But that is not enough... Now I also use smarter crossing edge detection at intersection, still not enough.. 
|
|
|
|
|
That's how I have solved some knotty issues with a Python bouncy ball simulation I have been writing(just because I wondered what all the hype about Python has been).
I created a logger class and wrote all the data out to a tab delimited file.
I then found fairly quickly where the issues were - as rather than see isolated data, which is what debugger information tends to present, I was able to see data over time and solve the problem from there.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Frankly, I solved that by not coding in python =P
It's a magical language in some ways, but the grammar was designed at gunpoint.
Who uses tabs to dictate program flow?
I protest the language out of my distaste for poor grammars
/grammar nazi
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: Who uses tabs to dictate program flow?
A thing I'm asking me all the time.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
i mean, it's one thing to use tabs to show program flow, but they should be descriptive, not prescriptive.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yes yes, I'm with you on this, and I think all who ever wrote a parser/compiler will agree. WhiteChars _are not_ an instrument to be a part of the gramatics.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Once you get used to it, the spacing makes a lot of sense.
I find it easier to follow programme flow with the indentation.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
most people indent.
write a python parser, then we'll talk about "getting used to it" when you have to make the grammar (including the tokenizer) context sensitive in order to handle significant vs insignificant whitespace.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
i love your signature by the way. it's too real.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Thank you
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Seems to me you have an ID problem here. I will try to explain. When your eraser tool, which is nothing but a circle object intersects with the existing object it creates new vertices. Those new vertices need to be connected to existing ones. During this process an AREA needs to be defined within the connections will happen. Since you have no area defined, newly formed vertices connect to the existing ones. Since no more than 2 vertices can be connected on a 2 dimensional object, an existing connection is broken splitting the object in 2. Here's how this happens: there's a vertex at the top left of your image where the breaking happens, and let's label it V1, and it's connected to a vertex below it, so let's label that one V2, and there's a Bezier curve that connects them. When you introduce the eraser tool (which is a new circle object that also consists of vertices) and intersect it with the object, you are creating new vertices, so for easier understanding let's say 2 new ones, V3 and V4. As a result, instead of new vertices V3 and V4 being connected and creating a Bezier curve between them, connection at V1 breaks, a new connection is created between V1 and V4, also between V2 and V3 thus splitting the object in two, and also creating a Bezier curve as it was their last state.
The best way to approach this problem is to create 2 new states for each vertex:
- is a vertex being deleted cause intersection happens where the vertex is, and 2 new vertices are created and connected thus eliminating the first one,
- if the intersection doesn't happen where the new vertex is, newly created vertices should be connected to the nearest left, between themselves, and nearest right, following the edge of the object.
Proposed solution
This is just a rough idea on what's going on and what the solution may be. I hope I helped.
modified 6-May-19 7:13am.
|
|
|
|
|
Actually, you know what? I think I found it!
When I got this
| |
==+==+==
\_/
Sometimes I have to merge vertex when they are separated by very small interval, otherwise I got algorithmic issue... (like never ending loop calculating approximate intersection)
But when I merge the intersection above, they become a touch.. i.e. the merge point is NOT an intersection anymore.. but I dunno it, all I know (at the moment) is a point with 4 line convergent on it, must be an intersection, right?
I have to take that into consideration! Woa,.. good find.. will implement that later!
(got othe rthings to do! )
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
