1. Strings and the like.
What if something like these were built-in?
-----------------------------------
type whole_number_set(sequence s)
for A = 1 to length(s) do
if (s[A] = floor(s[A])) then
return 0
end if
end for
return 1
end type
-----------------------------------
Then you would be able to specify any range and test it
effeciently such as a byte_set() below. Of course, these
sets are enforcing that you have a one dimensional sequence.
But that is the whole point of detecting strings.
-----------------------------------
type byte_set(sequence s)-- I.E.: standard ASCII byte STRING !!!
sequence temp
if whole_number_set(s) then
temp = ((s >= 0) and (255 > s))
return (find(0, temp) = 0)
else
return 0
end if
end type
-----------------------------------
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
2. Re: Strings and the like.
Hello,
Lucius L. Hilley III wrote:
> What if something like these were built-in?
>
>-----------------------------------
>type whole_number_set(sequence s)
> for A = 1 to length(s) do
> if (s[A] = floor(s[A])) then
> return 0
> end if
> end for
>
> return 1
>end type
>-----------------------------------
dont you mean:
if (s[A] != floor(s[A])) then
-- or ^
if not (s[A] = floor(s[A])) then
^
Correct me if I'm wrong, but dont you only want to return
zero if the char is NOT equal to the char floored?
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
3. Re: Strings and the like.
Oops, My mind must really be going. Yes, I meant to return 0 if not
equal.
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Lewis Townsend <keroltarr at HOTMAIL.COM>
> Subject: Re: Strings and the like.
> --------------------------------------------------------------------------
-----
>
> Hello,
>
> Lucius L. Hilley III wrote:
>
> > What if something like these were built-in?
> >
> >-----------------------------------
> >type whole_number_set(sequence s)
> > for A = 1 to length(s) do
> > if (s[A] = floor(s[A])) then
> > return 0
> > end if
> > end for
> >
> > return 1
> >end type
> >-----------------------------------
>
> dont you mean:
> if (s[A] != floor(s[A])) then
> -- or ^
> if not (s[A] = floor(s[A])) then
> ^
> Correct me if I'm wrong, but dont you only want to return
> zero if the char is NOT equal to the char floored?
>
> later,
> Lewis Townsend
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
4. Re: Strings and the like.
- Posted by Ad Rienks <kwibus at ZONNET.NL>
Dec 08, 1999
-
Last edited Dec 09, 1999
I thinks you mean:
if s[A] != floor(s[A]) then
return 0
end if
-- in your type whole_number_set() definition
----- Oorspronkelijk bericht -----
Van: Lucius L. Hilley III <lhilley at CDC.NET>
Aan: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Verzonden: woensdag 8 december 1999 14:53
Onderwerp: Strings and the like.
> What if something like these were built-in?
>
> -----------------------------------
> type whole_number_set(sequence s)
> for A = 1 to length(s) do
> if (s[A] = floor(s[A])) then
> return 0
> end if
> end for
>
> return 1
> end type
> -----------------------------------
>
> Then you would be able to specify any range and test it
> effeciently such as a byte_set() below. Of course, these
> sets are enforcing that you have a one dimensional sequence.
> But that is the whole point of detecting strings.
>
> -----------------------------------
> type byte_set(sequence s)-- I.E.: standard ASCII byte STRING !!!
> sequence temp
>
> if whole_number_set(s) then
> temp = ((s >= 0) and (255 > s))
> return (find(0, temp) = 0)
> else
> return 0
> end if
> end type
> -----------------------------------
>
>
> Lucius L. Hilley III
> lhilley at cdc.net
> +----------+--------------+--------------+
> | Hollow | ICQ: 9638898 | AIM: LLHIII |
> | Horse +--------------+--------------+
> | Software | http://www.cdc.net/~lhilley |
> +----------+-----------------------------+
5. Re: Strings and the like.
Lucius L. Hilley III wrote:
> What if something like these were built-in?
>
>-----------------------------------
>type whole_number_set(sequence s)
> for A = 1 to length(s) do
> if (s[A] = floor(s[A])) then
> return 0
> end if
> end for
>
> return 1
>end type
>-----------------------------------
I think that you have a small error in these routines, and I would not
see the difference between your's and this:
type whole_number_set(sequence s)
sequence temp1
temp1 = (s = floor(s))
return (find(0, temp) = 0)
end type
-----------------------------------
>
>Then you would be able to specify any range and test it
>effeciently such as a byte_set() below. Of course, these
>sets are enforcing that you have a one dimensional sequence.
>But that is the whole point of detecting strings.
>
>-----------------------------------
and this
type byte_set(sequence s) -- I.E.: standard ASCII byte STRING !!!
sequence temp
if whole_number_set(s) then
temp = ((s >= 0) and (255 > s))
return (find(0, temp) = 0)
end if
end type
Are you deliberately leaving xFF out of the set?
Anyway, I think I recognize a palliative gesture here. You have described a
very specific, very non-embedded Euphoria typing routine here. It appears
that the only way to type check by these techniques is to check the
entire sequence each time that any operation is made on the sequence...
OUCH!!...can anybody spell overhead. The only way to prevent this would
be to assign the substring to be affected to another type-checked variable
before the operation and then assign it back. Not only would this be
clumsy, in some cases it might be tricky and from what I can tell, it would
trigger the type check anyway on the whole string. Depending on how often
the test is triggered for operations that affect the whole or some slice of the
string, this could get ugly.
OUCH!!...I, as an Euphoria newby, just stomped on a really ugly artifact of
Euphoria and sequences. I see how relational and logical operators produce
multiple results, true values rather than logical values. A logical value is a
temporary item that only exists at the point of comparison unless
deliberately and separately preserved. Unless the comparands are also
preserved, any such logical "value" loses its relevance as soon as those
comparands lose their validity. For validity, where a single logical result is
expected, Euphoria should sequentially "and" together the truth values
for this purpose. This should be valid, for example:
type whole_number_set(sequence s)
return (s = floor(s))
end type
And in any other case where a single value would be necessary for
consistency. Another example would be:
sequence s
s = "ABCD"
if s = floor(s) then ....
end if
This is a major logical hole in the language. There needs to be a clear
distinguishing between relational and logical as functional operators
returning a value or values and those same operators as standard truth
tests in our standard binary logic system. Neither mode needs to be
excluded. Overloading is not a problem here...I don't think. Maybe
somebody can come up with a counter to that thought.
Everett L.(Rett) Williams
rett at gvtc.com
6. Re: Strings and the like.
My apologies, but somehow, I sent this previously incomplete. This is the
full text.
Lucius L. Hilley III wrote:
> What if something like these were built-in?
>
>-----------------------------------
>type whole_number_set(sequence s)
> for A = 1 to length(s) do
> if (s[A] = floor(s[A])) then
> return 0
> end if
> end for
>
> return 1
>end type
>-----------------------------------
I think that you have a small error in these routines, and I would not
see the difference between your's and this:
type whole_number_set(sequence s)
sequence temp1
temp1 = (s = floor(s))
return (find(0, temp) = 0)
end type
-----------------------------------
>
>Then you would be able to specify any range and test it
>effeciently such as a byte_set() below. Of course, these
>sets are enforcing that you have a one dimensional sequence.
>But that is the whole point of detecting strings.
>
>-----------------------------------
and this
type byte_set(sequence s) -- I.E.: standard ASCII byte STRING !!!
sequence temp
if whole_number_set(s) then
temp = ((s >= 0) and (255 > s))
return (find(0, temp) = 0)
end if
end type
Are you deliberately leaving xFF out of the set?
Anyway, I think I recognize a palliative gesture here. You have described a
very specific, very non-embedded Euphoria typing routine here. It appears
that the only way to type check by these techniques is to check the
entire sequence each time that any operation is made on the sequence...
OUCH!!...can anybody spell overhead. The only way to prevent this would
be to assign the substring to be affected to another type-checked variable
before the operation and then assign it back. Not only would this be
clumsy, in some cases it might be tricky and from what I can tell, it would
trigger the type check anyway on the whole string. Depending on how often
the test is triggered for operations that affect the whole or some slice of the
string, this could get ugly.
OUCH!!...I, as an Euphoria newby, just stomped on a really ugly artifact of
Euphoria and sequences. I see how relational and logical operators produce
multiple results, true values rather than logical values. A logical value is a
temporary item that only exists at the point of comparison unless
deliberately and separately preserved. Unless the comparands are also
preserved, any such logical "value" loses its relevance as soon as those
comparands lose their validity. For validity, where a single logical result is
expected, Euphoria should sequentially "and" together the truth values
for this purpose. This should be valid, for example:
type whole_number_set(sequence s)
return (s = floor(s))
end type
And in any other case where a single value would be necessary for
consistency. Another example would be:
sequence s
s = "ABCD"
if s = floor(s) then ....
end if
This is a major logical hole in the language. There needs to be a clear
distinguishing between relational and logical symbols as functional
operators returning a value or values and those same operators as
standard truth tests in our standard binary logic system. Neither mode
needs to be excluded. Overloading is not a problem here...I don't think.
Maybe somebody can come up with a counter to that thought.
Everett L.(Rett) Williams
rett at gvtc.com
7. Re: Strings and the like.
Everett Williams wrote (in response to Lucius Hilley):
>> What if something like these were built-in?
>>
>>-----------------------------------
>>type whole_number_set(sequence s)
>> for A = 1 to length(s) do
>> if (s[A] = floor(s[A])) then
>> return 0
>> end if
>> end for
>>
>> return 1
>>end type
>>-----------------------------------
>
>I think that you have a small error in these routines, and I would not
>see the difference between your's and this:
>
>type whole_number_set(sequence s)
> sequence temp1
> temp1 = (s = floor(s))
> return (find(0, temp) = 0)
>end type
The difference between your logic and Lucius' is that Lucius' will detect
illegal values much faster than yours will. Lucius' routine evaluates one
element at a time, returning "false" *immediately* upon the discovery of an
illegal value. Your routine is forced to evaluate the whole sequence first,
*then* look for a false value.
Now, you may not think this makes any difference for type-checking -- after
all, an illegal value will cause the program to abort anyway, so what
difference does it make how fast it returns a false value?
Well, it can make a *big* difference when you employ MANUAL type-checking,
i.e., calling the type like a function:
sequence s
s = get_value_from_somewhere()
if whole_number_set(s) then
puts(1, "Yippee!\n")
-- process the sequence
else
puts(1, "Dang!\n")
-- do some error handling
end if
You will notice that using *this* kind of type-checking avoids the problems
of automatic type-checking happening when you don't want it to. Plus, it
gives your program the opportunity to abort gracefully, saving data,
displaying a user-friendly error message, etc., etc. Your program may even
*expect* to have hundreds of type-check fails in this manner, and need to
react accordingly (as is the case with my BGET routine). In this situation,
the speed at which the type returns a "false" value can be vitally
important.
>type byte_set(sequence s) -- I.E.: standard ASCII byte STRING !!!
> sequence temp
> if whole_number_set(s) then
> temp = ((s >= 0) and (255 > s))
> return (find(0, temp) = 0)
> end if
>end type
<PICKYMODE=ON>
Sorry, but this routine looks woefully inefficient, no matter what kind of
type-checking you do. The following is the speediest string type I was able
to create for my BGET routine. It's optimized to return a "false" value
ASAP, so it might not be the speediest for automatic type-checking. (It's
still mighty fast, though...) 
type string(sequence s) -- string8
object x
for i = 1 to length(s) do
x = s[i]
if integer(x) then
if x < 0 then
return 0
elsif x > #FF then
return 0
end if
else
return 0
end if
end for
return 1
end type
</PICKYMODE>
>Anyway, I think I recognize a palliative gesture here. You have described a
>very specific, very non-embedded Euphoria typing routine here. It appears
>that the only way to type check by these techniques is to check the
>entire sequence each time that any operation is made on the sequence...
>OUCH!!...can anybody spell overhead.
Can anybody spell, "use this wisely?" Again, if you don't like the automatic
type-checking, do it manually.
>The only way to prevent this would
>be to assign the substring to be affected to another type-checked variable
>before the operation and then assign it back. Not only would this be
>clumsy, in some cases it might be tricky and from what I can tell, it would
>trigger the type check anyway on the whole string. Depending on how often
>the test is triggered for operations that affect the whole or some slice of
the
>string, this could get ugly.
I don't see why this is "clumsy". Again, just type-check MANUALLY in these
unusual situations. IMO you are making this sound like far more of a problem
than it really is.
>OUCH!!...I, as an Euphoria newby, just stomped on a really ugly artifact of
>Euphoria and sequences. I see how relational and logical operators produce
>multiple results, true values rather than logical values. A logical value
is a
>temporary item that only exists at the point of comparison unless
>deliberately and separately preserved. Unless the comparands are also
>preserved, any such logical "value" loses its relevance as soon as those
>comparands lose their validity. For validity, where a single logical result
is
>expected, Euphoria should sequentially "and" together the truth values
>for this purpose. This should be valid, for example:
>
>type whole_number_set(sequence s)
> return (s = floor(s))
>end type
Sorry, but you completely lost me with the "comparands" and "validity"
stuff. Perhaps this is why I don't understand what the problem is here.
Euphoria handles its logical operations consistently across all data types.
This consistency makes the language easier to understand than other
languages with too many exceptional conditions.
As for your whole_number_set type, you could just write it like this:
type whole_number_set(sequence s)
return not find(0, (s = floor(s)))
end type
Or, if you're going to do a lot of this kind of logic and want it to be more
readable, you can use my generic all_true() function:
function all_true(sequence s)
return not find(0, s)
end function
Using this, you can then write your whole_number_set type like this...
type whole_number_set(sequence s)
return all_true(s = floor(s))
end type
...which not only works, but also results in very readable code.
>And in any other case where a single value would be necessary for
>consistency. Another example would be:
>
>sequence s
>s = "ABCD"
>if s = floor(s) then ....
>
>end if
Again, your proposal does not strike me as being "consistent." This could
just as easily be accomplished by coding:
if all_true(s = floor(s)) then...
>This is a major logical hole in the language.
No, it isn't. If you want it to work differently, it's quite easy to make it
do so, as I have shown.
Hep yadda,
Gabriel Boehme
----------
If we can define our aim, we are halfway to achieving it.
Robert Fripp
----------
8. Re: Strings and the like.
Gabriel Boehme wrote:
>Everett Williams wrote (in response to Lucius Hilley):
>>> What if something like these were built-in?
>>>
>>>-----------------------------------
>>>type whole_number_set(sequence s)
>>> for A = 1 to length(s) do
>>> if (s[A] = floor(s[A])) then
>>> return 0
>>> end if
>>> end for
>>>
>>> return 1
>>>end type
>>>-----------------------------------
>>
>>I think that you have a small error in these routines, and I would not
>>see the difference between your's and this:
>>
>>type whole_number_set(sequence s)
>> sequence temp1
>> temp1 = (s = floor(s))
>> return (find(0, temp) = 0)
>>end type
>
>The difference between your logic and Lucius' is that Lucius' will detect
>illegal values much faster than yours will. Lucius' routine evaluates one
>element at a time, returning "false" *immediately* upon the discovery of an
>illegal value. Your routine is forced to evaluate the whole sequence first,
>*then* look for a false value.
You're telling me that loop overhead for half the string(assumed average
length of scan) is not equivalent to optimized handling of the whole string.
Could be...could not be. Would have to test here.
>Now, you may not think this makes any difference for type-checking -- after
>all, an illegal value will cause the program to abort anyway, so what
>difference does it make how fast it returns a false value?
>Well, it can make a *big* difference when you employ MANUAL type-checking,
>i.e., calling the type like a function:
>
>sequence s
>s = get_value_from_somewhere()
>
>if whole_number_set(s) then
> puts(1, "Yippee!\n")
> -- process the sequence
>else
> puts(1, "Dang!\n")
> -- do some error handling
>end if
>
>You will notice that using *this* kind of type-checking avoids the problems
>of automatic type-checking happening when you don't want it to. Plus, it
>gives your program the opportunity to abort gracefully, saving data,
>displaying a user-friendly error message, etc., etc. Your program may even
>*expect* to have hundreds of type-check fails in this manner, and need to
>react accordingly (as is the case with my BGET routine). In this situation,
>the speed at which the type returns a "false" value can be vitally
>important.
Absolutely, and an internal type-check can deal with indexed accesses to
the string without dealing with anything but the indexed item.
snip
>Can anybody spell, "use this wisely?" Again, if you don't like the automatic
>type-checking, do it manually.
As noted above, we poor injuns out here don't have access to all the places
that the interpreter does. The error handling is the killer in this mystery.
>>The only way to prevent this would
>>be to assign the substring to be affected to another type-checked variable
>>before the operation and then assign it back. Not only would this be
>>clumsy, in some cases it might be tricky and from what I can tell, it would
>>trigger the type check anyway on the whole string. Depending on how often
>>the test is triggered for operations that affect the whole or some slice of
>the
>>string, this could get ugly.
>
>I don't see why this is "clumsy". Again, just type-check MANUALLY in these
>unusual situations. IMO you are making this sound like far more of a problem
>than it really is.
Unusual, my Aunt Agnes! Any kind of string editing, streaming, whatever
will include thousands of indexed accesses to elements in the string.
>>OUCH!!...I, as an Euphoria newby, just stomped on a really ugly artifact of
>>Euphoria and sequences. I see how relational and logical operators produce
>>multiple results, true values rather than logical values. A logical value
>is a
>>temporary item that only exists at the point of comparison unless
>>deliberately and separately preserved. Unless the comparands are also
>>preserved, any such logical "value" loses its relevance as soon as those
>>comparands lose their validity. For validity, where a single logical result
>is
>>expected, Euphoria should sequentially "and" together the truth values
>>for this purpose. This should be valid, for example:
>>
>>type whole_number_set(sequence s)
>> return (s = floor(s))
>>end type
>
>Sorry, but you completely lost me with the "comparands" and "validity"
>stuff. Perhaps this is why I don't understand what the problem is here.
>Euphoria handles its logical operations consistently across all data types.
>This consistency makes the language easier to understand than other
>languages with too many exceptional conditions.
>
>As for your whole_number_set type, you could just write it like this:
>
>type whole_number_set(sequence s)
> return not find(0, (s = floor(s)))
>end type
>
>Or, if you're going to do a lot of this kind of logic and want it to be more
>readable, you can use my generic all_true() function:
>
>function all_true(sequence s)
> return not find(0, s)
>end function
>
>Using this, you can then write your whole_number_set type like this...
>
>type whole_number_set(sequence s)
> return all_true(s = floor(s))
>end type
>
>...which not only works, but also results in very readable code.
Your code is some of the best and cleanest that I see on this list...
without any doubt. Certainly, it is better than my poor efforts. The
purpose of my samples is not to get into a coding contest that I will
most certainly lose, but to make points about language issues that affect
me.
>
>>And in any other case where a single value would be necessary for
>>consistency. Another example would be:
>>
>>sequence s
>>s = "ABCD"
>>if s = floor(s) then ....
>>
>>end if
>
>Again, your proposal does not strike me as being "consistent." This could
>just as easily be accomplished by coding:
>
>if all_true(s = floor(s)) then...
>
>
>>This is a major logical hole in the language.
>
>No, it isn't. If you want it to work differently, it's quite easy to make it
>do so, as I have shown.
>
Basic rules of logic require a different kind of consistency...that of the
statement as it stands. The relational statement
s = floor(s)
has "a" truth value. It also has many interim results. It can be most cleanly
short-circuited to accomplish your loop goals. There is no reason to proceed
past the first false as it infects the whole process. The fact that those
interim results can be stored is a violation of standard binary logic as the
rest of the world knows it, but it is useful. There is no problem that I can see
in allowing both interpretations of the result. The greater question, though,
is still the one asked by the following line. Is the sequence represented by s
equal to the sequence represented by the result of floor(s)? The "if"
statement shows this in it's purest form. "If" statements store no values,
but act on a single logical value that is the result of relational and logical
operators. What we are doing in Euphoria is ignoring the global result in
favor of the interim results.
Everett L.(Rett) Williams
rett at gvtc.com
9. Re: Strings and the like.
- Posted by "Lucius L. Hilley III" <lhilley at CDC.NET>
Dec 08, 1999
-
Last edited Dec 09, 1999
The error in using the below code is that it doesn't check to see if there
is a sequence inside s. And if there is. It fails to check it properly as
well.
Run this example:
type whole_set(sequence s)
return find(0, s = floor(s))
end type
? whole_set({1, 2, 3})
? whole_set({1, 2, {3}})
? whole_set({1, 2, {3.14}})
of course you could try this.
type whole_set(sequence s)
return (compare(repeat(1, length(s)), s = floor(s)) = 1)
end type
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
10. Re: Strings and the like.
Everett Williams wrote:
>Basic rules of logic require a different kind of consistency...that of the
>statement as it stands. The relational statement
>
> s = floor(s)
>
>has "a" truth value.
AH!!! I get it, you mean you want to do this!
if equal(s, floor(s)) then...
equal() always returns 1 (true) or 0 (false), reflecting the overall
equality of the two values. Using equal() instead of = is analogous to using
compare() instead of >, <, >=, <=, !=, or =. The operators act recursively
upon objects, "diving in" to compare them in detail, while the equal() and
compare() functions only deal with the surface value of an object, treating
it as "flat" and merely reflecting their overall equality/inequality. (I
don't know much technical computer terminology, so I hope this is all making
sense!)
>The greater question, though,
>is still the one asked by the following line. Is the sequence represented
by s
>equal to the sequence represented by the result of floor(s)? The "if"
>statement shows this in it's purest form. "If" statements store no values,
>but act on a single logical value that is the result of relational and
logical
>operators. What we are doing in Euphoria is ignoring the global result in
>favor of the interim results.
Ah, NOW I see what you're getting at. You're operating under the assumption
that any expression contained within an "if" statement (and also,
presumably, within a "while" statement as well) should always evaluate to an
atomic TRUE or FALSE value. This is not the case, although I think I can see
where you might be getting the idea that it should be.
Before Euphoria v2.1, expressions in "if" and "while" statements were
treated no differently than expressions used anywhere else in a program.
Thus, you could always expect logical expressions within "if" statements to
execute identically to logical expressions anywhere else (like on a "return"
statement). However, since v2.1 and the implementation of short-circuit
evaluation, expressions are now handled slightly differently when they're in
"if" or "while" statements. While this change made excellent practical sense
(IMHO), it did nevertheless create a precedent for treating "if" and "while"
expressions differently from other expressions. Nevertheless, the current
differences arise only in the handling of the "and"/"or" operators; the
other expression evaluation rules remain the same.
So, although I can see where you *may* have gotten your idea from, I still
do not agree that we need to force all "if" and "while" statements to
evaluate all expressions as simply TRUE or FALSE. For one thing, this could
allow errors to slip through (at least, "if" expressions which evaluate to
sequences are errors in *my* programs...), and we already have equal() and
compare() for higher-level comparisons anyway.
I hope this addresses your concerns more directly.
Hep yadda,
Gabriel Boehme
----------
Relaxation is necessary tension.
Tension is unnecessary tension.
Robert Fripp
----------
11. Re: Strings and the like.
Lucius L. Hilley III wrote:
> The error in using the below code is that it doesn't check to see if
there
>is a sequence inside s. And if there is. It fails to check it properly as
>well.
>
>Run this example:
>
>type whole_set(sequence s)
> return find(0, s = floor(s))
>end type
>
>? whole_set({1, 2, 3})
>? whole_set({1, 2, {3}})
>? whole_set({1, 2, {3.14}})
Oops! Er... <SHEEPISH_MODE=ON>
>of course you could try this.
>
>type whole_set(sequence s)
> return (compare(repeat(1, length(s)), s = floor(s)) = 1)
>end type
Okay, so then my all_true() function should be revised as follows:
function all_true(sequence s)
return equal(s, repeat(1, length(s)))
end function
Thanks for the correction, Lucius!
Hep yadda,
Gabriel Boehme
----------
There is no mistake save one: the failure to learn from a mistake.
Robert Fripp
----------
</SHEEPISH_MODE> (Well, I don't want to leave it on for *too* long...)
12. Re: Strings and the like.
- Posted by Everett Williams <rett at GVTC.COM>
Dec 08, 1999
-
Last edited Dec 09, 1999
On Wed, 8 Dec 1999 19:43:30 -0500, Lucius L. Hilley III <lhilley at CDC.NET>
wrote:
> The error in using the below code is that it doesn't check to see if there
>is a sequence inside s. And if there is. It fails to check it properly as
>well.
>
>Run this example:
>
>type whole_set(sequence s)
> return find(0, s = floor(s))
>end type
>
>? whole_set({1, 2, 3})
>? whole_set({1, 2, {3}})
>? whole_set({1, 2, {3.14}})
>
>of course you could try this.
>
>type whole_set(sequence s)
> return (compare(repeat(1, length(s)), s = floor(s)) = 1)
>end type
>
All examples with either type definitions return 0's and I'm not quite sure
what that means. Your original premise, though, I agree with. The likelyhood
of sub-sequences in a string is fairly low, however, especially if we are
talking about externally supplied data.
Everett L.(Rett) Williams
rett at gvtc.com
13. Re: Strings and the like.
Gabriel Boehme wrote:
>Everett Williams wrote:
>
>>Basic rules of logic require a different kind of consistency...that of the
>>statement as it stands. The relational statement
>>
>> s = floor(s)
>>
>>has "a" truth value.
>
>AH!!! I get it, you mean you want to do this!
>
>if equal(s, floor(s)) then...
>
>equal() always returns 1 (true) or 0 (false), reflecting the overall
>equality of the two values. Using equal() instead of = is analogous to using
>compare() instead of >, <, >=, <=, !=, or =. The operators act recursively
>upon objects, "diving in" to compare them in detail, while the equal() and
>compare() functions only deal with the surface value of an object, treating
>it as "flat" and merely reflecting their overall equality/inequality. (I
>don't know much technical computer terminology, so I hope this is all making
>sense!)
Your definitions fit the language as presented and as I have now finally
picked up on...except for compare. Compare is not a logical function by
the definition of logic that we have. It represents a ternary or triple valued
logic. It can be used with short circuiting to swiftly get to a binary form.
>
>>The greater question, though,
>>is still the one asked by the following line. Is the sequence represented
>by s
>>equal to the sequence represented by the result of floor(s)? The "if"
>>statement shows this in it's purest form. "If" statements store no values,
>>but act on a single logical value that is the result of relational and
>logical
>>operators. What we are doing in Euphoria is ignoring the global result in
>>favor of the interim results.
>
>Ah, NOW I see what you're getting at. You're operating under the assumption
>that any expression contained within an "if" statement (and also,
>presumably, within a "while" statement as well) should always evaluate to an
>atomic TRUE or FALSE value. This is not the case, although I think I can see
>where you might be getting the idea that it should be.
It may not be the case, but it should be.
>Before Euphoria v2.1, expressions in "if" and "while" statements were
>treated no differently than expressions used anywhere else in a program.
>Thus, you could always expect logical expressions within "if" statements to
>execute identically to logical expressions anywhere else (like on a "return"
>statement). However, since v2.1 and the implementation of short-circuit
>evaluation, expressions are now handled slightly differently when they're in
>"if" or "while" statements. While this change made excellent practical sense
>(IMHO), it did nevertheless create a precedent for treating "if" and "while"
>expressions differently from other expressions. Nevertheless, the current
>differences arise only in the handling of the "and"/"or" operators; the
>other expression evaluation rules remain the same.
All true and interesting, but not relevant other than in the fact of the
existence
of special handling. And I am not against short-circuiting. It's convenience
outweighs any minor inconsistency.
>So, although I can see where you *may* have gotten your idea from, I still
>do not agree that we need to force all "if" and "while" statements to
>evaluate all expressions as simply TRUE or FALSE. For one thing, this could
>allow errors to slip through (at least, "if" expressions which evaluate to
>sequences are errors in *my* programs...), and we already have equal() and
>compare() for higher-level comparisons anyway.
"If" expressions need not and should not evaluate to sequences. Consecutive
"and" ing of results solves this problem and provides short-circuiting to boot.
The only other proper result of such a comparison is invalid...apples and
oranges, sequence and atom, etc.
>I hope this addresses your concerns more directly.
At last some meat and potatoes. I NOW see the equal function. Somehow,
I had missed it previously. I still don't see the need for it. The highest level
comparison is the natural one, all others should be handled either implicitly
or by function where functions return values. In the syllogism, logic is
binary. The equal sign means equivalence. It does not deal with values.
It deals with the path to be followed. It is a switch set by the values on
either side of it. There is no problem when a function returns multiple
values in a sequence. That is consistency. The equal sign as assignment
operator deals with values. It creates no inconsistency when it allows
multiple values to be assigned. When multiple values are returned by
an equivalence that "can" have and demands a single value, consistency is
not served. It is not difficult for the interpreter to distinguish situations
where a single value is required. There is no inconsistency or programmatic
problem when comparing any two values or sets of values in a structure as
long as both the structure and the values are equivalent. But, they are
either equal or unequal, true or false, then or else.
Everett L.(Rett) Williams
rett at gvtc.com
14. Re: Strings and the like.
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Everett Williams <rett at GVTC.COM>
> Subject: Re: Strings and the like.
> --------------------------------------------------------------------------
-----
>
> On Wed, 8 Dec 1999 19:43:30 -0500, Lucius L. Hilley III <lhilley at CDC.NET>
wrote:
>
> > The error in using the below code is that it doesn't check to see if
there
> >is a sequence inside s. And if there is. It fails to check it properly
as
> >well.
> >
> >Run this example:
> >
> >type whole_set(sequence s)
> > return find(0, s = floor(s))
> >end type
> >
> >? whole_set({1, 2, 3})
> >? whole_set({1, 2, {3}})
> >? whole_set({1, 2, {3.14}})
> >
> >of course you could try this.
> >
> >type whole_set(sequence s)
> > return (compare(repeat(1, length(s)), s = floor(s)) = 1)
> >end type
> >
>
> All examples with either type definitions return 0's and I'm not quite
sure
> what that means. Your original premise, though, I agree with. The
likelyhood
> of sub-sequences in a string is fairly low, however, especially if we are
> talking about externally supplied data.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
What it means is that I need to pay a lot more attention to what I am
coding
I have apparently made MANY fumbles in the past few days.
NOW....... Since I have tested and corrected the code.
Simply change
floor(s)) = 1)
to
floor(s)) = 0).
OR use the equal() command that was stated earlier.
You will find that only first example is and should be returned TRUE.
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
15. Re: Strings and the like.
On Thu, 09 Dec 1999, Everett Willaims wrote:
> At last some meat and potatoes. I NOW see the equal function. Somehow,
> I had missed it previously. I still don't see the need for it. The highest
> level
> comparison is the natural one, all others should be handled either implicitly
> or by function where functions return values. In the syllogism, logic is
> binary. The equal sign means equivalence. It does not deal with values.
> It deals with the path to be followed. It is a switch set by the values on
> either side of it. There is no problem when a function returns multiple
> values in a sequence. That is consistency. The equal sign as assignment
> operator deals with values. It creates no inconsistency when it allows
> multiple values to be assigned. When multiple values are returned by
> an equivalence that "can" have and demands a single value, consistency is
> not served. It is not difficult for the interpreter to distinguish situations
> where a single value is required. There is no inconsistency or programmatic
> problem when comparing any two values or sets of values in a structure as
> long as both the structure and the values are equivalent. But, they are
> either equal or unequal, true or false, then or else.
Now this is an actual problem, which is a source of confusion in the beginning,
and a continuing aggravation thereafter.
Why, indeed, shouldn't the = within an 'if a = b then...' construct return a
true/false result, computed as follows:
1. if the lengths are different, return false
2. if every byte of a = every byte of b, then return true
else return false
In part, this would help achieve a kind of symmetry within the language:
a = 5
if a = 5 then....
b = "Bill"
if b = "Joe" then.... nope, no need for an error, Bill will never equal Joe
if b = 5 then.... ditto.
For the rarer case when we actually need a byte-by-byte comparison returned -
(somebody suggest an appropriate keyword)
a = "Bart"
b = "Bill"
? coincidence(a,b)
returns: {1,0,0,0}
Regards,
Irv
16. Re: Strings and the like.
Irv Mullins wrote:
>For the rarer case when we actually need a byte-by-byte comparison returned -
>(somebody suggest an appropriate keyword)
>a = "Bart"
>b = "Bill"
>? coincidence(a,b)
>returns: {1,0,0,0}
>
>Regards,
>Irv
Had I reminded you about that really "sharp" sense of humor of yours...
coincidence...as in is it just a coincidence that these two are alike or
coincidence as in do these coincide? Actually, I don't see the need
for a special function. It should be quite easy for the interpreter to
"interpret" when one value or multiple values are needed.
Everett L.(Rett) Williams
rett at gvtc.com
17. Re: Strings and the like.
On Sat, 11 Dec 1999, you wrote:
> Irv Mullins wrote:
>
> >For the rarer case when we actually need a byte-by-byte comparison returned -
> >(somebody suggest an appropriate keyword)
> >a = "Bart"
> >b = "Bill"
> >? coincidence(a,b)
> >returns: {1,0,0,0}
> >
> Actually, I don't see the need
> for a special function. It should be quite easy for the interpreter to
> "interpret" when one value or multiple values are needed.
Of course you're right - the context should indicate whether to return a
sequence or a boolean in most cases. I wonder about this one, however:
a = "Hello"
b = "World"
result = (a = b)
One person would want result to be {0,0,0,1,0} as it is now, while another
might want result to be a true/false flag.
I wonder why, if you define result as an atom or integer, the assignment can't
evaluate the returned sequence {0,0,0,1,0} and cast it as false, since the
interpreter _does_ do a type check, and knows that the sequence cannot be
assigned to an atom?
Further, consider the following:
sequence a,b
type boolean (object x) -- attempt to convert a sequence of 1's and 0's into a
integer flag
flag = 0
for i = 1 to length(x) do
if x[i] != 0 then flag = 1 exit
end if
end for
return flag
end type
boolean result
a = "Hello"
b = "World"
result = (a = b)
? result
Guess what - this fails, because type() can't return anything except a
1 or 0, where 1 means "it passed my check" and 0 means "it failed, so abort"
If we could return a meaninful result from the type() routine, that would open
up the way for us to define as many variable types as we desired, without
breaking any existing code. It would also allow useful error recovery routines
to be written: call a user-written error-handling routine from within the type()
check, which could either allow the user to fix the problem by modifying the
return data to as to be more acceptable, or to exit gracefully.
Irv
18. Re: Strings and the like.
Irv Mullins wrote:
snip...will get to this later
>If we could return a meaninful result from the type() routine, that would open
>up the way for us to define as many variable types as we desired, without
>breaking any existing code. It would also allow useful error recovery routines
>to be written: call a user-written error-handling routine from within the
>type()
>check, which could either allow the user to fix the problem by modifying the
>return data to as to be more acceptable, or to exit gracefully.
>
>Irv
What a beautiful idea for extending the language with absolute minimum
violence. I am not sure without some further checking that this will answer
all possible error situations for which an error routine would be needed. On
the downside, type checking seems to incur some rather draconian
overhead, so this might be a purely practical objection to this construction
where error handling is really needed and type checking would normally be
turned off.
Everett L.(Rett) Williams
rett at gvtc.com
