I'm currently testing a hierarchical method of maze-solving to simulate 1-way
doors, and I've made some very small changes which have resulted in a massive
slowdown - probably 1/8 to 1/10 the original speed.  :O

All I've done is replace 5 lines where comparisons using = now use a <= or a >.
The first slowdown was noticed by changing a single line from
#if (walkability [a][b] != unwalkable)
to
#if (walkability [a][b] <= Threshold)

Also, there is one extra test block that got added:
#if (walkability [a][b] = exited)
    #declare Threshold = 5;
#end
{switches 1-way doors from a walkable path to an obstacle}

Has anyone experienced this sort of thing before?

Are there faster ways to do this sort of thing?
Using a ternary operator to assign a value rather than #if block?
Using a function rather than an inline equation?

I'm probably going to have to run my old function time-comparison scene file to
perform these types of methods 100,000 times and see if there's a massive
slowdown between = and >.

Really any suggestions are welcome.   This is now going WAY too slow.

Post a reply to this message

On 02.05.2024 4:39, Bald Eagle wrote:

> #if (walkability [a][b] != unwalkable)
> to
> #if (walkability [a][b] <= Threshold)

Sorry for a stupid question, is there a way to use some !> instead of <=

?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> ...
> > #if (walkability [a][b] != unwalkable)
> > ...
> Sorry for a stupid question, is there a way to use some !> instead of <=
>
> ?


unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
just another way of saying "less than", ie '<' (saving two keystrokes :-)).


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm currently testing a hierarchical method of maze-solving to simulate 1-way
> doors, and I've made some very small changes which have resulted in a massive
> slowdown - probably 1/8 to 1/10 the original speed.  :O
>
> All I've done is replace 5 lines where comparisons using = now use a <= or a >.
> The first slowdown was noticed by changing a single line from
> #if (walkability [a][b] != unwalkable)
> to
> #if (walkability [a][b] <= Threshold)

One of the things about trying to do stuff like this with a renderer rather than
a language where you can draw directly on the screen in real time is that you're
always working blind.   It's like playing a long game of chess, but you make all
of the moves in your mind, and then just set up the chess board in the final
configuration.

I do believe the problem lies not in the operator, but in the consequences of
changing the behaviour of the pathfinding algorithm when using the inequalities
that I've specified.

Last night I ran a 100-person evacuation simulation, and although I was
expecting it to take a full 40 min, it only took 25.
I had implemented a timer to see how long it took to solve each path, and most
of the paths too around 900 ms, but some took nearly 3 minutes!

So I'm thinking that maybe somehow the logic has changed in such a way that it's
ignoring obstacles when it shouldn't be.  And it occurred to me while walking
down a dark hallway, that when the algorithm is exploring potential directions
from a pixel, it has EIGHT directions to choose from, which coincidentally was
the rate of slowdown (on average, for 50 solves).

I'll have to give it some more mental chess consideration as well as think about
ways to get better feedback about what the algorithm is doing during the course
of its search.

Maybe pick one of the LONG path-finding points and trace out the entire search
path.

- BW

Post a reply to this message

On 02.05.2024 12:49, jr wrote:
> hi,
> 
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> ...
>>> #if (walkability [a][b] != unwalkable)
>>> ...
>> Sorry for a stupid question, is there a way to use some !> instead of <=
>>
>> ?
> 
> 
> unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
> just another way of saying "less than", ie '<' (saving two keystrokes :-)).

"Not greater" is "less or equal" actually ;-) I'm just suggesting trying 
to do it some other way (different branch of "if" or something) and see 
what happens. Yes, I know that from math point of view it's the same, 
I'm suggesting to evaluate prog point of view ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 02.05.2024 12:49, jr wrote:
> > ...
> > unsure I understand '!>' correctly, meaning "not greater" ?  if so, then that is
> > just another way of saying "less than", ie '<' (saving two keystrokes :-)).
>
> "Not greater" is "less or equal" actually ;-)

yes.  (I had one of my "shit-for-brains" days.  sorry)


> I'm just suggesting trying
> to do it some other way (different branch of "if" or something) and see
> what happens. Yes, I know that from math point of view it's the same,
> I'm suggesting to evaluate prog point of view ;-)

I've never looked at the povray source code (C++), but would be surprised if
adding a '!>' (and '!<' for "symmetry"?) operator were real "difficult".


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> And it occurred to me while walking
> down a dark hallway, that when the algorithm is exploring potential directions
> from a pixel, it has EIGHT directions to choose from...

Although I haven't been following your path-finding scheme in detail-- real life
has interfered again-- I was wondering about those eight possible directions: As
you walk down the hallway, you already know that you have traversed the previous
pixel. So, it seems that at least that particular direction could be eliminated
from the search, while continuing along the path. Thus, SEVEN possible
directions instead of eight, for further searching. Not *much* of a speed
improvement, but every little bit helps. ;-)

That is, if I understand how your path-finding code is meant to operate...

Post a reply to this message