I defined a decimal field with a scale / significant digits of 4 in mysql (ex. 10.0001 ). ActiveRecord returns it as a BigDecimal.
I can set the field in ActiveRecord with a scale of 5 (ex. 10.00001 ), and save it, which effectively truncates the value (it's stored as 10.0000).
Is there a way to prevent this? I already looked at the BigDecimal class if there is a way to force scale. Couldn't find one. I can calculate the scale of a BigDecimal and return a validation error, but I wonder if there is a nicer way to enforce it.
You could add a before_save handler for your class and include logic to round at your preference, for example:
class MyRecord < ActiveRecord::Base
SCALE = 4
before_save :round_decimal_field
def round_decimal_field
self.decimal_field.round(SCALE, BigDecimal::ROUND_UP)
end
end
r = MyRecord.new(:decimal_field => 10.00009)
r.save!
r.decimal_field # => 10.0001
The scale factor might even be assignable automatically by reading the schema somehow.
See the ROUND_* constant names in the Ruby BigDecimal class documentation for other rounding modes.
Related
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 Thing class with an float x attribute. And I want to approximately compare two instances of Thing with a relelative tolerance of 1e-5.
import attr
#attr.s
class Thing(object):
x: float = attr.ib()
>>> assert Thing(3.141592) == Thing(3.1415926535) # I want this to be true with a relelative tolerance of 1e-5
False
Do I need to override the __eq__ method or is there a clean way of telling attr to use math.isclose() or a custom comparison function?
Yes, setting eq=True and implementing your own __eq__/__ne__ is your way to go. In this case your need is so specific that I wouldn't even know how to abstract it away without making it confusing.
I am using Dentaku gem to solve little complex expressions like basic salary is 70% of Gross salary. As the formulas are user editable so I worked on dentaku.
When I write calculator = Dentaku::Calculator.new to initialize and then enter the command calculator.evaluate("60000*70%") then error comes like below:
Dentaku::ParseError: Dentaku::AST::Modulo requires numeric operands
from /Users/sulman/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/dentaku-2.0.8/lib/dentaku/ast/arithmetic.rb:11:in `initialize'
I have array is which formula is stored like: ["EarningItem-5","*","6","7","%"] where EarningItem-5 is an object and has value 60000
How can I resolve such expressions?
For this particular case you can use basic_salary = gross_salary * 0.7
Next you need to create the number field in your views which accepts 0..100 range. At last, set up the after_save callback and use this code:
model
after_create :percent_to_float
protected
def percent_to_float
self.percent = percent / 100.0
self.save
end
edit:
Of course, you can simply use this formula without any callbacks:
basic_salary = gross_salary / 100.0 * 70
where 70 is user defined value.
Dentaku does not appear to support "percent". Try this instead
calculator.evaluate('60000 * 0.7')
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.
I'd like to implement measurement unit preferences in a Ruby on Rails app.
For instance, the user should be able to select between displaying distances in miles or in kilometers. And, obviously, not only displaying, but entering values, too.
I suppose all values should be stored in one global measurement system to simplify calculations.
Are there any drop-in solutions for this? Or should I maybe write my own?
The ruby gem "ruby-units" may help:
http://ruby-units.rubyforge.org/ruby-units/
require 'rubygems'
require 'ruby-units'
'8.4 mi'.to('km') # => 13.3576 km
'8 lb 8 oz'.to('kg') # => 3.85554 kg
a = '3 in'.to_unit
b = Unit('5 cm')
a + b # => 4.968 in
(a + b).to('cm') # => 16.62 cm
You can maybe have a look at this gem, which let's you perform some unit conversions.
Quantity on Github
I built Unitwise to solve most unit conversion and measurement math problems in Ruby.
Simple usage looks like this:
require 'unitwise/ext'
26.2.mile.convert_to('km')
# => #<Unitwise::Measurement 42.164897129794255 kilometer>
If you want store measurements in your Rails models, you could do something like this:
class Race < ActiveRecord::Base
# Convert value to kilometer and store the number
def distance=(value)
super(value.convert_to("kilometer").to_f)
end
# Convert the database value to kilometer measurement when retrieved
def distance
super.convert_to('kilometer')
end
end
# Then you could do
five_k = Race.new(distance: 5)
five_k.distance
# => #<Unitwise::Measurement 5 kilometer>
marathon = Race.new(distance: 26.2.mile)
marathon.distance.convert_to('foot')
# => #<Unitwise::Measurement 138336.27667255333 foot>
Quick search on GitHub turned up this: http://github.com/collectiveidea/measurement
Sounds like it does what you need (as far as converting between units), but I can't say I've used it myself.
Edit: Pierre's gem looks like it's more robust and active.