Integrated Application Platform › Forums › General › RoundUp problems
 This topic has 5 replies, 2 voices, and was last updated 10 years, 4 months ago by ajith.

AuthorPosts

May 28, 2013 at 4:35 pm #754ajithParticipant
Hi,
I couldn’t find a RoundUp method for numbers.
I tried thisRoundUp(digits)
{
factor = 10.Pow(digits.Int())
return (this* factor).Ceiling() / factor
}It works fine for positive numbers. But for negative number, there is some problem:
9.0120456789.RoundUp(4) gives 9.0121
9.0120456789.RoundUp(4) gives 9.0121, when it should be 9.0120Trying the steps from WorkSpace, I found that
((9.0120456789 * 10.Pow(4)).Ceiling() )/ 10.Pow(4) gives 9.012, the correct answer.However, 90120.456789.Ceiling() gives 90121
Are you able to recreate the problem? If so, what is the reason?
BTW, suneido had collapsed when I tried putting Print(digit) inside the Round method before I tried the code. Error in Errohandler had shown value stack overflow
ajith
May 28, 2013 at 10:29 pm #985amckinlayKeymasterIt’s because Suneido is interpreting it as:
(90120.456789.Ceiling())
whereas what you want is:
(90120.456789).Ceiling()
try using a variable:
x = 90120.456789
x.Ceiling()same problem with your RoundUp example
May 28, 2013 at 10:48 pm #986amckinlayKeymasterI think the definition of RoundDown was wrong. I changed it to be like your RoundUp except with Floor instead of Ceiling. I also improved Floor and Ceiling slightly.
Here’s what I now have in stdlib:
Ceiling()
{
i = .Int()
return this > i ? i + 1 : i
}
Floor()
{
i = .Int()
return this < i ? i  1 : i
}
Round(digits)
{
factor = .Sign() * 10.Pow(digits.Int())
return (this * factor + .5).Int() / factor
}
RoundDown(digits)
{
factor = 10.Pow(digits.Int())
return (this * factor).Floor() / factor
}
RoundUp(digits)
{
factor = 10.Pow(digits.Int())
return (this * factor).Ceiling() / factor
}May 29, 2013 at 3:09 pm #987ajithParticipantIt’s because Suneido is interpreting it as:
(90120.456789.Ceiling())
whereas what you want is:
(90120.456789).Ceiling()
1) Is this interpretation right? I mean shouldn’t Suneido interpret it a negative number and then apply the method?
2) Does this mean that when there is a possibility of a negative number being acted upon by a method, we should always use the number inside parenthesis or supply it as variable?
3) Your explanation works for the results obtained from WorkSpace. When a Print((this * factor).Ceiling()) is used inside the RoundUp method, it gives a positive number ignoring the sign of the supplied number. When a Print(this) is used, it can be seen that this is returned as a positive number, ignoring the sign. Is this behaviour expected?
4) When I use a Print(digit) statement inside the Round() method, Suneido crashes showing value stack overflow error.
ajithMay 29, 2013 at 3:30 pm #988amckinlayKeymaster1) I think the interpretation is correct, or at least not wrong. For example, if you had x.Abs() I think you would want it to do .Abs() first. The question is, for 123.Fn() is the minus sign part of the number, or is it an operator as it is in x.Fn() Currently it is treated as an operator.
2) In general, if the precedence of operations is unclear, then it’s a good idea to use parenthesis. Even if it is only for the benefit of making the code clearer when read later.
3) I am not sure if I understand this question. Inside Numbers methods, ‘this’ will be the original number.
4) The stack overflow is likely because the Print code is calling the method containing the Print, so you get infinite recursion.
May 29, 2013 at 7:20 pm #989ajithParticipant3) I am not sure if I understand this question. Inside Numbers methods, ‘this’ will be the original number.
Yes, it should be.
I typed Print((this * factor).Ceiling())inside the RoundUp() method and ran 9.0123456.RoundUp(4) from WorkSpace. The Print statement printed out 90124 and the RoundUp method gave 9.0124.
Then I tried putting Print(this) in place of the first Print((this * factor).Ceiling()). Again, I ran 9.0123456.RoundUp(4) from WorkSpace . Now, the Print statement printed out 9.0123456 followed by the RoundUp method’s result 9.0124.So, i thought that “this” somehow was ignoring the negative sign of the original number. I thought it was an error. Now, I know that it is solved if the number is placed inside parenthesis along with its sign.
Thanks for the explanations
ajith 
AuthorPosts
 You must be logged in to reply to this topic.