Brain Teaser; Find nothing in nothing

Brain Teaser; Find nothing in nothing

Post by Clark Kellog » Thu, 05 Apr 2001 11:34:40



I ran across this inconsistency when porting to jbase from AP/PRO.

Consider:
A=""
B=""
LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

Then Consider:

LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

In the first example both jBase and AP/Pro say  "FOUND"

In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

Apparently PICK thinks that a null dynamic array reference is
different than a null variable, but only if the reference is greater
than 1.  Because

LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
will produce "FOUND"  under AP/PRO.

TWILIGHT ZONE.....

However, why is this even an issue.  IF 5 X 0=0, the logic is no
matter what you have on one side of the equation, the result is ALWAYS
the same.  You can't get something from nothing.

Hence, how can you find nothing in nothing?

Have a great day!

Clark

 
 
 

Brain Teaser; Find nothing in nothing

Post by mike ryde » Thu, 05 Apr 2001 17:31:21


Just to start a good discussion ;-)

I would expect the AP/PRO answer if I were using this code construct.

You are not searching a null string, you are searching for an empty string -
and these are subtly different.

Variable B is an empty string and can be 'LOCATED' whereas B<2> is a NULL
string (unpopulated) and contains no empty strings.

My 2p

Mike


Quote:> I ran across this inconsistency when porting to jbase from AP/PRO.

> Consider:
> A=""
> B=""
> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> Then Consider:

> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> In the first example both jBase and AP/Pro say  "FOUND"

> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

> Apparently PICK thinks that a null dynamic array reference is
> different than a null variable, but only if the reference is greater
> than 1.  Because

> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> will produce "FOUND"  under AP/PRO.

> TWILIGHT ZONE.....

> However, why is this even an issue.  IF 5 X 0=0, the logic is no
> matter what you have on one side of the equation, the result is ALWAYS
> the same.  You can't get something from nothing.

> Hence, how can you find nothing in nothing?

> Have a great day!

> Clark


 
 
 

Brain Teaser; Find nothing in nothing

Post by Anthony W. Youngma » Thu, 05 Apr 2001 18:39:51


And, if I'm right, the NULL string is an alien concept to Pick (imported
from SQL), so it will always be a hack to use it.

In INFORMATION the "LOCATE A IN B" syntax was invalid, it required
"LOCATE A IN B<1>" to tell it which level to search - the last entry in
angle brackets had to be 1, I think, and it then returned the "modified"
value in the position variable. It had no concept whatsoever of NULL.

Having an empty string as part of an mv array is something we regularly
do, and is a right pain. But I'm not at all sure that the SQL NULL is
actually a good way of getting round this, either.

-----Original Message-----

Posted At: 04 April 2001 09:31
Posted To: pick
Conversation: Brain Teaser; Find nothing in nothing
Subject: Re: Brain Teaser; Find nothing in nothing

Just to start a good discussion ;-)

I would expect the AP/PRO answer if I were using this code construct.

You are not searching a null string, you are searching for an empty
string -
and these are subtly different.

Variable B is an empty string and can be 'LOCATED' whereas B<2> is a
NULL
string (unpopulated) and contains no empty strings.

My 2p

Mike



> I ran across this inconsistency when porting to jbase from AP/PRO.

> Consider:
> A=""
> B=""
> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> Then Consider:

> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> In the first example both jBase and AP/Pro say  "FOUND"

> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

> Apparently PICK thinks that a null dynamic array reference is
> different than a null variable, but only if the reference is greater
> than 1.  Because

> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> will produce "FOUND"  under AP/PRO.

> TWILIGHT ZONE.....

> However, why is this even an issue.  IF 5 X 0=0, the logic is no
> matter what you have on one side of the equation, the result is ALWAYS
> the same.  You can't get something from nothing.

> Hence, how can you find nothing in nothing?

> Have a great day!

> Clark

 
 
 

Brain Teaser; Find nothing in nothing

Post by Daniel Klei » Thu, 05 Apr 2001 23:01:44


On Wed, 4 Apr 2001 10:39:51 +0100, "Anthony W. Youngman"


>In INFORMATION the "LOCATE A IN B" syntax was invalid, it required
>"LOCATE A IN B<1>" to tell it which level to search - the last entry in
>angle brackets had to be 1, I think, and it then returned the "modified"
>value in the position variable. It had no concept whatsoever of NULL.

I've always found the PRIME syntax of the LOCATE statement to be
counter-intuitive. In every other instance of the language, <a> means attribute
'a', not the 'starting position' within attribute 'a'.

        LOCATE foo IN bar

in my book says, search for an attribute value of 'foo' in the dynamic array
'bar'. And

        LOCATE foo IN bar<a>

says, search for the multivalue 'foo' in attribute <a> of the 'bar' dynamic
array.

My 2 cents (if I even had 2 cents) :-)

Dan

 
 
 

Brain Teaser; Find nothing in nothing

Post by Daniel Klei » Thu, 05 Apr 2001 23:17:28



>Just to start a good discussion ;-)

I love a spirited conversation as much as the next guy...

Quote:>I would expect the AP/PRO answer if I were using this code construct.

>You are not searching a null string, you are searching for an empty string -
>and these are subtly different.

There's no difference in the MV world; a null string _is_ and empty string.
Tell me what this means


What is in <2,2>? And empty string? Or a null string?

Quote:>Variable B is an empty string and can be 'LOCATED' whereas B<2> is a NULL
>string (unpopulated) and contains no empty strings.

What do you think a dynamic array is? In my humble experience, there is no such
thing as a 'null' dynamic array, that is, the representation of the complete
absence of a dynamic array in BASIC code. Take the following code

        ray = ''
        PRINT (ray<2> = '')

This returns '1' (or 'true). So I would have to disagree that (in your example)
B<2> contains 'no empty strings'.

Or does this return 'false' on AP/PRO? I'd bet the farm that it doesn't.

Dan

 
 
 

Brain Teaser; Find nothing in nothing

Post by Jared Solom » Thu, 05 Apr 2001 23:51:11




Quote:>There's no difference in the MV world; a null string _is_ and empty string.

There's no difference in the MV world may be true, however, in the
algorithmic construction that the PICKBasic compiler does, there are
bound to be several different ways of doing this.  Especially if there
isn't a standardized behavior for something like this.

Difference being... do you allocate a new pointer to a string (since
it's an address, and an address is an address, C-wise you can do some
nifty stuff with it), or do you allocate an empty string.

Further, do you allocate a new pointer and a new string and reference
the pointer to the new empty string.

If jBase is doing what I expect it to, in both cases, you've a null
pointer, and it's checking their equivalence.  Whiz-bang, no problem.

Unfortunately, I'm not certain what AP/PRO is doing.  I haven't worked
with it.  But obviously, something different.

My $2*10^(-2)

Jared Solomon

 
 
 

Brain Teaser; Find nothing in nothing

Post by Clark Kellog » Fri, 06 Apr 2001 00:53:00


And you would win the the farm.  AP/Pro does in fact return true.




>>Just to start a good discussion ;-)

>I love a spirited conversation as much as the next guy...

>>I would expect the AP/PRO answer if I were using this code construct.

>>You are not searching a null string, you are searching for an empty string -
>>and these are subtly different.

>There's no difference in the MV world; a null string _is_ and empty string.
>Tell me what this means


>What is in <2,2>? And empty string? Or a null string?

>>Variable B is an empty string and can be 'LOCATED' whereas B<2> is a NULL
>>string (unpopulated) and contains no empty strings.

>What do you think a dynamic array is? In my humble experience, there is no such
>thing as a 'null' dynamic array, that is, the representation of the complete
>absence of a dynamic array in BASIC code. Take the following code

>    ray = ''
>    PRINT (ray<2> = '')

>This returns '1' (or 'true). So I would have to disagree that (in your example)
>B<2> contains 'no empty strings'.

>Or does this return 'false' on AP/PRO? I'd bet the farm that it doesn't.

>Dan

 
 
 

Brain Teaser; Find nothing in nothing

Post by Garry Dixo » Fri, 06 Apr 2001 22:20:23


Clark,

Check these statements using the variation on LOCATE

A=""
B=""
LOCATE(A,B;POS) THEN CRT "FOUND" ELSE CRT "MISSING"
LOCATE(A,B<2>;POS) THEN CRT "FOUND" ELSE CRT "MISSING"

Results are FOUND,FOUND

The main difference between the two B<2> references is that the LOCATE()
version EXTACTs attribute 2 from B before passing the variable to LOCATE
whereas the LOCATE SETTING is intellegent enough, or not, to realise it
should pass a 2 for the attribute count.

Try compiling the code with (A to see the p-code output.

Garry


Quote:> I ran across this inconsistency when porting to jbase from AP/PRO.

> Consider:
> A=""
> B=""
> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> Then Consider:

> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> In the first example both jBase and AP/Pro say  "FOUND"

> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

> Apparently PICK thinks that a null dynamic array reference is
> different than a null variable, but only if the reference is greater
> than 1.  Because

> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> will produce "FOUND"  under AP/PRO.

> TWILIGHT ZONE.....

> However, why is this even an issue.  IF 5 X 0=0, the logic is no
> matter what you have on one side of the equation, the result is ALWAYS
> the same.  You can't get something from nothing.

> Hence, how can you find nothing in nothing?

> Have a great day!

> Clark

 
 
 

Brain Teaser; Find nothing in nothing

Post by Clark Kellog » Sat, 07 Apr 2001 00:27:26


Thanks Garry.

But, if you will refer to another thread here titled : D3 Help Request
and look at test 2 you will find that the results differ from yours on
a D3 machine.

What I have been able to determine is that different flavors of MV
basic handle this condition differently.  Some will return found, D3
will return missing.

Which is most correct, and why, I am not qualified to answer.
I do point out that D3's treatment is at least consistent with AP/Pro.
That being said, it has disturbing implications, in that the branch it
takes depends on the data set irrespective of the data being searched.

By this I mean that given a value search of null, on say attribute 5,
which is set to null, an else branch (missing) will occur if the data
set contains less than 5 attributes, but the then (found) branch will
be taken if the data set contains five or more attributes.  
What this means is that even though you have effectively the same data
and the same code, a different branch can be taken depending on the
number of elements in the data set.

Logic would dictate to me a consistent result.  Why Pick operates in
this fashion, I can only guess.  But it does.

Regards,

Clark

On Thu, 5 Apr 2001 14:20:23 +0100, "Garry Dixon"


>Clark,

>Check these statements using the variation on LOCATE

>A=""
>B=""
>LOCATE(A,B;POS) THEN CRT "FOUND" ELSE CRT "MISSING"
>LOCATE(A,B<2>;POS) THEN CRT "FOUND" ELSE CRT "MISSING"

>Results are FOUND,FOUND

>The main difference between the two B<2> references is that the LOCATE()
>version EXTACTs attribute 2 from B before passing the variable to LOCATE
>whereas the LOCATE SETTING is intellegent enough, or not, to realise it
>should pass a 2 for the attribute count.

>Try compiling the code with (A to see the p-code output.

>Garry



>> I ran across this inconsistency when porting to jbase from AP/PRO.

>> Consider:
>> A=""
>> B=""
>> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

>> Then Consider:

>> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

>> In the first example both jBase and AP/Pro say  "FOUND"

>> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

>> Apparently PICK thinks that a null dynamic array reference is
>> different than a null variable, but only if the reference is greater
>> than 1.  Because

>> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
>> will produce "FOUND"  under AP/PRO.

>> TWILIGHT ZONE.....

>> However, why is this even an issue.  IF 5 X 0=0, the logic is no
>> matter what you have on one side of the equation, the result is ALWAYS
>> the same.  You can't get something from nothing.

>> Hence, how can you find nothing in nothing?

>> Have a great day!

>> Clark

 
 
 

Brain Teaser; Find nothing in nothing

Post by Bill » Wed, 11 Apr 2001 12:01:16


Clark:

This is interesting.  I'd think there is a difference, conceptually, between
an attribute with nothing in it and no attribute at all, kind of like a car
with no gas and no car at all.  So, I'd expect the locate to fail - my car
may be useless but I have one. :-)

Being consistent, however, this means that if I did a READV for a
non-existent attribute the ELSE clause should be taken if no attribute
exists.  But this isn't true, READV will take the THEN if the item exists.

I guess I learn something new every day.

Bill


> Thanks Garry.

> But, if you will refer to another thread here titled : D3 Help Request
> and look at test 2 you will find that the results differ from yours on
> a D3 machine.

> What I have been able to determine is that different flavors of MV
> basic handle this condition differently.  Some will return found, D3
> will return missing.

> Which is most correct, and why, I am not qualified to answer.
> I do point out that D3's treatment is at least consistent with AP/Pro.
> That being said, it has disturbing implications, in that the branch it
> takes depends on the data set irrespective of the data being searched.

> By this I mean that given a value search of null, on say attribute 5,
> which is set to null, an else branch (missing) will occur if the data
> set contains less than 5 attributes, but the then (found) branch will
> be taken if the data set contains five or more attributes.
> What this means is that even though you have effectively the same data
> and the same code, a different branch can be taken depending on the
> number of elements in the data set.

> Logic would dictate to me a consistent result.  Why Pick operates in
> this fashion, I can only guess.  But it does.

> Regards,

> Clark

> On Thu, 5 Apr 2001 14:20:23 +0100, "Garry Dixon"

> >Clark,

> >Check these statements using the variation on LOCATE

> >A=""
> >B=""
> >LOCATE(A,B;POS) THEN CRT "FOUND" ELSE CRT "MISSING"
> >LOCATE(A,B<2>;POS) THEN CRT "FOUND" ELSE CRT "MISSING"

> >Results are FOUND,FOUND

> >The main difference between the two B<2> references is that the LOCATE()
> >version EXTACTs attribute 2 from B before passing the variable to LOCATE
> >whereas the LOCATE SETTING is intellegent enough, or not, to realise it
> >should pass a 2 for the attribute count.

> >Try compiling the code with (A to see the p-code output.

> >Garry



> >> I ran across this inconsistency when porting to jbase from AP/PRO.

> >> Consider:
> >> A=""
> >> B=""
> >> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> >> Then Consider:

> >> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"

> >> In the first example both jBase and AP/Pro say  "FOUND"

> >> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"

> >> Apparently PICK thinks that a null dynamic array reference is
> >> different than a null variable, but only if the reference is greater
> >> than 1.  Because

> >> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> >> will produce "FOUND"  under AP/PRO.

> >> TWILIGHT ZONE.....

> >> However, why is this even an issue.  IF 5 X 0=0, the logic is no
> >> matter what you have on one side of the equation, the result is ALWAYS
> >> the same.  You can't get something from nothing.

> >> Hence, how can you find nothing in nothing?

> >> Have a great day!

> >> Clark

 
 
 

1. Recordset.Close, set Recordset = Nothing vs set Recordset = Nothing

I'm just curious, is there any difference doing

Recordset.Close
Set Recordset = Nothing

versus doing

set Recordset = Nothing

I've always been under the impression destroying the recordset object
implicitly closed the connection, but I was recently contradicted. So have I
been wrong all along?

Jay Oliver

2. VindossXP prof and VB6

3. Find nothing.com

4. WWW and esqlc

5. Help the difference between " and '

6. pgsql-server/src/interfaces/ecpg/compatlib inf ...

7. Help with Query finding nothing

8. Find nothing.com

9. an sql brain teaser

10. Semi additive brain teaser

11. Brain Teaser (at least it is for me)