 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / October 2004Percentage between two values
Hello Everyone. I need to find the Profit percentage using the Cost and Sale. I use this formula to find the percentage; Cost = 100 Sale = 110 ProfitPercent = (Sale * 100 / Cost) - 100 Works fine but if the Cost = 0 and Sale= 110 I get in troubles. I have no idea how to calculate a percentage from Cost=0 with a Sale= 110. Can you help me please? Thanks in advance! Regards, George There is no such percentage. 0 can be multiplied infinitely and still be less than 110. That is why division by zero is always an error. To work around this, your code can test for when cost = 0, and you can set to ProfitPercent to a special value in that case. But I have no idea what value that would be. The percentage is infinite.  SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Hello Everyone. > [quoted text clipped - 14 lines] > Regards, > George if cost is 0 then profit percentage is undefiined if percentage is based on cost but if profit percentage is based on sales price, then that will be 100% profit is "usually" expressed in percent of sales in most businesses I've worked for > Hello Everyone. > [quoted text clipped - 14 lines] > Regards, > George The formula is : profit = ((sale - cost) / Abs(cost)) * 100 But since your cost is 0, you'll get a divide by 0 error if you attempt to use this formula - or any formula where cost is the denominator - when 0. You can wrap the code in a conditional test, if cost > 0 then .... end if but I recommend writing it as a function: private function ProfitPercent(nCost as single, nSale as Single) as long if nCost = 0 then ProfitPercent = 0 exit function end if ProfitPercent = ((sale - cost) / Abs(cost)) * 100 end function This lets you define all the appropritate tests for valid cost and sale values in one place, and call the routine such as: Cost = 100 Sale = 110 p = ProfitPercent(Cost, Sale) You could even code the routine to return a known value for your testing, eg ... private function ProfitPercent(nCost as single, nSale as Single) as long if nCost = 0 then ProfitPercent = -9999 '<<< exit function end if ProfitPercent = ((sale - cost) / Abs(cost)) * 100 end function Cost = 100 Sale = 110 p = ProfitPercent(Cost, Sale) if p <> -9999 then print "the profit is " p endif SignatureRandy Birch MS MVP Visual Basic http://vbnet.mvps.org/ : Hello Everyone. : [quoted text clipped - 14 lines] : Regards, : George FYI, the outer parentheses are redundant and can make for more difficult reading. As long as you know your arithmetic hierarchy you can save some typing. Division and multiplication are of the same precedence and will be performed left-to-right (i.e. order doesn't matter.) The compacted formula then is: profit = (sale - cost) / Abs(cost) * 100 > The formula is : > [quoted text clipped - 68 lines] > : Regards, > : George Charlie, > FYI, the outer parentheses are redundant and can make for more difficult > reading. As long as you know your arithmetic hierarchy you can save some [quoted text clipped - 3 lines] > > profit = (sale - cost) / Abs(cost) * 100 I agree with you that the additional parentheses are not required. However, I agree with Randy about which is easier to read. I almost always include the additonal parentheses to make it obvious (at the cost of a little extra typing) when reading the code. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > > FYI, the outer parentheses are redundant and can make for more difficult > > reading. As long as you know your arithmetic hierarchy you can save some [quoted text clipped - 10 lines] > the additonal parentheses to make it obvious (at the cost of a little extra > typing) when reading the code. Personally, I don't like extra parentheses. I agree, some might get confused about what is being multiplied by 100 given the layout. My solution would be to write the above this way... profit = 100 * (sale - cost) / Abs(cost) I find very few people get confused for this layout. Rick - MVP > > > FYI, the outer parentheses are redundant and can make for more > difficult [quoted text clipped - 26 lines] > > Rick - MVP I'm one of the few people. Math and operator precedence was 35 years ago. IMHO I like Randy's explicit style. Jim Edgar >> profit = 100 * (sale - cost) / Abs(cost) >> >> I find very few people get confused for this layout. > > I'm one of the few people. Math and operator precedence > was 35 years ago. IMHO I like Randy's explicit style. It was a bit less than that for me but I also prefer the extra parens since I can see immediately what the order of operations is without having to stop and think about operator precedence at all. SignatureReply to the group so all can participate VB.Net... just say "No" Sorry to those of you who are easily confused. I don't know, I don't have to "stop and think about operator precedence." I just read the formula. Like riding a bike. This reminds of one time I received a junk (snail) mail marketing ploy saying I could win a prize if I could solve this problem: (21 * 3) + 9 / 4 (The prize, of course, being something like attachments to a vacuum cleaner I would have to buy.) The answer, 65.25, seemed a little odd for the type of mail-out (and the parentheses were suspiciously out of place), so I called. The telemarketer AND his manager insisted that the result was 18, "because their calculator said so!" (although I was "still eligible for the prize...") Hahahaha. > >> profit = 100 * (sale - cost) / Abs(cost) > >> [quoted text clipped - 6 lines] > I can see immediately what the order of operations is without having to stop > and think about operator precedence at all. > Sorry to those of you who are easily confused. I don't know, I don't have to > "stop and think about operator precedence." I just read the formula. Like [quoted text clipped - 12 lines] > > (although I was "still eligible for the prize...") Hahahaha. Your example is pretty simple and even *I* can see that the answer is 65.25. I meant examples like this one. It's a line out of a routine I wrote that calculates a date for Rosh Hashanah: dDate=JtoG+(F1*JY)+((iYear Mod 4)/4)-((313*CLng(iYear)+89081)/98496) Jim Edgar Sure, it was a simple example, but even I can see that dDate=JtoG+(F1*JY)+((iYear Mod 4)/4)-((313*CLng(iYear)+89081)/98496) could be written dDate=JtoG+F1*JY+iYear Mod 4/4-(313*iYear+89081)/98496 (as long as you Dim iYear As Long, which I would have done anyway, to avoid having to do those extra type conversions.) This is not about syntax. Either formula works fine. It's just that some of us prefer less clutter. > > Sorry to those of you who are easily confused. I don't know, I don't have to > > "stop and think about operator precedence." I just read the formula. Like [quoted text clipped - 20 lines] > > Jim Edgar > Sure, it was a simple example, but even I can see that > [quoted text clipped - 9 lines] > This is not about syntax. Either formula works fine. It's just that > some of us prefer less clutter. That depends on your definition of clutter... I'd say the first is less cluttered since it clearly delimits each operation rather than having them all jumbled together. At the *very* least I would put (iYear Mod 4) since while the add/subtract/divide/multiply order is ingrained enough to not be a big concern it's easy to forget where operator like MOD are in the precendence rules. IMO anything you can do to make your intentions 100% clear in the code so that people reading it after you know what *you* thought would happen is good. I will agree that iYear Mod 4 is crap, but then I think the VB compiler development team should have stayed with the syntax used for all VB functions, Mod(iYear, 4), because that's what it is. That would've solved THAT parentheses problem. I'm sure they had their reason for the alternate syntax. OK, so here's 100% clear? No, I could add a few more pairs and still have a correct mathematical expression. Don't laugh, I have actually seen it. dDate=((JtoG+(F1*JY))+(((iYear Mod 4)/4)-((((313*CLng(iYear))+89081))/98496))) > > Sure, it was a simple example, but even I can see that > > [quoted text clipped - 18 lines] > clear in the code so that people reading it after you know what *you* > thought would happen is good. > I will agree that iYear Mod 4 is crap, but then I think the VB > compiler development team should have stayed with the syntax used for > all VB functions, Mod(iYear, 4), because that's what it is. That > would've solved THAT parentheses problem. Yes, I would prefer that as well. I type it that way once in a while anyway when the brain gets a line or two ahead of the hands when coding! > I'm sure they had their reason for the alternate syntax. I doubt that it made any sense though... <g> > OK, so here's 100% clear? No, I could add a few more pairs and still > have a correct mathematical expression. Don't laugh, I have actually > seen it. > > dDate=((JtoG+(F1*JY))+(((iYear Mod 4)/4)- > ((((313*CLng(iYear))+89081))/98496))) LOL. I've seen it too and too many can be worse than too few. SignatureReply to the group so all can participate VB.Net... just say "No" > I will agree that iYear Mod 4 is crap, but then I think the VB compiler > development team should have stayed with the syntax used for all VB > functions, Mod(iYear, 4), because that's what it is. That would've solved > THAT parentheses problem. I'm sure they had their reason for the alternate > syntax. Yes, compatability w/ BASIC syntax... Now why that was chosen can only be surmised as an (albeit mistaken) attempt to maintain a simple syntax for the (original) target audience for BASIC. >> I will agree that iYear Mod 4 is crap, but then I think the VB >> compiler development team should have stayed with the syntax used [quoted text clipped - 7 lines] > attempt to maintain a simple syntax for the (original) target audience > for BASIC. Sounds like the argument that life on earth started when it was seeded by aliens... all it does it keep moving the question further back in time without answering how it started in the first place. <g> The smart move, once the "x Mod y" syntax existed would have been to support it for a rev or two *and* added Mod(x,y) to make it more readable. Of course, it's probably x.Math.SpecialFunctions.ExtraLayer.JustToHideIt.Modulus(y) now... SignatureReply to the group so all can participate VB.Net... just say "No" ... > The smart move, once the "x Mod y" syntax existed would have been to support > it for a rev or two *and* added Mod(x,y) to make it more readable. ... Did ANSI BASIC do the "smart" thing? If it had, I suspect MS would have followed--that they didn't makes me suspect that the Standard wasn't changed... > ... > > The smart move, once the "x Mod y" syntax existed would have been to support [quoted text clipped - 3 lines] > followed--that they didn't makes me suspect that the Standard wasn't > changed... Well, "inquiring minds" may want to know...I couldn't find a posted ANSI BASIC standard (they want $$ for it) so couldn't check directly. But, I looked at the list of functions w/ TrueBasic which is supposed to be (and I have no reason to suspect it isn't) ANSI-compliant and it does, indeed, use the mod(x,y) form. Couldn't ascertain whether it would still accept (x mod y) or not--I'd presume not. So, looks like MS didn't keep even the core language in VB consistent w/ standards. >> Sure, it was a simple example, but even I can see that >> [quoted text clipped - 18 lines] >clear in the code so that people reading it after you know what *you* >thought would happen is good. Clutter, Clutter. Who does the cluttering? First off lets show the lines as they are in the IDE -> dDate = JtoG + (F1 * JY) + ((iYear Mod 4) / 4) - ((313 * CLng(iYear) + 89081) / 98496) dDate = JtoG + F1 * JY + iYear Mod 4 / 4 - (313 * iYear + 89081) / 98496 Hmmm... Little spacing does Un-Clutter the Clutter don't you think??? I have used many '()' pairs [in excess you could say] during debugging so I could use intellesense to see the break down of the calculation(s) in a routine that was giving wrong results... Then afterwards going back and removing the extras to 'clean' things up a bit... FYI: iYear Mod 4 / 4 is the same as (iYear Mod 4 / 4). If this is what you want then alls well and great but I believe what you are really looking for here is (iYear Mod 4) / 4 .... LOL... As for my old tired eyes and gray matter my code looks like Clutter Cluttering the Clutter... Have a good day... Don >>> Sure, it was a simple example, but even I can see that >>> [quoted text clipped - 29 lines] > > Hmmm... Little spacing does Un-Clutter the Clutter don't you think??? Definitely. That first version is looking even better and clearer with the proper spacing! <g> SignatureReply to the group so all can participate VB.Net... just say "No" > Sure, it was a simple example, but even I can see that > [quoted text clipped - 3 lines] > > dDate=JtoG+F1*JY+iYear Mod 4/4-(313*iYear+89081)/98496 ((iYear Mod 4)/4) is not the same as iYear Mod 4/4 as you posted. According to the help files the division operator has precedence over the mod operator. Assuming that iYear = 2002 then the first example returns 0.5 while your example returns 0. I think I'll stick to the parentheses. JEdgar Did you drop the code in a project and test it? > > Sure, it was a simple example, but even I can see that > > [quoted text clipped - 10 lines] > > JEdgar Yes I did. VB6 SP5 WinXP Pro. JEdgar > Did you drop the code in a project and test it? > [quoted text clipped - 12 lines] > > > > JEdgar You are right, I tested a year that produced the same result by coincidence. I stand corrected! Have a nice weekend! > Yes I did. VB6 SP5 WinXP Pro. > [quoted text clipped - 16 lines] > > > > > > JEdgar > You are right, I tested a year that produced the same result by > coincidence. I stand corrected! Have a nice weekend! [quoted text clipped - 4 lines] >> >>> Did you drop the code in a project and test it? The defense rests. <g> LOL, yeah, I told my buddy in the next cubicle how y'all caught me with my pants down. We had a good laugh! It would've been REALLY funny if i'd ripped out ALL of the parentheses from that equation. Take THAT! <g> > > You are right, I tested a year that produced the same result by > > coincidence. I stand corrected! Have a nice weekend! [quoted text clipped - 6 lines] > > The defense rests. <g> I'm sorry but I think that's pretty condescending to refer to those who find the parenthesis a little easier to read as "easily confused." And then you offer a trivial expression as an example. I suspect you are younger than some of us as I recognize the attitude. But after years of reading large amounts of code, either written by others or myself many years ago, I find whatever makes the code easier to read can be a benefit. I've even written an expression evaluator (it's posted on my site as eval.zip) that takes into account all issues regarding parentheses and operator precedence. But when I'm reading code that implements a hash algorithm that will most effectively implement a smart file comparison, I don't want to think about operator precedence. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Sorry to those of you who are easily confused. I don't know, I don't have to > "stop and think about operator precedence." I just read the formula. Like [quoted text clipped - 23 lines] > > I can see immediately what the order of operations is without having to stop > > and think about operator precedence at all. Maybe you wouldn't have had to read such "large amount amounts of code" if you hadn't put in so many extra parentheses. More is not always better. After reading your post to Rick Rothstein I'm wondering who has the attitude problem. Eval? Been there done that. > I'm sorry but I think that's pretty condescending to refer to those who find > the parenthesis a little easier to read as "easily confused." And then you [quoted text clipped - 42 lines] > stop > > > and think about operator precedence at all. Charlie, > Maybe you wouldn't have had to read such "large amount amounts of code" if > you hadn't put in so many extra parentheses. More is not always better. Oh give me a break. Some tasks are complex. Using terse code won't make it a small amount of code--what sort of nonsense is that? You've already claimed that you don't even need to think about operator precedence while being caught getting it wrong. You can fool some of the people some of the time, etc. I suspect I've been doing this a lot longer than you have. You code however you want. Hopefully, I'll never have to deal with any of your code. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Hopefully, I'll never have to deal with any of your code. But unfortunately, we already have - for certain (small) values of "deal with" My input: parentheses can't be "excessive" until they're actually duplicative. (and then they're trivially recognized and/or removed) Computers are consistent; source code is for HUMANS to read. Bob Signatureoccasionally it may LOOK like I'm resting, but it's more like I'm banging my head on the desk v e r y s l o w l y Rick, > Personally, I don't like extra parentheses. I agree, some might get > confused about what is being multiplied by 100 given the layout. Yeah, well if I remember some of your posts correctly, ease of reading didn't appear to be your top priority. I guess it's a matter of taste. All I can say is that I enjoyed the terse syntax that C allowed for many years. Now, I routinely do a little extra typing if it makes the code a little more obvious to read. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > > Personally, I don't like extra parentheses. I agree, some might get > > confused about what is being multiplied by 100 given the layout. > > Yeah, well if I remember some of your posts correctly, ease of reading > didn't appear to be your top priority. LOL I never said anything about "ease of reading"; only that I didn't like extra parentheses... these are not necessarily the same thing.<g> Rick Thanks Everybody! That is a great help because I was real lost. Regards, George There is no such percentage. 0 can be multiplied infinitely and still be less than 110. That is why division by zero is always an error. To work around this, your code can test for when cost = 0, and you can set to ProfitPercent to a special value in that case. But I have no idea what value that would be. The percentage is infinite. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm if cost is 0 then profit percentage is undefiined if percentage is based on cost but if profit percentage is based on sales price, then that will be 100% profit is "usually" expressed in percent of sales in most businesses I've worked for The formula is : profit = ((sale - cost) / Abs(cost)) * 100 But since your cost is 0, you'll get a divide by 0 error if you attempt to use this formula - or any formula where cost is the denominator - when 0. You can wrap the code in a conditional test, if cost > 0 then .... end if but I recommend writing it as a function: private function ProfitPercent(nCost as single, nSale as Single) as long if nCost = 0 then ProfitPercent = 0 exit function end if ProfitPercent = ((sale - cost) / Abs(cost)) * 100 end function This lets you define all the appropritate tests for valid cost and sale values in one place, and call the routine such as: Cost = 100 Sale = 110 p = ProfitPercent(Cost, Sale) You could even code the routine to return a known value for your testing, eg ... private function ProfitPercent(nCost as single, nSale as Single) as long if nCost = 0 then ProfitPercent = -9999 '<<< exit function end if ProfitPercent = ((sale - cost) / Abs(cost)) * 100 end function Cost = 100 Sale = 110 p = ProfitPercent(Cost, Sale) if p <> -9999 then print "the profit is " p endif -- Randy Birch MS MVP Visual Basic http://vbnet.mvps.org/ I bet Ol' George didn't expect his question would generate such interest! Ah, the Passions of Personal Style. Have a nice weekend all! > Hello Everyone. > [quoted text clipped - 14 lines] > Regards, > George |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.