Sean I do not agree.

I have tried to write down some projections in his system and you can do them without any calculations at all just by coping the data around.

Knud



On Sat, 17 Sep 2005 16:39:11 +0000, Sean Kelly wrote:

> In article <dghg6n$h8d$1@digitaldaemon.com>, Sean Kelly says...
>>
>>There's an interesting article on slashdot today about a new method for solving trig. problems without using sin/cos/tan.  A link to info on the book is here:
>>
>>http://web.maths.unsw.edu.au.nyud.net:8090/~norman/book.htm
>>
>>I'll be curious to see the difference in speed and complexity of this new method compared to the classic approach.  I don't suppose anyone has heard of this guy before?
> 
> Upon further reading, while the author talks up his ideas quite a lot, I don't see much that's actually revolutionary.  It may turn out that the best aspect of this approach is its use as a teaching aid.
> 
> 
> Sean

In article <pan.2005.09.18.14.26.58.463008@sneakemail.com>, =?iso-8859-1?q?Knud_S=F8rensen?= says...
>
>Sean I do not agree.
>
>I have tried to write down some projections in his system and you can do them without any calculations at all just by coping the data around.

That's what I meant by its use as a teaching aid, though I'll admit that his method of solving trig problems beats the heck out of drawing a million circles. The reason I said it's not revolutionary is simply because his method draws from established trigonometric properties--quadrance, for example.  That it avoids floating point math almost entirely, however, is very nice.  I need to go back and finish reading the sample chapter--I had to run out after getting through the first few pages.  I'd be interested in trying some performance comparisons between his method and traditional trig.  I imagine it would extend quite easily to three dimensions?


Sean

But I agree with sean,

This new method looks easy, as it tries to avoid square roots and trig functions in intermediate steps. So, instead of length they use quadrance and instead of angle thay use spread (which is actually sin of the angle, hence spread is independent of angle being acute or obtuse, remember "all silver tea cups" ?)

So it saves time by not requiring to find lengths and angles for intermediate steps.

However, this approach is not new at all, engineers use it all the time to solve equations involving trig functions. By working with tan(theta/2) instead of angles, the difference is, here the author proposes sin(theta) as the measure of angle. And quadrance avoids square root, thats all, nothing innovative.

As for me, I generally dont determine angles and lenghts in intermediate steps when it is not required. instead directly use sin_theta or len_squared directly where possible.

I also doubt if it can be good teaching aid. I really think angle is more easy to understand than spread, and length is more natural to think than quadrance, even for a math bigginer.

This new method is nothing but a interesting outcome of re-defining basic objects in geometry. Something like re-defining fundamental units as [force, volume, velocity] instead of [mass, length, time]

Sai



In article <dgk3ec$2p03$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <pan.2005.09.18.14.26.58.463008@sneakemail.com>, =?iso-8859-1?q?Knud_S=F8rensen?= says...
>>
>>Sean I do not agree.
>>
>>I have tried to write down some projections in his system and you can do them without any calculations at all just by coping the data around.

Walter Bright wrote:
> "Don Clugston" <dac@nospam.com.au> wrote in message
> news:dgdq0d$30tl$1@digitaldaemon.com...
> 
>>Nor do I, really. copysign() achieves the same thing in every case I've
>>been able to think of. There seemed to be a lot of objection to removing
>>it from std.math2, though. I figured that if it was included, it should
>>be implemented correctly. If you've unmoved by the clamour, just throw
>>it away.
> 
> 
> copysign() is a standard function and needs to be there. It just doesn't
> need to be in std.math2.

I meant sign() could be removed from std.math2, not copysign(). I've found copysign() to be very useful.

In general c = sign(a)*func(b) can always be replaced with:
c = copysign(a, func(b));
which is also more efficient than a multiply. copysign() is already in std.math.

> trunc() is in the DMC standard library. I just need to trannsfer it.

real trunc(real x)		{ return std.c.math.truncl(x); }

seems to work. Is it that simple?

> 
> I think the Cephes libraries are the best out there. A couple years ago, I
> emailed Steve Moshier, the author, about the license with the same question,
> and here was his response:
> 
> ---------------------------------------------------------------------
> Thank you for writing. I have not put any restrictions on the use of
> material posted to the net. Bell Labs has suggested this for the files
> in netlib/cephes:
> http://www.netlib.org/research/boilerplate
> ---------------------------------------------------------------------

Excellent!

> Since then, I have filled in many gaps in the DMC runtime library with
> Steve's Cephes code. The Cephes code seems based on the old Cody&Waite
> algorithms, which are based on the earlier Hart&Cheney book.
> 
> Cephes does have functions missing from DMC like asinh, and the only reason
> I hadn't incorporated them yet is because it's a fair amount of work to
> adapt them, and I'm lazy.

And you've got more important things to do :-). That stuff can be done by people like me, who can't contribute to the compiler.
As I get the time, I hope to port some of those functions from Cephes to DMD. I imagine it is be quite easy to port DMD functions to DMC.

The thicket of #ifdef's need to be removed, the
> symbols need to be converted to DMC symbols, the tables need to be converted
> from hex kludges to the modern hex float format, the poly calculation needs
> to be rewritten to use DMC's poly function, and the special cases need to be
> rewritten to use the x87's features.

poly[] is the other function from std.math2 which needs to be redone in std.math. Presumably the order should be
a[2]*x^2 + a[1]*x + a[0]
rather than the Cephes format
a[0] * x^2 + a[1]*x + a[2]

And there should also be a version with a signature like:

real poly(real x, real [] coeffs...)

The min(), max() and avg() functions in std.math2 should be redone as templates anyway, so I don't think there's any need to retain std.math2 now. Move to etc?

"Don Clugston" <dac@nospam.com.au> wrote in message news:dglr4j$158q$1@digitaldaemon.com...
> Walter Bright wrote:
> > trunc() is in the DMC standard library. I just need to trannsfer it.
>
> real trunc(real x) { return std.c.math.truncl(x); }
>
> seems to work. Is it that simple?

Yes. The only issue is for C libraries that don't have a truncl().

> poly[] is the other function from std.math2 which needs to be redone in
> std.math. Presumably the order should be
> a[2]*x^2 + a[1]*x + a[0]
> rather than the Cephes format
> a[0] * x^2 + a[1]*x + a[2]

That's right. There's already one in the DMC library that is hand-built 8087 code.

> And there should also be a version with a signature like:
>
> real poly(real x, real [] coeffs...)

Yes.

> The min(), max() and avg() functions in std.math2 should be redone as
> templates anyway, so I don't think there's any need to retain std.math2
> now. Move to etc?

Yes, or just abandon it entirely.