none
Operator '*' cannot be applied to operands of type 'decimal' and 'double' ??

    Question

  • I keep getting these silly errors with C# mostly because I dont know what numeric types it can/cannot handle in math related operations.

    Is there SOMEWHERE I can reference detailing which types C# doesn't like with math operations?

    So, I realize I need much more than the numeric specifier to force conversion to C# required type. (I know I can use D or M to force conversion). What I need is a reference to C# type requirements in math operations.

    Finally, WTF! What is so difficult (or wrong) about multiplying a decimal and a double?? (sorry c# lovers, VB.NET is so much easier/convenient to deal with). 
     

    Failing equation: Math.Floor(3)*6.3d;

    Error: Operator '*' cannot be applied to operands of type 'decimal' and 'double'    =  silliness!!

    Wednesday, October 01, 2008 1:09 PM

Answers

  • Hello EricEricEricEric,
        Math operations can only occur on variables of the same type, never two different types. Try adding: ConvertTo.Double(variable) or ConverTo.Decimal(variable) to convert.

    Hope this helps!
    Thanks!
    chukrum47
    How are a plum and a rabbit similar? They're both purple, except for the rabbit.
    Wednesday, October 01, 2008 10:36 PM

All replies

  • If you take a look at this extremely long post on Visual Basic division problems, you'll see why this "silliness" is way preferrable to VB's unpredictable behavior.
    Wednesday, October 01, 2008 1:36 PM
  • VB's unpredictable behavior? What is so predictable about not being able multiply a decimal and double?

    Refer to my original question which was where can I find SOMETHING referencing C#'s unpredictable silliness with handling relatively simple math operations. So I can handle them all (if thats even possible with C#).

    Not looking for a debate. Thanks
    Wednesday, October 01, 2008 5:24 PM
  • What is so predictable about not being able multiply a decimal and double?

    What's predictable about it is that it kicks out an exception and lets you know it before you build.  VB just blithely chugs along kicking out improper values all day long without letting you know anything.  [In defense of VB, which I'm a fan of, it can be made to do math properly, you just have to be aware of the automatic type conversions it does and preempt them]

    However, to answer your question, take a look at the Implicit Numeric Conversions Table for c#.  If there's not one listed for your type, then you'll probably get a complaint from the compiler.
    Wednesday, October 01, 2008 5:40 PM
  • Hello EricEricEricEric,
        Math operations can only occur on variables of the same type, never two different types. Try adding: ConvertTo.Double(variable) or ConverTo.Decimal(variable) to convert.

    Hope this helps!
    Thanks!
    chukrum47
    How are a plum and a rabbit similar? They're both purple, except for the rabbit.
    Wednesday, October 01, 2008 10:36 PM
  • EricEricEricEric said:

    VB's unpredictable behavior? What is so predictable about not being able multiply a decimal and double?


    If you knew the difference between a decimal and a double (other than the spelling), I suspect you'd feel differently.
    Thursday, October 02, 2008 12:46 AM

  •  


    If you knew the difference between a decimal and a double (other than the spelling), I suspect you'd feel differently.



    I love it. It is great.

    The OP should be explained that decimal is a much more complicated representation of numeric values, require special hardware to run, and provides basis for completely accurate operations like division and multiplication. Doubles on the other hand provide inherently inaccurate basis for the abovementioned operations with potential for accumulating computational errors out of all proportion. Doubles under the best of circumstances can represent only 2/3 of decimal places as decimals do. Thus mixing them devalues decimals, degrades them to the status of doubles and makes no sense whatsoever.
    AlexB
    Thursday, October 02, 2008 1:17 AM
  • Mixing types was the issue. Apparently, Math.Floor has some ambiguities which I knew but thought C# could handle well.

    So, appending a 'd' to all terms fixed it.

    Thursday, October 02, 2008 12:33 PM
  • AlexBB said:


     


    If you knew the difference between a decimal and a double (other than the spelling), I suspect you'd feel differently.



    I love it. It is great.

    The OP should be explained that decimal is a much more complicated representation of numeric values, require special hardware to run, and provides basis for completely accurate operations like division and multiplication. Doubles on the other hand provide inherently inaccurate basis for the abovementioned operations with potential for accumulating computational errors out of all proportion. Doubles under the best of circumstances can represent only 2/3 of decimal places as decimals do. Thus mixing them devalues decimals, degrades them to the status of doubles and makes no sense whatsoever.
    AlexB

    The Decimal type requires special hardware to run? I think you're a bit mistaken there...

    Also: "provides basis for completely accurate operations like division and multiplication."

    Oh yes? Well what about the following code then:

    Decimal x = 1.0m; 
    Decimal y = 3.0m; 
    Decimal oneThird = x/y; 
     
    Decimal t = 0.0m; 
     
    for (int i = 0; i < 3000; ++i) 
        t += oneThird;  // Compute 3000*(1/3) = 1000 
     
    Console.WriteLine(t); 
     

    This prints 999.9999999999999999999999720 on my test system.

    Not quite "complete accurate"...

    The reality is that there is no way to represent some number such as 1/3 in a binary or decimal system, so you will get some errors no matter which representation you use. You need to be aware of, and account for, such inaccuracies.



    Thursday, October 02, 2008 1:17 PM
  • Mathew, you are correct. I should have said that the accurate representation is not possible when the result is irrational or a rational periodic number but this should have been implied by default. It is the nature of the beast. That example of yours (1/3) is so trivial that you should not have made a big splash out of it, sure you cannot.

    As far as the special hardware to run, you are mistaken in challenging this. Special registers are required. Nowadays they are a standard component of any computer box but in the old days you had to pay extra for those registers (chips). I forgot their name. They had a special name for that.

    You can refere to wikipedia.org for complete explanation as to how decimals operate on hardware level.

    AlexB
    Thursday, October 02, 2008 2:08 PM
  • I'm pretty sure that my PC doesn't have any special hardware for calculating with Decimals other than an Intel microprocessor!

    I really don't understand what this special hardware is that you're talking about... Are you sure you're not talking about the FPU (Floating Point Unit) which did used to be separate from the microprocessor years ago. However, note that (a) that predates any Decimal type, (b) the FPU is built into modern Intel microprocessors and (c) the "double" type uses the FPU, so isn't any different from the Decimal type in that regard.
    Thursday, October 02, 2008 3:35 PM
  • I don't quite remember where I read it. I found this quote which does not appear to be conclusive:

    The same argument applies when hardware of this type uses an embedded microcontroller or other small processor. Often, smaller code results when representing numbers internally in BCD format, since a conversion from or to binary representation can be expensive on such limited processors. For these applications, some small processors feature BCD arithmetic modes, which assist when writing routines that manipulate BCD quantities.

    The source is. http://en.wikipedia.org/wiki/Binary-coded_decimal

    I will keep looking.

    Yes, you are probably correct. I meant those floating point processors most likely which used to be separate.


    AlexB
    Friday, October 03, 2008 7:54 PM