I asked a while back what effect the ‘-w’ flag had.
I believe that, in response, I was told warned you about things like:
if var = 3 # ‘=’ instead of ‘==’
…
end
But Ruby warns you about that anyways. The man page says:
-w enables verbose mode without printing version message
at the beginning. It set the `$VERBOSE' variable to
true.
Is that all it does? It sets $VERBOSE to true?
At first sight, Ruby seems to behave like it has the equivalent of Perl’s
warnings by default. If that’s the case, that’s wornderful. I just want
to know if that is the case.
Thanks for the help,
Daniel Carrera
Graduate Teaching Assisant. Math Dept.
University of Maryland. (301) 405-5137
’ Enables verbose mode. Unlike -v, reads program from standard input if no
program files are present on the command line. We recommend running your
Ruby programs with -w.
I asked a while back what effect the ‘-w’ flag had.
I believe that, in response, I was told warned you about things like:
if var = 3 # ‘=’ instead of ‘==’
…
end
But Ruby warns you about that anyways. The man page says:
-w enables verbose mode without printing version message
at the beginning. It set the `$VERBOSE' variable to
true.
Is that all it does? It sets $VERBOSE to true?
At first sight, Ruby seems to behave like it has the equivalent of Perl’s
warnings by default. If that’s the case, that’s wornderful. I just want
to know if that is the case.
Thanks for the help,
Daniel Carrera
Graduate Teaching Assisant. Math Dept.
University of Maryland. (301) 405-5137
dcarrera ~ $ ruby -we ‘p (1)’
-e:1: warning: p (…) interpreted as method call
1
What does that error mean? What’s wrong with ‘p (1)’. I realize that
it’s the space before the bracket that causes the error. But I don’t
understand what’s wrong with the space.
Thanks.
Daniel Carrera
Graduate Teaching Assisant. Math Dept.
University of Maryland. (301) 405-5137
In message “Re: warnings -w” on 02/12/10, Daniel Carrera dcarrera@math.umd.edu writes:
dcarrera ~ $ ruby -we ‘p (1)’
-e:1: warning: p (…) interpreted as method call
1
What does that error mean? What’s wrong with ‘p (1)’. I realize that
it’s the space before the bracket that causes the error. But I don’t
understand what’s wrong with the space.
Think about “p (1+2)*3”. It’s “(p(1+2))*3”, not “p((1+2)*3)”,
1.7 has different parentheses priority though.
The problem is that two-tenths (0.2) cannot be exactly represented as a
binary floating point number. When you look at the details, the number
0.2 is just really …
“%.20f” % 0.2
=> “0.20000000000000001110”
… or just a shade larger than two-tenths. Therefore, when you divide
2.4 by something just a bit larger that two-tenths, you get something
just a bit smaller than 12…
This is a consequence of representing numbers in floating point and is
common whenever dealing with floating point numbers. Last week at work,
I came across a situation where a sum of monetary amounts were off by a
penny … Yes, they were using floating point to represent dollar
amounts. Never a good idea.
···
On Tue, 2002-12-10 at 03:07, Daniel Carrera wrote:
The problem is that two-tenths (0.2) cannot be exactly represented as a
binary floating point number. When you look at the details, the number
0.2 is just really …
“%.20f” % 0.2
=> “0.20000000000000001110”
… or just a shade larger than two-tenths. Therefore, when you divide
2.4 by something just a bit larger that two-tenths, you get something
just a bit smaller than 12…
This is a consequence of representing numbers in floating point and is
common whenever dealing with floating point numbers. Last week at work,
I came across a situation where a sum of monetary amounts were off by a
penny … Yes, they were using floating point to represent dollar
amounts. Never a good idea.
Duh forgot about that, wish I’d recieved this before I sent my mail out.
Well, you can search comp.lang.c about a thread on what type to use
(int/long/double/etc.) to represent dollar amounts (including the
cents). I don’t think there is a clear answer that representing dollar
amounts with floating point is a bad idea. It depends on what kinds of
operations you are going to do, which in this case is a division.
This is a consequence of representing numbers in floating point and is
common whenever dealing with floating point numbers. Last week at work,
I came across a situation where a sum of monetary amounts were off by a
penny … Yes, they were using floating point to represent dollar
amounts. Never a good idea.
My own experience (based on developing real-time trading systems for
some merchant banks), is that the best solution is to use scaled
integers, to 100th of a cent. So, $154.34 → 1543400. You then
get very fast operations (they are all integer operations) and, in
general, well with ± 4 billion. Ruby, with BigInt makes it trivial.
Yes, they were using floating point to represent dollar
amounts. Never a good idea.
Well, you can search comp.lang.c about a thread on what type to use
(int/long/double/etc.) to represent dollar amounts (including the
cents). I don’t think there is a clear answer that representing dollar
amounts with floating point is a bad idea. It depends on what kinds of
operations you are going to do, which in this case is a division.
This is a consequence of representing numbers in floating point and is
common whenever dealing with floating point numbers. Last week at work,
I came across a situation where a sum of monetary amounts were off by a
penny … Yes, they were using floating point to represent dollar
amounts. Never a good idea.
Well, you can search comp.lang.c about a thread on what type to use
(int/long/double/etc.) to represent dollar amounts (including the
cents). I don’t think there is a clear answer that representing dollar
amounts with floating point is a bad idea. It depends on what kinds of
operations you are going to do, which in this case is a division.
In the rare case that I have represented money, I’ve used an integer to
represent the nuber of cents, with a “Currency” (or similar) class wrapped
around it providing lots of groovy methods.
As 2.4 /0.2 is fundementally 12, why should (2.4/0.2).floor or .truncate
give 11?
It’s 12 on the real number line. It’s something quite different
in your computers implementation of IEEE floating point
standards.
The method should be called on the result of the 2.4 / 0.2 calculation
which is 12 or 12.0 and therefore the result should always be 12.
This is a fact of life in doing floating point
arithmetic on a computer and has absolutely nothing to do with
Ruby. I suggest that you goggle IEEE floating point and learn
some of the basics of floating point programming.
Normally, I think financial people like to use fixed-point stuff, so that they
don’t get any kind of strange rounding errors, like adding up a bunch of
numbers that should be precisely $1.00 and getting $99.997 or something like
that.
Maybe there’s room for a Money class that uses the encoding suggested above
(ie $154.34 is represented as 1543400), but has an appropriate to_s (not sure
whether you’d need anything else). For that matter, I guess a more generic
FixedPoint class could be set up and Money could be a subclass of that.
I realise there are probably issues like … what does you do if you have X
dollars and want to do calculations based on it and some non FixedPoint
value, like an interest rate of 6.25%. I guess you’d need appropriate
conversions between floating point and FixedPoint.
In any case, I’m sure these are things that people who do financial
calculations have thought about long and hard and have appropriate solutions
for.
Yes, they were using floating point to represent dollar
amounts. Never a good idea.
Well, you can search comp.lang.c about a thread on what type to use
(int/long/double/etc.) to represent dollar amounts (including the
cents). I don’t think there is a clear answer that representing dollar
amounts with floating point is a bad idea. It depends on what kinds of
operations you are going to do, which in this case is a division.
My own experience (based on developing real-time trading systems for
some merchant banks), is that the best solution is to use scaled
integers, to 100th of a cent. So, $154.34 → 1543400. You then
get very fast operations (they are all integer operations) and, in
general, well with ± 4 billion. Ruby, with BigInt makes it trivial.