Welcome Guest! To enable all features please Login. New Registrations are disabled.

Notification

Icon
Error

Login


Options
Go to last post Go to first unread
Offline buenos  
#1 Posted : 14 March 2010 05:09:46(UTC)
buenos

Rank: Newbie

Groups: Registered
Joined: 06/02/2010(UTC)
Posts: 8
Location: uk

hi

if i try to calculate this:
300^1.3 then it gives the result fine.
if i try to calculate 300^1.274 then it gives an error: "result is above max allowed positive number"

i tried this with the latest beta release. the previous verson from february calculates it fine.

Wanna join the discussion?! Login to your SMath Studio Forum forum account. New Registrations are disabled.

Offline Andrey Ivashov  
#2 Posted : 14 March 2010 08:10:16(UTC)
Andrey Ivashov


Rank: Administration

Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member
Joined: 11/07/2008(UTC)
Posts: 1,616
Man
Russian Federation

Was thanked: 1978 time(s) in 666 post(s)
Hello.

This is known problem. The only way to beat it is to use workaround with round(...) function as shown on the screenshot below:


This will be fixed later.
Offline omorr  
#3 Posted : 14 March 2010 13:43:39(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
If you remember, "eval" function has been introduced in the case of rather complicated symbolic result resulting in slow calculation. If we need the numerical result only, by using "eval" the calculation time can be reduced drastically. Sometimes "eval" will not help. Here is an example were "round" can aslo help Good. This is an Example from the SMath included Examples.

(Numerical instability is expected, of course). Without "round" you can use up to 26-th polynomial degree.

Regards,
Radovan

PS. It is interesting to note that in this particular case "eval" will drastically increase the computational time. It might be usless (very slow) for higher polynomial degree. I do not know why, but "round" will do do job quite good. Forgot to mention - this is from 0.87 stable version. Could someone check it on 0.87 Beta? I will also check it tomorow at my office.

Edited by user 14 March 2010 17:19:20(UTC)  | Reason: Not specified

When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
Offline buenos  
#4 Posted : 14 March 2010 14:55:05(UTC)
buenos

Rank: Newbie

Groups: Registered
Joined: 06/02/2010(UTC)
Posts: 8
Location: uk

hi

thanks.
but it worked fine in the 10-february-2010 release. i mean there was no need for using the rounding...
i have a calculation sheet that worked fine, but after installing the new beta version yesterday it gave an error.
i could attach the file here, but there is no such button.

regards,
istvan
Offline omorr  
#5 Posted : 14 March 2010 16:46:38(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
Hello Istvan,
Yes, you are right. In the 0.87 stable version there would be no error issued.
buenos wrote:
i have a calculation sheet that worked fine, but after installing the new beta version yesterday it gave an error.
i could attach the file here, but there is no such button.

You could use some file hosting service or you can make from .sm an archived (.zip) file and upload it on the Wiki (File Management - menu on the right). Then make a link to it here.

Regards,
Radovan

Edited by user 14 March 2010 17:15:39(UTC)  | Reason: Not specified

When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
Offline buenos  
#6 Posted : 14 March 2010 19:30:07(UTC)
buenos

Rank: Newbie

Groups: Registered
Joined: 06/02/2010(UTC)
Posts: 8
Location: uk

hi

i uploaded the file to the examples on "wiki":
http://smath.info/wiki/G...onverter_Dissipation.zip

can i expect that all known problems will be fixed in the next stable release?
Offline Andrey Ivashov  
#7 Posted : 14 March 2010 20:38:44(UTC)
Andrey Ivashov


Rank: Administration

Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member
Joined: 11/07/2008(UTC)
Posts: 1,616
Man
Russian Federation

Was thanked: 1978 time(s) in 666 post(s)
Not sure about next stable release, but this will be fixed in future. For now we have a solution mentioned in my previous comment (it is acceptable for your file as well).

Edited by user 14 March 2010 20:40:32(UTC)  | Reason: Not specified

Offline Andrey Ivashov  
#8 Posted : 01 April 2010 06:30:26(UTC)
Andrey Ivashov


Rank: Administration

Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member
Joined: 11/07/2008(UTC)
Posts: 1,616
Man
Russian Federation

Was thanked: 1978 time(s) in 666 post(s)
buenos wrote:
if i try to calculate 300^1.274 then it gives an error: "result is above max allowed positive number"


Fixed.

Offline oscampo  
#9 Posted : 16 April 2010 23:56:26(UTC)
oscampo


Rank: Advanced Member

Groups: Registered
Joined: 10/12/2009(UTC)
Posts: 247
Man
Colombia
Location: Cali, Colombia

Was thanked: 87 time(s) in 66 post(s)
Hi,
I was trying:

n:=30000
pf:=1/n
pv:=pf*(1-pf)^n

and I obtained the error "result is above max allowed positive number". But, when I select the "pv:=pf*(1-pf)^n" and choose "Calculation/Optimization/Numeric", SMath find the correct answer: "pv=1.226*10^-5". The same happen when you choose "Calculation/Optimization/None"

Regards,

Oscar
Offline captainblack  
#10 Posted : 18 April 2010 13:49:36(UTC)
captainblack


Rank: Member

Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK

oscampo wrote:
Hi,
I was trying:

n:=30000
pf:=1/n
pv:=pf*(1-pf)^n

and I obtained the error "result is above max allowed positive number". But, when I select the "pv:=pf*(1-pf)^n" and choose "Calculation/Optimization/Numeric", SMath find the correct answer: "pv=1.226*10^-5". The same happen when you choose "Calculation/Optimization/None"

Regards,

Oscar


Right click over the definition of pv and select optimisation and set the option to numeric (this is for version 0.88) and all will be well.


Note, to very high precision (1-1/3000)^3000=1/e, e being Euler's number and the base of natural logarithms.


CB

Edited by user 18 April 2010 14:06:53(UTC)  | Reason: Not specified

Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.