Forum Replies Created

Viewing 15 posts - 61 through 75 (of 223 total)

  • Reply To: Float Issues

    Jeff Moden wrote:

    Opinion noted... However, I can more easily do things with DATETIME that can only be dreamed of with DATETIME2.  Even Microsoft realized their mistake but, instead of fixing it,...

  • Reply To: Float Issues

    Possibly, but then again, we all know how much accountants love guesswork, right 😀

    Anyway, I could easily dig up examples from the EU where the conversion rates between the EURO...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    I think there are accounting standads that say 4 d.p. should be used for money calculations.

    Well, that would depend on your country of operation, wouldn't it?

  • Reply To: Float Issues

    roger.plowman wrote:

    Actually, MONEY is useful if only for documentation purposes. You could use decimal but why would you want to? Being an integer makes the type faster than decimal.

    DATETIME does...

  • Reply To: Float Issues

    Yes, because MONEY is a precise data type with 4 decimal places. It's implemented as a 64-bit integer, scaled down by 10000. That and DATETIME must be the two lamest...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    I think the extra decimal digit is because if you multiply a number with 2 decimal places by a number with 1 decimal place, the result can have 3...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    Yes, a strange result. Try this:

    DECLARE @tmp1 FLOAT = 0.289;
    SELECT CONVERT(decimal(38,36),ROUND(@tmp1, 2)*100),
    CONVERT(decimal(38,36),ROUND(@tmp1, 2))*100

    Well, that's no more strange than any...

  • Reply To: Float Issues

    Well, 29 would have been too easy, and the title of the QOTD hinted at the result not being quite the obvious. Casting to INT always truncates decimals, so it...

  • Reply To: Float Issues

    Good one!

    The problem is that casting to int always removes any decimals, and with the example, 0.289 is actually stored as a value which, when converted with the maximum number...

    • This reply was modified 4 years, 11 months ago by  Rune Bivrin.
  • Reply To: Renaming Columns

    Aaron N. Cutshall wrote:

    Option 1 works only if you replace the {} with [] as follows:

    df.columns = ['BillMonth', 'InvoiceAmount']

    True, dat! So, we're down to the missing alternative of "None", I suppose...

  • Reply To: Renaming Columns

    richardmgreen1 wrote:

    Option 1 may well work, but in this instance, it's renaming the wrong field so is wrong for the question posted.

    (I know, I'm being really picky now).

    I really don't...

  • Reply To: Renaming Columns

    richardmgreen1 wrote:

    Option one won't work as it's renaming the wrong field.

    Option one should work, shouldn't it, since it sets the name of all the columns, but uses the old name...

  • Reply To: Renaming Columns

    I thought I wouldn't touch this question until it's been reviewed, but I couldn't resist.

    Clearly, option 3 wouldn't work, since the original column name is "BillingAmount", and not "BillAmount". In...

  • Reply To: Sorting the Data Frame

    I'll defer answering until Steve has sorted this one out.

  • Reply To: The Default NULL

    Well, unfortunately, the documentation is a bit off. The bit about the session settings is correct, which matches what I wrote.

    The bit about the database settings is incorrect. The correct...

Viewing 15 posts - 61 through 75 (of 223 total)