Page 2 of 3 <123>
Topic Options
#78921 - 2002-06-11 09:32 PM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
no.
all I'm saying is that having it at position before first character is different from having no match at all.
but...
as I put my mind to rest I come more close to others opinion.
and the arguments I said about string having something inside and kix can make it's ways.
so, I think I'll give up. when matching against zero length string it should return 0 as no match.
matching viewable characters not possible other parts string may contain.
_________________________
!

download KiXnet

Top
#78922 - 2002-06-11 11:52 PM Re: Instr() Behaviour
Bxn Offline
Getting the hang of it

Registered: 2002-06-05
Posts: 63
Loc: Alpha Centauri
Hi, Brian ...
You asked :
quote:
Are you saying that if a string doesn't exist in the other string, we should assign that a negative value as well?
Well, not exactly, if Lonkero permits me to take the service [Wink] ...

Of course if a string is simply not present in another string, no use to return another value than zero, as the documentation states.
But, the problem in our case is that we can't really prevent some people (and me, Oh God For One ! I was [Wink] ) to hammering the null string is present in every string and HowEver not to be satisfied at all with a return value of 1 as it actually is.

The special case of the empty string :

It is PRESENT, but DIFFERENT FROM EACH (every ?) CHARACTER in the string ... Sure you Follow me ...

So :

Present => return value <> 0 (>0 accordin' to the doc.)
Diff. From Each Character => return value = 0

That's why a returned value < 0 wouldn't have been illogical to my mind.

But, although I initiated the topic in that way, I would now perfectly agree with the fact, that it wouldn't be very efficient and certainly would have a malicious effect in some existing code ...

'Hope to be boring ...

Top
#78923 - 2002-06-11 11:54 PM Re: Instr() Behaviour
Bxn Offline
Getting the hang of it

Registered: 2002-06-05
Posts: 63
Loc: Alpha Centauri
Sorry, lapsus :

'Hope NOT to be boring [Wink]

Top
#78924 - 2002-06-12 09:42 AM Re: Instr() Behaviour
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Lonkero,

First, *please* stop calling me Howard. It gets awfully confusing and I don't think Howard should take the blame for my views and mistakes [Wink]

To pick up on a couple of your points:
quote:
kix, as it's script-language, can determine pretty much what strings contain
Don't forget that KiXtart is an interpreted language. There is a program which is reading the code and translating it. That program is written in...?

Ultimately the way strings are handled is determined by the interpreter. Strings are almost always handled as zero terminated arrays of characters. As in other languages, if you want to handle binary/raw data you don't use strings to do it, you use a binary storage object.

quote:
and if you try to add to the end of string manually the null character what happens?
cause that's allowed in c...

No it's not allowed in C.

If you treat the object as a string you cannot add '\0', because that's the end of the string - it's completely redundant.

Try this:
code:
printf("String length is %d\n",strlen("\0\0\0\0\0"));

The answer is of course zero.

You *can* access the memory where the string is stored and add whatever data you like to the end of it, but that is because you are no longer treating it as a string, you are accessing the memory as a raw object. Whenever you subsequently access it as a string the extra data past the first '\0' will be ignored.

Strings in C are not real storage objects, there is no "string" type in C. They are an abstract of character arrays, and that abstract expects them to be "any number of characters except '\0'"

This is true of KiXtart as well of course, except they are further abstracted by the interpreter, which has no provision to access the underlying storage object.

I know I've gone on a bit, but I think that it is useful to explain how the underlying storage mechanisms work, as it makes it easier to understand why some things work (or don't work) the way that they do.

Top
#78925 - 2002-06-12 10:19 AM Re: Instr() Behaviour
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11611
Loc: CA
Quote by Howard [Eek!] hehehe I mean Richard:

Don't forget that KiXtart is an interpreted language. There is a program which is reading the code and translating it. That program is written in...?

code:
KIX32.EXE (204800 bytes)

Is a DOS executable
Size of header.....: 00000040h / 64 bytes
File size in header: 00000490h / 1168 bytes
Entrypoint.........: 00000040h / 64
Overlay size.......: 00031B70h / 203632
No relocation entries

PE EXE at offset 256/00000100h
Entrypoint: 0001BDC8h / 114120 (RVA: 0001BDC8h) (.text)
Calculated PE EXE size: 00032000h / 204800
Calculated overlay size: 00000000h / 0
Image base: 00400000h
Required CPU type: 80386
Required OS: 4.00 - Win 95 or NT 4
Subsystem: Console
Linker version: 6.00
Flags:
Relocation info stripped from file
File is executable
Line numbers stripped from file
Local symbols stripped from file
Machine based on 32-bit-word architecture
Stack reserve: 00100000h / 1048576
Stack commit: 00001000h / 4096
Heap reserve: 00100000h / 1048576
Heap commit: 00001000h / 4096

Sections according to section table (section align = 00001000h):
Name Virt size RVA Phys size Phys offs
.text 00023914h 00001000h 00024000h 00001000h
.rdata 0000264Eh 00025000h 00003000h 00025000h
.data 0001B6D4h 00028000h 00009000h 00028000h
.rsrc 000003F0h 00044000h 00001000h 00031000h

Listing of all used data directory entries (used: 3, total: 16):
Import Table - offset: 000261FCh - RVA: 000261FCh (.rdata)
Ressource Table - offset: 00031000h - RVA: 00044000h (.rsrc)
Import Address Table - offset: 00025000h - RVA: 00025000h (.rdata)

Resources at offset 00031000h (RVA 00044000h):
Version:
ID: 0x00000001h RVA: 0x00044060h; Offset: 0x0003105Fh; Size: 908 bytes
VersionInfo resource:
Fileversion: 4.02.00 (0)
Productversion: 4.02.00 (63)
Target OS: 32 bit Windows running with MS-DOS

Total resource size: 996 bytes (ressources: 908 bytes, table: 88 bytes)

Processed with:
Found compiler 'Visual C++ 5.0 ?'
Seems to be compiled by MS Visual C++ 6.0

However, since the KiXtart 2001 manual already tells us, I guess I did not need to trace the file type.

From page 111 of the 2001 manual you have.

About KiXtart
KiXtart 2001 is a spare time project of Ruud van Velsen of Microsoft Netherlands.

KiXtart was developed on Windows XP using Microsoft Visual Studio, Microsoft Visual C 6.0 SP4, Microsoft Assembler 6.1 and the Windows 32 Software Development Kit.

The SPK format used by the PLAY command was originally designed by Gordon E. Peterson II. The SPK files were translated from BASIC and Assembler programs gathered from various public domain sources

[Cool]

Top
#78926 - 2002-06-12 10:37 AM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
howie...
this is weird, I've allways read your name to be richard howard!

don't know why. but how* sounds better than ric* (notice the hard tasting c there...)

but as it comes to the c again.

have you tried writing string like:
"my fellow"
added the null to fourth place:
"my "
and then added as example 1 in its place.
"my 1 fellow"

?
_________________________
!

download KiXnet

Top
#78927 - 2002-06-12 11:34 AM Re: Instr() Behaviour
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Perhaps you're confusing me with Howard Bullock.

Your example illustrates what I was saying.

When you place the '\0' in the fourth character position you are terminating the string there. No string functions will read past it - whatever is past the third character is unavailable.

If you want to access the rest of the data beyond character 4 you will need to do it a different way, string semantics won't do it for you.

Replacing the '\0' with another character means that it will read up to the next '\0', which will be at the end of your original string, unless something else has used the memory beyond the '\0' in which case you will get garbage.

In your example, the final string would be
"my 1ellow"

[ 12 June 2002, 11:38: Message edited by: Richard Howarth ]

Top
#78928 - 2002-06-13 12:01 AM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
I know that there is difference between richard howie and howard bullock (uttleast I suppose so).

but anyhow...

my example went broken when bb cuts empty spaces... it had 3 tabs...
_________________________
!

download KiXnet

Top
#78929 - 2002-06-12 06:52 PM Re: Instr() Behaviour
Jack Lothian Offline
MM club member
*****

Registered: 1999-10-22
Posts: 1169
Loc: Ottawa,Ontario, Canada
Richard,

I am afraid I started this calling of you Howard. I corrected my mistake shortly after but unforunately is seems to have stuck in others members head. I am sorry.

Brian,

I have been busy lately & this is a complex subject so I have no time to develop a respond to your comments.

I don't think I expressed myself very well. I believe this discussion is about a fundamental paradox. I do believe it closely parallels Bertrand Russell's paradox. The basic paradox is an infinite number of nothings exist in everything. Like Russell's paradox, it can not be resolved unless you apply extra constraints or axioms to your logic system.

You say 0 is the best value to return because there is a nothing just in front of your string. But there is another nothing in front of that nothing so maybe -1 is better. Of course we can continue this arguement forever until we arrive at minus infinity. Clearly, an infinite number of contradictory results can be obtained. Neither 0 or 1 is a consistent result. When using symbolic logic you must be very careful when any of the symbols can take on a value of 0 or infinity. Most logical proofs break down when values of 0 or ininity are introduced.

Lonkero's solution has strong merits. A return of an error explicitly tells the user that this can not be solved within the current logic system. In essence the user has asked the unanswerable.

I believe you can add constraints to the logic system that enables one to always derive an answer of 1 but never 0. (Unless of couse you always start your countings at 0 like some computer do. These languages define arrays starting from position 0 onwards.)

I am not sure you can add constraints that develop a closed logic system that only counts nothings once. To return 0, I think you need such a constraint to consistently derive your answer.

From the point of view of a programming language though I see no great issue with returning 0. Of course, the user will not be able to tell the difference between not finding it & it was impossible to look. Both of these cases will return a zero.
_________________________
Jack

Top
#78930 - 2002-06-12 07:19 PM Re: Instr() Behaviour
Howard Bullock Offline
KiX Supporter
*****

Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
I am just glad that I haven't been posting these comments to which I was unaware. [Wink]

[ 12 June 2002, 19:19: Message edited by: Howard Bullock ]
_________________________
Home page: http://www.kixhelp.com/hb/

Top
#78931 - 2002-06-12 10:18 PM Re: Instr() Behaviour
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
Hmmm.. interesting points, Jack.

I can easily understand how you can define a boolean system of proofs to decide that an empty set (or sequence) is always in every set (or sequence), so you would return a value of "YES" (or 1) to validate that one sequence intersects another. However, (implied from what you said) you can have an infinite number of empty sequences before or after a defined sequence, so these empty sets could be indexed to infinity in one direction or the other....

The only problem with this theory is that INSTR is defined by calculating first IF a string exists in another string AND the index of that string as defined by numbering the characters in the string. Because the empty sequences before and after the characters that exist are not defined, it would be impossible to define an empty sequence using one of the numbers that already defines a starting point that does exist in the string.

For example:
INSTR("abc","A") = INSTR("abc","") = 1 should NOT be true.

If indeed INSTR("abc","d") = INSTR("abc","")=0 should not be true either because the two conditions are not identical, then two different return codes should be chosen for each case UNLESS it is unnecessary to distinguish between the two situations. Perhaps the easiest way to solve this problem would be to let:

INSTR("abc","d") = 0 with @error = 0
and
INSTR("abc","") = 0 with @error = something(1, or -1)

The 0 represents that the 2nd string has no index in the first. The @error represents whether or not the 2nd string is an empty set.

This way people that don't care to distinguish between the 2 latter evaluations would have to write no additional code to handle them. Those of us that may at some point wish to handle them will have an alternative to do so.

Brian

[ 13 June 2002, 14:24: Message edited by: BrianTX ]

Top
#78932 - 2002-06-13 10:31 AM Re: Instr() Behaviour
Bxn Offline
Getting the hang of it

Registered: 2002-06-05
Posts: 63
Loc: Alpha Centauri
Interestin' Indeed !
But I suggest you to apply the new jokin' function :

Replace(Substr(Dummy),Instr(Dummy))

Just to stay on Topic [Big Grin]

Top
#78933 - 2002-06-13 10:46 AM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
but what was the topic?

{edit}
checked and yes, it's about instr...

[ 13 June 2002, 10:47: Message edited by: Lonkero ]
_________________________
!

download KiXnet

Top
#78934 - 2002-06-13 02:23 PM Re: Instr() Behaviour
BrianTX Offline
Korg Regular

Registered: 2002-04-01
Posts: 895
Oops.. lol.. geez.. that's what I meant.. let me fix that! lol -- It's called "absent-minded professor syndrome!"

Brian

[ 13 June 2002, 14:25: Message edited by: BrianTX ]

Top
#78935 - 2002-08-23 08:43 AM Re: Instr() Behaviour
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 363
Loc: Amsterdam, The Netherlands
Better late than never, I hope: the long and shotr of why InStr returns 1 if you search for an empty string is... that it is compatible with the implementation of InStr in other languages (such as Visual Basic).

Maybe not the exciting answer you were looking for, but there you go ;-)

Ruud

Top
#78936 - 2002-08-23 04:16 PM Re: Instr() Behaviour
Sealeopard Offline
KiX Master
*****

Registered: 2001-04-25
Posts: 11163
Loc: Boston, MA, USA
That's actually a very good and reasonable explanation [Smile]
_________________________
There are two types of vessels, submarines and targets.

Top
#78937 - 2002-08-24 03:11 AM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
still, it does not make any explanation at all. as I think of, it was made as a quickie instr-support to have kix be as much as possible like vb...

well, kix ain't like that. kix is purely independent in many cases and these likelyhoods, if questioned, should also be discussed...

anyway, as ruud's project, he can rule on these and my opinion just is that opinions are good.
_________________________
!

download KiXnet

Top
#78938 - 2002-08-24 05:20 AM Re: Instr() Behaviour
Jack Lothian Offline
MM club member
*****

Registered: 1999-10-22
Posts: 1169
Loc: Ottawa,Ontario, Canada
Brian,

Sorry for my late comment but I was busy that week & I never looked back in on this discussion & I missed your comments.

You suggest that

quote:

For example:
INSTR("abc","A") = INSTR("abc","") = 1 should NOT be true.

Why? Looking for "nothing" fundamentally violates the logic system so why couldn't it return an illogical answer.

I agree my patch or constraint on the logic doesn't resolve all the logical conflicts but I am not sure that there is any constraint that is logically consistent in every circumstance.

A point:

If ""="" is true would it be logical to have INSTR("","") be false?

I don't think there is a logical answer to this debate & Ruud's reason is as good as any.

[ 24. August 2002, 05:27: Message edited by: Jack Lothian ]
_________________________
Jack

Top
#78939 - 2002-08-26 05:30 PM Re: Instr() Behaviour
Bxn Offline
Getting the hang of it

Registered: 2002-06-05
Posts: 63
Loc: Alpha Centauri
I see I've introduced Lots Of "verbiage" for nothing ...

Will I be wrong another time if I suggest little mods in doc (to alert newbees and not CompatibilityAware people like me, that this function "... does not always return the first occurence ...")?

Top
#78940 - 2002-08-26 07:49 PM Re: Instr() Behaviour
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22344
Loc: OK
bxn, it could be done but with not those words.

as it would state:
"function does not always work"

[Big Grin]

[ 26. August 2002, 20:12: Message edited by: Lonkero ]
_________________________
!

download KiXnet

Top
Page 2 of 3 <123>


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 304 anonymous users online.
Newest Members
Praveer, Ollero, rayyo, Foxlicht, DonChild
17742 Registered Users

Generated in 0.047 seconds in which 0.014 seconds were spent on a total of 12 queries. Zlib compression enabled.