3300+ oranges

[irihapeti]

you got 1 unnecessary addition in the end encoding as well as reintroduce collision

+

also

if move the encoding to the harness side then more oranges. 3424 about

[LepreKhaun]

---

irihapeti wrote:

you got 1 unnecessary addition in the end encoding as well as reintroduce collision

+

also

if move the encoding to the harness side then more oranges. 3424 about

---

You're correct, my approach is extremely flawed and anything based on it would be defective.

 

Let's hope that no ignorant, clueless NOOBs* have made the mistake of relying on my work.

 

* ETA: the phrase is used affectionately btw. We all love the beginners in our forums, it's just that they can be so exasperating until they realize how little they know.

[Perrie Juran]

---

LepreKhaun wrote:

---

irihapeti wrote:

you got 1 unnecessary addition in the end encoding as well as reintroduce collision

+

also

if move the encoding to the harness side then more oranges. 3424 about

---

You're correct, my approach is extremely flawed and anything based on it would be defective.

 

Let's hope that no

ignorant, clueless

NOOBs*

 have made the mistake of relying on my work.

 

* 

ETA: the phrase is used affectionately 

btw

. We all love the learners in our forums, it's just that hey can be so exasperating until they realize how little they know.

---

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

[LepreKhaun]

---

Perrie Juran wrote:

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

---

Where I live, those that pick fights with others are called bullies and can't expect the other to accept their rules.

[Perrie Juran]

---

LepreKhaun wrote:

---

Perrie Juran wrote:

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

---

Where I live, those that pick fights with others are called bullies and can't expect the other to accept their rules.

---

Where I live it's only those who pick on the weak.  

 

(I will confess to being very fond of her.  I know of no one else who can go 'vroooom vrooooom' the way she does).

[LepreKhaun]

---

Perrie Juran wrote:

---

LepreKhaun wrote:

---

Perrie Juran wrote:

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

---

Where I live, those that pick fights with others are called bullies and can't expect the other to accept their rules.

---

Where I live it's only those who pick on the weak.  

 

(I will confess to being very fond of her.  I know of no one else who can go 'vroooom vrooooom' the way she does).

---

Picking on someone stronger only makes them a foolish bully.

[irihapeti]

---

LepreKhaun wrote:

---

 

---

And, on reflection, I see it was completely unneeded since the odds of ever matching anything NOT on a key boundary is vanishly small (it works out to be

(

number_of_keys_added

- 2)*(number_of_keys_added

 - 1)/2*8

* 

1.329228e-36 * 1/256 = 

approximately 0.000,000,000,000,000,000,000,008,748 - figuring 3,300 eight 15 bit possibilities with a ninth of 8 bits, all having to match) and one just needs llSubStringIndex().

 

I've changed my original code to reflect this much better solution since the chance of a false positive is so incredibly small the complication I had originally added is unnecessary.

[Edited to more correctly show that the first two additions to the data string will, of course, 

never

result in a false match and to 

cite my source

 as to how that extremely small figure is to be obtained.

---

you might want to check your arithmetic

2 encoded keys: ABCDEFGHa  XJKYMNOPb

compare a 3rd key QRSTUVWXc

where lowercase in the set [0..255] and uppercase in the set [0..32767]

the potential cross-boundary collisions are:

BCDEFGHax 

CDEFGHaXj

DEFGHaXJk

EFGHaXJKy

FGHaXJKYm

GHaXJKYMn

HaXJKYMNo

aXJKYMNOp

+

also need to factor in that the set of all keys is an arrangement

using 2bits by example:

k = [00,01]

c = [0,0] compare [10]. 0 collision

k = [00,01,10] 

c = [0,0][1,1] compare [11]. 1 collision

---

k = [00,01]

c = [0,0] compare [11]. 0 collision

k = [00,01,11]

c = [0,0][1,1] compare [10]. 0 collision

---

k = [00,10]

c = [0,1] compare [01]  1 collision

k = [00,10,01]

c = [0,1][0,0] compare [11]  0 collision

---

k = [00,10]

c = [0,1] compare [11]. 0 collision

k = [00,10,11]

c = [0,1][0,1] compare [01]. 1 collision. as the 2nd collision will never happen

etc

[Madelaine McMasters]

;-).

[Perrie Juran]

I love it when you talk dirty. 

[LepreKhaun]

---

irihapeti wrote:

---

LepreKhaun wrote:

---

 

---

And, on reflection, I see it was completely unneeded since the odds of ever matching anything NOT on a key boundary is vanishly small (it works out to be

(

number_of_keys_added

- 2)*(number_of_keys_added

 - 1)/2*8

* 

1.329228e-36 * 1/256 = 

approximately 0.000,000,000,000,000,000,000,008,748 - figuring 3,300 eight 15 bit possibilities with a ninth of 8 bits, all having to match) and one just needs llSubStringIndex().

 

I've changed my original code to reflect this much better solution since the chance of a false positive is so incredibly small the complication I had originally added is unnecessary.

[Edited to more correctly show that the first two additions to the data string will, of course, 

never

result in a false match and to 

cite my source

 as to how that extremely small figure is to be obtained.

---

you might want to check your arithmetic

2 encoded keys: ABCDEFGHa  XJKYMNOPb

compare a 3rd key QRSTUVWXc

where lowercase in the set [0..255] and uppercase in the set [0..32767]

the potential cross-boundary collisions are:

BCDEFGHax 

CDEFGHaXj

DEFGHaXJk

EFGHaXJKy

FGHaXJKYm

GHaXJKYMn

HaXJKYMNo

aXJKYMNOp

+

also need to factor in that the set of all keys is an arrangement

using 2bits by example:

k = [00,01]

c = [0,0] compare [10]. 0 collision

k = [00,01,10] 

c = [0,0][1,1] compare [11]. 1 collision

---

k = [00,01]

c = [0,0] compare [11]. 0 collision

k = [00,01,11]

c = [0,0][1,1] compare [10]. 0 collision

---

k = [00,10]

c = [0,1] compare [01]  1 collision

k = [00,10,01]

c = [0,1][0,0] compare [11]  0 collision

---

k = [00,10]

c = [0,1] compare [11]. 0 collision

k = [00,10,11]

c = [0,1][0,1] compare [01]. 1 collision. as the 2nd collision will never happen

etc

---

Well, you started off right.

First possible mismatch is when the 3rd key is added and, yes, there are only 8 possible places for it to mismatch. But you skipped figuring out what is the possibility of each of those mismatches at that point.

See, each of those 8 possible mismatches must each exactly match 9 characters. The first character has 2^15 possible states, so its chance of mismatching is 1 out of 32,768 or 0.000030517578125. The chance of the first character AND THEN the second character mismatching is 1/32768 * 1/32768 (since the first and second characters are independent of each, as per my cited source for how this math works). The chance of the 3rd character then mismatching after the first two is given as 1/32768 * 1/32768 * 1/32768 and so on until the final character, which has 2^8 states.

So, the possibility of any 1 of those mismatches is:

1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 ~

1.329228e-36 * 1/256

And, since we have 8 possible mismatches when we add the third key, its possible mismatch chance is:

8 * 1.329228e-36 * 1/256

Now, when we add the 4th key it has 16 places to mismatch, the fifth key has 24, the sixth key 32 etc (since if(character_place%9==0) we actually have a good match). And, yes, we do have to "factor in that the set of all keys is an arrangement", let me show you how my original formula does exactly that.

Since the keys are added into the arrangement one at a time, we have to add the previous chances of mismatches as we go. In other words, though the 4th key has 16 possible mismatches, we can't disregard the 8 possibilities the third had. And when the fifth key is added, the running total is 8 + 16 + 24; 6th is 8 + 16 + 24 + 32; and so on to the 3,300th key added, which would be 8 + 16 + 24 + 32 + 40 + 48 + ... + 26,384; where "..." is a fairly long string of numbers, the last if which is (3,300 - 3) * 8.

That final string of numbers can be simplified using a high school formula. First we factor out the 8, giving us 8 * (1 + 2 + 3 + 4 + ... + 3,298) and we see we're just doing the sum of consecutive integers (N(N+1)/2) so we simply plug in 3300 -2 for N, multiply by factor of 8 and then again by the chance of each mismatch and we have:

(3300 - 2)*(3300 - 1)/2 * 8 * 1.329228e-36 * 1/256 or

 

approximately 0.000,000,000,000,000,000,000,008,748

 

Hope that clears it up for you.

 

[irihapeti]

---

LepreKhaun wrote:

---

irihapeti wrote:

---

LepreKhaun wrote:

---

 

---

And, on reflection, I see it was completely unneeded since the odds of ever matching anything NOT on a key boundary is vanishly small (it works out to be

(

number_of_keys_added

- 2)*(number_of_keys_added

 - 1)/2*8

* 

1.329228e-36 * 1/256 = 

approximately 0.000,000,000,000,000,000,000,008,748 - figuring 3,300 eight 15 bit possibilities with a ninth of 8 bits, all having to match) and one just needs llSubStringIndex().

 

I've changed my original code to reflect this much better solution since the chance of a false positive is so incredibly small the complication I had originally added is unnecessary.

[Edited to more correctly show that the first two additions to the data string will, of course, 

never

result in a false match and to 

cite my source

 as to how that extremely small figure is to be obtained.

---

you might want to check your arithmetic

2 encoded keys: ABCDEFGHa  XJKYMNOPb

compare a 3rd key QRSTUVWXc

where lowercase in the set [0..255] and uppercase in the set [0..32767]

the potential cross-boundary collisions are:

BCDEFGHax 

CDEFGHaXj

DEFGHaXJk

EFGHaXJKy

FGHaXJKYm

GHaXJKYMn

HaXJKYMNo

aXJKYMNOp

+

also need to factor in that the set of all keys is an arrangement

using 2bits by example:

k = [00,01]

c = [0,0] compare [10]. 0 collision

k = [00,01,10] 

c = [0,0][1,1] compare [11]. 1 collision

---

k = [00,01]

c = [0,0] compare [11]. 0 collision

k = [00,01,11]

c = [0,0][1,1] compare [10]. 0 collision

---

k = [00,10]

c = [0,1] compare [01]  1 collision

k = [00,10,01]

c = [0,1][0,0] compare [11]  0 collision

---

k = [00,10]

c = [0,1] compare [11]. 0 collision

k = [00,10,11]

c = [0,1][0,1] compare [01]. 1 collision. as the 2nd collision will never happen

etc

---

Well, you started off right.

First possible mismatch

is

when the 3rd key is added and,

yes

, there are only 8 possible places for it to mismatch. But you skipped figuring out what is the possibility of each of those mismatches at that point.

See, each of those 8 possible mismatches must each exactly match 9 characters. The first character has 2^15 possible states, so its chance of mismatching is 1 out of 32,768 or 0.000030517578125. The chance of the first character AND THEN the second character mismatching is 1/32768 * 1/32768 (since the first and second characters are independent of each, as per my

cited source

for how this math works). The chance of the 3rd character then mismatching after the first two is given as 1/32768 * 1/32768 * 1/32768 and so on until the final character, which has 2^8 states.

So, the possibility of any 1 of those mismatches is:

1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 ~

1.329228e-36 * 1/256

And, since we have 8 possible mismatches when we add the third key, its possible mismatch chance is:

8 * 1.329228e-36 * 1/256

Now, when we add the 4th key it has 16 places to mismatch, the fifth key has 24, the sixth key 32 etc (since

if(character_place%9==0)

we actually have a good match). And, yes, we do have to "factor in that the set of all keys is an arrangement", let me show you how my original formula does exactly that.

Since the keys are added into the arrangement one at a time, we have to add the previous chances of mismatches as we go. In other words, though the 4th key has 16 possible mismatches, we can't disregard the 8 possibilities the third had. And when the fifth key is added, the running total is 8 + 16 + 24; 6th is 8 + 16 + 24 + 32; and so on to the 3,300th key added, which would be 8 + 16 + 24 + 32 + 40 + 48 + ... + 26,384; where "..." is a fairly long string of numbers, the last if which is (3,300 - 3) * 8.

That final string of numbers can be simplified using a high school formula. First we factor out the 8, giving us 8 * (1 + 2 + 3 + 4 + ... + 3,298) and we see we're just doing

the sum of consecutive integers

 (

N(N+1)/2

) so we simply plug in 3300 -2 for

N

, multiply by factor of 8 and then again by the chance of each mismatch and we have:

(3300 - 2)*(3300 - 1)/2 * 8 * 1.329228e-36 * 1/256

or

 

approximately 0.000,000,000,000,000,000,000,008,748

 

Hope that clears it up for you.

 

---

look at the pattern. is 7 of 1/32768 and 2 of 1/256

ETA: also

each key is not n where n = 0xFFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF. Only the 1st one is. The 2nd key is n-1. The third key is n-2. The 4th key is n-3. The keys are an arrangement. Factoring all as 1/n puts your number out by billions

look at the bit pattern example. It shows this

+

you over-estimating the probability of collision. is billions less probability  than the number you posted

if you are going to gamble with your script users then best to know what the probabilities actual are

[LepreKhaun]

---

irihapeti wrote:

look at the pattern. is 7 * 1/32768 and 2 * 1/256

---

I don't see it.

default{    touch_end(integer num)    {        integer i;        for (i = 28; i >= 0; i -= 4)        {            llOwnerSay((string)i);        }    }}

 Outputs:

[06:18] Object: 28

[06:18] Object: 24

[06:18] Object: 20

[06:18] Object: 16

[06:18] Object: 12

[06:18] Object: 8

[06:18] Object: 4

[06:18] Object: 0

which is 8 iterations, not 7. And how you came to arrive at two 1/256's is beyond me because there is only one (which happens when the variable b is finally processed).

 

What am I missing here?

[irihapeti]

 

look at the pattern

 

xxxxxxxxAxxxxxxxxA xxxxxxxAA  xxxxxxAxA   xxxxxAxxA    xxxxAxxxA     xxxAxxxxA      xxAxxxxxA       xAxxxxxxA        AxxxxxxxA 

 

[LepreKhaun]

Ahhh, I see what you're saying.

So, if that pattern applies:

1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 * 1/256 =
2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-8) * 2^(-8) =
2^(-121) ~
3.7615819e-37

Then the formula becomes
(3,300 - 2)*(3,300 - 1) * 8 * 3.7615819e-37=
87,040,816 * 3.7615819e-37

Giving us approximately 3.274e-29 instead of 8.748e-24.

Mmmm, but I still agree with your original assessment- too big of a chance. Why risk it?

 

Your design change is much better!

[irihapeti]

---

LepreKhaun wrote:

Ahhh, I see what you're saying.

So, if that pattern applies:

1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 * 1/256 =

2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-15) * 2^(-8) * 2^(-8) =

2^(-121) ~

3.7615819e-37

Then the formula becomes

(3,300 - 2)*(3,300 - 1) * 8 * 3.7615819e-37=

87,040,816 * 3.7615819e-37

Giving us approximately 3.274e-29 instead of 8.748e-24.

Mmmm, but I

still agree

with your original assessment- too big of a chance. Why risk it?

 

Your design change

is

much better!

---

is an arrangement of unique keys coming in

n = 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 * 1/256

is right for the 1st. the 2nd n is 1 less than this. the 3rd n is 2 less. and so on

instead of power(n,n) as your workings show, is factorial(n) coming in. refer the 2bit example i gave before which shows this

ETA: [removed inconclusive statement from here]

ETA more. 1/256 is actual not right. is (256/32768)/32768

+

changing the end encoding as you originally suggested is the best way. Is no question about this. zero collision is better than non-zero collision no matter how tiny. Specially when is no extra coding cost or runtime load

you know this. You a dev professional with 20+ years experience. If you raise this topic with your RL colleagues and tell them it dont matter bc tiny then the seniors in the group will frown at you. The juniors will go waaaaah !!!

 

[LepreKhaun]

If such precision was required, you might have a point. But since I no longer support that suggestion, regardless of the approximation, , I'll move on to more productive things and hope you do as well.

[irihapeti]

---

LepreKhaun wrote:

If such precision was required, you might have a point. But since I no longer support that suggestion, regardless of the approximation, , I'll move on to more productive things and hope you do as well.

---

precision is always required in the field of mathematics. Approximation is only ever done when the spacetime cost of computation outweigh the spacetime cost of finding the optimal solution. The optimal solution you already found previous

so yes agree. Is unproductive to continue wasting spacetime on computing an answer to a problem where no problem exists

[LepreKhaun]

---

irihapeti wrote:

...

so yes agree. Is unproductive to continue wasting spacetime on computing an answer to a problem where no problem exists

---

Good, it sounded to me as if you actually saw a problem there. A few decimal places in an extremely small approximtion is less germane to programing than defective licensing and ones spacetime should be spent wisely.

[LepreKhaun]

---

Perrie Juran wrote:

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

---

What you said kept tickling the back of my mind, but it took awhile to recall the exact phrase that it reminded me of-

Do not meddle in the affairs of Dragons, for you are crunchy and taste good with ketchup!

~ Anon ~

[Perrie Juran]

---

LepreKhaun wrote:

---

Perrie Juran wrote:

You should be honored. 

Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. 

---

What you said kept tickling the back of my mind, but it took awhile to recall the exact phrase that it reminded me of-

Do not meddle in the affairs of 

Dragons

, for you are 

crunchy

 and taste good with 

ketchup

!

~ Anon ~

---

Of course we should always be careful before placing our head in the lion's mouth.

[LepreKhaun]

I've learned to be careful just rubbing a strange cat. Some of them don't like it and I've got some scars for not picking up on it in time.

[irihapeti]

---

LepreKhaun wrote:

---

irihapeti wrote:

...

so yes agree. Is unproductive to continue wasting spacetime on computing an answer to a problem where no problem exists

---

Good, it sounded to me as if you actually saw a problem there. A few decimal places in an extremely small approximtion is less germane to programing than defective licensing and ones 

spacetime should be spent wisely.

---

the waste of spacetime is when invent a problem for a situation for which no problem exists. And then compound this by waste further time attempting to calculate an answer to the invented problem. Specially when the person who invented the problem has 20+ years professional industry experience and is yet unable to calculate the answer. Even when that person has the formula (which they linked to themself) and also have all necessary info/parameters available to them

[Perrie Juran]

---

LepreKhaun wrote:

I've learned to be careful just rubbing a strange cat. Some of them don't like it and I've got some scars for not picking up on it in time.

---

My neighbors dog and my cat got into it one day.

My neighbor grabbed his dog.

I grabbed my cat.

This is when you learn how fast a cat really is.

I never saw the swipe that layed open my arm.

Faster than the blink of an eye.

I've still got the scars too.

(After that fight they never fought again.  We actually found them sleeping together a couple of times)

[LepreKhaun]

---

Perrie Juran wrote:

---

LepreKhaun wrote:

I've learned to be careful just rubbing a strange cat. Some of them don't like it and I've got some scars for not picking up on it in time.

---

My neighbors dog and my cat got into it one day.

My neighbor grabbed his dog.

I grabbed my cat.

This is when you learn how fast a cat really is.

I never saw the swipe that layed open my arm.

Faster than the blink of an eye.

I've still got the scars too.

(After that fight they never fought again.  We actually found them sleeping together a couple of times)

---

Delightful story, thanks for sharing!

 

However, this is veering far from both the topic and the purpose of this forum which is for discussions about scripts and scripting. Perhaps we could talk about our pets in General Discussion some time.