OpenEuphoria

Re: Minimum & Maximum

• Posted by Hawke <mdeland at NWINFO.NET> Sep 25, 1998
• 519 views

jiri babor wrote:
> >Michael Palffy wrote:
> >How's this..
> >function max(sequence a, sequence b)
>Now we are really cooking, echos of c.r.white...
>Nice and short, and it works! (It does not happen
>all that often on this list )
very sweet :)
makes me wonder how you and carl (as per his post)
come up with these darned line... i racked my poor wittle
head trying to come up with that line :)


>But (there is almost always a 'but' lurking somewhere in everything!)
>these function have no explicit type checking that all the previous
>suggestions had.
to me, bad form... bad bad bad form...

>So it gives me a chance to ask a question I wanted toask anyway:
>do we really need those explicit checks? And I think, we
>do not!
actually, yes, in this case (and in perhaps other cases--see below)

>The compiler itself will eventually tell us, anyway, if we try
>something stupid, illegal. The error message may be a bit more cryptic
>('an attempt to subscribe an atom', or whatever...), but we will not
>get away with it.
you are correct here. the compiler will look at those things.
but, think of david and things he has mentioned about the
compiler's "error messages" and how it behaves when an error occurs.

it *DIES*. *BAM*.

the program aborts in a poor manner.  you lose your data, and
the possibility to see what values caused the problem.

and if it is a program distributed to the masses, you *CANNOT*
distribute with the registered version, and if that program
is over 300lines then the end user cannot give you any debug info.

so, i say, intercept before the crash, and my Error() routine
accepts not only a message to print, but the *data* that caused
the problem, and it prints the *full* value of that data,
which even ex.err does not capture (it truncates long sequences).

this data can then be saved to a file or printed by the
Error() routine. the end user is happy too, cuz their data
is preserved...

to me, leaving it to the compiler is just not an option any
longer, and that philosophy is also "bad form" in the first place.

>And these superfluous checks always slow things down,
>sometimes considerably!
what is the price to pay for safe data?
what is the price to pay to prevent crashing?
and
what is the priced to pay for end-user peace of mind?

> Now a treat for the benchmark freaks. I stripped my minimum function
> down to
> function minimum(object a, object b)
> to make it more directly comparable with Mike's.
                                      Mike's          Mine
==========================================================
> min(5,3)                             1.14           0.91
                won by ~80%
> min({5,3,1},{-5,2,6})                6.69           6.89
                call this tied
> min({5,3,{4,5},1},{-5,2,{-7,7},6})  11.82          13.27
                lost by ~10%
in most cases i would go with jiri's, as we generally use
min/max on lists of atoms...
but for this particular library, i need sequence speed...
very very close race tho, kudos to jiri,carl and mike.

thanks one and all--Hawke'

p.s.
1    if atom(a) then            --jne 4 (gotta do at least this)
2        if b<a then a=b end if --jmp 8 after 'end if'
3    else
4        for i=1 to length(a) do
5            a[i]=minimum(a[i],b[i])
6        end for
7    end if
8    return a
if you wanna speed yours up, by maybe enough to get you
back in the running with sequences... its a small
improvement, but it could save up to like 20-30
clockticks per loop...
(lets say it saves 10 ticks, over a million iterations,
thats 10 million clockticks... 25MHZ machine = halfsecond)
itsa trick from the days when computers were a bit
slower and you would notice these things
try:
1   if atom(a) then             --jne 4 (gotta do at least this)
2      if b<a then a=b end if   --
3      return a                 --no jmp here, we exit
4   else
5      for...endfor
6   end if
7   return a
what this does (i think) is save a jmp statement to the
"return a" after the "end if" at the end of the function...
rule is: get out while the getting is good...
try rerunning the benchmarks with/without this in place...
try with 10,000,000 iterations...
lemme know???

pps... i checked my borland turbo assembler documentation and
it says that a jmp can use between 3 and 45 ticks on a 486...
it depends (for 1) on how much code is between the if and the
end if... some long if/endif blocks might see real performance
boosts, at least the way i read it...