Bill McCarthy wrote:
> On Fri 20-Jun-08 3:08pm -0600, Bram Moolenaar wrote:
>> Ben Schmidt wrote:
>>> - No chance of getting sin(), cos(), atan() and log10()? I realised
>>> after thinking a bit further and reading some other users' posts that
>>> these actually would truly be useful. Surely they would only take a
>>> few minutes to implement, no time to maintain, and I would have a lot
>>> of use for them. I don't know how many users are like me, but there
>>> must be a few as surely programming is fairly closely related to
>>> mathematics in many ways. (I'd like exp() and log() as well, but these
>>> can be done with pow() and log10() by appropriately defining e, so not
>>> an issue. tan(), sgn(), rand(), etc. are easy with scripts, too, so no
>>> problems there.)
>
>> log10() is there. I don't see a use for sin() and the like. If you
>> really want these please come up with an example.
>
> It's useful to have a calculator available at your
> fingertips and to be able to create tables in Vim which are
> easy when the math functions are there.
>
> I see you have log10, pow and sqrt now. In a few minutes I
> added log and exp to both Vim and Gvim. In another 10
> minutes I could have added sin, cos, tan, asin, acos, atan
> and, modeling after pow, atan2 - but I don't like the idea
> of needing to patch eval.c every time you make a change.
>
> Since there is virtually no overhead or maintenance, the
> question becomes why not just add them.
>
> If you don't have the time, others can do this - I, Ben or
> others would likely be happy to make the patch.
You bet!
The ones I suggested really were just the bare bones that couldn't be
easily scripted based on others, and which are more traditionally
included in minimalist mathematics libraries.
I for one certainly wouldn't mind having a fuller set! For purposes of
accuracy, using the library functions is better than layering scripts on
top, too. But I wouldn't be too upset with a slimmer set either, as long
as that slimmer set uses the library functions so at least one layer of
inaccuracy is removed. But not having even those essentials I mentioned
in my previous post would be a real shame in my eyes.
Two more suggestions: How about v:inf and v:nan? Then we wouldn't need
to resort to ugliness such as str2float('inf') or (1.0/0) to do this.
Ben.
P.S. Given v:e, v:pi, sin(), cos(), atan(), sqrt() and pow() we can get:
exp(x) = pow(v:e,x)
log(x) = log10(x)/log10(v:e)
sinh(x) = (pow(v:e,x)-pow(v:e,-x))/2
cosh(x) = (pow(v:e,x)+pow(v:e,-x))/2
tanh(x) = (pow(v:e,x)+pow(v:e,-x))/2
tan(x) = sin(x)/cos(x)
atan2(y,x) = x==0 ? ( y>0 ? v:pi/2 : -v:pi/2 )
: ( x>0 ? ( y>0 ? atan(y/x) : atan(y/x)+2*v:pi )
: atan(y/x)+v:pi )
acos(x) = x==0 ? v:pi/2
: ( x>0 ? atan(sqrt(1/pow(x,2)-1))
: v:pi-atan(sqrt(1/pow(x,2)-1)) )
asin(x) = x==1 ? v:pi/2
: ( x==-1 ? -v:pi/2
: ( x>0 ? atan(sqrt(1/(1-pow(x,2))-1))
: -atan(sqrt(1/(1-pow(x,2))-1)) ))
You can see how ugly this is, how many operations it involves and thus
increases room for inaccuracy to creep in, and thus why the fuller set
would be nice, but also that it's possible to script once you have the
essentials. These are not even full implementations, as they don't
account for all the +-0 and +-infinity subtleties, either (which is why
v:inf would be a nice bare bones thing to have!). And I haven't tested
them, and with such ugliness there are probably errors. But you get the
gist.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
