Round to Even (aka Banker''s Rounding) - The final function

  • dmbaker

    SSCertifiable

    Points: 5025

    Yeah, OK, whatever. Would you please, as I originally asked, elaborate on the apparent contradiction between your statement:

    No datatype decribed as holding absolute precise numbers. Because it would be insane.

    And what Books Online says:

    The decimal data type stores an exact representation of the number; there is no approximation of the stored value.

    I think the disconnect is what you mean by "precise" and what SQL Server means by "exact representation". To me, they mean the same thing, but to you they apparently do not. Would like to understand more why that is and what you base it on (e.g. do you have any citations that I may refer to, as opposed to anecdotal sources).

  • dmbaker

    SSCertifiable

    Points: 5025

    Yeah, OK, whatever. Would you please, as I originally asked, elaborate on the apparent contradiction between your statement:

    No datatype decribed as holding absolute precise numbers. Because it would be insane.

    And what Books Online says:

    The decimal data type stores an exact representation of the number; there is no approximation of the stored value.

    I think the disconnect is what you mean by "precise" and what SQL Server means by "exact representation". To me, they mean the same thing, but to you they apparently do not. Would like to understand more why that is and what you base it on (e.g. do you have any citations that I may refer to, as opposed to anecdotal sources).

  • dmbaker

    SSCertifiable

    Points: 5025

    Yeah, OK, whatever. Would you please, as I originally asked, elaborate on the apparent contradiction between your statement:

    No datatype decribed as holding absolute precise numbers. Because it would be insane.

    And what Books Online says:

    The decimal data type stores an exact representation of the number; there is no approximation of the stored value.

    I think the disconnect is what you mean by "precise" and what SQL Server means by "exact representation". To me, they mean the same thing, but to you they apparently do not. Would like to understand more why that is and what you base it on (e.g. do you have any citations that I may refer to, as opposed to anecdotal sources).

  • Sergiy

    SSC Guru

    Points: 109672

    dmbaker,

    I wish you read it as many times as you posted it.

    an exact representation of the number

    Representation is named exact, not the number.

    I really don't know what they mean by naming it "exact" but it could not be absolute precision, because on the same page they specify the limitation for maximum possible precision.

  • dmbaker

    SSCertifiable

    Points: 5025

    Yeah, sorry for the multiple posts, not sure why that happened. Anyway, I'm still not clear on what you're talking about.

    Is it perhaps that you're playing a semantic game whereby you contend that the number is not its representation? If that's the case then I have to ask "So what? Who really gives a crap?"

    And "who really gives a crap" I think, pretty much sums up this whole argument, doesn't it. ")

  • Sergiy

    SSC Guru

    Points: 109672

    Try to store 1/3 in DECIMAL(12,6) and DECIMAL(12,4)

    Find the difference and see who really gives a crap.

  • David Burrows

    SSC Guru

    Points: 64592

    quote Absolutely precise numbers must have p = infinity.

    Sergiy, please define your interpretation of "precise number"

    Please post a reference that proves this statement.

    quote absolute precision

    Again, please define your interpretation of "absolute precision"

    Far away is close at hand in the images of elsewhere.
    Anon.

  • Sergiy

    SSC Guru

    Points: 109672

    David, have you done your homework with one thirds?

  • David Burrows

    SSC Guru

    Points: 64592

    quote David, have you done your homework with one thirds?

    What has that to do with the questions I asked?

    Are you unable to answer a straightforward question?

    It seems not, as you have not answered any questions asked of you, because you are unable to.

    You only obfuscate but have yet to provide any answers or proof, because again you cannot.

    Far away is close at hand in the images of elsewhere.
    Anon.

  • Sergiy

    SSC Guru

    Points: 109672

    Do your homework first, then join the discussion.

  • David Burrows

    SSC Guru

    Points: 64592

    quote Do your homework first, then join the discussion.

    You answer my questions first

    But I know that you cannot

    Far away is close at hand in the images of elsewhere.
    Anon.

  • Sergiy

    SSC Guru

    Points: 109672

    Repeat it 7 times before you go to bed.

    It will probably meka you feel happy.

    But don't do it on public.

    You are ridiculous enough even without it.

  • dmbaker

    SSCertifiable

    Points: 5025

    Try storing the value "12.5" in a DECIMAL(3, 1) field.

    I already said that I understand perfectly well that there are some numeric values that cannot be stored precisley in SQL Server (and it's not just decimal/floating point values). As such, performing your excercise is not necessary and is irrelevant to my underlying question (that being, how do I resolve what you said with what Books Online says, as Books Online apparently contradicts you).

    Are you saying that some numeric values cannot be stored precisely, or are you saying that *all* numeric values cannot be stored precisely? Maybe if you would be so kind as to answer that question, I'll have a better understanding.

    On a related note, can you tell me why manufacturers of toasters put a setting on their toasters that inevitably chars the toast beyond all hope of recovery? Are there people out there who really like to eat chunks of carbon?

  • Sergiy

    SSC Guru

    Points: 109672

    What is "12.5" value?

    Where you've got it from?

    It's a result of either some measurement or some calculation (of values measured) stored with some precision you cannot change and have to accept.

    So, if "12.5" stored in money datatipe field tells you that the real value is between 12.5000(0) and 12.5000(9).

    Storing it in DECIMAL(3, 1) field you decrease its precision, because money value 12.5123 will end up in exactly the same DECIMAL(3, 1) value as 12.5421 or 12.5252.

    So, you cannot use assumption of "implied zeros" as some "brilliant minds" suggested here.

    > Are you saying that some numeric values cannot be stored precisely, or are you saying that *all* numeric values cannot be stored precisely?

    You probebly did not read the whole topic. Because I answered on this question at least 3 times.

    OK, it's Saturday here, so I can afford to repeat it again and not to force you to go through this.

    There is 1 value which is represented by 12.5000 precisely: it's 12.5000(0).

    There is infinite number of values which are represented by 12.5000 not precisely: > 12.5000(0) and < 12.5001(0).

    The probability of the actual value (which don't have a chance to know) is represented by 12.5000 precisely equals 1/infinity = 0.

    "Probablity = 0" means "it's impossible".

    If it's impossible event when numeric value is stored precisely then all numeric values cannot be stored precisely.

    Any objection to this logic?

  • Lynn Pettis

    SSC Guru

    Points: 442180

    Just one objection Sergiy, 1/infinity <> 0.  It is extremely close, but isn't, so there is a possibility however slight that you can get a precise value.

Viewing 15 posts - 346 through 360 (of 378 total)

You must be logged in to reply to this topic. Login to reply