473,594 Members | 2,720 Online

# scrip drops a penny when amount ends with .d0

I call a function that takes the unit price and quantity ordered to
create an amount...it looks something like this.

function calculateCost()
{
quantity=docume nt.RFO.quantity .value;
unitPrice=docum ent.RFO.unitPri ce.value;
total=0;
if(isPositiveIn teger(quantity) )
{
quantity=parseF loat(quantity)
{
total=quantity * unitPrice;
}
}
document.RFO.to tal.value=forma t(total)
}

if a person enters a unit price that ends with .10, .20, .30, ..., .90,
my code drops a penny off the total? However if the price ends with .1,
..2, .3, ..., .9, my code works fine.
Seems it has a problem calculating prices ending with 0 unless it's .00

May 10 '06 #1
35 2276

ey****@ncsa.uiu c.edu wrote:
if a person enters a unit price that ends with .10, .20, .30, ..., .90,
my code drops a penny off the total? However if the price ends with .1,
.2, .3, ..., .9, my code works fine.
Seems it has a problem calculating prices ending with 0 unless it's .00

<http://www.jibbering.c om/faq/#FAQ4_6>

May 10 '06 #2
Why would I need to convert a number into a string?

May 10 '06 #3
ey****@ncsa.uiu c.edu wrote:
Why would I need to convert a number into a string?

Why do you want to know?

May 10 '06 #4
You told me to go to http://www.jibbering.com/faq/#FAQ4_6
this was the answer to my question....

http://www.jibbering.com/faq/#FAQ4_6 explains how to convert a number
into a string

May 10 '06 #5

ey****@ncsa.uiu c.edu wrote:
Why would I need to convert a number into a string?

Because you don't want to have your penni lost. What was a question,
was it? <11************ **********@e56g 2000cwe.googleg roups.com>

May 10 '06 #6
ey****@ncsa.uiu c.edu wrote:
I call a function that takes the unit price and
quantity ordered to create an amount...it looks
something like this.

function calculateCost()
{
quantity=docume nt.RFO.quantity .value;
unitPrice=docum ent.RFO.unitPri ce.value;
total=0;
The variables - quantity -, - unitPrice - and - total - should be
declared local to the function using the - var - keyword whenever there
is no good reason for them being global (and there doesn't appear to be
any reason for that).
if(isPositiveIn teger(quantity) )
{
quantity=parseF loat(quantity)
Why - parseFloat -? Surly a quantity has got to be an integer (and
particularly if - isPositiveInteg er - does what its name suggests), so
why not - parseInt - and if you are verifying that the string contains a
representation of a positive integer why not let the type conversion
implicit in multiplication do that job.
{ ^ total=quantity * unitPrice;
} ^

What are these opening and closing braces doing here? They form a Block
statement, but there is no reason for a Block statement appearing here.
}
document.RFO.to tal.value=forma t(total)
}

if a person enters a unit price that ends with .10,
.20, .30, ..., .90, my code drops a penny off the
total? However if the price ends with .1, .2, .3,
..., .9, my code works fine. Seems it has a problem
calculating prices ending with 0 unless it's
.00

There is nothing in this code that would suggest the phenomenon you
describe. A quick test of the javascript operations you are using finds
no evidence of differing results using strings with trailing zeros and
the same strings with the trailing zeros stripped off:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<title></title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<body>
<pre>
<script type="text/javascript">

var l = [
'1.00','1.10',' 1.20','1.30','1 .40','1.50','1. 60','1.70','1.8 0','1.90',
'2.00','2.10',' 2.20','2.30','2 .40','2.50','2. 60','2.70','2.8 0','2.90',
'3.00','3.10',' 3.20','3.30','3 .40','3.50','3. 60','3.70','3.8 0','3.90',
'4.00','4.10',' 4.20','4.30','4 .40','4.50','4. 60','4.70','4.8 0','4.90',
'5.00','5.10',' 5.20','5.30','5 .40','5.50','5. 60','5.70','5.8 0','5.90',
'6.00','6.10',' 6.20','6.30','6 .40','6.50','6. 60','6.70','6.8 0','6.90',
'7.00','7.10',' 7.20','7.30','7 .40','7.50','7. 60','7.70','7.8 0','7.90',
'8.00','8.10',' 8.20','8.30','8 .40','8.50','8. 60','8.70','8.8 0','8.90',
'9.00','9.10',' 9.20','9.30','9 .40','9.50','9. 60','9.70','9.8 0','9.90'
];
var q = [
'1','2','3','4' ,'5','6','7','8 ','9'
];

function isPositiveInteg er(){
return true;
}

function calculateCost2( x, y){
quantity = q[y];
unitPrice = l[x];
total=0;
var unitPrice2, total2;
if(isPositiveIn teger(quantity) ){
quantity = parseFloat(quan tity)
{
total = quantity * unitPrice;
unitPrice2 = unitPrice.subst ring(0, (unitPrice.leng th - 1));
total2 = quantity * unitPrice2;
}
}
return (quantity+' * '+unitPrice+' = '+total+'\n'+qu antity+' * '+
unitPrice2+' = '+total2+'\t\t' +
((total != total2)?'****** **** Differ **********':'') );
}

for(var c = 0;c < q.length;++c){
for(var d = 0;d < l.length;++d){
document.write( calculateCost2( d, c)+'\n\n')
}
}

</script>
</per>
</body>
</html>

With no evidence of the phenomena it cannot be attributed. You will have
to create an example that actually shows this in action. It would be a
good idea to mention the browser you are using in case this is an
implementation specific bug (I used IE and Mozilla for testing the above
code).

(Incidentally, although the FAQ reference VK posted is relevant to the
issues of money calculations and number to formatted string
transformations , it cannot account for the symptoms you describe. VK
should generally be ignored, he does not know javascript at all and as a
result he cannot see what would be expected from executing javascript
code, and so is incapable of attributing effects to causes except by
(inevitably often wrong) guess-work.)

Richard.
May 10 '06 #7
JRS: In article <11************ **********@e56g 2000cwe.googleg roups.com>
, dated Tue, 9 May 2006 08:32:06 remote, seen in
news:comp.lang. javascript, ey****@ncsa.uiu c.edu posted :
I call a function that takes the unit price and quantity ordered to
create an amount...it looks something like this.

function calculateCost()
{
quantity=docume nt.RFO.quantity .value;
unitPrice=docum ent.RFO.unitPri ce.value;
total=0;
if(isPositiveIn teger(quantity) )
{
quantity=parseF loat(quantity)
{
total=quantity * unitPrice;
}
}
document.RFO.to tal.value=forma t(total)
}

if a person enters a unit price that ends with .10, .20, .30, ..., .90,
my code drops a penny off the total? However if the price ends with .1,
.2, .3, ..., .9, my code works fine.
Seems it has a problem calculating prices ending with 0 unless it's .00

Your code lacks isPositiveInteg er and format, so cannot be tested by me.

Your first move should be to omit use of format, since you need to know
whether there is an error up to that stage; or to try alert(total)
before that. H'mmm - I notice you use total in two ways - that is
at best injudicious; change one of them, to be safe.

It seems illogical to use parseFloat on something just shown to be
integer; you could use unary + instead; you don't need that line, unless
you must allow trailing characters.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
May 10 '06 #8
I wrote a basic code because the real code has so much other stuff
going on. My code allows the user to add as many lines of items to be
purchased...so I have no idea how many items to total up for line item
or main total, so this statement gets all the sets of values.
The problem is only seen when 3 or 6 items are purchased at a cost of
..70 cents...that's the only time it's wrong.
My code gives the following totals
3 * .70 = 2.09
6 * .70 = 4.19

btw, I'm not asking for anyone's thoughts using eval...I had no choice
but to use it, the information is coming from some visual basic
statements and would not work without the eval...I also had to use the
Visual Basic to create collapsible / expandable items to be purchased
area.

My code:
for(i=2;i<=nrow ;i++) {
eval("quant" + i + "=document.RFO. quant_" + i + ".value");
eval("unit" + i + "=document.RFO. unit_" + i + ".value");
eval("tot" + i + "=0");

eval("tquant=qu ant" + i + "");
eval("tunit=uni t" + i + "");
eval("ttot=tot" + i + "");

if(isPositiveIn teger(tquant))
{
tquant=parseFlo at(tquant)
{
ttot=tquant * tunit;
}
}
eval("document. RFO.tot_" + i + ".value=format( ttot)");
}
For testing, I have stripped to code down to nothing which only ran on
the first set of values...the code I listed before...and I get the same
here...even removing the isPositiveInteg er statment to make sure the
problem was not there. I still get the same result, every combination
of values work except 3 or 6 items at a price of ".70" or ".7"

function calculateCost()
{
nrow=document.R FO.nrow.value;
quant1=document .RFO.quant_1.va lue;
unit1=document. RFO.unit_1.valu e;
tot1=0;
quant1=parseInt (quant1)
unit1=parseFloa t(unit1)
{
tot1=quant1 * unit1;
}
}
document.RFO.to t_1.value=forma t(tot1)

May 10 '06 #9
if(isPositiveIn teger(tquant))
{
document.RFO.el ements["tot_"+i].value=tquant*t unit;
}

You haven't shown us your format() function. As suggested
before, run without it to determine if it's the problem.

keep reading...I removed the function as well as other stuff to test
the code.

May 10 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.