>> - 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. >> - 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. >>>> - 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. >> - 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. Cheers, Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
