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. E.g. pow(32,0.20)=2.0 > (fifth root of 32). OK. > - float2nr(nan) gives -2147483648, which I think is fair enough (indeed, > quite a clever solution, I think), but isn't documented. Hmm, strange that this happens, since numbers below -0x7fffffff should be truncated to -0x7fffffff. Must have something to do with how NaN is stored. But it's OK. > - Related to this: Would you consider using the same values for Numbers? > i.e. -1/0 => -2147483647 and 0/0 => -2147483648 as well as the current > 1/0 => 2147483647. That would make a *lot* of sense, and make Numbers > and Floats inside float2nr() behave consistently. And since there is a > small chance this could break compatibility (though surely few scripts > would rely on this behaviour), 7.2 would be a good time to make the > change. (It wouldn't be perfect as Numbers don't have a negative zero, > but it'd be as good as possible within the realm of Numbers.) OK. > >> - The neater display is nice. IMHO it would be better to show full > >> precision when this is there. I.e. it's great that :echo 2.7 shows > >> just 2.7. But it'd be great if :echo 2.718281828459045 showed that, > >> rather than just 2.718282. I guess this depends on printf, and so may > >> not be possible (I can't get it to work in Vim at present, doing %.16g > >> and %g loses it's nice truncation of zeros property), but it would be > >> nicer, I think, if it is easily possible. > > > > printf() uses a default precision of 6. I think it's OK for a default, > > showing more is mostly not useful. > > The problem I have with only showing that much is that it gives the > (false) impression that Vim is only using single precision. So... > > - Here is at least another documentation deficiency. Although precision > is mentioned and related to the 'library Vim was compiled with', it > doesn't mention that 'double' is used. That would be good to fix. I'll mention "double". > - 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? > - 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. > >> - 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 > inolving 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 :-). I really added floating point support to do some simple computations, such as adding up a list of amounts and currency conversions. I don't want to get too far from that intention. > >> - Actually, though, an abs() function may be worth implementing, the > >> reason being that with floats you often need to compare with a given > >> precision to make it work. Since often computations will result in > >> slightly different numbers, the == operator is not adequate, and you > >> need to do something like abs(a-b) < 1.0e-9 as a kind of > >> 'approximately equal to' instead. > > > > It's useful. I suppose we can make it work for both Float and Number, > > without changing the return type. > > - You mean returning the same type that it's fed? That sounds like a > great idea to me. > > - 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. > - 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. > - 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. -- hundred-and-one symptoms of being an internet addict: 58. You turn on your computer and turn off your wife. /// 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 -~----------~----~----~----~------~----~------~--~---
