Well, I was demonstrating the initial case. Projections and further proof are
left as an exercise for the reader. 8-)
-Original Message-
From: "Phil Smith III" <[EMAIL PROTECTED]>
To: "IBMVM@LISTSERV.UARK.EDU"
Sent: 5/3/07 4:38 AM
Subject: Re: QUERY CAPABI
David Boyes <[EMAIL PROTECTED]> wrote:
> After all, 1+1=3 for sufficiently large values of 1.
Hmm, the way we learned it was "2+2=5 for sufficiently large values of 2"...I
guess we were studying higher math!!
...phsiii
--- David Boyes <[EMAIL PROTECTED]> wrote:
> > I never claimed to be a math whiz, but wouldn't ie
> be impossible to
> reach
> > zero my dividing any number repeately by 50%?
> Granted, you can end up
> > with a lot of numbers to the right of the decimal
> point, and the
> result
> > gets ahrd to
z/VM Operating System"
05/02/2007 12:06 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: QUERY CAPABILITY question
Call us cave men and see what it gets you!!!
Regards,
Richard Schuh
-Original Message-
From: The IBM
SERV.UARK.EDU
Subject: Re: [IBMVM] QUERY CAPABILITY question
In all seriousness, lower=faster is no more a restricting factor than =
higher=faster. In either methodology you're going to run out of bits a=
nd whether it's at the high end (overflow) or the low end (underflow) is
irrelevant.
> Now you guys cut that out! You know what I meant. Eventually
everything
> turns to a value of 1 since you would never willingly round a capacity
> number *down*.
Nonsense! You just aren't adjusting the scales of the measurement
correctly.
See "How to Lie with Statistics" for a lesson in data
In all seriousness, lower=faster is no more a restricting factor than
higher=faster. In either methodology you're going to run out of bits a
nd
whether it's at the high end (overflow) or the low end (underflow) is
irrelevant. When the condition approaches you either need to add more
bits (t
Call us cave men and see what it gets you!!!
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Wednesday, May 02, 2007 9:50 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: QUERY CAPABILITY question
On
On Wednesday, 05/02/2007 at 09:02 MST, "Schuh, Richard" <[EMAIL PROTECTED]>
wrote:
> However, zero will be a limit --- and you need to multiply by 50%
> (expressed as .5) to divide by 2. If you divide by .5, the result will
> be an ever increasing value. (10 / .5 = 100 / 5 = 20)
Now you guys cut
PROTECTED] On
Behalf Of David Boyes
Sent: Wednesday, May 02, 2007 7:33 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: QUERY CAPABILITY question
> I never claimed to be a math whiz, but wouldn't ie be impossible to
reach
> zero my dividing any number repeately by 50%? Granted, you can end
On: Tue, May 01, 2007 at 08:18:00PM -0500,Mike Walter Wrote:
} I never claimed to be a math whiz, but wouldn't ie be impossible to reach
zero my dividing any number repeately by 50%? Granted, you can end up with a
lot of numbers to the right of the decimal point, and the result gets ahrd to
un
> I never claimed to be a math whiz, but wouldn't ie be impossible to
reach
> zero my dividing any number repeately by 50%? Granted, you can end up
> with a lot of numbers to the right of the decimal point, and the
result
> gets ahrd to understand - worse: is counter-intuitive.
Zeno's Paradox. To
D]
Sent: 05/01/2007 04:57 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: QUERY CAPABILITY question
On Tuesday, 05/01/2007 at 03:03 EST, Brian Nielsen
<[EMAIL PROTECTED]> wrote:
> The z/Architecture Principles of Operations describes the information
> returned by the STSI instruction from which the abo
On Tuesday, 05/01/2007 at 03:03 EST, Brian Nielsen
<[EMAIL PROTECTED]> wrote:
> The z/Architecture Principles of Operations describes the information
> returned by the STSI instruction from which the above values are
> obtained. In particular it states (pg 10-117) that "a lower value
> indicates
On a z/890 I'm running z/VM 5.2 in an LPAR with 2 dedicated IFL's. There
are also 2 CP's (capacity setting 260) running multiple z/OS LPARs.
From z/VM:
q capability
CAPABILITY: PRIMARY 4224 SECONDARY 2416
Ready; T=0.01/0.01 13:20:03
The z/Architecture Principles of Operations describes th
15 matches
Mail list logo
