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
> sample patch in response to Bill's patch that does pretty much
> *everything* you could possibly want to include, including this, so
> perhaps what I've done would suffice.
I'll add a remark about using "%g" by default.
> >> - 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
> >> maximum precision output can be obtained with %.15g.
> >
> > I don't see this, for me %.16g does produce a longer result.
>
> Yes, but the extra digits are bogus, as they are beyond the precision of
> the underlying data type (double). Actually %.15e is reliably maximum
> precision for a double. Depending on the size of the number and how %g
> therefore decides to display it, it will either be %.15g or %.16g that
> will be the maximum precision for that conversion. Quite awkward.
Doesn't this depend on the magnitude of the number? Anyway, this is too
much detail to mention in the Vim docs.
> >>>> - 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.
> >> The most classic example surely has to be conversions between polar and
> >> rectangular coordinates. This needs to happen a lot when doing GUI work
> >> involving circles (e.g. drawing a clock face or implementing some kind of
> >> spinning progress indicator), editing data files with coordinates (e.g.
> >> for mapping applications or a flight simulator). Sometimes these are
> >> one-off calculations that you want just to hard code a constant into
> >> code or such; other times you want to convert a list of figures, and
> >> it'd be great to just be able to whack qq and with a bunch of yanks,
> >> <C-r>= and so on, hack together a macro to do it quickly in Vim.
> >>
> >> Though I hate to say it...these functions would probably be most useful
> >> if they worked with degrees not radians. However, for accuracy, it would
> >> definitely be best just to use the C library functions, which basically
> >> use processor instructions, rather than having Vim add additional
> >> computations of its own (so as long as you're not using one of those
> >> early Pentiums...). deg2rad() and rad2deg() are easy to implement in
> >> scripts with an appropriate definition for pi, but perhaps since the
> >> more useful applications for programming are with degrees, it'd be worth
> >> including them as Vim functions--then the more useful case is easily
> >> accessible out of the box without sacrificing accuracy and thus
> >> crippling its use for more scientific applications.
> >>
> >> For that matter, could we define v:e and v:pi?
> >>
> >> v:e=2.718281828459045
> >> v:pi=3.141592653589793
> >>
> >> They would be useful. Not essential, though, as easy to do in a script
> >> (well, with g: variables rather than v: ones though--or with functions
> >> that return them).
> >
> > You can see where this is going. Once we add sin() someone wants
> > deg2rad(). And then pi and others. I think drawing the line before
> > adding sin() makes sense. I don't see how Vim is used to draw the face
> > of a clock. Other than this remark triggering someone to write a script
> > that does that :-).
>
> Vim isn't used to draw the clock. Vim is used to edit the source code
> that draws the clock. Or to edit other coordinates that drive a piece of
> software.
>
> I really do want it, as I would find it very useful. I spend plenty of
> time copying and pasting values between bc and vim to do these kinds of
> conversions--and bc pretty much only implements sin, cos, atan, exp and
> log by default. It's just hard convincing you as evidently you wouldn't
> find it useful. I realise there may be a lot of users like you who
> wouldn't find it useful, and to be honest, I'm really very happy to do
> most of the mathematical stuff I'd like in a plugin, even though a
> little accuracy would be lost. But this isn't really possible without
> sin, cos and atan.
>
> So...if you must draw a line so far from full mathematical
> functionality, couldn't you please draw it at the very least after sin,
> cos and atan? Then I'll make a plugin to do the rest myself. At least
> Bill and I would find that useful, and there must be many more like us.
OK, just adding sin(), cos() and atan() sounds reasonable. That avoids
having to use an external program for that one user that does want to
use trigonometric stuff. Why atan() instead of tan()?
> >> - I wonder whether it's smart to make ceil, floor, round, trunc behave
> >> like that, too? All of them return a Number unchanged.
> >
> > No, I don't think we should change ceil() and the like. Using them on a
> > Number is not intended. It won't fail if you do, but I think it's
> > unexpected that the return type is undefined.
>
> Yeah. I agree. I thought of that after I posted.
>
> >> - And another documentation one: I guess the job of a nr2float function
> >> is filled by str2float. However, it *looks* like an omission because
> >> it's not listed under 'Floating point computation' in the function
> >> list. Perhaps list it there as well as under 'String manipulation'
> >> with a note that it can be used on Numbers?
> >
> > I don't see what you mean. If you want to convert a Number to a Float
> > you can add 0.0 to it. But in most cases it's converted automatically,
> > so you will hardly ever need this.
>
> Not necessarily a constant Number, but a Number in a variable can be
> converted to a Float this way. So, for example, you may have a=5 and b=6
> and then want to do :let c=str2float(a)/b to ensure a Float result.
> Minor issue, though.
>
> >> - It may also be worth noting at the str2float documentation that
> >> feeding it a Number (or variable holding one) works because of
> >> automatic Number->String conversion.
> >
> > This is true for all places where a String is used. Mentioning it here
> > might give people the idea that this is the only place where it works.
>
> OK, if you think so. Another minor issue.
--
hundred-and-one symptoms of being an internet addict:
62. If your doorbell rings, you think that new mail has arrived. And then
you're disappointed that it's only someone at the door.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
