HP calcs are really not that accurate..

12032017, 11:40 AM
Post: #41




RE: HP calcs are really not that accurate..  
12032017, 01:45 PM
Post: #42




RE: HP calcs are really not that accurate..
(12032017 10:03 AM)emece67 Wrote:(12022017 07:42 AM)DA74254 Wrote: And yes, I know exactly how big my land plot is in square plancks (just over 5,5x10^72) Finally someone noticing it. Wikis are great, Contribute :) 

12032017, 02:15 PM
Post: #43




RE: HP calcs are really not that accurate..
(12032017 01:45 PM)pier4r Wrote:(12032017 10:03 AM)emece67 Wrote: Thus, apparently, you only needed 2 digits to measure your plot in square planks. Ok, then.. 5.5239270495615041346253643432252334828540904763434087809926093365504231\ 804817592757697276389655441007940097088632679222802317397420429653488735108049\ 431522283055306025755503308162972536920967090801455644232660234663533541930694\ 817334452387637360300940472628380640156082840510901474744449309617737322204628\ 587857751372514370713807275201882769301371525005286841080723750834087309062435\ 786357479267274998838754526213738836620730505474652837615093166252526834316754\ 046480271470039410437409593057379145134933345546416041604225885527104187396816\ 222529775627122498896098356291836153104596440768891614076851135059293733838206\ 324717202805921738614097762147662658563248581721585263902179318564270997228015\ 355171051818799271443241875167662659776580186704352442235721802530022563019264\ 476709810881299909889223152355355454806291706563321136110714040551396736772884\ 815235066188761998588231596924493632289988054229591203322875289740833929857937\ 532990991958317041160217176167458475693651120361566485792429849638653120217264\ 03334754862313137E+72 Esben 28s, 35s, 49G+, 50G, Prime, SwissMicros DM42 Elektronika MK52 & MK61 

12032017, 07:33 PM
Post: #44




RE: HP calcs are really not that accurate..
(12032017 08:54 AM)DA74254 Wrote:(12022017 11:51 PM)Claudio L. Wrote: newRPL commercial..I've been looking at that site every now and then. I don't mean to pollute this thread with any more ads, but yes, 39gs/40gs/49g+/50g for now. Thanks for the interest. 

12032017, 08:05 PM
Post: #45




RE: HP calcs are really not that accurate..
(12032017 02:31 AM)AlexFekken Wrote: My previoius post reminded me of literally the first two basic principles that I learned when I started studying physics (and mathematics) at university in 1976: Totally meaningless without units? That's not the physics they taught me. The error margin I agree, if you stick to physics. When you get to engineering, it's combined with many other uncertainty factors into a global safety factor, so it's not necessary to repeat and analyze each result's error margin, we know roughly what it is, and combined with all the other things that can go wrong, we establish what works or not. No need for a lot of digits precision though, we are talking large percentage factors... (12032017 02:31 AM)AlexFekken Wrote: But still, should we not have an abundance of (freely available) tools now to do, for example, interval arithmetic? And should these not be the standard in scientific education by now. Clearly, this is much more fundamental and important than e.g. CAS or graphing capabilties. Sounds like a nice challenge... I'll start thinking about this, you might see it implemented in 6 months or so in... [that project I mentioned a million times]. 

12032017, 08:15 PM
Post: #46




RE: HP calcs are really not that accurate..
"There are four properties of computers that are relevant to their use in the
numerical solution of problems of algebra and analysis. These properties are causes of many pitfalls: (i) Computers use not the real number system, but instead a simulation of it called a "floatingpoint number system." This introduces the problem of roundoff. (ii) The speed of computer processing permits the solution of very large problems. And frequently (but not always) large problems have answers that are much more sensitive to perturbations of the data than small problems are. (iii) The speed of computer processing permits many more operations to be carried out for a reasonable price than were possible in the precomputer era. As a result, the instability of many processes is conspicuously revealed. (iv) Normally the intermediate results of a computer computation are hidden in the store of the machine, and never known to the programmer. Consequently the programmer must be able to detect errors in his process without seeing the warning signals of possible error that occur in desk computation, where all intermediate results are in front of the problem solver. Or, conversely, he must be able to prove that his process cannot fail in any way". Pitfalls in Computation, or Why a Math Book Isn't Enough by George E. Forsythe (Stanford University) 

12032017, 09:53 PM
Post: #47




RE: HP calcs are really not that accurate..
(12032017 02:31 AM)AlexFekken Wrote: But still, should we not have an abundance of (freely available) tools now to do, for example, interval arithmetic? How would you automate calculation with intervals? Without knowing the actual distribution of each variable, and without knowing which ones are independent and which ones are not, those calculations would be meaningless. I think we're still stuck with leaving error analysis to humans... 

12032017, 10:41 PM
Post: #48




RE: HP calcs are really not that accurate..
(12032017 09:53 PM)Thomas Okken Wrote: How would you automate calculation with intervals? Without knowing the actual distribution of each variable, and without knowing which ones are independent and which ones are not, those calculations would be meaningless.You are right, it is not that straightforward. Which is why I (sneakily) switched from talking about error margins to interval arithmetic. Interval arithmetic should not be a problem (technically) and it should at least give you a rough idea of how fast errors could be propagating. Better than lying with either hidden digits or unknown rounding errors. 

12032017, 10:42 PM
Post: #49




RE: HP calcs are really not that accurate..
(12032017 08:05 PM)Claudio L. Wrote: Totally meaningless without units?OK I admit: not all of them, just the vast majority... (12032017 08:05 PM)Claudio L. Wrote: Sounds like a nice challenge... I'll start thinking about this, you might see it implemented in 6 months or so in... [that project I mentioned a million times].Looking forward to it. Please keep Thomas's caveat in mind... 

12032017, 11:18 PM
Post: #50




RE: HP calcs are really not that accurate..
(12032017 08:05 PM)Claudio L. Wrote: Sounds like a nice challenge... I'll start thinking about this, you might see it implemented in 6 months or so in... [that project I mentioned a million times]. By the way, I am serious enough to buy an HP 50g (while they are still reasonably priced) if you are serious about this. I assume you are talking about something like interval arithmetic in newRPL...? So are you serious? 

12032017, 11:18 PM
Post: #51




RE: HP calcs are really not that accurate..
(12032017 09:53 PM)Thomas Okken Wrote: How would you automate calculation with intervals? Without knowing the actual distribution of each variable, and without knowing which ones are independent and which ones are not, those calculations would be meaningless. I think we're still stuck with leaving error analysis to humans... Be very conservative and watch the intervals blow out to infinity. There are interval libraries. MPFI based on MPFR seemed good when I looked some time back. Pauli 

12032017, 11:29 PM
(This post was last modified: 12032017 11:31 PM by AlexFekken.)
Post: #52




RE: HP calcs are really not that accurate..
(12032017 11:18 PM)Paul Dale Wrote: Be very conservative and watch the intervals blow out to infinity.At least then you have some confirmation then that your answer is probably meaningless. Of course for purely mathematical calculations you could start with a very large number of digits, e.g. more than 256 :), as it usually takes a while before you actually get to infinity. EDIT: (12032017 11:18 PM)Paul Dale Wrote: There are interval libraries. MPFI based on MPFR seemed good when I looked some time back.Thanks, now let's see if there will be a calculator version soon. 

12032017, 11:39 PM
Post: #53




RE: HP calcs are really not that accurate..
There are lots of convergent interval algorithms. While intervals do use conservative rounding estimates, there are two common operations that shrink intervals. The first is the obvious division by a constant. (A,B)/2 becomes (A/2, B/2) with A/2 being rounded down and B/2 being rounded up. The new interval is smaller than the original (not twice as small though.)
The second, and not as obvious shrinking algorithm is the interval Newton's method. One starts with an interval (A,B) which is guaranteed to cover the answer; next the interval Newton is applied (it's not just applying Newton's method with interval rounding to the endpoints; there is some other stuff that can be done but I don't remember all of it.) One gets a new interval (C,D) that also includes the solution. This interval may actually be larger than the input interval. (Magic Manipulation Alert) As both (A,B) and (C,D) include the desired point, the intersection of the intervals must also include the solution. So the interval (Max(A,C), Min(B,D)) (no rounding involved) must also contain the solution. In one dimension, this method always converges (unlike ordinary Newton) and provides a convergent sequence of intervals bracketing the solution. The convergence isn't guaranteed in several dimensions though. 

12042017, 12:00 AM
Post: #54




RE: HP calcs are really not that accurate..
(12032017 11:39 PM)ttw Wrote: there are two common operations that shrink intervals And any function with the absolute value of the derivative (uniformly) less than 1 should do that too. Chosing the right algorithms (e.g. forward vs backward iterations) will be important to keep the interval sizes under control. Of course this has always been the case but interval arithmetic would show the impact more clearly, i.e. it would help making the right choices and justifying them... 

12042017, 01:22 AM
Post: #55




RE: HP calcs are really not that accurate..
To me, one of the more interesting ideas in interval arithmetic is the ability to use intersections (and unions) of guaranteed solutioncontaining intervals. Pointvalued Newton does not guarantee convergence compared to intervalvalued Newton which does.


12042017, 02:06 AM
Post: #56




RE: HP calcs are really not that accurate..  
12042017, 02:16 AM
Post: #57




RE: HP calcs are really not that accurate..  
12042017, 02:24 AM
(This post was last modified: 12042017 02:28 AM by AlexFekken.)
Post: #58




RE: HP calcs are really not that accurate..
(12042017 02:16 AM)Thomas Okken Wrote: Newton's method not guaranteed to converge? That's news to me. Could you elaborate? As I remember it, it is only garanteed to converge when you start "close enough" (and the function smooth enough of course) because the function that you iterate is a (local) contraction with the zero as its fixed point. Global convergence is not garanteed unless you have additional (global) constraints. Will see if I can find an example. EDIT: https://en.wikipedia.org/wiki/Newton%27s...e_analysis 

12042017, 02:38 AM
Post: #59




RE: HP calcs are really not that accurate..
Yes, certain conditions have to be met in order for convergence to be guaranteed. That's highschool math. What changes when you calculate with intervals?


12042017, 02:56 AM
Post: #60




RE: HP calcs are really not that accurate..
(12042017 02:38 AM)Thomas Okken Wrote: Yes, certain conditions have to be met in order for convergence to be guaranteed. That's highschool math. What changes when you calculate with intervals? You need to add an essential additional requirement: that the starting interval contains the solution/fixed point. Of course if you have such an interval then bisection or a combination of bisection and Newton would also garantee convergence to a solution. But I am not sure why the 'Starting point enters a cycle' situation could not occur and prevent convergence. Perhaps someone should try f(x)=x^32x+2 with an interval that includes 0 and 1... (Thinking a bit more) since 0 is mapped to 1 and 1 to 0 they will be in every iteration of the interval. I think that disproves it: intervalNewton does not necessarily converge either. 

« Next Oldest  Next Newest »

User(s) browsing this thread: joeres, 1 Guest(s)