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 get
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, and %.15g =
is
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
[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 point
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 be good.
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
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...
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. I've sent a
- 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, that
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
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
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 W8065 .\eval.c
.\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 = round(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:
if (f 0)
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 .\eval.c
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() function with
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.5);
Yes.
I think it's:
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
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 they would
- 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
23 matches
Mail list logo
