Threaded Mode | Linear Mode

Thomas Klemm · 01-22-2014, 06:02 AM

A little late to the party. A variant of Didier's solution:

Code:

01 LBL A

02 1/x

03 STO+ X

04 x<> L

05 INC

06 RCL/ L

07 END

Cheers
Thomas

walter b · 01-22-2014, 07:04 AM

(01-22-2014 05:47 AM)Thomas Klemm Wrote: There's a left reply button?

In a way, yes, there's a reply button left (over by some folks) Wink

Didier Lachieze · 01-22-2014, 07:15 AM

Well, the use of the different reply or quote buttons is meaningful only in the Threaded Mode.
I think that most people (including me) use the Linear Mode to browse threads, and in this mode whatever the way you choose to reply to a post, it makes no difference as the posts are ordered by time stamps.

walter b · 01-22-2014, 08:16 AM

(01-22-2014 07:15 AM)Didier Lachieze Wrote: I think that most people (including me) use the Linear Mode to browse threads, and in this mode whatever the way you choose to reply to a post, it makes no difference as the posts are ordered by time stamps.

(Emphasis added.) Sounds like the difference between progress and regress. Everybody is free to use whatever (s)he likes, of course. We may also decide to drop punctuation / grammar / orthography since most people forget it anyway so we think it makes no difference. Personally, I vote for pursuing another level of clarity in a forum devoted to math, science, and the like. YMMV

d:-/

Didier Lachieze · 01-22-2014, 08:46 AM

The issue I have with the Threaded Mode as it is implemented in this new forum is that it shows only one post at a time and doesn't highlight the new posts, while the Linear Mode shows the content of several posts on the same page which I found much easier to use. If there are any options to change this I would like to know them.
I agree that the old forum threaded mode would be better but this not what we have in the new forum, so I'll stick with the Linear Mode which btw is the default mode, this is why I think it is the one used my the majority of people.

Dieter · 01-22-2014, 01:12 PM

(01-21-2014 04:07 PM)Didier Lachieze Wrote: Well, here is a solution working on both the 42S and WP 34S, not limited to integers and where I don't see the rounding error highlighted above:

Code:

00 {15-Byte Prgm} 01 LBL "GS" 02 X^2 03 RCL+ ST L 04 1/X 05 RCL+ ST X 06 1/X 07 END

Have you tried n = 7 ?-)

Consecutive 1/x commands are prone to roundoff errors. I do not have a safe five-step solution, but if one additional step is okay, this should yield accurate results:

Code:

01 LBL "GS"

02 X^2

03 RCL+ L

04 SIGN

05 STO+ X

06 STO/ L

07 X<> L

08 END

Dieter

Dieter · 01-22-2014, 01:20 PM

(01-22-2014 06:02 AM)Thomas Klemm Wrote: A little late to the party. A variant of Didier's solution:

Code:

01 LBL A 02 1/x 03 STO+ X 04 x<> L 05 INC 06 RCL/ L 07 END
Cheers
Thomas

Have your tried n = 11, 12, 13 or 14? The last digit may be off by one or two units.
So a final ROUNDI is recommended, which makes a total of six steps. ;-)

Dieter

Gerson W. Barbosa · 01-22-2014, 05:27 PM

(01-22-2014 01:12 PM)Dieter Wrote:
(01-21-2014 04:07 PM)Didier Lachieze Wrote: Well, here is a solution working on both the 42S and WP 34S, not limited to integers and where I don't see the rounding error highlighted above:

Code:

00 {15-Byte Prgm} 01 LBL "GS" 02 X^2 03 RCL+ ST L 04 1/X 05 RCL+ ST X 06 1/X 07 END

Have you tried n = 7 ?-)

Consecutive 1/x commands are prone to roundoff errors. I do not have a safe five-step solution, but if one additional step is okay, this should yield accurate results:

Code:

01 LBL "GS" 02 X^2 03 RCL+ L 04 SIGN 05 STO+ X 06 STO/ L 07 X<> L 08 END

Dieter

What is wrong with 28.0000000001? That's a perfect 28 for all practical purposes :-)
Of course the original formula (n^2 + n)/2 is better because it always yields exact results for integer arguments (even when using binary number formats), but occasional errors of a few ULP's are acceptable (and expected) when using a digital computer or calculator, IMHO.

Regards,

Gerson.

Thomas Klemm · 01-22-2014, 06:35 PM

(01-22-2014 01:20 PM)Dieter Wrote: Have your tried n = 11, 12, 13 or 14? The last digit may be off by one or two units.
So a final ROUNDI is recommended, which makes a total of six steps. ;-)

Dieter

Depends on what you declare as the last digit. I get the following results: 66, 78, 91, 105. The difference to the exact values are in the order of \(10^{-14}\) or \(10^{-32}\) depending on whether DBLOFF or DBLON is used. Interestingly the result is exact for n = 14 in both cases.
Probably I would't care much as long as I don't notice the difference in the display.

Cheers
Thomas

Dieter · 01-22-2014, 08:27 PM

(01-22-2014 06:35 PM)Thomas Klemm Wrote: Depends on what you declare as the last digit.

Simply the last one that X can hold. The 16th digit in SP resp. the 34th in DP.

(01-22-2014 06:35 PM)Thomas Klemm Wrote: I get the following results: 66, 78, 91, 105.

These are not the results. It's just what you can see in the display. ;-)

(01-22-2014 06:35 PM)Thomas Klemm Wrote: The difference to the exact values are in the order of \(10^{-14}\) or \(10^{-32}\) depending on whether DBLOFF or DBLON is used. Interestingly the result is exact for n = 14 in both cases.

Yes, the result for 14 is exact - I used 12-digit precision instead of 16. On the other hand the result for n = 13 is off by three ULP.

(01-22-2014 06:35 PM)Thomas Klemm Wrote: Probably I would't care much as long as I don't notice the difference in the display.

Whoaaahh... no way! This is not what the 34s was designed for. A lot of effort was put into the algorithms to make sure that at least in SP mode all 16 digits are exact. "Who cares about the last four" would not have been acceptable. Especially if non-integer results are returned where the exact result must be integer. Just my 2 Eurocents.

Dieter