radical false

[Travis Bower]

I tried to verify rationalizing the denominator.  I think I did it correctly ;^)

but I was met with ''false".

I await your explanation.

Try typing in 1/sqrt3 = (sqrt3) / 3

[Sean Bird]

The pictures helped make it clear that either your settings are set for 'approximate' or you are not using the TI-Nspire CAS.
I got a response of 'true' when using CAS.
The numeric Nspire returns a decimal answer for radicals, but the CAS returns a symbolic answer.

- Sean Bird
Indianapolis, IN

[mpowell]

I looks like it's a bug in the OS. You should let Ti know to see if
the can fix it.
I did it on mine, I got the same results.

http://education.ti.com/educationportal/sites/US/nonProductSingle/global_forms_customersvcform.html

Their email address is ti-c...@ti.com

On Sep 8, 2:18 pm, Travis Bower <tbo...@dphs.org> wrote:
> I tried to verify rationalizing the denominator.  I think I did it correctly
> ;^)

> but I was met with ''*false*".

> I await your explanation.
> Try typing in 1/sqrt3 = (sqrt3) / 3
>

>  09-08-2010 Image002.jpg
> 24KViewDownload
>
>  09-08-2010 Image001.jpg
> 27KViewDownload
>
>  rat denom.tns
> 2KViewDownload

[Sean Bird]

Here is a picture.

[tmb-Travis]

Sean,
your picture did not show up--at least not on my imac at home.
[attaching screen shots really helps. do others agree?]
I am using numeric non-cas.

If a bug, they will probably email me; they have before. [they are
part of our google group]

On Sep 8, 6:53 pm, Sean Bird <covenantb...@gmail.com> wrote:
> Here is a picture.
>
>
>
> On Wed, Sep 8, 2010 at 9:24 PM, Sean Bird <covenantb...@gmail.com> wrote:
> > The pictures helped make it clear that either your settings are set for
> > 'approximate' or you are not using the TI-Nspire CAS.
> > I got a response of 'true' when using CAS.
> > The numeric Nspire returns a decimal answer for radicals, but the CAS
> > returns a symbolic answer.
>
> > - Sean Bird
> > Indianapolis, IN
>
> > On Wed, Sep 8, 2010 at 6:18 PM, Travis Bower <tbo...@dphs.org> wrote:
>
> >> I tried to verify rationalizing the denominator.  I think I did it
> >> correctly ;^)

> >> but I was met with ''*false*".

[Nelson Sousa]

Hi.

These screenshots were made on TI-Nspire CAS with exact/approx mode set as Auto.

Cheers,

Nelson

--
To post to this group, send email to tins...@googlegroups.com
To unsubscribe send email to tinspire+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
The tns documents shared by group members are archived at
http://lafacroft.com/archive/nspire.php

[Nelson Sousa]

And this one was made with  Exact/Approx set as Approximate.

There's a rounding error (which obviously occurs in every approximate calculation) on the 14th decimal place. Therefore the condition returns false. TI-Nspire CAS works with a 14 digit precision for decimal numbers.

This is what Sean was talking about, it's not a bug.

My personal reccommendation for TI-Nspire CAS users: always have your unit set-up for Auto. Then when you want an approximate answer just add a decimal point next to any integer (1./2 returns 0.5 in auto mode) or press Ctrl+Enter instead of Enter to get an approximation of a specific result.

Cheers,

Nelson

[mpowell]

Wow, Definitely a bug in the OS. I also get the same results in my Ti-
nSpire...

> >> To unsubscribe send email to tinspire+u...@googlegroups.com<tinspire%2Bunsu...@googlegroups.com>

> >> For more options, visit this group at
> >>http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> >> The tns documents shared by group members are archived at
> >>http://lafacroft.com/archive/nspire.php
>
>
>

>  screenshot3.jpg
> 21KViewDownload

[Nelson Sousa]

Errrrr.... no, it isn't. It's a rounding error. Which occurs in every algorithm.

Read above replies, please.

Nelson

[Sean Bird]

It isn't a bug when it does what it is suppose to do. With the numeric TI-Nspire, you get a numeric decimal approximation for radicals. With the CAS you will get the desired 'true' result, because it is giving a symbolic exact answer. See Nelsons pictures and explanation for why it is not an OS bug.
Perhaps it could be a future requested feature, but it isn't a glitch.

On Thu, Sep 9, 2010 at 1:35 PM, mpowell <mpo...@rogershsa.com> wrote:

Wow, Definitely a bug in the OS. I also get the same results in my Ti-
nSpire...

On Sep 9, 3:12 am, Nelson Sousa <nso...@gmail.com> wrote:
> And this one was made with  Exact/Approx set as Approximate.
>
> There's a rounding error (which obviously occurs in every approximate
> calculation) on the 14th decimal place. Therefore the condition returns
> false. TI-Nspire CAS works with a 14 digit precision for decimal numbers.
>
> This is what Sean was talking about, it's not a bug.
>
> My personal reccommendation for TI-Nspire CAS users: always have your unit
> set-up for Auto. Then when you want an approximate answer just add a decimal
> point next to any integer (1./2 returns 0.5 in auto mode) or press
> Ctrl+Enter instead of Enter to get an approximation of a specific result.
>
> Cheers,
> Nelson
>

> On Thu, Sep 9, 2010 at 12:07, Nelson Sousa <nso...@gmail.com> wrote:
>
> > Hi.
>
> > These screenshots were made on TI-Nspire CAS with exact/approx mode set as
> > Auto.
>
> > Cheers,
> > Nelson
>

[tmb-Travis]

You guys know a lot more about this than I.
I thought the two would round to the same amount?? and thus return a
'true' [i tried to do float 12 and fix 12 on Scratchpad to see more
decimals, but that did not work for me]

numeric non-cas
1/sqrt2 = sqrt2 / 2 yields true
yet replacing the 2 with 3 yields false. [I even did an x and stored
various values]
So sometimes it works?
Maybe a more robust algorithm is needed? [or maybe I should get a
CAS ;^) lol

> > > >> > >> Try typing in 1/sqrt3 = (sqrt3) / 3- Hide quoted text -
>
> - Show quoted text -

[Joaquim Marques]

e^(pi * sqr 163) = 262537412640768743,99999999999925007...

(e^(pi * sqr 163) - 744) ^ (1/3) = 640319,99999999999999999999999939031...

...

Can you think that a better algorithm tells that all this type of numbers aren't integers?

It's impossible. This isn't an algorithmic problem, this is a mathematical problem without solution.


Joaquim

=====================
Joaquim de Fontes Marques
Rua de Aldriz, 54
4505-073 Argoncilhe
PORTUGAL
=====================

--
To post to this group, send email to tins...@googlegroups.com
To unsubscribe send email to tinspire+u...@googlegroups.com

[Joe]

If it's not a bug, are we to understand that the wrong answer being
returned is not wrong because nspire was designed to return that
answer which makes the wrong answer right and the problem actually
with the people who wrongly think that it should return the right
answer? Gee, that aught to be a really big seller.

> > > >> To unsubscribe send email to tinspire+u...@googlegroups.com<tinspire%2Bunsubscribe@googlegroups.c­om>
> > <tinspire%2Bunsu...@googlegroups.com<tinspire%252Bunsubscribe@googlegro­ups.com>

>
> > > >> For more options, visit this group at
> > > >>http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> > > >> The tns documents shared by group members are archived at
> > > >>http://lafacroft.com/archive/nspire.php
>
> > >  screenshot3.jpg
> > > 21KViewDownload
>
> > --
> > To post to this group, send email to tins...@googlegroups.com

> > To unsubscribe send email to tinspire+u...@googlegroups.com<tinspire%2Bunsubscribe@googlegroups.c­om>

> > For more options, visit this group at
> >http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> > The tns documents shared by group members are archived at

> >http://lafacroft.com/archive/nspire.php- Hide quoted text -

[Nelson Sousa]

Didn't any of you guys take a numerical analysis course in college????

Algorithm error, numerical rounding, error maximization, stuff like that?

On any numerical computer, 1/3 = 0.3333333333333 up to the machine's precision.

Now multiply by 3. You get 0.999999999999999 up to machine precision.

Because most machines work with more digits than they display, 0.99999999999999 is displayed as 1.

Now subtract 1. You get -1*10^-n, where n is the machine's precision.

(number of digits above is meant to be the same everywhere).

This happens on EVERY numerical machine. It's too bad that numerical errors get in your way, that's why algorithms take over to try to minimize them and stop them from displaying. But errors are inherent to ANY algorithm.

On a non numeric machine floating numbers should NEVER be compared using =. Numerical results are always approximations. The comparison is made by subtracting the two numbers. If abs(difference) is smaller than a given tolerance then it should be treated as 0.

In all the above, machine doesn't mean a calculator. It means ANY computer.

Nelson

[Nelson Sousa]

Oh, another thing I just remembered, about the fact that 1/sqrt(2)=sqrt(2)/2 gives true, while with 3 gives false.

1/7 = 0.142857 ... (the pattern 142857 repeats forever).

2/7 = 0.285714 ... (the pattern is the same, but rotated, starts with 2)

3/7 = 0.428571 ...  (same)

and so on.

So, let's work with 6 digits precision, shall we? (it doesn't matter how many, the same principle holds).

1/7 = 0.142857 (rounded down)

Multiply by 4 and get 0.571428

4/7 = 0.571829 (rounded up)

If you compare the two results (it's relevant which operations are done first, of course), you would get false.

bug? no. Just a simple consequence of working with finite precision.

Nelson

[Nelson Sousa]

* 4/7 = 0.571429 (rounded up)

[Joe]

Excellent job of explaining the problem and I for one appreciate your
efforts very much. The question then becomes, are there ways of
compensating for that inherent problem with software, for example if
the rounding error is always in the 14th digit then just use 13 digits
for the comparison? What I am seeing here is the problem of trust.
If one can not trust the true/false answer returned, then isn't it
better to not have that capability at all?
P.S. I am not trying to be difficult, I am just trying to understand
if the issue can be cleared up with some sort of software patch, of if
ultimately it would be better to simply eliminate the feature that can
not be trusted to return the correct answer? Again, thanks for the
explanation.

> >>> <tinspire%2Bunsubscr...@googlegroups.c­om>
> >>> > > <tinspire%2Bunsu...@googlegroups.com<tinspire%252Bunsubscribe@googlegro­ups.com>

> >>> <tinspire%252Bunsubscribe@googlegro­ups.com>
>
> >>> > > > >> For more options, visit this group at
> >>> > > > >>http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> >>> > > > >> The tns documents shared by group members are archived at
> >>> > > > >>http://lafacroft.com/archive/nspire.php
>
> >>> > > >  screenshot3.jpg
> >>> > > > 21KViewDownload
>
> >>> > > --
> >>> > > To post to this group, send email to tins...@googlegroups.com
> >>> > > To unsubscribe send email to tinspire+u...@googlegroups.com<tinspire%2Bunsubscribe@googlegroups.c­om>

> >>> <tinspire%2Bunsubscr...@googlegroups.c­om>

> >>> > > For more options, visit this group at
> >>> > >http://groups.google.com.au/group/tinspire?hl=en-GB?hl=en-GB
> >>> > > The tns documents shared by group members are archived at

> >>> > >http://lafacroft.com/archive/nspire.php-Hide quoted text -

[Nelson Sousa]

Don't worry, I totally understand your point of view.

The short answer is: no. Unfortunately.

But the question is perhaps not the most convenient. The problem is not the trust on true/false. The answer is actually false, the Nspire got that right. The problem is you cannot, on floating point arithmetic with fixed precision, trust on = comparisons.

Every single comparison must have a specified tolerance level. = is exactly that. =. One cannot set = to mean "approximately equal to". And with decimal numbers every comparison should be an "approximately equal to". Meaning that you should look at the difference between two numbers and rely on intuition/knowledge to decide whether those two numbers should be considered equivalent or not (example: I have a bunch of programs that, depending on the conditions of the problem, set a tolerance of 10^-8, others set it at 10^-10 and others at 10^-5).

Back to the question in hand...

We have 14 digits of precision. Division doesn't lose precision, therefore the error is maximized by 10^-13 (if we're dividing small things by small things - see below)

But a power of a fraction, being computed as the power of an approximation, will have a larger error.

The sine of a fraction, being computed as a power series expansion of some sort will have a larger error...

Each and every single operation you do will have a different error, either of the magnitude of the precision or bigger. Good algorithms have errors that increase slowly with the loss of precision of the inputs, but no algorithm exists that, in general, can assure that precision will remain the same. And in some cases the best algorithms available (btw, the first person to suggest that better algorithms must be found will get a list of PhD positions in numerical analysis as a reply) may ensure that you "only" lose half of the initial precision, meaning that if data has 14 digits of precision the output will have a whooping 7.

Because of this, the Nspire only displays 12 digits. To account for errors 1 or 2 orders of magnitude larger than the machine precision. Older TI graphing models had 10 digits visible but only 11 internal, which caused more numerical approximation errors to be visible; If memory serves me right, here's the full list:

TI-80, TI-81, TI-82: 10 displayed, 11 internal

TI-83, TI-83+, TI-84+: 10 displayed, 12 internal (not sure whether the 83 didn't have only 11 internal)

TI-85, TI-86: 12 displayed, 14 internal

TI-89, TI-92, Voyage 200: arbitrary precision; 12 displayed, 14 internal in floating point.

TI-Nspire: 12 displayed, 14 internal

TI-Nspire CAS: same as 89, 92 and V 200

(can anybody confirm this? I'm not in my twenties anymore, memory for this kind of details sometimes fails me)

Again, back to the question in hand...

A numeric derivative of a "simple" function like sine, cosine, exponencial, will have a typical precision or, perhaps 8, 9 or 10 digits;

Numeric derivatives of tan(x) or ln(x) or rational functions will have a precision that depends on where are we computing it (degrades rapidly near discontinuity points).

Higher order derivatives behave worse and worse as order increases (and by worse I mean that if 1st order derivative loses 2 digits in precision, 4th order will lose 8!);

Taylor series are the worst when computed numerically because each term requires a higher order derivative, plus division by really large numbers!

Numerical integrals typically lose 2 or 3 orders of magnitude in precision, and can be worse when integrating "nasty" things.

And, to make matters worse, we have 14 digits, not 14 decimal places. Meaning that a numeric value of the order of 10^7 will have a precision of 10^-7. And the precision of the result is at best equal to the worst precision of the input.

So, the answer is no, it cannot be done (except by considering more and more cases into some "exceptional" behaviour and next time we'll be discussing questionable accuracy for other mathematical operations; and even so, those exception can be dangerously close to what may be considered CAS!). 

There's no way the TI-Nspire can decide when to consider two numbers close enough as equal or not. Plus, if one was to consider a=b if |a-b|<10^-13, for example, then Pi=3.1415926535898 should be considered equal to 3.1415926535899.

Meaning that to the question Pi=3.1415926535899 the answer should be true (and it's obviously false). But by the same reasoning, 3.1415926535899=3.1415926535900 should also be true (and, again, it's false). By transitivity, Pi=3.1415926535900 should be true.

And, (ah, la pièce de résistance), proceeding recursively, one could make the Nspire return true to the quesstion Pi=4. Which, by the way, could have been passed into law in the state of Indiana in the 1890s, but fortunately wasn't. ;)

I hope this helps clarifying things a bit.

Cheers,

[Joe]

"I hope this helps clarifying things a bit."

Yes, it does but because people unwittingly assume that the answers
that they get from a calculator are correct, I am thinking that a
warning should be prominantly posted on the screen warning the user
that 'for this type of problem the answer may be wrong.' Does that
seem reasonable?

> ...
>
> read more »- Hide quoted text -

[Nelson Sousa]

"people unwittingly assume that the answers

that they get from a calculator are correct"

This is not an issue with calculators. It happens with ANY machine that works with limited precision, being an 8088 Intel CPU from the 70s or a brand new iPad. And working beyond limited precision is a matter of developin CAS-like software, not something inherentely better on the CPUS.

You can never assume answers from any sort of computer are correct. Same goes for safe web browsing, you can't assume your browser is safe; same goes for space travelling, airplanes, nuclear power plants, health care systems. Whenever reliability is vital, correct answers are NOT assumed, they're verified by redundant systems. You're asking a reliability from the TI-Nspire or calculators in general that top notch industries throughout the world KNOW doesn't exist and work around it adding extra check points to make sure humans don't make the wrong assumptions (and every now and then they do and accidents happen).

The fact that a computer's answers have limited reliability, imposed by its internal precision and the precision and accuracy of its algorithms is perhaps the single most important issue you should be aware of. And even if in this case a warning is issued, there's always going to be another computation that someone, somewhere in the world, expects to be absolutely correct and will cause similar issues. It's just a computer. For all due purposes it's a stupid piece of machinery, knows nothing other than what was taught to it. You can't just teach it EVERY single possible case out there! Basically, in this case you're asking for the moon

Cheers,

Nelson

PS: by the way, the Questionable Accuracy warning already exists. It shows whenever the tolerance of an algorithm is not verified. But it can't be issued every single time, can it?

[John Hanna]

Time to throw this in…

 

“…The reason people have difficulty in learning to use a slide rule is likely to be that they do not understand the mathematics on which the instrument is based, or the formulas they are trying to evaluate. …”

-       Pickett Slide Rule Manual, © 1960

 

 

---

[Joe]

Sorry, I didn't mean that answers are correct by assumption, but that
it seems to be human nature for people to assume that a calculator
doesn't make mistakes. Your comment that "correct answers are NOT
assumed, they're
verified by redundant systems" is key. So should a questionable
answer be verified by another calculator brand, or Maple or
Mathematica, or do all these systems use similiar programs and
consequently would make the same mistake? How about using a cas model
to verify the non-cas models answers? I guess what I am asking is
what sort of verification other than hand calculations would you use
to verify an nspire answer?

On Sep 12, 6:18 am, John Hanna <johneha...@gmail.com> wrote:
> Time to throw this in…
>
> “…The reason people have difficulty in learning to use a slide rule is
> likely to be that they do not understand the mathematics on which the
> instrument is based, or the formulas they are trying to evaluate. …”
>
> -       Pickett Slide Rule Manual, © 1960
>
>   _____  
>

[Joaquim Marques]

If you need formal proof, you can use Isabelle.

http://www.cl.cam.ac.uk/research/hvg/Isabelle/index.html

It's free.


(Formal Proof > CAS > Numeric)

Joaquim

=====================
Joaquim de Fontes Marques
Rua de Aldriz, 54
4505-073 Argoncilhe
PORTUGAL
=====================

[Nelson Sousa]

Ai, ai, ai, Joe, there you go misquoting. I explicitly said "You can never assume answers from any sort of computer are correct". Not a calculator specifically. In fact, nothing of what's been told here, regardless of implications by various people in that direction, is specific to calculators, TI calculators or the TI-Nspire in particular.

Examples of fixed precision pieces of software, that will have rounding errors (not in this specific example):

- All non CAS TI calculators (meaning, all but TI-89 family, TI-92 family, Voyage 200 family and TI-Nspire CAS)

- All non CAS Casio calculators (meaning all but Classpad and Algebra Fx 2.0)

- All non CAS HP calculators (meaning all but 48, 49 and 50 families - not sure if there are other CAS HP models, I think not)

- Windows calculator;

- All scientific calculators without CAS (I think this means ALL scientifc calculators in the world, but I'm not sure)

- All CAS systems when on approximate  mode, or when approximate solutions are EXPLICITLY asked for (case in question, a TI-Nspire CAS on Approx mode) - this includes: Mathematica, Nspire CAS, Classpad, HP50G, Maple and any other piece of CAS software when you deliberately ask for an approximation

Examples of arbitrary precision systems, that won't have this kind of rounding errors:

- TI-Nspire CAS, 89 family, 92 family, Voyage 200

- Classpad family;

- Algebra Fx 2.0

- HP 48, 49 and 50 families

- Mathematica

- Maple

- Any other piece of CAS software

Exception is when you ask for approximate answers (see above)

The above refers only to NUMERIC APPROXIMATION errors. Doesn't imply that CAS systems always provide correct answers, only means that on numerical calculations where arbitrary precision is used, no rounding errors should be present (and as far as I know, there aren't in any of these). Means nothing about scope, performance or reliability of symbolic manipulation algorithms, all of which will have bugs, limitations and idiosyncracies.

Now, when I say "vital" systems, I mean things like: life-support; air traffic control; space travel; nuclear power plants, ... These are examples of VITAL applications that require redundant checking.

Getting your answers right on an exam? No, that's not vital. May be important. It's not vital. One can expect a calculator brand and the software programmers to do the best possible to provide accurate answers to the questions we ask. We cannot expect them to perform miracles, such as inventing new mathematics and doing things already proven impossible just to accommodate one's needs because we want to blindly trust whatever result we're given.

Plus, one of the things students are asked for in an exam is to provide CORRECT answers, not to simply quote a calculator's answer. If a student wants to rely solely on a calculator (ANY brand) or a piece of software, without the necessary reasoning to disregard things like immaginary temperatures and other oddities (and typos, syntax errors, misplaced parenthesis, etc.) ... well, no piece of technology and no top notch algorithm will save this student. No matter which safeguards you put in place.

Finally, form previous conversations we had in the group, I think you're a college maths teacher, right? And this is all new to you???

Nelson

[Nelson Sousa]

I meant "not necessarily in this specific example", instead of "not in this specific example".

[Nelson Sousa]

and even Isabelle will have its own limitations ;)

[Joaquim Marques]

of course.
Thanks to Godel!

Joaquim

=====================
Joaquim de Fontes Marques
Rua de Aldriz, 54
4505-073 Argoncilhe
PORTUGAL
=====================

[Jessica Kachur]

Nelson,

i suffered through that course and to this day still kringe whenever any one gets close to starting to even talk about eigen values and the like
 

Jess Kachur
Mathematics Teacher
Springfield High School, Springfield, Illinois
T3 Regional Instructor
Muka, CGC, TDI, Retired, CL2, CL3-F, CL3-S, CL3-H, TN-O, WV-N
and
Jibay, Sandy Acres lil' Phantom, CGC, CL4, CL4-F, CL4-S, CL4-H

---

From: Nelson Sousa <nso...@gmail.com>
To: tins...@googlegroups.com
Sent: Fri, September 10, 2010 4:11:09 AM

Subject: Re: [tinspire] Re: radical false