Wrong limit?

[whilealive]

Hi all.

I got these two different results for a limit (TInspire gets it right). Am I doing something wrong here or is this a bug?

   
   

Bests, Bruno

[salvomic]

If you use lim(expand(...)) it returns ½ also in the Prime

[Arno K]

Well, doing it by hand I get 1/4. Ups, I used a wrong formula, 4*2^n in the middle instead of 4^(2*n).
@Salvo: expand also gives 1/4 on my Prime.
@Bruno: rechecking the screenshots I saw that I used two different formulas
Arno

[salvomic]

(06-10-2016 03:25 PM)Arno K Wrote:  Well, doing it by hand I get 1/4, so TI is wrong and HP is correct.
@Salvo: expand also gives 1/4 on my Prime.
Arno

hi Arno, I used
\[ \lim_{x\to\infty}( \text{expand} (\frac{2^{4x}+4^{2x}+8^x}{4^{2x+1}})) \]
With FW 10077 it should be ½, later I'll control again, however (maybe I'm wrong)...

[Arno K]

As I inserted above I used the wrong formula, so this is a bug. Imho a very serious one as one usually uses commands like "lim" to keep oneself from these computations.
Arno

[salvomic]

(06-10-2016 03:49 PM)Arno K Wrote:  As I inserted above I used the wrong formula, so this is a bug. Imho a very serious one as one usually uses commands like "lim" to keep oneself from these computations.
Arno

I agree with you, Arno, a serious bug, apparently so simple but very insidious.
Salvo

[whilealive]

Thanks for checking. Yes, adding expand() fixes it for me, too. (also FW 10077 here)

Bruno

[roadrunner]

Xcas get's it wrong unless you simplify first. Maybe a Giac issue?

   

[parisse]

Fix done in source code, I will update the Xcas binaries next week.
It comes from missing simplifications between ln(8), ln(4) and ln(2) not from the limit algorithm itself.

[chromos]

(06-11-2016 08:24 AM)parisse Wrote:  Fix done in source code, I will update the Xcas binaries next week.

Although I don't use this advanced mathematics much, I want to say: thank you for very fast bug fixes.

[DrD]

(06-11-2016 08:24 AM)parisse Wrote:  Fix done in source code, I will update the Xcas binaries next week.
It comes from missing simplifications between ln(8), ln(4) and ln(2) not from the limit algorithm itself.

Do the missing simplifications of ln(x), in the limit() command, effect any other commands, (those that might rely on those same simplification code blocks); or is this just a local problem within the limit command?

Thanks for the quick fixes!

-Dale-

[retoa]

A part from the bug, the first image in Bruno's post is quite funny.
I don't know if you noticed that, but the app title is in german (Erweiterte Grafiken) and the error message is in french (Fonctionne seulement en mode radians...)
Menus are in german (Spch for Speichern)

So you have two different languages at the same time. (three if you count the Simplify menu)

How can it be?

[DrD]

(06-16-2016 07:16 AM)retoa Wrote:  How can it be?

One [possible] very corporate explanation: "honor diversity?"

-Dale-