Home > Archive > Visual Basic > October 2004 > Percentage between two values
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Percentage between two values
|
|
| George Inacio 2004-10-28, 3:55 am |
| 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
| |
| Jonathan Wood 2004-10-28, 3:55 am |
| 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.
--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
"George Inacio" <jginacio@hotmail.com> wrote in message
news:clpjdk$15d$1@ctb-nnrp2.saix.net...
> 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
>
>
| |
| Hal Rosser 2004-10-28, 3:55 am |
| 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
"George Inacio" <jginacio@hotmail.com> wrote in message
news:clpjdk$15d$1@ctb-nnrp2.saix.net...
> 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
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.781 / Virus Database: 527 - Release Date: 10/21/2004
| |
| Randy Birch 2004-10-28, 3:55 am |
| 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/
"George Inacio" <jginacio@hotmail.com> wrote in message
news:clpjdk$15d$1@ctb-nnrp2.saix.net...
: 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
:
:
| |
| George Inacio 2004-10-28, 3:55 am |
| 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.
--
Jonathan 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
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.781 / Virus Database: 527 - Release Date: 10/21/2004
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/
| |
| Charlie 2004-10-28, 8:55 am |
| 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
"Randy Birch" wrote:
> 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/
>
>
> "George Inacio" <jginacio@hotmail.com> wrote in message
> news:clpjdk$15d$1@ctb-nnrp2.saix.net...
> : 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
> :
> :
>
>
| |
| Jonathan Wood 2004-10-28, 3:55 pm |
| 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
> 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
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.
--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
| |
| Rick Rothstein 2004-10-28, 3:55 pm |
| > > FYI, the outer parentheses are redundant and can make for more
difficult
some[color=darkred]
will[color=darkred]
> be
> formula
>
> 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.
Personally, I don't like extra parentheses. I agree, some might get
 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 for this layout.
Rick - MVP
| |
| Jim Edgar 2004-10-28, 3:55 pm |
|
"Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message
news:e4rm4vQvEHA.2520@TK2MSFTNGP15.phx.gbl...
> difficult
> some
> will
> However,
> include
> extra
>
> Personally, I don't like extra parentheses. I agree, some might get
> 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 for this layout.
>
> 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
| |
| Bob Butler 2004-10-28, 3:55 pm |
| "Jim Edgar" <djedgarNOSPAM@cox.net> wrote in message
news:%23sfQd7QvEHA.1292@TK2MSFTNGP10.phx.gbl
>
> 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.
--
Reply to the group so all can participate
VB.Net... just say "No"
| |
| Charlie 2004-10-28, 8:55 pm |
| Sorry to those of you who are easily . 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.
"Bob Butler" wrote:
> "Jim Edgar" <djedgarNOSPAM@cox.net> wrote in message
> news:%23sfQd7QvEHA.1292@TK2MSFTNGP10.phx.gbl
>
> 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.
>
> --
> Reply to the group so all can participate
> VB.Net... just say "No"
>
>
| |
| Jim Edgar 2004-10-28, 8:55 pm |
| > Sorry to those of you who are easily . 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.
>
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
| |
| Jonathan Wood 2004-10-28, 8:55 pm |
| Rick,
> Personally, I don't like extra parentheses. I agree, some might get
> 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.
--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
| |
| Jonathan Wood 2004-10-28, 8:55 pm |
| 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 ." 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.
--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
"Charlie" <Charlie@discussions.microsoft.com> wrote in message
news:4078253D-2096-4018-B4FE-1DB3BBB45F18@microsoft.com...
> Sorry to those of you who are easily . 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[color=darkred]
> AND his manager insisted that the result was 18, "because their calculator
> said so!"
>
> (although I was "still eligible for the prize...") Hahahaha.
>
>
> "Bob Butler" wrote:
>
since[color=darkred]
stop[color=darkred]
| |
| Rick Rothstein 2004-10-28, 8:55 pm |
| > > Personally, I don't like extra parentheses. I agree, some might get
>
> 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
| |
| Charlie 2004-10-29, 3:55 pm |
| 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.
"Jim Edgar" wrote:
>
> 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
>
>
>
| |
| Charlie 2004-10-29, 3:55 pm |
| 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.
"Jonathan Wood" wrote:
> 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 ." 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.
>
> --
> Jonathan Wood
> SoftCircuits
> http://www.softcircuits.com
> Available for consulting: http://www.softcircuits.com/jwood/resume.htm
>
> "Charlie" <Charlie@discussions.microsoft.com> wrote in message
> news:4078253D-2096-4018-B4FE-1DB3BBB45F18@microsoft.com...
> to
> Like
> cleaner
> telemarketer
> since
> stop
>
>
>
| |
| Bob Butler 2004-10-29, 3:55 pm |
| "Charlie" <Charlie@discussions.microsoft.com> wrote in message
news:B7864265-7CDF-46F3-84B0-B2AC35B37335@microsoft.com
> 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.
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.
| |
| Charlie 2004-10-29, 3:55 pm |
| 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)))
"Bob Butler" wrote:
> "Charlie" <Charlie@discussions.microsoft.com> wrote in message
> news:B7864265-7CDF-46F3-84B0-B2AC35B37335@microsoft.com
>
> 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.
>
>
| |
| Jim Edgar 2004-10-29, 3:55 pm |
|
"Charlie" wrote:
> 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
>
((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
| |
| Charlie 2004-10-29, 3:55 pm |
| Did you drop the code in a project and test it?
"Jim Edgar" wrote:
>
>
> "Charlie" wrote:
>
>
> ((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
| |
| Bob Butler 2004-10-29, 3:55 pm |
| "Charlie" <Charlie@discussions.microsoft.com> wrote in message
news:40B563C0-C039-4C09-B970-7CA8607E17F4@microsoft.com
> 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.
--
Reply to the group so all can participate
VB.Net... just say "No"
| |
| Jim Edgar 2004-10-29, 3:55 pm |
| Yes I did. VB6 SP5 WinXP Pro.
JEdgar
"Charlie" wrote:
[color=darkred]
> Did you drop the code in a project and test it?
>
> "Jim Edgar" wrote:
>
| |
| Charlie 2004-10-29, 3:55 pm |
| I bet Ol' George didn't expect his question would generate such interest!
Ah, the Passions of Personal Style. Have a nice w end all!
"George Inacio" wrote:
> 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
>
>
>
| |
| Charlie 2004-10-29, 3:55 pm |
| You are right, I tested a year that produced the same result by coincidence.
I stand corrected! Have a nice wend!
"Jim Edgar" wrote:
[color=darkred]
> Yes I did. VB6 SP5 WinXP Pro.
>
> JEdgar
>
> "Charlie" wrote:
>
| |
| Bob Butler 2004-10-29, 3:55 pm |
| "Charlie" <Charlie@discussions.microsoft.com> wrote in message
news:6FA4B796-302F-48F9-9FCD-0E5540A6E80A@microsoft.com[color=darkred]
> You are right, I tested a year that produced the same result by
> coincidence. I stand corrected! Have a nice wend!
>
> "Jim Edgar" wrote:
>
The defense rests. <g>
| |
| Charlie 2004-10-29, 3:55 pm |
| 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>
"Bob Butler" wrote:
> "Charlie" <Charlie@discussions.microsoft.com> wrote in message
> news:6FA4B796-302F-48F9-9FCD-0E5540A6E80A@microsoft.com
>
> The defense rests. <g>
>
>
>
| |
| Jonathan Wood 2004-10-29, 3:55 pm |
| 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.
--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
| |
| Duane Bozarth 2004-10-29, 3:55 pm |
| Charlie wrote:
>
> 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.
| |
| Bob O`Bob 2004-10-29, 3:55 pm |
| Jonathan Wood wrote:
> 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
--
occasionally 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
| |
| Bob Butler 2004-10-29, 3:55 pm |
| "Duane Bozarth" <dp_bozarth@swko.dot.net> wrote in message
news:41828621.61390F43@swko.dot.net
> Charlie wrote:
>
> 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.
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...
--
Reply to the group so all can participate
VB.Net... just say "No"
| |
| Duane Bozarth 2004-10-29, 8:55 pm |
| Bob Butler wrote:
>
....
> 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...
| |
| Don@home.com 2004-10-30, 8:55 am |
| On Fri, 29 Oct 2004 06:50:32 -0700, "Bob Butler" <tiredofit@nospam.com> wrote:
>"Charlie" <Charlie@discussions.microsoft.com> wrote in message
>news:B7864265-7CDF-46F3-84B0-B2AC35B37335@microsoft.com
>
>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.
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
| |
| Bob Butler 2004-10-30, 8:55 am |
| <Don@home.com> wrote in message
news:bbp6o01r644uubikhm97mtqur71sirk75s@
4ax.com
> On Fri, 29 Oct 2004 06:50:32 -0700, "Bob Butler"
> <tiredofit@nospam.com> wrote:
>
>
> 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???
Definitely. That first version is looking even better and clearer with the
proper spacing! <g>
--
Reply to the group so all can participate
VB.Net... just say "No"
| |
| Duane Bozarth 2004-10-30, 3:55 pm |
| Duane Bozarth wrote:
>
> Bob Butler wrote:
> ...
>
> 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...
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.
|
|
|
|
|