[squeak-dev] inverse hyperbolic function

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 22 21:05:11 UTC 2011


Thanks everybody for your answers.

I abandon argSh because mostly French and don't translate well in English.
I abandon sh because there is no reason to abbreviate that much (again
mostly a French usage).

Basically there are two choices to make
- arcus (arc) vs area (ar) or just a (stdlib, matlab etc...)
- lowercase or camelCase

I abandon arcus because not correct, though it seems widely used, even
by computer algebra references (hey, I think they copy each other).
My point is that Smalltalk goal is primarily to educate.

By homogeneity with arcSin I abandon asinh... We don't have asin, no
reason to abbreviate that much.
By homogeneity with already existing arcSin I will also choose camelCase.

Between arSinh and areaSinh I choose arSinh because a bit more
standard (recommended by an ISO 31-11)
Also, if sine and hyperbolic are abbreviated, why wouldn't area?

Now, the question of the final H or h remains

    sinH cosH tanH
    arSinH arCosH arTanH

Or:

    sinh cosh tanh
    arSinh arCosh arTanh

Though H would be more correct since clearly belonging to another word,
I personnally find it unaesthetic (maybe just because I'm not used to it ?)
Also it would make Smalltalk choice different from any other language
for a minor reason.

Using sinHyp and arSinHyp as Bert suggested would equilibrate the
camelCasing, but would put us a bit further off the standards.
So my preference is for keeping sinh (but sinH would not hurt me that much...)

Nicolas

2011/4/22 Louis LaBrunda <Lou at keystone-software.com>:
> With respect to the camelcase question only, I think we can look at it from
> two directions.  A Smalltalk programmer looking to do some math work would
> expect to find the functions implemented in methods with camelcase names. A
> math person, new to Smalltalk would expect to find the functions
> implemented in methods with names commonly used for math.
>
> Can we have both (I know that might be a lot of work).  Implement with what
> ever naming convention you prefer and in a loadable package implement with
> the other naming convention as extensions that call the methods named in
> the main package.
>
> I apologize in advance for possibly adding to anyone's work load.
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
>
>
>



More information about the Squeak-dev mailing list