1. pilib.e (was: Re: How to handle crashes?)
I haven't added the ability to do ((PI*7)/PI == 7) in fraclib.e,
as it was so complex that it demanded to have its own library.
I'm working on pilib.e, mainly trying to find the best way to represet
PI. Right now, its an 8-length sequence which encodes this algorithm:
(x) + (y*PI) + (PI^z) + (a*(PI^b)) + (c/PI) + (d/(PI^f))
Hence, in order to represent 2PI, you have:
(-1) + (2*PI) + (PI^0) + (0*(PI^0)) + (0/PI) + (0/(PI^1))
That sort of thing is rather unwieldy however, and makes something like 2PI+2PI
a complex computation.
If anyone has ideas on how this could be simplified, feel free to let me know.
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
2. Re: pilib.e (was: Re: How to handle crashes?)
On Tue, 10 Jun 2003 17:33:44 -0400, jbrown105 at speedymail.org wrote:
>I haven't added the ability to do ((PI*7)/PI =3D=3D 7) in fraclib.e,
<snip>
>If anyone has ideas on how this could be simplified, feel free to let me=
know.
Something else on this list recently prompted me to comment:
-- PL 7/6/3 It just struck me that rather than holding values as
fractions, they should
-- remain as (simplified) expressions; instead of fraction
=3D{numerator,denominator},
-- it should be stored as a tree, eg div(PI,2). This would also allow
eg cos(expr) to
-- unambiguously return 0 when expr is -PI/2, PI/2, 3PI/2 etc.
So we store not 1.57079632679489661923132169163975, but div(PI,2), and
then cos(div(PI,2)) =3D=3D> 0. Equally we do not store
21.9911485751285526692385036829565 but mul(PI,7), then
div(mul(PI,7),7) =3D=3D> PI.
I shudder to think how difficult that might be to generalise.
Pete
PS there are other natural numbers and constants besides PI
3. Re: pilib.e (was: Re: How to handle crashes?)
On Wed, Jun 11, 2003 at 12:53:10AM +0100, Pete Lomax wrote:
>
>
> On Tue, 10 Jun 2003 17:33:44 -0400, jbrown105 at speedymail.org wrote:
>
> >I haven't added the ability to do ((PI*7)/PI == 7) in fraclib.e,
> <snip>
> >If anyone has ideas on how this could be simplified, feel free to let me
> >know.
> Something else on this list recently prompted me to comment:
> -- PL 7/6/3 It just struck me that rather than holding values as
> fractions, they should
> -- remain as (simplified) expressions; instead of fraction
> ={numerator,denominator},
> -- it should be stored as a tree, eg div(PI,2). This would also allow
> eg cos(expr) to
> -- unambiguously return 0 when expr is -PI/2, PI/2, 3PI/2 etc.
>
> So we store not 1.57079632679489661923132169163975, but div(PI,2), and
> then cos(div(PI,2)) ==> 0. Equally we do not store
> 21.9911485751285526692385036829565 but mul(PI,7), then
> div(mul(PI,7),7) ==> PI.
>
Hmm, that would be a less expesive way to hold it (and also would be easier
to apply more generally). But it also requires a more complex parser.
> I shudder to think how difficult that might be to generalise.
The hard part would be figuring how to parse and store it internally, once
that is done the rest is not as difficult.
>
> Pete
> PS there are other natural numbers and constants besides PI
>
Such as e, sqrt(2), etc.... Yes I do hope to be able to represent those
symbolicly
as well... eventually.
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
