![]() (result: –2,7637.), which requires just 4 resp. In the above case the method I originally suggested starts with |t|=2,781. I assume there's something wrong with the initial guess for the Student quantile. Now imagine how fast this would run in compiled C-code. ![]() So I tried a program in user code, et voilà: less than 5 seconds (resp. For instance a simple case like t –1 (p=0,01, df=10) runs for more than 15 seconds on a hardware 34s. There are also some troubles with the 34s versions that have been mentioned earlier. (04-18-2014 07:12 PM)walter b Wrote: FYI, we've got a problem with the commands contained in DISTR. I suggest should be the default switch date (as usual in calendar calculations), and the user may specify any other. I do not see any reason why this should not get implemented. And as an additional benefit it extends the functionality in that it allows calculations based on a proleptic Julian or Gregorian calendar (cf. It allows correct results (WDAY, ΔDAYS, DAYS+) for all users. Something like a JGSET command seems to be not the worst idea. As already stated earlier: "accuracy is not optional". But the 31s can have a perfect implementation for correct results under all circumstances. JG1582 (which should be the 34s default) and JG1752 are better than nothing, and obviously memory restrictions on the 34s did not allow a better, complete solution. That's why it can't stay the way it is: the 31s currently returns dubious results because the Julian day number - which is used for three date-related commands - is calculated in a way that's wrong for most users. I don't see how Julian day numbers with all the bells and whistles never seen in any calculator before shall foster that. ![]() WP 31S shall be an entry level scientific (incorporating a subset of WP 34S firmware).
0 Comments
Leave a Reply. |