Hello,
In common Lisp, sin, cos, or tan, etc., only accept radian?
For example, I would like to get a degree value from the below.
cosT = A , therefore, T = acosA.
In common Lisp, I get the result of "T" as a radian value.
But, I'd like to get that as a normal degree.
(e.g., cos60 = 0.5, and acos0.5 = 60)
How could I convert radian to degree?
Is there any function or macro to do this?
Thanks for your help.
Sungwoo
"Sungwoo, Lim" wrote:
> How could I convert radian to degree?
> Is there any function or macro to do this?
In the standard language there isn't a ready-built one for this, IIRC.
Allegro's Windows version seems to have one, maybe other
implementations, too.
Writing your own isn't all that difficult:
(defun deg-to-rad (degrees) (* pi (/ degrees 180.0)))
and something similar for its inverse.
--
In article <·················@solibri.com>, Martti Halminen
<···············@solibri.com> wrote:
> In the standard language there isn't a ready-built one for this, IIRC.
> Allegro's Windows version seems to have one, maybe other
> implementations, too.
>
> Writing your own isn't all that difficult:
>
> (defun deg-to-rad (degrees) (* pi (/ degrees 180.0)))
>
> and something similar for its inverse.
>
> --
Thanks, =)
So, I could get the degreee from radian as below.
(defun rad-to-deg (radians) (/ (* radians 180.0) pi))
Thanks alot.
Sungwoo
"Sungwoo, Lim" wrote:
> > (defun deg-to-rad (degrees) (* pi (/ degrees 180.0)))
> >
> > and something similar for its inverse.
> So, I could get the degreee from radian as below.
>
> (defun rad-to-deg (radians) (/ (* radians 180.0) pi))
If for some odd reason you would need to do billions of these
transforms, a little faster version would be
(defun rad-to-deg (radians) (* radians 57.29577951308232d0))
or something like that. (Unless the compiler already did this?)
Rather less readable, though.
--
Martti Halminen wrote:
>
> "Sungwoo, Lim" wrote:
>
> > > (defun deg-to-rad (degrees) (* pi (/ degrees 180.0)))
> > >
> > > and something similar for its inverse.
>
> > So, I could get the degreee from radian as below.
> >
> > (defun rad-to-deg (radians) (/ (* radians 180.0) pi))
>
> If for some odd reason you would need to do billions of these
> transforms, a little faster version would be
>
> (defun rad-to-deg (radians) (* radians 57.29577951308232d0))
>
> or something like that. (Unless the compiler already did this?)
> Rather less readable, though.
If the function were written:
(defun rad-to-deg (radians)
(* (/ 180 pi) radians))
I would expect it to perform simple constant folding and be just as efficient as using (* radians 57.29577951308232d0).
>>>>> "Christopher" == Christopher J Vogt <····@computer.org> writes:
Christopher> Martti Halminen wrote:
>> If for some odd reason you would need to do billions of these
>> transforms, a little faster version would be
>>
>> (defun rad-to-deg (radians) (* radians 57.29577951308232d0))
>>
>> or something like that. (Unless the compiler already did this?)
>> Rather less readable, though.
Christopher> If the function were written:
Christopher> (defun rad-to-deg (radians)
Christopher> (* (/ 180 pi) radians))
Christopher> I would expect it to perform simple constant folding
Christopher> and be just as efficient as using (* radians
Christopher> 57.29577951308232d0).
Except that pi is a long-float, so that would be (* radians
57.2957795....L0). (I always forget this because CMUCL's long-float =
double-float.)
:-)
Ray
"Christopher J. Vogt" <····@computer.org> writes:
> If the function were written:
>
> (defun rad-to-deg (radians)
> (* (/ 180 pi) radians))
>
> I would expect it to perform simple constant folding and be just as
> efficient as using (* radians 57.29577951308232d0).
It might be silly, but I always write this as
(defun rad-to-deg (r)
(* #.(/ 180 pi) r))
John Wiseman
In article <··············@bjork.local.neodesic> on
<··············@bjork.local.neodesic>, "John Wiseman"
<·······@bjork.local.neodesic> wrote:
> It might be silly, but I always write this as
>
> (defun rad-to-deg (r)
> (* #.(/ 180 pi) r))
>
CMUCL interprets #. correctly for this usage, but I don't think this
syntax works on ACL. Can anyone confirm this?
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@rice.edu> writes:
> In article <··············@bjork.local.neodesic> on
> <··············@bjork.local.neodesic>, "John Wiseman"
> <·······@bjork.local.neodesic> wrote:
>
> > It might be silly, but I always write this as
> >
> > (defun rad-to-deg (r)
> > (* #.(/ 180 pi) r))
> >
>
> CMUCL interprets #. correctly for this usage, but I don't think this
> syntax works on ACL. Can anyone confirm this?
Works in acl6_trial here. What could go wrong?
Cheers,
M.
--
surely, somewhere, somehow, in the history of computing, at least
one manual has been written that you could at least remotely
attempt to consider possibly glancing at. -- Adam Rixey
In article <··············@atrus.jesus.cam.ac.uk> on
<··············@atrus.jesus.cam.ac.uk>, "Michael Hudson" <·····@cam.ac.uk>
wrote:
> "Rahul Jain" <·····@rice.edu> writes:
>
>> In article <··············@bjork.local.neodesic> on
>> <··············@bjork.local.neodesic>, "John Wiseman"
>> <·······@bjork.local.neodesic> wrote:
>>
>> > It might be silly, but I always write this as
>> >
>> > (defun rad-to-deg (r)
>> > (* #.(/ 180 pi) r))
>> >
>>
>> CMUCL interprets #. correctly for this usage, but I don't think this
>> syntax works on ACL. Can anyone confirm this?
>
> Works in acl6_trial here. What could go wrong?
Someone told me that the result of the evaluation was not insterted into
the surrounding form. I guess it was either a bug which has since been
fixed or a misunderstanding on our part. Thanks for clearing this up.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
>
> In article <··············@atrus.jesus.cam.ac.uk> on
> <··············@atrus.jesus.cam.ac.uk>, "Michael Hudson" <·····@cam.ac.uk>
> wrote:
>
> > "Rahul Jain" <·····@rice.edu> writes:
> >
> >> In article <··············@bjork.local.neodesic> on
> >> <··············@bjork.local.neodesic>, "John Wiseman"
> >> <·······@bjork.local.neodesic> wrote:
> >>
> >> > It might be silly, but I always write this as
> >> >
> >> > (defun rad-to-deg (r)
> >> > (* #.(/ 180 pi) r))
> >> >
> >>
> >> CMUCL interprets #. correctly for this usage, but I don't think this
> >> syntax works on ACL. Can anyone confirm this?
> >
> > Works in acl6_trial here. What could go wrong?
>
> Someone told me that the result of the evaluation was not insterted into
> the surrounding form. I guess it was either a bug which has since been
> fixed or a misunderstanding on our part. Thanks for clearing this up.
I hope CMUCL doesn't "interpret" #. rather than treating it as a
standard reader macro. I believe CMUCL is a high-quality implementation
and does the right thing, but "#." is a reader macro and has its
effect at read time. A program naively calling READ has no way to kow
whether or not #. was executed during the call to read. It _should_
have no way whereby it could know this (if *READ-EvAL* is true at
read time).
I'm quite sure (as one of its implementors) that Allegro treats #.
correctly, i.e., as a standard reader macro at read time, and that
neither the evaluator or the compiler could in any way be cognizant
whether some subform happened to be the result of a #. reader macro
form. However, I'm also aware that the "#." syntax is required to
fail (by signalling error) if a containing form is read when
*READ-EVAL* is NIL. If you write code that contains "#.", you
need to ensure that this code will be read in an environmentin which
*READ-EVAL* is true.
Now, I really thing that smart compiles ought to do constant folding
in places where it is "obvious to the programmer" that this constant
folding is appropriate. ACL tries to do this for you, and I'm pretty
sure that other implementations do this as well. But CL is a subtle
language, and it uis advisable (in that small portion of inner-loop
code where peformance actually makes a difference) to see the code
that the compiler generates (DISASSEMBLE, profiling, or whatever other
tools are provided) to make sure that the compiler is doing what you
need. Don't just assume that it isn't, but also don't just assume that
it is.
Anyway, it is hard to imagine an implementation in which treatment of
"#." wold likely be an _efficiency_ issue.
"Rahul Jain" <·····@rice.edu> writes:
> > (defun rad-to-deg (r)
> > (* #.(/ 180 pi) r))
> >
>
> CMUCL interprets #. correctly for this usage, but I don't think this
> syntax works on ACL. Can anyone confirm this?
#. is just a reader macro so why would it not work?
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
> >
> > (defun rad-to-deg (r)
> > (* #.(/ 180 pi) r))
> >
>
> CMUCL interprets #. correctly for this usage, but I don't think this
> syntax works on ACL. Can anyone confirm this?
>
>
I don't know about ACL, but it works on MCL. =)
Sungwoo
Sent via Deja.com
http://www.deja.com/
·······@cad.strath.ac.uk writes:
> 10 > (defun rad-to-deg (radians) (/ (* radians 180.0) pi))
> RAD-TO-DEG
> 10 > (time (rad-to-deg 1.5))
> (RAD-TO-DEG 1.5) took 0 milliseconds (0.000 seconds) to run.
> 32 bytes of memory allocated.
> 85.94366926962348
>
> 10 > (defun rad-to-deg (radians) (* radians 57.29577951308232d0))
> RAD-TO-DEG
> 10 > (time (rad-to-deg 1.5))
> (RAD-TO-DEG 1.5) took 0 milliseconds (0.000 seconds) to run.
> 16 bytes of memory allocated.
> 85.94366926962348
> 10 >
When you get timing results like this, it just means that the function
you are timing takes less time than the resolution of the timer. One
common way of getting (at least relative) timing information for very
quick functions is to build a test function that calls it many times.
For example:
(defun test1 (n) (dotimes (i n) (rad-to-deg1 1.5)))
(defun test2 (n) (dotimes (i n) (rad-to-deg2 1.5)))
and then pick a value for N that gets you somewhere away from zero time.
It is also important to remember to compile the test functions, although
since I recall that you use MCL, it does it for you.
A quick test of ACL (ver. 4.3) shows that the compiler will constant
fold the second form, but not it will not rearrange the computation
for constant folding in the first case:
(defun rad-to-deg1 (radians)
(declare (double-float radians) (optimize (speed 3) (safety 0)))
(/ (* radians 180.0d0) pi))
(defun rad-to-deg2 (radians)
(declare (double-float radians) (optimize (speed 3) (safety 0)))
(* radians (/180.0d0 pi)))
Also, the second form (only) runs about 10% faster on a Sparc2.
USER> (time (time1 1000000))
; cpu time (non-gc) 800 msec user, 10 msec system
; cpu time (gc) 40 msec user, 0 msec system
; cpu time (total) 840 msec user, 10 msec system
; real time 845 msec
; space allocation:
; 1 cons cell, 0 symbols, 24,000,032 other bytes
NIL
USER> (time (time2 1000000))
; cpu time (non-gc) 710 msec user, 0 msec system
; cpu time (gc) 50 msec user, 0 msec system
; cpu time (total) 760 msec user, 0 msec system
; real time 758 msec
; space allocation:
; 1 cons cell, 0 symbols, 24,000,032 other bytes
NIL
I don't know the source of all of the 24 bytes of consing per function
call. A double float requires 8 bytes of storage, and there is
presumably one word (4 bytes) of overhead, so that would account for 12
bytes. I don't know why the other 12 bytes are allocated.
Very interesting. =) I've got little different results. Here is my test
result with MCL 4.0 on Powerbook G3 series 233MHz.
----------------------------------------------------------------------------
? (defun rad-to-deg (radian) (/ (* radian 180.0) pi)) RAD-TO-DEG ? (defun
test (n) (dotimes (i n) (rad-to-deg 1.5))) TEST ? (time (test 1000000)) (TEST
1000000) took 2,971 milliseconds (2.971 seconds) to run. Of that, 181
milliseconds (0.181 seconds) were spent in The Cooperative Multitasking
Experience. 310 milliseconds (0.310 seconds) was spent in GC. 32,000,008
bytes of memory allocated. NIL ?
----------------------------------------------------------------------------
? (defun rad-to-deg (radian) (* radian (/ 180.0 pi))) RAD-TO-DEG ? (defun
test (n) (dotimes (i n) (rad-to-deg 1.5))) TEST ? (time (test 1000000)) (TEST
1000000) took 3,001 milliseconds (3.001 seconds) to run. Of that, 257
milliseconds (0.257 seconds) were spent in The Cooperative Multitasking
Experience. 268 milliseconds (0.268 seconds) was spent in GC. 32,000,008
bytes of memory allocated. NIL ?
----------------------------------------------------------------------------
? (defun rad-to-deg (radian) (* radian 57.29577951308232d0)) RAD-TO-DEG ?
(defun test (n) (dotimes (i n) (rad-to-deg 1.5))) TEST ? (time (test
1000000)) (TEST 1000000) took 1,489 milliseconds (1.489 seconds) to run. Of
that, 69 milliseconds (0.069 seconds) were spent in The Cooperative
Multitasking Experience. 16,000,000 bytes of memory allocated. NIL ?
----------------------------------------------------------------------------
? (defun rad-to-deg (radians) (declare (double-float radians) (optimize
(speed 3) (safety 0))) (/ (* radians 180.0d0) pi)) RAD-TO-DEG ? (defun test
(n) (dotimes (i n) (rad-to-deg 1.5))) TEST ? (time (test 1000000)) (TEST
1000000) took 2,960 milliseconds (2.960 seconds) to run. Of that, 212
milliseconds (0.212 seconds) were spent in The Cooperative Multitasking
Experience. 262 milliseconds (0.262 seconds) was spent in GC. 32,000,008
bytes of memory allocated. NIL ?
----------------------------------------------------------------------------
? (defun rad-to-deg (radians) (declare (double-float radians) (optimize
(speed 3) (safety 0))) (* radians (/ 180.0d0 pi))) RAD-TO-DEG ? (defun test
(n) (dotimes (i n) (rad-to-deg 1.5))) TEST ? (time (test 1000000)) (TEST
1000000) took 2,907 milliseconds (2.907 seconds) to run. Of that, 203
milliseconds (0.203 seconds) were spent in The Cooperative Multitasking
Experience. 275 milliseconds (0.275 seconds) was spent in GC. 32,000,008
bytes of memory allocated. NIL ?
----------------------------------------------------------------------------
Here, most fast result is third one which used '57.29577951308232d0' rather
than (/ 180.0 pi). The time difference is as twice faster than others, and
memory usage is just half as well. Hmm.. very interesting. Anyway, thanks to
tell me about the 'test' tips. =)
Sungwoo
Sent via Deja.com
http://www.deja.com/
I am very sorry again about ugly format.... T.T
Please hit the enter key before '?'.
Then you could see correct format.
Sungwoo.
Sent via Deja.com
http://www.deja.com/
Martti Halminen <···············@solibri.com> writes:
> If for some odd reason you would need to do billions of these
> transforms, a little faster version would be
>
> (defun rad-to-deg (radians) (* radians 57.29577951308232d0))
>
> or something like that. (Unless the compiler already did this?)
If you write it like this
(defun rad-to-deg (rad)
(declare (type double-float rad) (optimize (speed 3)))
(* rad (/ 180.0d0 pi)))
then probably any non-stupid compiler will notice and do the
constant calculation at compile-time. If you are dealing with a
particularly non-optimizing compiler, you can force the calculation to
read-time, e.g.
(defun rad-to-deg (rad)
(declare (type double-float rad) (optimize (speed 3)))
(* rad #.(/ 180.0d0 pi)))
or use a constant (though a sufficiently dumb compiler might still
refuse to inline the constant, so that you'd still have to use #.):
(declaim (type double-float rad-to-deg-conversion-factor))
(defconstant rad-to-deg-conversion-factor (/ 180.0d0 pi)
"Factor used to convert radiants to degrees by multiplication.")
(defun rad-to-deg (rad)
(declare (type double-float rad) (optimize (speed 3)))
(* rad rad-to-deg-conversion-factor))
> Rather less readable, though.
That should make it both more readable, and less error-prone.
If the need for speed is even greater you could consider declaring
rad-to-deg inline (or using compiler-macros for the same effect on
implementations like Franz' ACL) and/or (after careful analysis!)
reducing safety to 0.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
* "Pierre R. Mai" <····@acm.org>
| That should make it both more readable, and less error-prone. If the
| need for speed is even greater you could consider declaring rad-to-deg
| inline (or using compiler-macros for the same effect on
| implementations like Franz' ACL) and/or (after careful analysis!)
| reducing safety to 0.
I would have suggested a compiler macro on the trigonometric functions
that looked for a conversion of the argument from degrees to radians,
say with a form like (sin (degrees ...)), to do the computation and
conversion with as little loss of precision as possible. This may be
done only if you shadow the symbol in new package, since sin (etc) are
in the common-lisp package and anyone else doing a similar compiler-
macro would mess with yours.
#:Erik
--
The United States of America, soon a Bush league world power. Yeee-haw!
> the computation and conversion with as little loss of precision as possible.
I just suddenly got a question about 'loss of precision'...
With follow defun, the reverse result always little bit differ..
(defun deg-to-rad (degree) (* degree 0.017453292519943295d0))
(defun rad-to-deg (radian) (* radian 57.29577951308232d0))
? (deg-to-rad 60)
1.0471975511965976
? (rad-to-deg 1.0471975511965976)
59.99999999999999
?
Is there any way to correct this difference..? (In my case, 0.1d14 is same as
nothing because I use this degree for an analysis of probabilities... But if
I consider to use it with a different application which needs very very
accurate result, then it might be a problem?) Thanks alot.
Sungwoo
Sent via Deja.com
http://www.deja.com/
·······@cad.strath.ac.uk writes:
> > the computation and conversion with as little loss of precision as possible.
>
> I just suddenly got a question about 'loss of precision'...
> With follow defun, the reverse result always little bit differ..
>
> (defun deg-to-rad (degree) (* degree 0.017453292519943295d0))
> (defun rad-to-deg (radian) (* radian 57.29577951308232d0))
>
> ? (deg-to-rad 60)
> 1.0471975511965976
> ? (rad-to-deg 1.0471975511965976)
> 59.99999999999999
> ?
>
> Is there any way to correct this difference..?
no. welcome to the world of floating point.
the correct response is to _ignore_ this difference. do not test for
equality of floats, but compare the absolute value of their difference
with some suitably small number. choosing the size of this small
number is an exercise for the reader, not because i want to be rude,
but because it varies with your end goals and choice of algorithm.
> (In my case, 0.1d14 is same as
> nothing because I use this degree for an analysis of probabilities... But if
> I consider to use it with a different application which needs very very
> accurate result, then it might be a problem?) Thanks alot.
>
> Sungwoo
>
>
> Sent via Deja.com
> http://www.deja.com/
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
> no. welcome to the world of floating point.
>
> the correct response is to _ignore_ this difference. do not test for
> equality of floats, but compare the absolute value of their difference
> with some suitably small number. choosing the size of this small
> number is an exercise for the reader, not because i want to be rude,
> but because it varies with your end goals and choice of algorithm.
Hmm.. I see.
Thanks alot. =)
Sungwoo
Sent via Deja.com
http://www.deja.com/
"Sungwoo, Lim" wrote:
>
> Hello,
>
> In common Lisp, sin, cos, or tan, etc., only accept radian?
> For example, I would like to get a degree value from the below.
>
> cosT = A , therefore, T = acosA.
>
> In common Lisp, I get the result of "T" as a radian value.
> But, I'd like to get that as a normal degree.
> (e.g., cos60 = 0.5, and acos0.5 = 60)
> How could I convert radian to degree?
Good Lord, haven't you ever gone to school and study geometry. Well, anyway, the full
circle is 2P radian or 360deg. Can you convert from one to the other now <g>?
> Is there any function or macro to do this?
Write your own.
> Thanks for your help.
>
> Sungwoo