> When would you need Float -> Int? You can actually use
> printf(".0f", float), and rely on automatic String to Int conversion,
> but it's clumsy.
Float -> Int can be very handy, using floats as intermediate
calculations in scripts and then converting to ints for some kind of
display or condition, but usually in combination with a well-defined way
of converting between...i.e. a ceil, floor, round function. It would be
good if some of these could be implemented. How about a single round
function with a second parameter to specify the type of rounding, and
return an int? The second argument could be 'floor|down|int' (round
down), 'ceil|up' (round up), 'trunc|zero' (towards zero), 'away' (away
from zero), 'nearest|round' (towards nearest integer, round away from
zero if half way), 'even' (towards nearest integer, round to the even
number if half way).
>> 2. This is not strictly related to floating point, just noticed:
>>
>> :echo 1/0
>> 2147483647
>>
>> :echo 1.0/0
>> 2.147484e+09
>>
>> Shouldn't divide by 0 throw error?
>
> The number you see is the largest int value or a special value for
> floats which is INFINITY.
Something is wrong there, because it's not anywhere near the largest
value for floats, it is simply the largest value for a 32 bit int
converted to a float. Looks like some integer code has interfered with
the float code. Only on your system though. My system correctly reports
'inf', the special IEEE floating point representation of 'infinity'.
There is still a bug there, though:
:echo -1/0 " gives 2147483647, see below
:echo 0/0 " gives 2147483647, see below
:echo -1.0/0 " gives inf, should give -inf
:echo 0.0/0 " gives inf, should give nan
For the integer ones, the negative should report, if the 'maximum value'
philosophy is followed, -2147483648 (==-2^31, the smallest value a
32-bit int can represent). Though in Vim, a case could be made for
actually returning -2147483647 (i.e. one unit 'too high') since in Vim
-(-2147483648) == -2147483648 due to overflow, which isn't very
desirable! In practice, using -2147483647 and having a sign change work
as expected would be more useful. Care would have to be taken to have
things that work on 64 bit systems, too, I guess (and systems with
smaller words if we still compile for those!). However, this whole idea
isn't all that useful with ints anyway. It is useful with floats,
though, In most environments, integer division by zero chucks an error
and float division reports inf, -inf or nan as appropriate.
Apart from various types rounding, which I can definitely imagine being
useful, are there any mathematical functions that could be handy in a
text processing environment? So far I can only think of 'toy'
applications for them! Perhaps to minimise disruption but allow
flexibility they could all be wrapped in a 'math' function, where the
first argument is the function, and the second and optionally third
arguments are the parameters?
math('sqrt',argument)
math('exp',exponent[,base=e])
math('log',argument[,base=e])
math('sin',argument[,degrees (bool)=0])
math('cos',argument[,degrees (bool)=0])
math('tan',argument[,degrees (bool)=0])
math('atan',argument[,degrees (bool)=0])
I think that covers all the basics in an extensible and inobtrusive way.
>> 4. Cosmetic thing but truncating of 0s in floating numbers would be user
>> friendly (eg. store and display 0.5 instead of 0.500000)
>
> I don't see an argument to printf() to get this.
Yeah, that'd be a good improvement.
Are floats or doubles being used? They are definitely being displayed
with float, not double, precision at present. I would vastly prefer
double precision. 7 significant figures is barely worth it, and wouldn't
cut it for a lot of data files where having floating points in a text
editor would actually be useful! 15 significant figures gives you a lot
of power, and would allow you to interact with the floating points just
as accurately as most other software that would be reading your data
files.
Ben.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
