Re: on-line calculator

David W. Cantrell wrote:

Julio Di Egidio <julio@xxxxxxxxxxxxx> wrote:
troymius wrote:

[...]

In the code, pi is only defined with a limited
precision (16 digits or
so), so to get a completely correct answer for
tan(pi/2) i would have
to implement some kind of a logic... I am not
sure
how to do that yet.

Easy answer: with (closed) interval arithmetic!

It's not quite as easy as you thought; see below.
Furthermore, I doubt that the OP would want his
calculator to give answers
as intervals.


Hmm, why not? For instance, on the built-in Win calculator I simply get a NaN, which is anyway not that useful. Conversely, from an interval to a float (say, for display purposes) you just need a MID function or something like that. Not to mention, again, the fact that as soon as you go to graphing results, you *have* to think in terms of intervals.

Moreover, given all that there is about closed computation and the bounding of errors, I really do not see where the problem is, unless you are referring at algebraic systems with infinite precision, and, even in that case, are results really *correct* in any case, given also implied errors in measurements (the OP is an engineer)?

Am I missing something (maybe in some broader picture)?



In that realm:

pi = 'exact-pi' +- err

or rather, pi is the (topologically closed)
interval:

pi = ['exact-pi'-err, 'exact-pi'+err]

With closed interval arithmetic, then you'd get the
(still closed)
interval:

tan(pi/2) = [overflow, infinity]

No. There would need to be a corresponding negative
interval unioned with
that (since the tangent function is negative for
arguments slightly larger
than pi/2).


Yes, that is right: as I said I didn't think out my "calculation" too much, I was just trying to hint at a possible approach, and one actually that to me is very powerful for (obvious?) reasons, including the relative easiness of implementation.

In any case, you make me curious: would I be right in thinking that a correct answer might have been (implying we are in IR*):

tan(pi/2) = [-oo,-owf] u [+owf,+oo] c [-oo,+oo]

so, by containment:

tan(pi/2) = [-oo,+oo]

-LV



David

Hope my "calculation" is correct as I did it from
the top of my head. In
any case, the idea behind it should be clear enough
once you also think
that, when graphing your results, you always end up
drawing rectangles...

Let me know if you need further pointers, and also
maybe note that I am
myself trying to build (although in my spare time)
a system for
parsing/calculating/graphing, based on closed
interval arithmetic, to
eventually put on the web. Maybe we could join the
efforts with an open
source/free software kind of project?

-LV

[...]
.

Relevant Pages

  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... precision numbers in oracle, you've got 38 decimal digits to play ... and with minimal coaxing perl will handle them as ... digits from a 32 bit floating point number - I'll go out on a limb ... and hazard that one can expect 12 or so digits from a 64 bit floating ...
    (perl.dbi.users)
  • RE: float bug? perl 5.8, DBI and oracle 10.2.0
    ... I would not characterise 32-bit signed integers as giving 10 digits ... truncate and tell people you get 9 digits of precision. ... perl 5.8, DBI and oracle 10.2.0 ... Floating point values are typically stored in 64 bits or sometimes 96 ...
    (perl.dbi.users)
  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... I would not characterise 32-bit signed integers as giving 10 digits ... truncate and tell people you get 9 digits of precision. ... perl 5.8, DBI and oracle 10.2.0 ... Floating point values are typically stored in 64 bits or sometimes 96 ...
    (perl.dbi.users)
  • Re: 15 Significant Digits Limitation a Mistake for Spatial Informa
    ... DP does not restrict to 15 decimal digits. ... Input and output precision are more tightly linked in Excel ... Decimal data type or roll your own extended precision data types. ...
    (microsoft.public.excel)
  • Re: Salamin-Brent algorithm
    ... fraction-representing digits, which is of course ... might have thought one could dispose of because ... since one's precision is so increasing with the ... S-B algorithm)? ...
    (sci.math)