June 26, 2007 at 9:39 pm
I provided perfect proof:
the way TR rounds 0.1250.
As noted earlier, it's time to put up or shut up.
Probably for you - it's right time.
_____________
Code for TallyGenerator
June 26, 2007 at 9:50 pm
Um... I gotta ask... why wouldn't 0.3333 represent all of the numbers from 0.3332(5) to 0.3333(4) in the TR model?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2007 at 10:06 pm
Because that's the agreement accepted by mathematicians. Some would name it "Standard".
Result of any operation is getting represented by closest lower decimal number.
You may check it with
SELECT 2./3, 8./11, 10./11, etc.
Value 0.3332(5) would end up in money representation 0.3332.
BUT!
Pay attention. There should not any rounding be involved!
Even implicit one - your favourite...
_____________
Code for TallyGenerator
June 26, 2007 at 10:12 pm
Got another answer:
Because midnight is 12:00am
and noon is 12:00pm
If you can explain for yourself why midday belongs to pm then you not gonna have questions why 0.3333 represents 0.3333(0)..0.3333(9) and why .5 must be rounded up.
_____________
Code for TallyGenerator
June 26, 2007 at 11:02 pm
Again, prove that TR sees the precise number 0.3333 as all values between 0.3333(0) and 0.3333(9). That's all you need to do.
June 26, 2007 at 11:16 pm
TR sees any number X.XXXX as any value between X.XXXX(0) and X.XXXX(9)
Proof - it rounds "half way" numbers up.
Logic of such rounding is this:
X.XX50 value represents values X.XX50(0) .. X.XX50(9) which are always > X.XX50(0).
That's why for TR there are no "half way" numbers, any number belongs to one of two halves.
And .5 belongs to second half, exactly the same way as noon belongs to pm.
No any magic involved.
For those who understands math.
_____________
Code for TallyGenerator
June 27, 2007 at 6:06 am
Are you serious? While we've come to realize that when you say "I conclude", you really mean "I hope I'm right, but am likely wrong", I think ascribing a definition of "something for which I have zero evidence" to the word "proof" is a stretch, even for you.
Again, prove that TR sees the precise number 0.3333 as all values between 0.3333(0) and 0.3333(9).
June 27, 2007 at 6:15 am
<<exactly the same way as noon belongs to pm.>>
Absolute rubbish as usual.
http://www.worldtimezone.com/wtz-names/wtz-am-pm.html
Do try to get something right.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 27, 2007 at 1:56 pm
Chris, look at your watches at noon.
What do you see?
Now, who is the rubbish - you or your watches?
Or the definitions on the cite?
12am and 12pm notation exist much longer than rubbish definitions from that cite and, belive me, will exist long after they will rewrite the difinitions on this web cite.
_____________
Code for TallyGenerator
June 27, 2007 at 2:04 pm
Translation:
"No! No!!! I not gonna admit!"
What else you need to prove after I proved that TR is based on assumption that trailing digits beyond precision are anything but "all zeros"?
_____________
Code for TallyGenerator
June 27, 2007 at 3:20 pm
X.XX50 value represents values X.XX50(0) .. X.XX50(9) |
Sergiy,
Surely if TR is to produce a value X.XX50 then the range should be X.XX50(0) .. X.XX504(9)
as X.XX505(0) .. X.XX50(9) will result in X.XX51
Far away is close at hand in the images of elsewhere.
Anon.
June 27, 2007 at 3:34 pm
David,
Still waiting for you to show the way you can supply 1/3 to the function.
Concentrate, please. Don't be distracted.
_____________
Code for TallyGenerator
June 27, 2007 at 3:54 pm
I thought we had settled this, that as you can't.
Because 1/3 = 0 as you stated before, it is an expression, that is evaluated to (int) 1 / (int) 3
to get other than an int result, it is normal (I believe but probably wrong) to ask for 1/3 to n decimal places (with all the error, accuracy, rounding, deviation problems that it entails)
even if you pass 1.0 / 3.0 it will be evaluated as (float) 1 / (float) 3
btw still can seem to get the answer you want on 1/3 stored in computer, my crystal ball is just not playing fair
as far as I know the only way to accurately define 1/3 other than a fraction is to store the decimal,fractional and period to define it, but I know of no known datatype or structure that exists for that.
Will you tell me the answer and put me out of my misery
And will you answer my storekeeper question, please
Far away is close at hand in the images of elsewhere.
Anon.
June 27, 2007 at 4:12 pm
as far as I know the only way to accurately define 1/3 other than a fraction is to store the decimal,fractional and period to define it, but I know of no known datatype or structure that exists for that.
Me either.
But it was your statement that decimal 0.3333 is not equal to 1/3 and cannot represent 1/3 for BR purposes.
So, what is your way to supply 1/3 to BR function?
> And will you answer my storekeeper question, please
If you would listen to your math teacher in school you would know that correct rounding to Nth digit requires (N+1)th digit to be available and precise.
So, your example just illustrates your ignorance (take a note - I did not say stupidity), and nothing else.
Sorry.
_____________
Code for TallyGenerator
June 27, 2007 at 4:13 pm
In other words, you have no proof, correct? The closest you've come to meeting any definition of proof that might be tangentially related to anything you've brought forward so far is definition 6.
Again, prove that TR sees the precise number 0.3333 as all values between 0.3333(0) and 0.3333(9). You think we'll just believe you all of a sudden if you continue to not back up anything you say? Let's see some proof.
Viewing 15 posts - 226 through 240 (of 378 total)
You must be logged in to reply to this topic. Login to reply