Velocity Reviews > Extending Math Functions

# Extending Math Functions

Dr John Stockton
Guest
Posts: n/a

 06-24-2005
JRS: In article <(E-Mail Removed)>, dated
Fri, 24 Jun 2005 09:22:17, seen in news:comp.lang.javascript, Paul
Cooper <(E-Mail Removed)> posted :
>
>I am afraid you have just illustrated the point that John Stockton
>made - that it isn't as easy as that. Your functions will fail
>interestingly and undetectably in many cases - some could end up
>returning the result of taking the difference of two numbers very
>close in value, for example. The loss of precision would make the
>results meaningless. And of course, some may return the result of
>dividing a very large number by a very small number - again, with
>results depending on the behaviour of the floating point engine. Of
>course, the divide by zero error you mention will be caught, but other
>situations which result in disastrous loss of precision won't be.
>
>The text-book formulae are in most cases designed to illustrate the
>properties and derivation of the function, and are not a practical
>means of computing it reliably. Practical implementations have to take
>into account the problems of working with digital arithmetic, provide
>proper exception handling and guaranteed precision. That is why John
>Stockton suggested that creating and maintaining such a library was a
>task for a Mathematics or Computer Science group, not for an
>individual. I wouldn't take it on, and I am used to complex
>trigonometrical calculations.

Indeed. To illustrate : this expression is from the Help of several
versions of a widely-sold compiler family (not necessarily the latest
versions) :
ArcCos(x) = ArcTan (sqrt (1-sqr (x)) /x)

It is trigonometrically correct.

However, ArcTan always returns an angle within -90 to +90, whereas a
positive argument for ArcCos should return one of two values in that
range and a negative argument for ArcCos should return one of two values
in the other half of the circle.

They forgot that every positive real number has two square roots of
opposite sign, and that it is always necessary to choose the appropriate
one; whereas in that language sqrt, like Math.sqrt, always gives a non-
negative result.

The expression is computationally incorrect; other trigonometrical
expressions are also computationally correct.

I vaguely recall that ATAN2 may be better than ATAN as a primitive.

It could be possible to extend the Math object with bolt-on native code;
that would potentially be better, by allowing direct use of the FPU.

I can't recall whether I said this before, but I lived for a year at #54
of the road by which you work, if you are housed in SPRI.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

cwdjrxyz@yahoo.com
Guest
Posts: n/a

 06-25-2005

Paul Cooper wrote:
Practical implementations have to take
> into account the problems of working with digital arithmetic, provide
> proper exception handling and guaranteed precision.

There are many good programs written in Fortran and C++ as well as many
long discarded languages for evaluating the more common math functions.
These have built in checks and warning messages in many cases.These
programs often are fairly easy to adapt to JS. However one does not
always want the highest precision. In fact, if one is calculating math
functions within a deep nest, you need to use the least precision
possible for the problem to speed up very long calculations. This of
course requires a detailed analysis of the system at hand. Mathematica
5.1, for example, will allow you to select the number of places needed
for a function output.

If you are wanting to do math on the computer, and not the web, of
course you need to add C++, Fortran, or other higher level language
support, or you may be able to get by with Mathematica or something of
the sort. Unfortunately Mathematica 5.1 costs about \$US1800 new,
although Amazon is now having a sale in the \$1500 range. This is too
high a price for many indivaduals, although reduced rates are available
for students. There also is an expensive version of Mathematica you can
put on your server. However, here you must be very careful if you do
not have use of an entire server. Some math operations can use a huge
amount of server capacity. On a shared server, there often are
restrictions on the maximum percentage of capacity you can use at any
time. Exceeding this limit can result in huge bills or disconnection
until you resolve the problem. At least this is the way my domain host
works.

There is a free program, Dataplot, available from the NIST, the US
government standards organization, known as the NBS(National Bureau of
Standards) until fairly recently. See
http://www.itl.nist.gov/div898/software/dataplot/ . This is written in
Fortran, but compiled and ready to use on many different PC platforms
without adding a Fortran compiler. This program will evaluate a huge
number of even very uncommon functions. It will plot and display these
functions, or results for equations using functions. It will accept
input data and curve fit and do statistical analysis. The range of
types of statistical analysis is huge. I have found this program very
useful. It also can be installed on a server. Dataplot may not be as
fancy and do as many things as some of the expensive commercial
programs, but it does many things as well as many people need. It is
nice to have around when you want to check math you are doing using JS
for the web. I also believe the program is free to foreigners,
including the British, even though they are not US tax payers who
support the government organizations . I have had a little contact
with the NIST in the past and have been impressed by the quality of
most of their work. Unfortunately they have a very restricted budget
these days. Also the Nobel committee has been well impressed with the
quility of some of their work.

fox
Guest
Posts: n/a

 06-26-2005

Paul Cooper wrote:
> On Thu, 23 Jun 2005 21:27:12 -0500, fox <(E-Mail Removed)>
> wrote:
>
>
>>.
>>
>>>There is every benefit to adding at least 20 more standard browser Math
>>> objects. The standard hyperbolic and other functions that are used by
>>>even high school students are very easy to add. This should cost very
>>>little to do.

>>
>>adding hyperbolic functions to the current set would actually be an
>>exellent exercise for students to implement.
>>
>>it is not the job of language designers to provide all the specific
>>tools programmers will ever need, it it their job to provide the most
>>basic set of tools upon which programmers can build.
>>
>>anyway, the formula for hyperbolic transcendentals are easy to find and
>>just as easy to implement:
>>

>
> SNIP
>
>>The "telling" feature of every added hyberbolic function above is
>>"with(Math)" (everything you *need* is already there) and all that is
>>used is exp, log, sqrt, and/or one of the other methods being defined.
>>There is really nothing here complicated enough to merit having the
>>functions predefined in the Math object.
>>

>
>
>
> I am afraid you have just illustrated the point that John Stockton
> made - that it isn't as easy as that.

Actually, 1) I didn't *illustrate* ANYTHING of the sort, and 2) it IS as
easy as that... do you think that if these functions were implemented in
the native math package, they would be implemented differently than
this? JavaScript wasn't designed for mathmaticians or scientists... it
is a "general purpose" *scripting* language...

Besides, the *point* of my original response was *not* the functions
themselves, but the method of extending the Math package and how easily
accomplished it actually is. If practical implementations are important
to you, why don't you submit them here... instead of *just talking about
it*.

> Your functions will fail
> interestingly and undetectably in many cases - some could end up
> returning the result of taking the difference of two numbers very
> close in value, for example. The loss of precision would make the
> results meaningless. And of course, some may return the result of
> dividing a very large number by a very small number - again, with
> results depending on the behaviour of the floating point engine. Of
> course, the divide by zero error you mention will be caught, but other
> situations which result in disastrous loss of precision won't be.

Show me... then show me how any of it is different than what already
exists in the Math package. Show me in terms of a "normal" program that
somebody would need for an application, and not some kind of contrived
"special case" designed to break it.

The JS FP "engine" is quite robust... 64 bit ieee754 (if ecma compliant)
.... reports NaNs and Infinities... gradual underflow... fairly unbreakable.

BTW -- what is a "disastrous loss of precision?" I've been programming
over 23 years now, and I've never heard of this...

>
> The text-book formulae are in most cases designed to illustrate the
> properties and derivation of the function, and are not a practical
> means of computing it reliably.

I would contend that such derived functions (the "longer versions" being
"proofs") *are* a means of computing them reliably. The definitions did
not state "approximately equal to" -- they are as stated.

Practically speaking, from a programmer's point of view: the "extended"
Math functions/methods use already natively-provided functions and very
little overhead...i.e.: they won't slow you down much.

I don't think there are very many people around who would be patient
enough for a scripting language like JavaScript to evaluate Taylor's
Series Expansions and the like to achieve a "precise" value of any of
these functions. (and considering these series tend to "oscillate"
across a limit as they approach it, stopping the evaluation at
arbitrarily shorter terms to save time and/or execution overhead could
render the result MORE imprecise than using exponentials and logs.)

> Practical implementations have to take
> into account the problems of working with digital arithmetic, provide
> proper exception handling and guaranteed precision. That is why John
> Stockton suggested that creating and maintaining such a library was a
> task for a Mathematics or Computer Science group, not for an

this is almost hysterical... talk about overkill. What would they call it?

Applied Numerics And Logic group?

>

"Guaranteed precision" (whatever that is) is not a feature of the Math
package... never has been. Considering the precision we do have in Math,
if you implement precision handling within the methods themselves, you
take it out of the hands of the programmers who would not ordinarily
require it and slowing down operations for everybody across the board.
Programmers are responsible for handling ranges and precisions in and
out of the basic functions... this sort of thing does not belong inside
general purpose functions.

If you need to use a *browser* for "guaranteed precision", use Netscape
and load the java.math package for arbitrary-precision math:

if(navigator.appName.indexOf("Netscape") != -1)
// doomed to fail if spoofed
// also, java support in v6 was "interrupted"
// so this may or may not work in NN6
{

var BD = java.math.BigDecimal;

var somedecimal_1 =
new BD("12340.0000000000000000000000000000001");

var somedecimal_2 =
new BD("12340.0000000000000000000000000000003");

var sum = somedecimal_1.add(somedecimal_2);

}

else

var sum = "You need a Netscape browser to use this";

alert(sum);
// result: 24680.0000000000000000000000000000004 exactly
// works in NN4 and NN7/8 -- btw: that's 36 significant digits
// more than twice what you get in javascript
// and can have arbitrarily greater significant digits

use strings to instantiate the BigDecimal, otherwise you run into the
same binary -> decimal conversion problems.

roll your own ... ...knock yourself out...

(it will *not* be a "practical" use of your time... I can guarantee with
remarkable precision)

Paul Cooper
Guest
Posts: n/a

 06-27-2005
On Fri, 24 Jun 2005 22:54:32 +0100, Dr John Stockton
>
>I can't recall whether I said this before, but I lived for a year at #54
>of the road by which you work, if you are housed in SPRI.
>

I used to work at SPRI from 1979-1988 after which I moved to BAS. BAS
is located on Madingley Road, right next to the M11.

Best wishes

Paul

Dr John Stockton
Guest
Posts: n/a

 06-27-2005
JRS: In article <d9lo1i\$2jr\$(E-Mail Removed)>, dated Sun, 26 Jun
2005 03:12:29, seen in news:comp.lang.javascript, fox
<(E-Mail Removed)> posted :
>Paul Cooper wrote:

>> I am afraid you have just illustrated the point that John Stockton
>> made - that it isn't as easy as that.

>
>Actually, 1) I didn't *illustrate* ANYTHING of the sort, and 2) it IS as
>easy as that... do you think that if these functions were implemented in
>the native math package, they would be implemented differently than
>this?

That depends on the competence of the implementer, and on the degree of
effort used. For example, Math.cosh would most easily, I expect, be
provided by use of Math.exp itself; but it would more effectively be
provided by directly calling the machine's native exp function.

> JavaScript wasn't designed for mathmaticians or scientists... it
>is a "general purpose" *scripting* language...

ISTM that it was more thrown together than designed, in contrast to,
say, Wirth's Pascal.

Functions provided as part of the system should be implemented to full
machine accuracy over the full range; the system provider cannot
completely tell what the system may be used for, though he should
understand the commoner cases.

Remember that over 99% of javascripters will not recall cosh other than
as an instrument of assault; those who use it will largely be doing
technical applications, and will want correctness.

>Besides, the *point* of my original response was *not* the functions
>themselves, but the method of extending the Math package and how easily
>accomplished it actually is. If practical implementations are important
>to you, why don't you submit them here... instead of *just talking about
>it*.

He truly recognises the degree of effort and skill needed to do the job
well; you do not, or do not care.

>BTW -- what is a "disastrous loss of precision?" I've been programming
>over 23 years now, and I've never heard of this...

The self-taught generally have wide areas of lamentable ignorance; the
clever ones recognise this.

>I would contend that such derived functions (the "longer versions" being
>"proofs") *are* a means of computing them reliably. The definitions did
>not state "approximately equal to" -- they are as stated.

In infinite-precision mathematics, and where speed cannot matter, yes;
in actual implementation, no.

Consider sinh(x), defined as (exp(x)-exp(-x)/2. Calculated that way, it
has a 45% error at x=1E-16, and is 0 at x = 1E-17.

A competent implementation would substitute sinh(x) = x for sufficiently
small x, where sufficiently small seems to be reached at the 1E-5..1E-6
region, or more likely would use a method not requiring exp itself; in
particular, for x>=0 it would never return sinh(x)<x.

>I don't think there are very many people around who would be patient
>enough for a scripting language like JavaScript to evaluate Taylor's
>Series Expansions and the like to achieve a "precise" value of any of
>these functions. (and considering these series tend to "oscillate"
>across a limit as they approach it, stopping the evaluation at
>arbitrarily shorter terms to save time and/or execution overhead could
>render the result MORE imprecise than using exponentials and logs.)

But have you the depth of understanding required for your thought to be
of any value?

>> Practical implementations have to take
>> into account the problems of working with digital arithmetic, provide
>> proper exception handling and guaranteed precision. That is why John
>> Stockton suggested that creating and maintaining such a library was a
>> task for a Mathematics or Computer Science group, not for an

>
>
>this is almost hysterical... talk about overkill. What would they call it?
>
>Applied Numerics And Logic group?

DAMTP? not quite.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Dr John Stockton
Guest
Posts: n/a

 06-27-2005
JRS: In article <(E-Mail Removed)>, dated
Mon, 27 Jun 2005 11:29:41, seen in news:comp.lang.javascript, Paul
Cooper <(E-Mail Removed)> posted :
>On Fri, 24 Jun 2005 22:54:32 +0100, Dr John Stockton
>>
>>I can't recall whether I said this before, but I lived for a year at #54
>>of the road by which you work, if you are housed in SPRI.
>>

>
>I used to work at SPRI from 1979-1988 after which I moved to BAS. BAS
>is located on Madingley Road, right next to the M11.

After my time.

Regards,

--
© John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??(E-Mail Removed) ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

fox
Guest
Posts: n/a

 06-29-2005

Dr John Stockton wrote:
> JRS: In article <d9lo1i\$2jr\$(E-Mail Removed)>, dated Sun, 26 Jun

>
> That depends on the competence of the implementer, and on the degree of
> effort used...
>
> He truly recognises the degree of effort and skill needed to do the job
> well; you do not, or do not care.

> The self-taught generally have wide areas of lamentable ignorance; the
> clever ones recognise this.

> A competent implementation ...
>
> But have you the depth of understanding required for your thought to be
> of any value?

You are entitled to your opinion. Somewhat harsh... but maybe you're right.

I have a "little" program I wrote about five or six years ago and I'm
have a section of code I could use your help with (actually not entirely
off-topic...quite a lot of "extended math functions" technically
reapplied to the Number object though)...it's *right up your alley.* It
involves physics and perhaps you're right, a mere programmer is not
capable of the understanding required. [haven't had the time to revisit
it since so the gui I planned never materialized-- it's very bare bones
-- not "cluttered".]

It should be really simple to read... after all, I wrote it *for* myself.

If you find yourself wondering: I attached the methods to the Number
object so I could easily follow along with Meeus' book: Astronomical
Algorithms. Extra PI precision (in places) because this was supposed to
be ported to Java later. Originally started out with "classic" orbital
elements then converted to vsop.

The main Object is "Planet()" [index page] instantiated from "handleClick"

For my application, I do not need better precision than to the nearest
arcminute (although arcseconds would definitely be preferable... but
hey! this is me we're talking about) compared to the ephemerides of JPL
or the like for "apparent geocentric" coordinates and the output is in
terms of Zodiacal position (longitude -- just converting degrees to
something familiar).

....I'm having a little problem with Pluto (up to +/- 5 arcmins off), and
perhaps you could see where my errors are:

http://fxmahoney.com/demo/astro/

Pluto specific routines are at the bottom of the vsop.js file (before
the moon routines).

[recommend Courier New (8pt, if possible) used as font for viewing source]

I really would appreciate your help. You *are* the doctor.

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post VK Javascript 15 05-02-2010 03:43 PM Philipp Java 9 07-23-2008 12:37 AM Mark Healey C Programming 7 05-22-2006 10:42 AM AciD_X C++ 4 04-01-2004 07:29 PM chirs Java 18 03-02-2004 06:00 PM

Advertisments