HDTenEightyP/NetNews huggingface dataset:
From: lowry@watson.ibm.com (Andy Lowry)
Subject: Re: Does "400% faster" make sense? (Was: Re: finding 1st one in integer)
Date: Thu, 23 Jul 1992 15:56:36 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<1992Jul22.172337@is.morgan.com>
Organization: IBM T.J. Watson Research Center

In article <1992Jul22.172337@is.morgan.com> berlin@is.morgan.com (Alexander Berlin) writes:
 > In article <LOWRY.92Jul22154231@rotor.watson.ibm.com>, lowry@watson.ibm.com (Andy Lowry) writes:
 > |> In article <1992Jul22.120735@is.morgan.com> berlin@is.morgan.com (Alexander Berlin) writes:
 > |>  > Just a side note: it's impossible to have code that runs 400% faster. Twice
 > |>  > as fast means 50% faster. 100% faster means in NO TIME.
 > |>  > 400% slower makes sense, 400% faster doesn't.
 > |>  > 4 times faster means 75% faster.
 > |> 
 > |> Hmm... did somebody issue an edict on this of which I wasn't aware (or
 > |> was this the edict itself :-)?  I know these are confusing terms that
 > 
 > Must be your math teacher :)

I have another theory.  Perhaps one of your math teachers taught you a
precise definition of these things and then did you the misfortune of
making you think everybody in the world uses it!

 > If some job takes me 100 seconds and you can do it in 25 seconds:
 > I am 300% slower then you are.              (100-25)/25*100 
 > You are 75% faster than I am(not 300)       (100-25)/100*100
 > Your performance is 400% of mine.           (1/25)/(1/100)*100
 > My performance is 25% of yours.             (1/100)/(1/25)*100
 > 
 > And yes, to do the job 75% faster (in 75% less time) you need to increase your 
 > performance by 300%. Vote is not required here.

You're missing my point entirely.  Repeating what I clearly understood
will not make me agree with you.  The fact (sad, perhaps) is that if
you go digging through a bunch of scientific literature, or listen in
on engineering discussions, you will find that these terms are
generally used very loosely, and there simply is no precise definition
that is used consistently, or even close to consistently.  So saying
there is such a definition not only does no good, it makes the
situation worse because it can mislead some people.  Anyone who
believes you will, like you, have false expectations that everybody
will use the terms in a certain way.  It does no good to hold dear to
a mythological view of how the world works.

The meaning of words isn't dictated by dictionaries or glossaries or
textbooks or math teachers.  When common usage contradicts those
sources, common usage wins.  Of course, this implies that if you mount
a campaign to get people to start using your definitions and you do a
good job of it, perhaps down the road the situation will have changed,
and we'll all be better off for having these terms finally nailed down
and used consistently.  But I wouldn't go around claiming that we're
already there!
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598
From: kurt@tc.fluke.COM (Kurt Guntheroth)
Newsgroups: comp.programming
Subject: Re: Advantages/disadvantages of macros/inlining?
Keywords: macro inline
Date: 22 Jul 92 15:46:47 GMT
Article-I.D.: tc.1992Jul22.154647.877
Reply-To: kurt@tc.fluke.COM (Kurt Guntheroth)
Organization: John Fluke Mfg. Co., Inc., Everett, WA

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>On the one hand, computer people are stupidly insisting that the
>compiler can do all, and that human attempts to improve what compilers
>can do are futile.  Now we hear the complaint that the compiler will
>choke on the problem.
>
>On the one hand, we hear that there are lots of registers.  On the
>other hand, we hear that there are not enough for inlining.
>
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399

Well, it's all true.

On a large program, a world-class compiler can do far better than even an
experienced programmer at discovering optimizations.  I would expect the
compiler to win every time on non-toy problems.

On some RISC processors, there are virtually unlimited registers; hundreds
of them.

On the other hand, there are constructs (like inlining) that can make it
more difficult for some compilers to do a good job.  Are these world class
compilers?  Maybe and maybe not, but it doesn't rob the truth from the first
assertion.  The best compilers on the best machines translating appropriate
languages can do far better than a human.

And there are machines with absolutely miserable register sets, and
compilers with code generation strategies optimized for machines with many
registers often suck big-time on machines with few or difficult-to-use
registers.

What this all means is that you have to pick the appropriate tool for the
job, and even an excellent hammer is no good for sawing wood.  Does this
make computer science an oxymoron?  Hardly.
From: pinkas@caraway.intel.com (Israel Pinkas)
Newsgroups: comp.programming
Subject: Re: finding 1st one in integer
Date: 22 Jul 92 01:16:17 GMT
	<1992Jul21.173805.12045@bcrka451.bnr.ca> <14hsk4INNke@rodan.UU.NET>
	<1992Jul21.165726@is.morgan.com>
Organization: Software Technologies, INTeL Corporation, Santa Clara, CA
In-reply-to: berlin@is.morgan.com's message of 21 Jul 92 20:57:26 GMT

berlin@is.morgan.com (Alexander Berlin) writes:

   Vadim, you are assuming Big Endian, aren't you?
   The original article asked for PORTABLE code. ">>=" depends on byte order.


>>= is very portable.  Remeber:

l>>=i is equivalent to l=l>>i.  This effectively divides l by 2^i.  Very
portable.

-Israel
--
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.
From: nickel@cs.tu-berlin.de (Juergen Nickelsen)
Subject: cleanup on exit (Was Re: Chasing memory leaks: tools, procedures?)
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
	<1992Jul18.203518.14496@murdoch.acc.Virginia.EDU>
	<1992Jul19.160323.8820@organpipe.uug.arizona.edu>
	<NICKEL.92Jul19184631@desaster.cs.tu-berlin.de>
	<9220400.530@mulga.cs.mu.OZ.AU>
Date: Wed, 22 Jul 1992 19:02:34 GMT

In article <9220400.530@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus James HENDERSON) writes:

> nickel@cs.tu-berlin.de (Juergen Nickelsen) writes:
[...]
> >To make this more useful, must_alloc() should also call some
> >cleanup-function. For some application it is a must to have control of
> >their termination, e.g. to remove temporary files, re-rename
> >temporarily renamed files etc.
> 
> Why not just use at_exit() to install an error handler if necessary?

I would really *like* to use it, but it's not portable. SunOS has a
function

    int on_exit(procp, arg)

, but the manual page says

    NOTES
	 This call is specific to  the  SunOS  operating  system  and
	 should not be used if portability is a concern.

POSIX doesn't define something like this, SysV.3, BSD 4.3, and Ultrix
don't seem to have somthing like that.

"Historical" Note:
With VAX C on VMS, at_exit() (or atexit() ?) was fun, since the
installed exit handler was executed even when the program had been
interrupted and the user started another one. (The program image was
still considered running then, if it hadn't been explicitely removed
with "stop".) Caused lots of user confusion.

--
Juergen Nickelsen
Newsgroups: comp.programming
From: jeroen@cs.ruu.nl (Jeroen Fokker)
Subject: Re: Calculating a cube root
Date: Tue, 21 Jul 1992 08:50:23 GMT
Organization: Utrecht University, Dept. of Computer Science

dave@cs.arizona.edu (Dave Schaumann) had some remarks about my
cuberoot-program.

>> A faster function [than exp(log(x)/3.0)] 
>> uses Newton's method, using iteration

> I don't think so [...].  Library routines like exp(), log(), and pow()
> are generally defined using a polynomial expansion, which
> require perhaps 5 floating point multiplies, 

This is correct. On my computer, iteration using Newton's method 
is about 5 times slower than using the exp/log method.
However, I believe that it is slightly unfair to compare C-functions
with higly-optimized library routines.

>> #define EPSILON 0.00001

>  which of course limits the accuracy quite severly.

The nice thing about #defined constants is that you can
adapt them to your needs. 


About the approximate-equal-to-routine he comments:

> There's also another advantage to using library routines.  
> Presumably, someone was paid to make sure they are correct.

>> return( a-b<EPSILON && b-a<EPSILON );

> This expression will always yield 0.

Nice try for an insult, but not justified.
Here is the "correctness proof":

     a lies within EPS from b  <==>
     a<b+EPS && a>b-EPS        <==>
     a<b+EPS && -a<EPS-b       <==>
     a-b<EPS && b-a<EPS

Speaking of correctness: try and calculate cubert(0.0)
using exp(log(x)/3.0).

--
Jeroen Fokker                                 |  jeroen@cs.ruu.nl
dept.of Computer Science, Utrecht University  |  tel.+31-30-534129
PObox 80089, 3508TB Utrecht, the Netherlands  |  fax.+31-30-513791
From: vladimir@Eng.Sun.COM (Vladimir Ivanovic)
Newsgroups: comp.programming
Subject: Re: One Pass Assemblers
Date: 19 Jul 92 18:59:39 GMT
	<Dyw7NB1w164w@naos.actrix.gen.nz>
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ronnie
In-reply-to: ewen@naos.actrix.gen.nz's message of Sun, 19 Jul 92 16:02:12   Y

>> Can't say as I do, but I am curious as to why you would want a one-pass
>> assembler.
>>
> Speed is the usual reason.  If the assembler needs to make only one pass
> then it doesn't have to waste time reading in the source a couple of
> times, and generally abusing the disk.

If the file were read into memory (mmap'ed), doesn't that obviate the need
to go to the disk multiple times?

On my system, /tmp is memory, backed by disk (see the manpage for tmpfs) so
that *all* my intermediate files from compilations are memory resident.

-- Vladimir
--
Vladimir G. Ivanovic                            Sun Microsystems, Inc
(415) 336-2315                                  MTV12-33
vladimir@Eng.Sun.COM                            2550 Garcia Ave.
{decwrl,hplabs,ucbvax}!sun!Eng!vladimir         Mountain View, CA 94043-1100
                         Disclaimer: I speak for myself.
From: norman@a.cs.okstate.edu (Norman Graham)
Newsgroups: comp.programming
Subject: Re: 400% makes sense
Date: 28 Jul 92 23:57:24 GMT
Organization: Oklahoma State University

From article <w2mmnc-.pdh@netcom.com>, by pdh@netcom.com (Phil Howard ):
> norman@a.cs.okstate.edu (Norman Graham) writes:
> 
>>Not exactly. 400% is a nonsensical term. Percent (%) means 'per hundred' or
>>'of each hundred', and thus is only meaningful for values between 0 and
>>100 (inclusive). Percent is best used for absolute measurements, rather
>>than relative comparisons such as the above example.
> 
> I do not see where any limit must exist.  Dividing 400 by 100 leaves 4.
> It's not a negative number.  It's not an imaginary number.  It's 4.

If you view percent as simply meaning 'divide by 100', then you're
correct of course. But then, if that's all percent means, then what's
the point of using it? Does 400% somehow communicate more effectively
than 4?

The point that I was trying to make is that, for many people, percent
means more than just 'divide by 100': It also carries the idea of 
'part of the whole'. IMHO, if you're not talking about some part of 
a whole (i.e. 0% to 100%) then there is nothing to be gained from
using the percent notation.

Of course, this is just my personal percent usage rule. It's obvious
from literature and advertisements that many people either disagree
with this usage or haven't thought much about it. My experience is
that communication is enhanced when the use of percent is restricted
to numbers describing parts of some whole.
 
>>The use of percent in relative comparisons naturally leads to subtle
>>misunderstandings.  Thus its best to say something like "machine A
>>(at 20 M op/sec) is four times as fast as machine B (at 5 M op/sec)."
> 
> I agree that is better to say.  But I think the problem is that there
> are differences in the understandings of the semantics of the WORDS
> (i.e. we all work the formulas the same way, but just come up with
> different fomulas).
> 
> (5 M op/sec vs 4 M op/sec)
> "machine A is 20% slower than machine B"
> "machine A is 80% of the speed of machine B"
> 
> Wording makes a difference.

Agreed.

BTW, this is getting pretty far from comp.programming territory,
so I'll let this be my last comment on the subject.
-- 
Norman Graham
<norman@a.cs.okstate.edu>                 Standard Disclaimer Applies
Newsgroups: comp.programming
From: norman@a.cs.okstate.edu (Norman Graham)
Subject: Re: 400% makes sense
Organization: Oklahoma State University
Date: Sat, 25 Jul 92 21:57:13 GMT

From article <RJBODKIN.92Jul25162546@laennec.lcs.mit.edu>, by rjbodkin@theory.lcs.mit.edu (Ronald Bodkin):
> In article <1992Jul25.184259.20358@a.cs.okstate.edu> norman@a.cs.okstate.edu (Norman Graham) writes:
>    Not exactly. 400% is a nonsensical term. Percent (%) means 'per hundred' or
>    'of each hundred', and thus is only meaningful for values between 0 and
>    100 (inclusive). Percent is best used for absolute measurements, rather
>    than relative comparisons such as the above example.
> 
> 	Rational numbers are defined for values greater than one.
> This "argument" is as silly as saying 7/3 makes no sense, because it
> is seven thirds, and you cannot have more than three thirds of a
> 		Ron

If you view percent as a mathematical operator meaning 'divide the previous
number by 100', then sure, your point stands. But, it's been my experience
that people tend to reserve percent to mean 'some part of a whole', and
when you deviate from that use, people can sometimes become confused.

Communication was the point of my note, and in the interest of 
communication I've found it helpful to reserve percent only for those
cases when I'm describing some part of a whole. Come now, is communication
really enhanced by saying "A is 400% the speed of B", rather than just
"A is 4 times the speed of B"? Some people I know would be confused by
the first statement.
-- 
Norman Graham
<norman@a.cs.okstate.edu>                 Standard Disclaimer Applies
Newsgroups: comp.programming
From: ressler@cs.cornell.edu (Gene Ressler)
Subject: Re: finding 1st one in integer
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Wed, 22 Jul 1992 19:56:26 GMT

In article <1992Jul22.120735@is.morgan.com> berlin@is.morgan.com (Alexander Berlin) writes:
>In article <1992Jul22.152827.14267@cs.cornell.edu>, ressler@cs.cornell.edu (Gene Ressler) writes:
>
>|> ....
>|> benchmark code (chris torek?), this runs about 400% faster than the 37 element
>|> ....
>
>Just a side note: it's impossible to have code that runs 400% faster. 

Of course.  Silly mistake.  I meant 4 times as fast.
Gene
From: bruce@supr.scm.liv.ac.uk (Bruce Stephens)
Newsgroups: comp.programming
Subject: Re: MAZE
Date: 29 Jul 92 10:48:54 GMT
Organization: Centre for Mathematical Software Research, Univ. Liverpool, UK
Nntp-Posting-User: bruce

>>>>> On 23 Jul 92 18:11:57 GMT, dfs@doe.carleton.ca (David F. Skoll) said:

> In <1992Jul23.145751.29068@wuecl.wustl.edu> ppc1@cec2.wustl.edu (Peter
> Pui Tak Chiu) writes:

>>I am trying to write a 3D maze in which the player can move around as if
>>he/she is "inside" the maze.  (something like the adventure game ULTIMA
>>when you are inside a dungeon...)

> The basic idea is to draw a single cell's view, shrink the size
> down, and keep drawing successive cells until a wall blocks the
> view.  You can also terminate after a fixed number of cells to limit
> the distance a player can see.

That works.  For sensible mazes it looks fine, and worked quite fast
enough in Basic on a BBC Micro when I wrote one ages ago.  In fact, if
you have a really good library you can probably find a listing of some
version in one of the hobby magazines, because that's where I got the
idea from.

What it doesn't work on is mazes with open areas in them, so make sure
you use a sensible maze generator that creates passages one-grid wide.

Bruce
Newsgroups: comp.programming
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: finding 1st one in integer
Reply-To: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Organization: Bell-Northern Research, Ottawa, Canada
Date: Tue, 21 Jul 1992 17:38:05 GMT

In article <Brqu3F.1J4@undergrad.math.waterloo.edu>,
amichail@cayley.waterloo.edu (Amir Michail) writes:
> I need a very efficient way of finding the first bit set ( doesn't matter
> which side ) in a 32 bit integer. 
> 
> For example:
> 
>   binary  -> position
>   	1 -> 0
>     10000 -> 4
>      1000 -> 3
> 
> One can make the simplifying assumption that only 1 bit will be
> set in the 32 bit integer (if that helps).
> 
> Amir
> 
> P.S.  Please do not tell me to use a large lookup table.  I know about that.
>       I also know that the 68020 and 80386 have instructions to do
this; I want
>       portable C code though.

Check a byte at a time for non-zero (being careful not to assume byte
ordering or behaviour of shifting signed values if you want to be portable).

Either use a lookup table of 256 values, or split the byte into two
so that your table is only 16 long.

If you often have numbers with the 2 lowest bytes clear, you might want to
start by checking 2-byte values against 0.

Stuart

: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.programming
From: lowry@watson.ibm.com (Andy Lowry)
Subject: Does "400% faster" make sense? (Was: Re: finding 1st one in integer)
Date: Wed, 22 Jul 1992 20:42:31 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

In article <1992Jul22.120735@is.morgan.com> berlin@is.morgan.com (Alexander Berlin) writes:
 > Just a side note: it's impossible to have code that runs 400% faster. Twice
 > as fast means 50% faster. 100% faster means in NO TIME.
 > 400% slower makes sense, 400% faster doesn't.
 > 4 times faster means 75% faster.

Hmm... did somebody issue an edict on this of which I wasn't aware (or
was this the edict itself :-)?  I know these are confusing terms that
are vague because they are used differently by different people, but I
can make a perfectly good case for saying that "400% faster" should
mean "at 400% the speed," i.e. "at four times the speed."  Or maybe
I'd prefer to say that "400% faster" means "at a speed that is 400%
greater" which means "at five times the speed."  This is also in line
with what I would expect a "400% speedup" to mean.  I certainly would
think it confusing if making something 75% faster were to result in a
300% speedup!

Your rule appears to be that if measured time is cut to x% of the
original, then you call it "(100-x)% faster" if x < 100 and (I'm
guessing) "x% slower" if x > 100.  But "fast" is a word that I
associate with speed, not time, so even if the world were to vote on
what these phrases were supposed to mean, I don't think I'd vote for
your definitions!

And if the world doesn't vote and start using consistent definitions,
then your side note is pretty much without value (or perhaps of
negative value because of its misleading statements), since it doesn't
help me one iota in reading literature that makes use of such phrases.
I still have to rely on either a precise definition made up front by
the author, or on being able to deduce the intended meaning from
context, because I certainly can't assume that the author is following
your conventions!

It's much better to point out the inherent vagueness in these terms as
they are used in practice, and encourage people to include precise
definitions when needed, than to claim that there's some universally
accepted precise definition when there isn't.
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.programming
From: spuler@coral.cs.jcu.edu.au (David Spuler)
Subject: Re: Finding the first bit set
Organization: James Cook University
Date: 23 Jul 92 05:24:57 GMT

In <1992Jul22.160034.7162@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:

How about

int FirstBit(unsigned long L) {
	return L - (L & (L-1));
}

since L&(L-1) removes the first bit (try it!) then L - (L&(L-1) or L^(L&(L-1)
should yield only that bit. It's so neat it could be made a macro.
--
David Spuler, James Cook University of North Queensland, Australia
Author of "Comprehensive C", Prentice-Hall, 1992, pp416, ISBN  0-13-156514-1
INTRO TOPICS: types, operators, structures, strings, fns, ptrs, files etc etc
ADVANCED TOPICS: efficiency, debugging, style, portability, large programs
Newsgroups: comp.programming
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Chasing memory leaks: tools, procedures?
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 21 Jul 1992 14:27:02 GMT

nickel@cs.tu-berlin.de (Juergen Nickelsen) writes:

>dave@cs.arizona.edu (Dave Schaumann) writes:
>> must_alloc() is just a function that calls malloc and aborts if malloc
>> returns NULL.
>
>To make this more useful, must_alloc() should also call some
>cleanup-function. For some application it is a must to have control of
>their termination, e.g. to remove temporary files, re-rename
>temporarily renamed files etc.

Why not just use at_exit() to install an error handler if necessary?

--
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.programming
From: gupw@uniwa.uwa.edu.au (Paul Wagland)
Subject: Re: Is 2.0 PM very different from 1.x PM?
Organization: University of Western Australia
Date: Tue, 28 Jul 1992 01:06:53 GMT

dave@cs.arizona.edu (Dave Schaumann) writes:

>In article <1992Jul27.014642.4971@uniwa.uwa.edu.au>, gupw@uniwa (Paul Wagland) writes:
>>Is programming for PM under v2.0 much different than under v1.x?
>What's `PM'?

>>The reason I wish to know is that the only PM programming books around
>>here are for OS/2 v1.x.
>Oh.  Some ibm thing, huh?  Maybe you could try asking in an ibm group?

OK Sorry Guys.  I accidently posted this to the wrong newsgroup.

Sorry!

Paul
-- 
Paul Wagland            | These opinions are mine and no-one elses
gupw@uniwa.uwa.edu.au   | I still don't like Microsoft, even after using
------------------------+  their products. :-)
Newsgroups: comp.programming
From: alex@bilver.uucp (Alex Matulich)
Subject: Re: finding 1st one in integer
Organization: W. J. Vermillion - Winter Park, FL
Date: Fri, 24 Jul 1992 03:01:58 GMT

amichail@cayley.waterloo.edu (Amir Michail) writes:
>I need a very efficient way of finding the first bit set ( doesn't matter
>which side ) in a 32 bit integer. 

How about this one?  It finds the position of the high-order bit, and it
works even if more than 1 bit is set.

int firstbit(int n)
{
   int i = 0, j;
   while ( (j = n << 1) > n) {
      ++i;
      n = j;
   }
return i;
}

This function will return a number that assumes bit 0 is the high-order bit.

-- 
 _ |__  Alex Matulich
 /(+__>  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
//| \     UUCP:  alex@bilver.uucp   {peora|ge-dab|uunet!tous}!bilver!alex
///__)     Internet:  alex@bilver.oau.org | alex%bilver@peora.sdc.ccur.com
Newsgroups: comp.programming
From: tsmaster@media.mit.edu (David LeCompte)
Subject: Re: greedy algorithms
Organization: MIT Media Laboratory
Date: Fri, 31 Jul 1992 14:47:22 GMT

In article <rosauer.712517016@ferrari> rosauer@fzi.de (Bernd Rosauer) writes:
>Does anyone know a textbook or survey paper about greedy algorithms?
You might try "Algorithms" by C..., Leiserson, and Rivest, MIT Press.
It was the text for my algorithms class, and I think that it has a
chapter or more on greedy algorithms.

As it was the text, I referred to it as "the algorithms text" or "the
CLR text", so my memory of the title may be as faulty as my memory of
the first author's name. 

				Hope this is of use.
-- 
---------------------
ObSig