Not discriminating is discrimination

dowie said:
Your flaw there is you're just looking at one person and you conviniently started e off behind any fast track people

Of course e has no delay (if no one else joins) - however the other non-fast track people had delays... if e had been in position 5 at the start say then she'd have been delayed

And of course as soon as any fast track person joins the queue she is delayed

The average wait time for the non s people has increase and it has decreased for the f people

If you don't believe eve me thenwirk through it again with an f behind e at the start

Or with an f joining the queue at some point in time

also if you're fast tracking people to the front then you're prosessimg them first...
Click to expand...
I started her at the back of the queue!

Seems like you're trying to manipulate it to try and engineer a result

F's were joining in the 2nd set of data at the same time they did in the first. (hence E didn't move at points 2,5,8)

You may be experiencing Cognitive Dissonance right about now....
 
cheesyboy said:
I started her at the back of the queue!

Seems like you're trying to manipulate it to try and engineer a result

F's were joining in the 2nd set of data at the same time they did in the first. (hence E didn't move at points 2,5,8)

You may be experiencing Cognitive Dissonance right about now....
Click to expand...

I'm not.. you are though...

You've thrown in some magic handwaving again and made all the existing fs disappear at the start - doesn't matter as once the queue is running have the same problem

Let's see again, I'll use your notation:

Suppose no fs at the start, we'll have one person join per day as you had

s-s-s-s-e

Current system:

1 s-s-s-s-e
2 s-s-s-e-s
3 s-s-e-s-s
an f joins on day 4
4 s-e-s-s-f
5 e-s-s-f-s
6 s-s-f-s-s
and so on.. with more s or f joining at random

New system

1 s-s-s-s-e
2 s-s-s-e-s
3 s-s-e-s-s
4 s-s-e-s-s f processed so rest of queue static
5 s-e-s-s-s
6 e-s-s-s-s

e is still in the queue at time 6

Each time we processed 5 people

when an f joined everyone was delayed

It would be clearer if you actually wrote out the full queue for the new system and explicitly wrote the fs joining at the front - by not doing so you've masked it and muddled your thinking

You engineered the previous one with your handwaving causing three fs to vanish at the start and then have exactly 3 join the queue

If you'd have had 2 join the e would have skipped ahead (because of your magic handwaving upon initialising the queue) if you'd had 4 fs join then e would have still been delayed by a place because your magic handwaving only removed 3 at the start. If you don't believe me then write it out again, even with your flaw you can still introduce a delay by having 4 join while e is there... also once it is up and running then the other s get delayed by any f joining.
 
Last edited:
@dowie
You see, under my model it's assumed that, overall, the arrival of 'f's will be reasonably consistent - as it would be as a population.

Under your model it's assumed that they only arrive when Ethel dies :D
 
cheesyboy said:
@dowie

LOL!!!

you just totally rigged it :D

That's nonsense and you know it

No f's until after the new system gets introduced :D
Click to expand...

How have I rigged it, I've used your rules... you rigged it by removing the fs at the start... see the edit above, if you only introduced two fs then e would be processed a time step earlier...

write out the full queue with no magical handwaving...
 
dowie said:
How have I rigged it, I've used your rules... you rigged it by removing the fs at the start... see the edit above, if you only introduced two fs then e would be processed a time step earlier...

write out the full queue with no magical handwaving...
Click to expand...
Look, I've said all along that there would need to be a 'push' to clear the 'backlog' of fasttrackers in the system. I don't believe that to be an onerous requirement, nor beyond the wit of man.

Once the system is up and running, it would look like I have laid it out. I've not done a snapshot of the changeover - it's comparing mature systems in either case.

Why do you have to 'cheat' with the timing of 'f's if your system is correct? Seems like you are weakening your own argument.
 
cheesyboy said:
Look, I've said all along that there would need to be a 'push' to clear the 'backlog' of fasttrackers in the system. I don't believe that to be an onerous requirement, nor beyond the wit of man.

Once the system is up and running, it would look like I have laid it out. I've not done a snapshot of the changeover - it's comparing mature systems in either case.

Why do you have to 'cheat' with the timing of 'f's if your system is correct? Seems like you are weakening your own argument.
Click to expand...

I've not cheated, that is what you did, you removed 3 fs at the start then just happened to process exactly 3fs before Ethel.. you're not comparing two systems, you're introducing the magic handwaving you've done repeatedly whenever a flaw appears

I'm on my mobile but I'll demonstrate why even the example you've posted is flawed later. Try to be honest here... work through it with say only 2 fs joining or 4 fs.. look at what happens to Ethel.. try labelling the other s people if you don't get it... also write out the full queue in the second part. Be honest and try it again... write it out in full
 
dowie said:
I've not cheated, that is what you did, you removed 3 fs at the start then just happened to process exactly 3fs before Ethel.. you're not comparing two systems, you're introducing the magic handwaving you've done repeatedly whenever a flaw appears
Click to expand...
That's not 'just happened', it happens because I modelled the flow of fasttrackers to be regular.

And if they are regular, then you will always see the same number in the queue as you would see arrive in the queue (or fasttrack) in the time it takes one person to flow through the system (subject to +/-1 on timings of entrance/exit). That's just maths!

Now I did it 1 in 3, but in a larger model you'd probably want it more like 1 in 10 or whatever the proportion would be. But there would also be a longer queue, and more than one processed at a time.

In any case, it would hold up if you made it much larger and more realistic in terms of proportions.
 
cheesyboy said:
That's not 'just happened', it happens because I modelled the flow of fasttrackers to be regular.

And if they are regular, then you will always see the same number in the queue as you would see arrive in the queue (or fasttrack) in the time it takes one person to flow through the system (subject to +/-1 on timings of entrance/exit). That's just maths!

Now I did it 1 in 3, but in a larger model you'd probably want it more like 1 in 10 or whatever the proportion would be. But there would also be a longer queue, and more than one processed at a time.

In any case, it would hold up if you made it much larger and more realistic in terms of proportions.
Click to expand...

I see you've avoided my suggestion and instead there is another handwaving excuse. You've tried writing it out but have only been able to make it work by introducing exactly 3 and that only works because you magically remove 3 at the start... also because you've only labelled that specific person e and just happened to start her behind 3 fs you removed then just happened to introduce 3 behind her you can pretend it worked

If you labelled the other s people you'd see the flaw, if you had more than one f join at a time you'd see the flaw and would write it out in full

Also once your queue is running under your new system you essentially only have s people in the queue, I've given an example in my previous post with just s people in the queue and comparing the two systems... so with a new Ethel, with your system up and running you'd have a delay

Instead of trying to find a fudged scenario (that I can easily illustrate the flaws of once I'm not on my mobile) try to be a bit more honest, the flaws are there, I've shown you where to look, I've shown you how it has a delay once up and running too... Trying to be deliberately dishonest just because you're being stubborn over this is just silly.
 
dowie said:
I see you've avoided my suggestion and instead there is another handwaving excuse. You've tried writing it out but have only been able to make it work by introducing exactly 3 and that only works because you magically remove 3 at the start... also because you've only labelled that specific person e and just happened to start her behind 3 fs you removed then just happened to introduce 3 behind her you can pretend it worked
Click to expand...
No.

Like I said, 3 are in the queue, and 3 appearing during the steps is not coincidence nor is it me engineering a result.

It's because I've modelled the 'f's coming in at regular intervals. This is the correct way to model it.
dowie said:
If you labelled the other s people you'd see the flaw, if you had more than one f join at a time you'd see the flaw and would write it out in full
Click to expand...
There will be times that some people are one step behind under my fasttrack model - and that's because I built it in such a way that the +/-1 'rounding' counts against me (the first new 'f' appears before the first in-system 'f' is processed). This wouldn't have happened if I'd put 9 in the queue instead of 10.

You see, I'm not trying to cheat ;)
 
cheesyboy said:
No.

Like I said, 3 are in the queue, and 3 appearing during the steps is not coincidence nor is it me engineering a result.

It's because I've modelled the 'f's coming in at regular intervals. This is the correct way to model it.

There will be times that some people are one step behind under my fasttrack model - and that's because I built it in such a way that the +/-1 'rounding' counts against me (the first new 'f' appears before the first in-system 'f' is processed). This wouldn't have happened if I'd put 9 in the queue instead of 10.

You see, I'm not trying to cheat ;)
Click to expand...

you might be being completely honest in spite of the magical hand waving you had too pull to try and get your example working by removing three people in the 'new' system ergo you've got the flaw that you're not making a fair comparison - there is no reason why the coroner can't work super hard over that same time period and remove three additional people from the other queue as it is ordered... that is a massive flaw

but regardless of that flaw you're then trying to take advantage of the fact the average time to process the queue in general is unchanged and to carry over your magic handwaving at the start by giving a very specific ordering of arrivals and maintaining the queue size - the whole thing relies on that hand waving trick and that constant queue

fact is people would be arriving at random... you could get any sort of ordering of arrivals (f,s,s,s,f) (s,s,f,s,f) etc.. and these get re-ordered, causing delays for the s's if your queue starts to build up this has a greater impact, if the backlog gets cleared and there is no queue there is no impact on an s or f arriving, if the queue grows there is even more impact by the arrival of an f - it isn't like the queue will be a fixed number, it will build up, reduce etc..

you might not be trying to cheat but you seem to have been stuck in a situation where you still can't grasp the issue and then you (whether intentionally or not) end up constructing flawed examples to try and make your concept fit reality

even with your handwaving, once the system is under way then if you say increase the death rate you'll see the flaw - there is a big coach crash for example and suddenly the queue is at +50.. all the fs go to the front, what happens to the delay for the rest... the average delay for the people as a whole is the same regardless of how you order them but for the fs specifically they get processed much faster ergo the ss get processed much slower... takes the same time to process the whole lot regardless of ordering- problem is you didn't just change the ordering, you rigged it by removing people with some handwaving.
 
Just to chip in, I can see where cheesyboy is coming from - once you're in the 'the flow' of the new system, rather than transitioning to it, the fact some people are being fast tracked on average wouldn't affect everyone else as they're effectively being fasttracked into queue positions that other members of their group would have previously been in but have already been 'fast tracked' out of. So for every step back you take on the queue due to a fast tracker, you've also taken one forward because someone was fast tracked out the door earlier than they would have been.

It would need additional resource at the initial transition as you'd have members of the fast track group already in the queue and adding new fast tracked entrants.

It would fall apart in practice because of the day to day variance in arrivals and the fact the average wouldn't end up being very average at any given point in time. (Edit - what I mean by this is that if you assumed an AAAAB AAAAB AAAAB arrival pattern, the theory would work as there is a regular 'hole' to be filled with a regular new arrival. When you accept that the pattern could just as easily be AAAAA BBAAA ABAAA then some of those As would have to be delayed to allow the Bs to move forward. The theory only really works 'on average' assuming a regular pattern.)
 
Last edited:
Amazing. When I saw this argument kicking off on page 2 and there were 8 pages of discussion, I couldn't wait to get to the part where Cheesyboy eventually ate a large, steaming slice of humble pie. But no. He's still going. Quite amazing. Reminds me of the guy on the misc who lost track of how many days there were in 2 weeks http://gawker.com/bodybuilders-try-fail-to-calculate-number-of-days-in-1677545788
 
Kenai said:
Just to chip in, I can see where cheesyboy is coming from - once you're in the 'the flow' of the new system, rather than transitioning to it, the fact some people are being fast tracked on average wouldn't affect everyone else as they're effectively being fasttracked into queue positions that other members of their group would have previously been in but have already been 'fast tracked' out of. So for every step back you take on the queue due to a fast tracker, you've also taken one forward because someone was fast tracked out the door earlier than they would have been.

It would need additional resource at the initial transition as you'd have members of the fast track group already in the queue and adding new fast tracked entrants.

It would fall apart in practice because of the day to day variance in arrivals and the fact the average wouldn't end up being very average at any given point in time.
Click to expand...

yup indeed, I can see that too - the whole thing relies on a fudge at the start and then a constant queue - so it isn't a fair comparison between two systems and yep it falls apart pretty quickly if you change the queue size, have the queue reduce to zero and build back up again or just grow a bit etc.. (unless he wants to keep on introducing his fudge - in which case he's basically claiming that the coroner can fast track some people without affecting others so long as he works harder... which is a bit of an irrelevant point to make but is all that he's really demonstrating)
 
The point that dowie and cheesyboy appear to have lost track of is succinctly contained in the thread title:
"Not discriminating is discrimination".​

The theory being put forward is that "Someone wins but nobody loses". Lewis Carroll and George Orwell would be proud of this assertion.

Pink folk can sit at the front of the bus, non-pink folk must sit at the back.

Discrimination on the basis of colour, gender, religion, sexual orientation, etc., etc. is never acceptable.
 
stockhausen said:
The point that dowie and cheesyboy appear to have lost track of is succinctly contained in the thread title:
"Not discriminating is discrimination".​

The theory being put forward is that "Someone wins but nobody loses". Lewis Carroll and George Orwell would be proud of this assertion.

Pink folk can sit at the front of the bus, non-pink folk must sit at the back.

Discrimination on the basis of colour, gender, religion, sexual orientation, etc., etc. is never acceptable.
Click to expand...

No we were just discussing the impact of implementing this, it doesn't mean I don't have an opinion on the ruling, I posted one earlier.
 
stockhausen said:
The point that dowie and cheesyboy appear to have lost track of is succinctly contained in the thread title:
"Not discriminating is discrimination".​

The theory being put forward is that "Someone wins but nobody loses". Lewis Carroll and George Orwell would be proud of this assertion.

Pink folk can sit at the front of the bus, non-pink folk must sit at the back.

Discrimination on the basis of colour, gender, religion, sexual orientation, etc., etc. is never acceptable.
Click to expand...
Indeed.

The ratchet has clicked, they’ve successfully transferred some advantages to their minority group at the expense of everyone else. I wonder what’s next on the list.
 
You must log in or register to reply here.
Back
Top Bottom