Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
message <[EMAIL PROTECTED]> :
> I have made a few more improvements:
Thanks Bram.
Using Borland C++ 5.5 (HUGE with FLOAT), I had the following warnings :
.\eval.c:
Warning W8065 .\eval.c 14642: Call to function 'round' with n
Hi,
Patrick Texier wrote:
> Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
> message <[EMAIL PROTECTED]> :
>
>> I have made a few more improvements:
>
> Thanks Bram.
>
> Using Borland C++ 5.5 (HUGE with FLOAT), I had the following warnings :
>
> .\eval.c:
> Warning W806
> > .\eval.c:
> > Warning W8065 .\eval.c 14642: Call to function 'round' with no prototype
> > in function f_round
> > Warning W8065 .\eval.c 17027: Call to function 'trunc' with no prototype
> > in function f_trunc
> As a workaround in eval.c you can simply replace
> rettv->vval.v_float = r
On Fri, Jun 20, 2008 at 2:17 PM, Jürgen Krämer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Patrick Texier wrote:
>> Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
>> message <[EMAIL PROTECTED]> :
>>
>>> I have made a few more improvements:
>>
>> Thanks Bram.
>>
>> Using Borland C++ 5.
On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
I don't have the previous post.
> > As a workaround in eval.c you can simply replace
> > rettv->vval.v_float = round(f);
> > with
> > rettv->vval.v_float = ceil(f + 0.5);
Yes.
> > and
> > rettv->vval.v_float = trunc(f);
> >
Patrick Texier wrote:
> On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
>
> I don't have the previous post.
>
> > > As a workaround in eval.c you can simply replace
> > > rettv->vval.v_float = round(f);
> > > with
> > > rettv->vval.v_float = ceil(f + 0.5);
>
> Yes.
I think it's
Patrick Texier wrote:
> Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
> message <[EMAIL PROTECTED]> :
>
> > I have made a few more improvements:
>
> Thanks Bram.
>
> Using Borland C++ 5.5 (HUGE with FLOAT), I had the following warnings :
>
> .\eval.c:
> Warning W8065 .
On Fri, 20 Jun 2008 17:31:03 +0200, Bram Moolenaar wrote:
> I think it's:
> if (f > 0)
> return floor(f + 0.5)
> else
> return ceil(f - 0.5)
>
> Otherwise -1.5 doesn't work like round() does. Glad we have a test to
> verify this :-)
Yes, I had test my round() functi
With a small amount of testing, it's looking good, Bram. Tests says "ALL
DONE" which I presume means they all passed.
A few points:
- Wouldn't float2nr() be more consistent with the other Vim functions
than float2number()? O yes! So much so that it seems that's what you
implemented it as.
Bram Moolenaar wrote:
>
> Patrick Texier wrote:
>
>> On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
>>
>> I don't have the previous post.
>>
As a workaround in eval.c you can simply replace
rettv->vval.v_float = round(f);
with
rettv->vval.v_float = ceil(f + 0
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 woul
Ben Schmidt wrote:
> With a small amount of testing, it's looking good, Bram. Tests says "ALL
> DONE" which I presume means they all passed.
>
> A few points:
>
> - Wouldn't float2nr() be more consistent with the other Vim functions
>than float2number()? O yes! So much so that it seems tha
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
>
> You are apparently looking at slightly outdated runtime files. I'll
> push the current version now, so that they match with the latest
> floating point patch.
Yep. They look better now. Two suggestions for improvement:
- An example of pow() with floats would be good. E.g. pow(32,0.20)=2.0
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
On Fri 20-Jun-08 11:20pm -0600, Ben Schmidt wrote:
>
> 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' pos
>
- 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 ha
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 tim
> I'm not sure how to add the variables.
I am. :-)
> I've patched 7.1.386 with the new floating point patch.
326 perhaps?
> The attached patch to that includes log, exp, sin, cos, tan,
> asin, acos, atan and atan2.
OK, here's a counter-patch, including documentation, which is the bigger
task,
[Actually the patch I attached goes over a couple of other patches I also
had applied; but it still applies to the current source and runtimes OK,
just with some offsets.]
Ben Schmidt wrote:
>> I'm not sure how to add the variables.
>
> I am. :-)
>
>> I've patched 7.1.386 with the new floating
Ben Schmidt wrote:
> > You are apparently looking at slightly outdated runtime files. I'll
> > push the current version now, so that they match with the latest
> > floating point patch.
>
> Yep. They look better now. Two suggestions for improvement:
>
> - An example of pow() with floats would
>> - If the default display precision is to remain at six, documenting this
>>would be good, at the same time noting that printf() can be used to
>>display with greater precision.
>
> Document this where?
Where the precision of floats is discussed makes most sense. I've sent a
sample pat
Bram Moolenaar wrote:
> OK, so Borland doesn't have round() and trunc(). I rather
> not have a Vim version with only part of the floating point
> support. The easy solution is to disable it for Borland in
> src/feature.h:
>
> #ifdef FEAT_NORMAL
> # define FEAT_EVAL
> # if d
John Beckett wrote:
> Bram Moolenaar wrote:
>> OK, so Borland doesn't have round() and trunc(). I rather
>> not have a Vim version with only part of the floating point
>> support. The easy solution is to disable it for Borland in
>> src/feature.h:
>>
>> #ifdef FEAT_NORMAL
>> # defin
> I don't see what you mean. If you want to convert a Number to a Float
> you can add 0.0 to it.
I misinterpreted you in my previous reply. I just realised what you
meant. That makes sense.
Ben.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev
Please do read my earlier replies where I note this and other things in
more detail, and provide patches to achieve them (by the way, I'm happy
to fiddle with the patch if you want things done differently/removed if
it makes things easier for you). I just realised something else
though...
> So...
Ben -
> >> - If the default display precision is to remain at six, documenting this
> >>would be good, at the same time noting that printf() can be used to
> >>display with greater precision.
> >
> > Document this where?
>
> Where the precision of floats is discussed makes most sense.
- Furthermore, on investigation, it seems there is an interesting
definition of 'significant figures' in the library docs, and %.15g is
the correct value, not %.16g. It might be worth noting at the printf()
docs, or the Float docs where precision is mentioned, or both,
On Sat 21-Jun-08 9:04am -0600, Bram Moolenaar wrote:
> OK, just adding sin(), cos() and atan() sounds reasonable.
Sure, if you don't use trig, log or exp functions - that
sounds reasonable. Personally patching eval.c isn't all
that bad - only 40 of the first 326 patches changed eval.c
and I don
Bram Moolenaar wrote:
> OK, so Borland doesn't have round() and trunc(). I rather
> not have a Vim version with only part of the floating point
> support. The easy solution is to disable it for Borland in
> src/feature.h:
>
> #ifdef FEAT_NORMAL
> # define FEAT_EVAL
> # if d
On Sat 21-Jun-08 11:41pm -0600, John Beckett wrote:
> My conclusion is that some variation of my earlier
> suggested code should be included
> in Vim so it does not rely on an external library for round/trunc.
This is much more reasonable than simply excluding some
users from the benefits of flo
Bram Moolenaar wrote:
> - Added a test. Please try this, I don't know if roundoff
> errors might break it.
It's a trivial issue, but test65 (floating point) disagrees with Microsoft
Visual C
MSVC 6.0.
Line 11 of test65.in is:
:$put =printf('%e', 123.456)
Corresponding result expected in tes
Bill McCarthy wrote:
> For rounding you suggested:
>
> f >= 0 ? floor(f + 0.5) : -floor(-f + 0.5)
>
> Slightly simpler is:
>
> f < 0 ? ceil(f - 0.5) : floor(f + 0.5)
>
> For truncation you suggested:
>
> f >= 0 ? floor(f) : -floor(-f)
>
> Slightly simpler is:
>
> f < 0 ? cei
On 21/06/08 13:56, Bram Moolenaar wrote:
>
> Ben Schmidt wrote:
[...]
>> - Furthermore, on investigation, it seems there is an interesting
>> definition of 'significant figures' in the library docs, and %.15g is
>> the correct value, not %.16g. It might be worth noting at the printf()
>>
On 21/06/08 16:04, Bram Moolenaar wrote:
> Why atan() instead of tan()?
[...]
Because tan(x) == sin(x) / cos(x), but the arctangent function isn't
that easy to derive.
Note that atan2(x,y) is usually more precise (sometimes _very much_
more) than atan(x/y), especially when the size of x and/or
On Sun 22-Jun-08 2:49pm -0600, Tony Mechelynck wrote:
> On 21/06/08 13:56, Bram Moolenaar wrote:
>> Ben Schmidt wrote:
>>> - Furthermore, on investigation, it seems there is an interesting
>>> definition of 'significant figures' in the library docs, and %.15g is
>>> the correct value, n
[...]
> >
>
> The floating point patch is really bloating Vim. 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.
>
Yes,
Bill McCarthy wrote:
> On Sun 22-Jun-08 2:49pm -0600, Tony Mechelynck wrote:
>
> > On 21/06/08 13:56, Bram Moolenaar wrote:
>
> >> Ben Schmidt wrote:
>
> >>> - Furthermore, on investigation, it seems there is an interesting
> >>> definition of 'significant figures' in the library docs, an
On Mon 23-Jun-08 3:33pm -0600, Bram Moolenaar wrote:
> I get the feeling we are splitting hairs here. Anyway, current Vim does
> like the above. Except:
>
> :echo PG(-0.00123)
> -1.23e-3
>
> I would prefer to see -0.00123, as Vim does now.
You can now control the number of zeros you
39 matches
Mail list logo
