Is there a function for mathematics constant PI?

 I usually use:

pi=acos(-1);=> 3.141593

 Someone has a better idea ?

defMathConstants() is what you want:

> defMathConstants('MyConsts)
MyConsts
> MyConsts.?
(SHRT_MAX SHRT_MIN INT_MAX INT_MIN DBL_MAX
    DBL_MIN E LOG2E LOG10E LN2
    LN10 PI PI_OVER_2 PI_OVER_4 ONE_OVER_PI
    TWO_OVER_PI TWO_OVER_SQRTPI SQRT_TWO SQRT_POINT_FIVE
)
> MyConsts.PI
3.141593
> printf("%.14f\n" MyConsts.PI)
3.14159265358979
t
> sstatus(fullPrecision t)
t
> MyConsts.??
(SQRT_POINT_FIVE 0.7071067811865476 SQRT_TWO 1.414213562373095 TWO_OVER_SQRTPI
    1.128379167095513 TWO_OVER_PI 0.6366197723675814 ONE_OVER_PI 0.3183098861837907
    PI_OVER_4 0.7853981633974483 PI_OVER_2 1.570796326794897 PI
    3.141592653589793 LN10 2.302585092994046 LN2 0.6931471805599453
    LOG10E 0.4342944819032518 LOG2E 1.442695040888963 E
    2.718281828459045 DBL_MIN 2.225073858507201e-308 DBL_MAX 1.797693134862316e+308
    INT_MIN -2147483648 INT_MAX 2147483647 SHRT_MIN
    -32768 SHRT_MAX 32767
)

Regards,

Andrew.

(defvar pi 3)  ;; meh, close enough

BTW, if SKILL had defconst, I would totally use it.

Many of my programs begin this way:

(alias defconst defvar)

(defconst pi 22/7.)  ;; good enough for ancient Egypt

Thank you Andrew. 

It seems that defMathConstants() create an instance of a class, and the PI is a function of the created instance. This makes me not quite comfortable.  

Isn't it more natural to use Math.PI if we can access the attribute or  function of the class directly and there's a class like Math?

I used to def a global variable PI = 2*acos(0),  as zmleitao did.

Anyway, defMathConstants() can meet the precision requirement, I'll try it more oftener. 

richardyuan said:

It seems that defMathConstants() create an instance of a class, and the PI is a function of the created instance.

No.  Look at the doc:

defMathConstants( 
s_id 
) 
=> s_id
 
Associates a set of predefined math constants as properties of
the given symbol.

If you try it interactively, you can see no classes are being instantiated here.

> defMathConstants('Math)
Math
> Math.?
(SHRT_MAX SHRT_MIN INT_MAX INT_MIN DBL_MAX
    DBL_MIN E LOG2E LOG10E LN2
    LN10 PI PI_OVER_2 PI_OVER_4 ONE_OVER_PI
    TWO_OVER_PI TWO_OVER_SQRTPI SQRT_TWO SQRT_POINT_FIVE
)
> classOf(Math)
*Error* eval: unbound variable - Math

What's happening is that "PI" (and some other things) are being placed on the property list of the symbol Math. When you write "Math.PI", you are accessing the "PI" property on Math's property list. This has nothing whatsoever to do with classes and instances.

Hi tweeks,

 You're right. No class is instantiated when use defMathConstants. But it behaves like a instance of a class. Just feel not quite comfortable.

Maybe a little fussy, hah...

richardyuan said:

You're right. No class is instantiated when use defMathConstants. But it behaves like a instance of a class.

Well, sure, in the sense that it has named fields you can read/write using the dot operator....  But it has no parent class, so no generic function specializers, no reader/writer slot definitions, etc.  So you could just as well say, "it behaves like an instances of a defstruct".

richardyuan said:

Just feel not quite comfortable.

Maybe a little fussy, hah...

I feel the same, though it's because I'm a functional programmer. :)  It's very odd to have a built-in that stuffs properties on a symbol's property list, even if it lets you specify which symbol.  I'd prefer a stateless interface:

getMathConstant('pi) => 3.14159.....

Or (returning a DPL):

getMathConstants().pi => 3.14159....

I'm not an object-oriented fan, but I'd even prefer a singleton class with constant attributes, like you suggested.  At least that would be a stateless interface!

Too many SKILL APIs are unnecessarily stateful.  For example, consider the awful gdm interface for copying Virtuoso cellviews requires stateful calls to create and manipulate a black-boxed "gdmSpecList" object.  You do gdmCreateSpecList() to create one, then you call gdmAddSpecToSpecList() to put things in it, and THEN (this is the nasty part) you need to do gdmNextFromSpecList() to iterate through.  It's like a port on a file: there is an invisible pointer in the gdmSpecList object that you are incrementing when you call gdmNextFromSpecList().  If you want to iterate again, you need to call gdmResetSpecList() to reset the pointer.  Why?  Why not just use normal lists of gdmSpec objects?  Why does this need to be an abstract data type?  Maybe there is a good reason -- perhaps it covers some corner case I haven't thought of.  Even if that is true, it would still be nice to have an optional stateless interface for us functional programmers.  I can roll my own, but it's just annoying.

tweeks said:

For example, consider the awful gdm interface for copying Virtuoso cellviews

OK, I was a little hard on poor gdm.  It's not objectively "awful", just "awfully stateful". :) 

There are multiple schools of thought about how programming should be done; I come from the "write pure/side-effect-free/stateless code wherever possible" school that you tend to find more in books about Scheme than in books about Common Lisp, though you can write pure code in Common Lisp too, and impure code in Scheme using "set!" etc.

One day I discovered that most of the SKILL I write can be thought of as application of the functional programming operatons "filter", "map", and "reduce" over the Cadence database: shapes, instances, cells in the hierarchy, etc.  Writing code in terms of these three higher-order functions tended to make things clearer: my code got simpler, temp variables were elided, etc.  That's why functional programming feels like the most natural style in SKILL for me, and why being forced to destructively update symbol property lists just to get the value of PI, or having to mutate a pointer inside a gdmSpecList object, is jarring: most of the time I work in this nice, pure, side-effect free world, but once in a while I have to get my hands dirty mutating data structures.

Maybe I'm just fussy too.... :)

The gdm interface is a pretty lightweight implementation in SKILL of the underlying C APIs which are iterator based. The CDBA C APIs are similar, but those have been abstracted out to use lists so that's hidden from the user. That didn't happen with the GDM APIs, so they seem awkward in comparison. There's no appetite to go back and provide a stateless interface though, because we'd have to support both old and new APIs and that would just double the maintenance work for primarily philosophical benefits...

defMathConstants does also feel slightly clunky, but I would have sooner had a predefined symbol with these values as properties rather than an API to retrieve a constant (it would be a pain to have to keep retrieving all the constants you need - you might end up with 19 function calls if you needed all of them, however unlikely that is). Of course you could argue it could have been implemented lots of different ways, including returning a DPL or a structure instance. However, it has been this way for 25 years probably and isn't going to change as there really is no benefit in making a change (as before, we'd have to support two ways, which seems overkill for a set of maths constants).

Andrew.