I'm trying to recalculate percentages in an after_update callback of my model.
def update_percentages
if self.likes_changed? or self.dislikes_changed?
total = self.likes + self.dislikes
self.likes_percent = (self.likes / total) * 100
self.dislikes_percent = (self.dislikes / total) * 100
self.save
end
end
This doesn't work. The percentage always comes out as a 100 or 0, which completely wrecks everything.
Where am I slipping up? I guarantee that self.likes and self.dislikes are being incremented correctly.
The Problem
When you divide an integer by an integer (aka integer division), most programming languages, including Ruby, assume you want your result to be an Integer. This is mostly due to History, because with lower level representations of numbers, an integer is very different than a number with a decimal point, and division with integers is much faster. So your percentage, a number between 0 and 1, has its decimal truncated, and so becomes either 0 or 1. When multiplied by 100, becomes either 0 or 100.
A General Solution
If any of the numbers in the division are not integers, then integer division will not be performed. The alternative is a number with a decimal point. There are several types of numbers like this, but typically they are referred to as floating point numbers, and in Ruby, the most typical floating point number is of the class Float.
1.0.class.ancestors
# => [Float, Precision, Numeric, Comparable, Object, Kernel]
1.class.ancestors
# => [Fixnum, Integer, Precision, Numeric, Comparable, Object, Kernel]
In Rails' models, floats are represented with the Ruby Float class, and decimal with the Ruby BigDecimal class. The difference is that BigDecimals are much more accurate (ie can be used for money).
Typically, you can "typecaste" your number to a float, which means that you will not be doing integer division any more. Then, you can convert it back to an integer after your calculations if necessary.
x = 20 # => 20
y = 30 # => 30
y.to_f # => 30.0
x.class # => Fixnum
y.class # => Fixnum
y.to_f.class # => Float
20 / 30 # => 0
20 / 30.0 # => 0.666666666666667
x / y # => 0
x / y.to_f # => 0.666666666666667
(x / y.to_f).round # => 1
A Solution For You
In your case, assuming you are wanting integer results (ie 42 for 42%) I think the easiest way to do this would be to multiply by 100 before you divide. That pushes your decimal point as far out to the right as it will ever go, before the division, which means that your number is as accurate as it will ever get.
before_save :update_percentages
def update_percentages
total = likes + dislikes
self.likes_percent = 100 * likes / total
self.dislikes_percent = 100 * dislikes / total
end
Notes:
I removed implicit self you only need them on assignment to disambiguate from creating a local variable, and when you have a local variable to disambiguate that you wish to invoke the method rather than reference the variable
As suggested by egarcia, I moved it to a callback that happens before the save (I selected before_save because I don't know why you would need to calculate this percentage on an update but not a create, and I feel like it should happen after you validate that the numbers are correct -- ie within range, and integers or decimal or whatever)
Because it is done before saving, we remove the call to save in the code, that is already going to happen
Because we are not explicitly saving in the callback, we do not risk an infinite loop, and thus do not need to check if the numbers have been updated. We just calculate the percentages every time we save.
Because likes/dislikes is an integer value and integer/integer = integer.
so you can do one of two things, convert to Float or change your order of operations.
self.likes_percent = (self.likes.to_f/total.to_f) * 100
Or, to keep everything integers
self.likes_percent = (self.likes * 100)/total
I'm not sure that this is the only problem that you have, but after_update gets called after the object is saved.
Try changing the update_percentages before - on a before_update or a before_validate instead. Also, remove the self.save line - it will be called automatically later on if you use one of those callbacks.
Related
I have model called Item, where I am updating the unit_price (Data Type is Decimal) value, currently I am not putting any limit when storing the value, storing the value as it is. But now I can see this PG error PG::NumericValueOutOfRange, when the value exceeds the limit.
So I was just trying to limit the value and checking something in the console, Below is the data. (Here in the data I am not putting all the decimal values)
#<Item id: 167199, description: "192830139", category_id: 10327, unit_id: 5596, weight: 0.1e5, unit_price: 0.4083333333659917816764132553606237816656920077972709552126705653021442494641325536062378168e1
i = Item.find 167199
i.unit_price.to_f
=> 4.083333333659918
#<Item id: 167199, description: "192830139", category_id: 10327, unit_id: 5596, weight: 0.1e5, unit_price: 0.6511366980197836882065909262763993442019943880913510722934069011050182329156169820243980265070876781866034494363303661586489199452739290976143216266200531728395970406461889852558384421962422689303402903e-2
i.unit_price.to_f
=> 0.006511366980197837
Can I know what will be the reason the to_f automatically reduce the limit of the decimal? What will be best way to solve this issue, I was just thinking about some truncate with some limit.
Can I know what will be the reason the to_f automatically reduce the limit of the decimal?
The reason is the to_f methods are used to convert objects to Floats, which are standard 64-bit double precision floating point numbers. The precision of these numbers is limited, therefore the precision of the original object must be automatically reduced during the conversion process in order to make it fit in a Float. All extra precision is lost.
It looks like you are using the BigDecimal class. The BigDecimal#to_f method will convert the arbitrary precision floating point decimal object into a Float. Naturally, information will be lost during this conversion should the big decimal be more precise than what Floats allow. This conversion can actually overflow or underflow if limits are exceeded.
I was just thinking about some truncate with some limit
There is a truncate method if you'd like explicit control over the precision of the result. No rounding of any kind will occur, there is a separate method for that.
BigDecimal#truncate
Deletes the entire fractional part of the number, leaving only an integer.
BigDecimal('3.14159').truncate #=> 3
BigDecimal#truncate(n)
Keeps n digits of precision, deletes the rest.
BigDecimal('3.14159').truncate(3) #=> 3.141
you can use ruby's built-in .truncate() method
for example:
floatNum = 1.222222222222222
truncatedNum = floatNum.truncate(3) #3 is the number of decimal places you want
puts floatNum #returns 1.222
another way is to use the .round() method
for example:
I'm looking for a way to simplify the code for the following logic:
Take a value that is either a nil or an empty string
Convert that value to an integer
Set zero values to the maximum value (empty string/nil are converted to 0 when cast as an int)
.clamp the value between a minimum and a maximum
Here's the long form that works:
minimum = 1
maximum = 10_000
value = value.to_i
value = maximum if value.zero?
value = value.clamp(minimum, maximum)
So for example, if value is "", I should get 10,000. If value is "15", I should get 15. If value is "45000", I should get 10000.
Is there a way to shorten this logic, assuming that minimum and maximum are defined and that the default value is the maximum?
The biggest problem I've had in shortening it is that null-coalescing doesn't work on the zero, since Ruby considers zero a truthy value. Otherwise, it could be a one-liner.
you could still do a one-liner with your current logic
minimum, maximum = 1, 10_000
value = ( value.to_i.zero? ? maximum: value.to_i ).clamp(minimum, maximum)
but not sure if your issue is that if you enter '0' you want 1 and not 10_000 if so then try this
minimum, maximum = 1, 10_000
value = (value.to_i if Float(value) rescue maximum).clamp(minimum, maximum)
Consider Fixing the Input Object or Method
If you're messing with String objects when you expect an Integer, you're probably dealing with user input. If that's the case, the problem should really be solved through input validation and/or looping over an input prompt elsewhere in your program rather than trying to perform input transformations inline.
Duck-typing is great, but I suspect you have a broken contract between methods or objects. As a general rule, it's better to fix the source of the mismatch unless you're deliberately wrapping some piece of code that shouldn't be modified. There are a number of possible refactorings and patterns if that's the case.
One such solution is to use a collaborator object or method for information hiding. This enables you to perform your input transformations without complicating your inline logic, and allowing you to access the transformed value as a simple method call such as user_input.value.
Turning a Value into a Collaborator Object
If you are just trying to tighten up your current method you can aim for shorter code, but I'd personally recommend aiming for maintainability instead. Pragmatically, that means sending your value to the constructor of a specialized object, and then asking that object for a result. As a bonus, this allows you to use a default variable assignment to handle nil. Consider the following:
class MaximizeUnsetInputValue
MIN = 1
MAX = 10_000
def initialize value=MAX
#value = value
set_empty_to_max
end
def set_empty_to_max
#value = MAX if #value.to_i.zero?
end
def value
#value.clamp MIN, MAX
end
end
You can easily validate that this handles your various use cases while hiding the implementation details inside the collaborator object's methods. For example:
inputs_and_expected_outputs = [
[0, 10000],
[1, 1],
[10, 10],
[10001, 10000],
[nil, 10000],
['', 10000]
]
inputs_and_expected_outputs.map do |input, expected|
MaximizeUnsetInputValue.new(input).value == expected
end
#=> [true, true, true, true, true, true]
There are certainly other approaches, but this is the one I'd recommend based on your posted code. It isn't shorter, but I think it's readable, maintainable, adaptable, and reusable. Your mileage may vary.
I have a list of float numbers, representing currency, and I need to turn them into integers, for precision.
The task is to turn float numbers into integers, likes:
0.95 => 95
1 => 100
1,465.01 => 146501
The problem is:
I don't have access to change the input csv files
The numbers came in a variety of ways (1.00, 1.0, 1, .95, 0.95, etc)
How can, safely, I turn these numbers into integers?
Some examples of my problem:
('16.81'.to_f * 100).to_i => 1680
('16.81'.to_f * 100_00).to_i / 100 => 1681
('342.28'.to_f * 100).to_i => 34228
('342.28'.to_f * 100_00).to_i / 100 => 34227
__ EDIT __
By the way, I'm using ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin19]
Floating point numbers can't necessarily represent all decimal numbers. This is explained in Is floating point math broken?. As such, when dealing with floats, you are always a bit uncertain and usually need to use rounding to get a desired number.
From your examples, ('16.81'.to_f * 100) results in 1680.9999999999998. Getting the integer value from that cuts off the fractional part, resulting in 1680. By using round instead, you can get the desired integer (which also solves the issue of partial cents). When relying on this, please note the details of how Ruby rounds exactly, specifically the optional half argument).
Instead of relying on Floats however, a better idea is to use BigDecimal numbers instead which allow arbitrary precision floating point numbers.
require 'bigdecimal'
(BigDecimal('16.81') * 100).round
# => 1681
(BigDecimal('.95') * 100).round
# => 95
number = '1,465.01'
# remove any "additional" characters
normalized = number.gsub(/[^-+0-9.]/, '')
(BigDecimal(normalized) * 100).round
# => 146501
In the last example, I have shown how you might cleanup your "human-readable" numbers for consistent parsing. Depending on your source data, you might need to perform additional changes (e.g. if you might have values such as '1.465,01' as is common in e.g. some European countries).
Use Bigdecimal for float numbers and append .to_i to convert it in integer
require 'bigdecimal'
(BigDecimal('16.81') * 100).to_i # 1681
(BigDecimal('342.28') * 100).to_i # 34228
For more details you can refer https://corainchicago.github.io/blog/why-does-ruby-add-numbers-wrong/
I have to send the amount of some price in cents to Stripe in order to make charge against a card. In my app, the total_price value is a decimal, i.e in dollars and cents. Obviously, I can convert this to cents by multiplying by 100:
total_price * 100
But the result is still a decimal, and Stripe gives me an 'Invalid amount' error. I know there can be issues with rounding floats. I want to know the safest way to cast my total_price to an integer in Rails. I have seen some reference to a money gem but is this necessary in this case?
Ruby has several methods available to floats, depending on what you need:
(cart.total_price * 100).to_i (discards all decimals)
(cart.total_price * 100).round # .round(numofdecimals)
(cart.total_price * 100).floor # 1.3 => 1
(cart.total_price * 100).ceil # 1.3 => 2
(cart.total_price * 100).to_r #to rationals, e.g. 2.5 => 5/2
I hope this helps.
There is actually a very easy way to do this, directly from a decimal without converting to a float first. Given:
decimal price = BigDecimal('100.00')
You can use BigDecimal's fix() and frac() methods to take the first part, multiply by 100 and add the fraction:
price_in_cents = ((decimal_price.fix * 100) + decimal_price.frac).to_i
Another seemingly simple possibility is to use string manipulation. You can convert the decimal to a string, strip the period, and convert to integer like:
price_in_cents = decimal_price.to_s.sub('.', '').to_i
But the gotcha here is that decimal_price.to_s == '100.0' not '100.00'. If there are non-zero digits in the fraction, then they would be preserved in the conversion, but otherwise one is lost. So if decimal_price == 111.11 then the above string manipulation would return the expected result.
I am storing a cost in my application. The cost is not formatted in the database. For example: 00.00 saves as 0, 1.00 saves as 1, and 40.50 saves as 40.5
I need to read these values from the database and convert them to strings for dollars and cents. For example: 0 --> cost_dollars = "00" & cost_cents = "00", 1 --> cost_dollars = "01" & cost_cents = "00", 40.5 --> cost_dollars = "40" & cost_cents = "50".
Is there an easy way to do this in ruby on rails? Or does someone have code that does this?
Thanks!
You can accomplish that with this little bit of Ruby code:
fmt = "%05.2f" % cost
cost_dollars, cost_cents = fmt.split '.'
If you're trying to format dollar values in a view, you should look at number_to_currency in ActionView::Helpers::NumberHelper.
>> bd = BigDecimal.new "5.75"
>> include ActionView::Helpers
>> number_to_currency(bd)
=> "$5.75"
As for breaking up the value into separate dollars and cents, my first question would be, "Why?" If you have a good reason, and you're dealing with decimals in your database, then you could do the following.
>> bd = BigDecimal.new "5.75"
>> "dollars:#{bd.truncate} cents:#{bd.modulo(1) * BigDecimal.new('100')}"
=> "dollars:5.0 cents:75.0"
number_to_currency is nice, but it can get expensive; you might want to roll your own if you need to call it a lot.
You should be aware that using a float to store currency can be problematic (and see) if you do a lot of calculations based on these values. One solution is to use integers for currency and count cents. This appears to be the approach used by the money plugin. Another solution is to use a decimal type in your migration, which should work out-of-the-box for modern versions of Rails (> 1.2):
add_column :items, :price, :decimal, :precision => 10, :scale => 2
(:scale is the number of places past the decimal, :precision is the total number of digits.) This will get you BigDecimal objects in Rails, which are a little harder to work with, but not too bad.
Both the integer and decimal approaches are a little slower than floating point. I'm using floats for currency in some places, because I know I won't need to do calculations on the values within Rails, only store and display them. But if you need accurate currency calculations, don't use floats.
Instead of storing as a decimal, store as an integral number of cents. So 1 dollar is stored as 100 in the database.
Alternatively, if you don't mind a bit of performance overhead, check for '.' in the database's value. If it exists, split on '.', and parse the pieces as integers.
sprintf is your friend here:
cost_dollars = sprintf('%02.f', cost)
cost_cents = sprintf('%.2f', cost)