1 страниц (7 вхождений)
Bug/Error in the execution of Range(3) function - brettwtowler@yahoo.com - Сообщения
#1 Опубликовано: 28.11.2012 20:11:03
There's a problem with the Range(3) function.
Here's an example:
1. Create a vector for a variable n using the range(3) function such as:
n:=0.03, 0.0325.. 0.05
This should produce a vector with 9 elements ranging from 0.03 to 0.05 in 0.0025 increments.
However, it actually produces an 8 element vector from 0.03 to 0.0475. It appears the last element (0.05) is truncated.
Why?
Thanks in advance,
Brett
Bug in Range(3) function, SMath 0.95.sm (5 КиБ) скачан 46 раз(а).
Here's an example:
1. Create a vector for a variable n using the range(3) function such as:
n:=0.03, 0.0325.. 0.05
This should produce a vector with 9 elements ranging from 0.03 to 0.05 in 0.0025 increments.
However, it actually produces an 8 element vector from 0.03 to 0.0475. It appears the last element (0.05) is truncated.
Why?
Thanks in advance,
Brett
Bug in Range(3) function, SMath 0.95.sm (5 КиБ) скачан 46 раз(а).
#2 Опубликовано: 29.11.2012 04:50:25
Hello Brett,
I think it is due to the machine floating point rounding error. Here is the possible explanation of it.
[MATH=eng]n:range(0.03,0.05+10^{-16},0.0325)[/MATH]
[MATH=eng]n=mat(0.03,0.0325,0.035,0.0375,0.04,0.0425,0.045,0.0475,0.05,9,1)[/MATH]
Adding a rather small number to the last number (order of magnitude of computing precision ~15 decimal place) might solve this.
Regards,
Radovan
I think it is due to the machine floating point rounding error. Here is the possible explanation of it.
[MATH=eng]n:range(0.03,0.05+10^{-16},0.0325)[/MATH]
[MATH=eng]n=mat(0.03,0.0325,0.035,0.0375,0.04,0.0425,0.045,0.0475,0.05,9,1)[/MATH]
Adding a rather small number to the last number (order of magnitude of computing precision ~15 decimal place) might solve this.
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#3 Опубликовано: 30.11.2012 19:51:51
Thanks Radovan! That worked (though I'm somewhat concerned that an error like this popped up in the first place).
Brett
Brett
#4 Опубликовано: 30.11.2012 20:41:26
I agree with Radovan that this feature is not exactly a bug. However, testing the loop exit condition with some tolerance halfway between the iterator increment and machine precision would be a default that might perhaps meet the intent of most users. Then ugly workarounds could be avoided.
Martin Kraska
Pre-configured portable distribution of SMath Studio: https://en.smath.info/wiki/SMath%20with%20Plugins.ashx
#5 Опубликовано: 01.12.2012 01:46:06
I think the easiest (and perhaps cleaner) workaround is the alternate method I included in the attachment. By using a For loop with a dummy (integer) index variable (e.g., i) run through a range of 1 to 9, then under the For loop create the vector n in an equation using the index variable.
For i:=1..9
n:=0.03+(i-1)*0.0025
For i:=1..9
n:=0.03+(i-1)*0.0025
#6 Опубликовано: 01.12.2012 06:51:28
The same without for loop:
[MATH lang=ENG]0.03+0.0025*(range(0,8))=mat(0.03,0.0325,0.035,0.0375,0.04,0.0425,0.045,0.0475,0.05,9,1)[/MATH]
Both versions of the workaround obfuscate the upper loop limit, that's why I would like the range(3) function to be modified. However, the workarounds make the iterator increment more obvious. Would perhaps be fine to have an alternative range(3) with range(start,stop,step) displaying as
start..stop by step
[MATH lang=ENG]0.03+0.0025*(range(0,8))=mat(0.03,0.0325,0.035,0.0375,0.04,0.0425,0.045,0.0475,0.05,9,1)[/MATH]
Both versions of the workaround obfuscate the upper loop limit, that's why I would like the range(3) function to be modified. However, the workarounds make the iterator increment more obvious. Would perhaps be fine to have an alternative range(3) with range(start,stop,step) displaying as
start..stop by step
Martin Kraska
Pre-configured portable distribution of SMath Studio: https://en.smath.info/wiki/SMath%20with%20Plugins.ashx
1 пользователям понравился этот пост
Davide Carpi 01.12.2012 09:08:00
#7 Опубликовано: 01.12.2012 09:09:39
WroteThe same without for loop:
[MATH lang=ENG]0.03+0.0025*(range(0,8))=mat(0.03,0.0325,0.035,0.0375,0.04,0.0425,0.045,0.0475,0.05,9,1)[/MATH]
Both versions of the workaround obfuscate the upper loop limit, that's why I would like the range(3) function to be modified. However, the workarounds make the iterator increment more obvious. Would perhaps be fine to have an alternative range(3) with range(start,stop,step) displaying as
start..stop by step
I agree with Martin :d
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
1 страниц (7 вхождений)
-
Новые сообщения
-
Нет новых сообщений