Re: [If/then and sequences...]
> Hi Hawke',
> I'm not very good at explaining myself am I? Sorry about that 
Also, I
am
> NOT trying to argue a postion or win anybody over to my opinion. I am
trying
> to explain my thoughts on this topic and to gain understanding about the
> reasons behind Robert's design decisions.
ditto :)
just trying to help u glean that understanding...
=]
> > now u have a nice neat list of 0's and 1, in a sequence, showing u the
> > indexes of all the teenagers, and the find() command will neatly locate
> > those indices...what could be simpler?
> Not much indeed. A very neat, simple and elegant construct. Truly a "good
> idea". It just that the symbols "<=" and ">=" mean different things
> depending on what they are applied to. I just thought it might have been a
> better idea to have them mean one thing only in all situations.
aye, im with u in many ways...
in my honest opinion, NO character in a language should perform
more then one duty...
to wit: the = sign meaning BOTH assignment and testing has always
been a thorn in my side...
i like pascal using := for assign and = for testing
no if's ands or buts what is attempting to happen then when u read that
code...
since we use & for sequences i always felt that &= should be used for
comparision testing....
if userinput &= "quit" then abort(1) end if
if x >17 then puts(1,"you can drink/vote/fight in a war") end if
x := x + 19
personally, i think its a lot clearer thusly with those examples...
the first is a comparision of sequences, the second is a comparison
of atoms/integers, and the third is an assignment...the clarity exudes :)
now, of course, &= is append and stuff....
i hate operator overload...shrug
>By all means
> have a built-in function that performs the operation on sequences like
they
> currently do, but use the syntax of a function call rather than the syntax
> of an operator. To the uninitiated, "{10,20,22,12,32,55,34,23,15} >= 13"
> might reasonably be assumed that it returns a sequences of all elements
that
> are greater than or equal to 13, namely {20,22,32,55,34,23,15}. The fact
> that it doesn't is a design decision by Robert. He chose to implement it
as
> a recursive ">=" comparison operator on each element. There's nothing
wrong
> with this sort of operation on sequences, I just wish he had chosen a
> different way to implement it.
ya, ugh, gotta make the big choices to make the big monies like rob does ;)
im with u tho still...in some ways i often need the operators to function
that
way and have to write kludges and hacks to get around it...
but then other times i need to have the operators work like they currently
do at this point... one of those cant win for lose cases???
>BTW, what does Euphoria return with this statement ... "atom1
> & atom2" ? Is it an atom or a sequence?
since the & sign is a sequence operator, it will concat the two atoms...
atom x, y
object z
x = 12
y = 13
z = x & y
in theory z outta be {12,13}
if not, i give up ;)
> > > (unless the operand is used in an IF statement, in which it is
illegal).
> > because there is no way to determine WHICH boolean within the sequence
> > you want to look at...
> > if u SPECIFY which boolean you want to look at within a sequence, by
> > referencing it SPECIFICALLY, then it works just fine...
> Yes, I know what Euphoria does here, but most what most coders mean when
> they write "if A = B" is "does A have the same value as B?" and given that
> the Euphoria can see the values at run-time, the answer is either Yes or
No.
> It doesn't matter if A or B are atom or sequences - the question being
asked
> is simply "are they the same?" not "if these are atoms, are they the same,
> but if these either of these are sequences, build another sequence that
> shows me where they might be different."
well the whole premise of all the other operators would be broken then
too...
u have to see that the unary operators and the binary operators and the
math and the sequence operators all perform the same way...
section 2.2.4 of the refman.doc shows how this works, and u mentioned
reading it in another message...
personally, i find that section quite consistent and logical to the TOUGH
choices rob had to make for certain tricky 'mixed' data operations...
this one inparticular stands out...
x = {5,6,7,{1,1}} + {10,10,20,100}
--x is now {15,16,27,{101,101}}
and also this one
w = {1,2,3} = {1,2,4}
--w is now {1,1,0}
things to ponder on, no? (when u design your compiler with extensions that
is)
> > eg: same as above
> > if ages = 12 then puts(1,"almost a teenager") end if
> > like...DOH, wont work...which person are you talking about???????
> Of course in Euphoria this statement doesn't make sense because its
> ambiguous at best. Does the coder what to know "is any age 12?", "does
every
> age in the set = 12?", "does the entire set consist of one age and is that
> age = 12?". Mixing data types in a comparision (atoms v sequences), I
> suspect, would not normally be a common requirement. In other languages,
> these symbols (=><) are 'comparsion' operators - that is they are used to
> ask questions about how one operand *compares* with another operand -
Robert
> has chosen to make the same symbols mean 'comparision' operators with
atoms
> and mean logical functions with sequences. In other words, in some
> situations they return a boolean result (YES/NO) and in others they return
a
> sequence (of booleans - but still a sequence).
well....
again...
it gives you back what u give it...
atoms beget atoms (booleans)
sequences beget sequences (of booleans)
overall, considering the other choices, i gotta say this choice is the
clearest and cleanest...
> Mmmmm "tri-state boolean", an interesting term - sort of like "dry water",
> "solid vacuum", "military intelligence", "Micro$oft care", ... Sorry - no
> offence - I just love oxymorons. I do understand what you're saying. And
I
> agree with you - 100 percent. I just think that the roles of '=><' and
> 'compare()' should have been reversed - that is compare() should return
the
> sequence of boolean values and =>< should return a single boolean in all
> cases. Look its no big deal. I'm sure Robert has very good reasons for
makin
> g it like this - I just can't see them yet, that's all.
actually, tristate devices are quite common in electronics and boolean logic
math...
a tristate LED glows one color with a certain DC polarity, another
color when u reverse the DC polarity, and a THIRD color if the
polarity is rapidly flipping (AC)
i'd call that tristate boolean myself....
damned handy thing tristate booleans are in fact, for fuzzy logic, circuit
analysis, graphics applications and sine wave analysis
> > saves a wee typing...shrug...no magic here
> Of course to save even more typing and add even more convenience, why not
> use '=' instead of 'equal()'? I'm sure every coder knows what I mean by
...
> while UserAnswer != "quit" do
> ...
> end while
i have yet to encounter a language that would let you do that....
u cannot compare an entire array against another array without
creating complex for loops and testing every element and storing
all the results...
yes, every coder here MIGHT like that construct, but, u would
potentially ruin the dictum of:
atoms beget atoms
sequences beget sequences
a dictum i think we prolly should keep
> because of the traditional meaning of '!=', but in Euphoria I must code
...
> while not equal(UserAnswer, "quit") do
> ...
> end while
> which is 9 more characters
ya more typing compared to != ....sigh
>and less "english-like" when you read it out aloud.
errrrr it reads in english quite nicely...
"while" "not" "equal" is spelled out in plain english...shrug
> > function IsTeenager(sequence data)
> > return (data >=13) and (data<=19)
> > end function
> > what is not simple about that function ????
> > where is the inconsistency???
> > seems quite clear and consistent to me?!?!?!?!
> Well, one interpretation is "This function returns the set of all numbers
> that are common to the subsets 'the set of data that are >= 13' and 'the
set
> of data that are <= 19'", which of course is not true. But, if Robert
had've
> chosen to implement these symbols to perform set operations, this is a
> possible interpretation. What is not obvious, unless one is aware of
> Euphoria's non-traditional use of '<=' and '>=', is that this function
> returns a sequence of booleans that map onto the original sequence to show
> which elements meet the criteria. With your example data above, this would
> return {0,0,0,0,0,0,0,0,1}.
so yer saying u want it to return {15} ???????????????
but i would lose the LOCATION of the teenager in the data that way...
makes DB coding a nightmare thusly
i like knowing the answer to the posed problem AND the location
of the answer, all at once, myself...
>Now, if consistancy were an overriding design
> criteria in Euphoria, the find() function could be used to return a
sequence
> of hits! Such that find(1, IsTeenager({9,14,44,15,21,90}) would return
> {2,4} - the two(!) positions that are teenagers.
here we go!!! :)))
ya find() is almost consistent, but NOT quite right imho
sometimes u need find to return a single value as T/F/location of first
match...
other times u need a find_all function that does as u propose...
i would vote in a heartbeat for rob to code find and match to
work as u suggesst, and i think we have groveled several times
for it to work that way...
> > wanna try writing IsTeenager useing that proposed method???
> > and have it return a list of boolean values that are exactly nested
> > as the passed sequences??????
> Sure...
> function IsTeenager(sequence data)
> return not (compare(compare(data,13) + compare(data,19), 0))
> end function
flip side of the coin now eh?
now u have drastically increased typing, and lowered clarity...
shrug...
its gotta be one way or the other as far as how it works...
i like the dictum the way it stands...overall, its been the easiest...
> compare({10,20,22,12,32,55,34,23,15},13) --> {-1,1,1,-1,1,1,1,1,1}
> compare({10,20,22,12,32,55,34,23,15},19) --> {-1,1,1,-1,1,1,1,1,-1}
> add them together --> {-2,2,2,-2,2,2,2,2,0}
> compare(...,0) --> {-1,1,1,-1,1,1,1,1,0}
> not (...) --> {0,0,0,0,0,0,0,0,1}
you are also performing a LOT more operations now for the same result...
return data>=13 and data<=19
is only three operations, and yours is five...
for large images, large databases, that speed penalty would grow fast
not to nitpic or nuffin... =]
> but I take you're point. A compare() function that returns a "tri-state"
> boolean (gotta love that term)
wish i had coined it but i didnt...
> Okay, so maybe a ge(), gt(), le() and lt() set of sequence
> functions would be handy.
mebbe indeed
frankly, in all the work i have done with EU, i've never ever actually
needed to use compare()=1 or -1
i always use one liner '<' and '>' functions to do my sequence testing
produces much cleaner code imho
and the sort() function as well, is totally blistering fast if u need to
maintain
string tables
> function IsTeenager(sequence data)
> return (ge(data,13) and le(data,19) )
> end function
i could live with that i guess
> > but i ***KNOW*** from just looking at it, without a doubt,
> > what the following code does:
> and that's because you know of Euphoria's non-traditional use of these
> comparision operators.
errrrr no, its cuz i read the manual :)
i found out that atoms beget atoms and sequences beget sequences...
once i found that out, the fat lady sung and it was all over but the
crying...
> Is what I said wrong? Are these symbols allowed with sequences in IF
> statements? Even with "proper referenced indicies", if this references a
> subsequence I'm stuffed.
ya you would be stuffed and fubar'd if u hit a subsequence or a pair
of sequences of unequal length or nesting...
thats why we have nice neat error messages :)
> > function minimum(object a, object b)
> > return a*(a<=b) + b*(b<a)
> > end function
> Kinda looks a bit 'C'-like don't it. At-a-glance-obvious code.
sorta, kinda, mebbe....
but it is at a glance obvious in many ways
> > hope this helps clear things up as to why EU does things the way
> > it does, and further elaborates on Irv's post as to why things
> > function they way they do in EU...
> Well.... not really. It does clear up WHAT Euphoria does, just not WHY.
>What I haven't established is why Robert chose the
>current way of doing this, as opposed to
>any of the hundreds of other ways of achieving the same thing.
sigh, well i tried to answer the why....
overall continuity, ease of reading generally, faster execution, and
easy coding of functions that apply to infintely nested sequences were
the why's i have tried to address...
mebbe i'll try to address the why's, in another way, at a later time
take care--Hawke'
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
|
Not Categorized, Please Help
|
|
