Yegappan Lakshmanan 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.
>>
>>
>> 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)
>>
>
> The floating point patch is really bloating Vim.
--disable-float (or similar) will fix this if you are concerned.
> This "feature" was not asked by many people before this.
> Some of the features like running a shell
> inside Vim were requested many times before and were rejected with
> a reasoning that they will un-necessarily bloat Vim.
Unnecessary bloat isn't the reason stated at :help design-not.
> Based on the number of outstanding bugs in the todo list, this patch and
> the amount of time being spent on improving it by adding more functions
> to it looks like a waste of precious time.
Not to me. A few extra minutes spent on floating point now => many minutes
saved
in my future day to day work => more spare time to spend on Vim.
Ben.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
