I need to format an integer representation of bytes into something friendly, and I'm hoping that there's a utility function in Ruby or in Rails that will do that formatting for me (to perpetuate my laziness, of course.)
I'm looking for something that would look like:
format_bytes(1024) -> "1 KB"
format_bytes(1048576) -> "1 MB"
Looks like there's some stuff in ActiveSupport to do it the other way around, but I haven't found a way to do it in this direction.
If there isn't one that exists, does anyone have a particularly elegant solution?
Number to human size is what you're looking for.
require 'action_view'
include ActionView::Helpers::NumberHelper
number_to_human_size(123) # => 123 Bytes
number_to_human_size(1234) # => 1.2 KB
number_to_human_size(12345) # => 12.1 KB
number_to_human_size(1234567) # => 1.2 MB
number_to_human_size(1234567890) # => 1.1 GB
number_to_human_size(1234567890123) # => 1.1 TB
number_to_human_size(1234567, :precision => 2) # => 1.18 MB
number_to_human_size(483989, :precision => 0) # => 473 KB
number_to_human_size(1234567, :precision => 2, :separator => ',') # => 1,18 MB
Accepted answer still work, but requires actionpack instead of actionview in newer rails.
require 'actionpack'
Accepted answer it's perfect, but I didn't need the first two lines.
I only put:
number_to_human_size(123) # => 123 Bytes
number_to_human_size(1234) # => 1.2 KB
number_to_human_size(12345) # => 12.1 KB
number_to_human_size(1234567) # => 1.2 MB
number_to_human_size(1234567890) # => 1.1 GB
number_to_human_size(1234567890123) # => 1.1 TB
number_to_human_size(1234567, :precision => 2) # => 1.18 MB
number_to_human_size(483989, :precision => 0) # => 473 KB
number_to_human_size(1234567, :precision => 2, :separator => ',') # => 1,18 MB
and works like a charm.
Related
In my application I need to convert integer to some term; for example:
1 → :red
2 → :green
3 → :blue
The table is static, it is known during compilation time and its indices range from <1, n>. There is around 60 of them.
In which way should the table be represented, so the lookup is the fastest? Dict, HashDict, tuple (with kernel.elem()), ets, function with pattern matching...?
As Julius Beckmann suggested in this case functions with pattern matching should be sufficient as they are according to my measurements over 5 times faster than accessing a map.
Below you can find an implementation of what you are looking for (benchmark code included at the bottom):
defmodule TermLookUpByInteger do
#term_by_integer %{
1 => :aa, 11 => :ba, 21 => :ca, 31 => :da, 41 => :ea, 51 => :fa, 61 => :ga,
2 => :ab, 12 => :bb, 22 => :cb, 32 => :db, 42 => :eb, 52 => :fb, 62 => :gb,
3 => :ac, 13 => :bc, 23 => :cc, 33 => :dc, 43 => :ec, 53 => :fc, 63 => :gc,
4 => :ad, 14 => :bd, 24 => :cd, 34 => :dd, 44 => :ed, 54 => :fd, 64 => :gd,
5 => :ae, 15 => :be, 25 => :ce, 35 => :de, 45 => :ee, 55 => :fe, 65 => :ge,
6 => :af, 16 => :bf, 26 => :cf, 36 => :df, 46 => :ef, 56 => :ff, 66 => :gf,
7 => :ag, 17 => :bg, 27 => :cg, 37 => :dg, 47 => :eg, 57 => :fg, 67 => :gg,
8 => :ah, 18 => :bh, 28 => :ch, 38 => :dh, 48 => :eh, 58 => :fh, 68 => :gh,
9 => :ai, 19 => :bi, 29 => :ci, 39 => :di, 49 => :ei, 59 => :fi, 69 => :gi,
0 => :aj, 10 => :bj, 20 => :cj, 30 => :dj, 40 => :ej, 50 => :fj, 60 => :gj,
}
#doc """
iex> TermLookUpByInteger.lookup_pmf(2)
:ab
"""
def lookup_pmf(int), do: do_lookup(int)
for {int, term} <- #term_by_integer do
defp do_lookup(unquote(int)), do: unquote(term)
end
#doc """
iex> TermLookUpByInteger.lookup_m(3)
:ac
"""
def lookup_m(int), do: #term_by_integer[int]
end
# Benchmark:
n = 1_000_000
range = 1..(n)
measure = fn fun -> :timer.tc(fn -> for _ <- range, do: fun.() end) end
{time_pmf, _result} = measure.(fn -> TermLookUpByInteger.lookup_pmf(:random.uniform(60)) end)
{time_m, _result} = measure.(fn -> TermLookUpByInteger.lookup_m(:random.uniform(60)) end)
IO.puts " Sample size: #{n}"
IO.puts "Pattern matching functions lookup: #{time_pmf/1000} ms"
IO.puts " Map lookup: #{time_m/1000} ms"
IO.puts " Absolute Difference: #{(time_pmf-time_m)/1000} ms"
IO.puts " Relative Difference: #{round((time_pmf-time_m)/time_m*100)}%"
IO.puts " Faster: x #{Float.round(time_m/time_pmf, 2)} times"
Results:
Sample size: 1000000
Pattern matching functions lookup: 447.6 ms
Map lookup: 2423.517 ms
Absolute Difference: -1975.917 ms
Relative Difference: -82%
Faster: x 5.41 times
I hope that will be useful.
If the map is completely static and will not change, you can use generated pattern matching. This will be the fastest way to integrate that lookup in your application.
Some example code, reading these mappings from a external file: https://github.com/h4cc/slugger/blob/master/lib/slugger.ex#L69-72
Instead of using a external file, your source map data can be held in a #attribute.
Even if new mappings will be needed on runtime, these could be handled with a catchall-pattern match doing a lookup in a HashDict.
If you rely on fast access from many processes, then mochiglobal may be the answer. It's tricky constant pool, which keeps keys and values as functions in module. Every time you put/2 something, module is recompiled (it's slow but doesn't matter in your case). With this approach value is not copied into process heap as it is function call. Here is better explanation.
I need to search locations with sort by distance from passed coordinates.
app/indices/location_index.rb
ThinkingSphinx::Index.define :location, :with => :active_record do
indexes :name
has latitude, longitude
end
Try to search:
> Location.search(:geo => [53.348962, 83.777988], :order => "#geodist DESC").size
ThinkingSphinx::SyntaxError: sphinxql: syntax error, unexpected USERVAR, expecting IDENT (or 5 other tokens) near '#geodist DESC LIMIT 0, 20; SHOW META'
> Location.search(:geo => [53.348962, 83.777988],:with => {"#geodist" => 0.0..5000.0}, :order => "#geodist DESC").size
ThinkingSphinx::SphinxError: sphinxql: only >=, <=, and BETWEEN floating-point filter types are supported in this version near '#geodist BETWEEN 0.0 AND 5000.0 AND sphinx_deleted = 0 ORDER BY #geodist DESC LIMIT 0, 20; SHOW META'
Sphinx 2.0.6-release (r3473; Oct 22, 2012)
thinking-sphinx (3.0.1)
Update:
Pat Allan suggested:
Geodist no longer requires the # symbol - so try the following instead:
Location.search(:geo => [53.348962, 83.777988], :order => "geodist DESC").size
Location.search(:geo => [53.348962, 83.777988],:with => {:geodist => 0.0..5000.0}, :order => "geodist DESC").size
Just in case people find this question thought I'd add the answer in the correct format and with a little more explanation.
Versions of Sphinx prior to 2.1.1 made the calculated distance available via the #geodist internal variable. In versions of Thinking Sphinx compatible with newer versions of Sphinx the value of GEODIST() has been aliased to geodist.
So this:
Location.search(:geo => [53.348962, 83.777988], :order => "#geodist DESC").size
Becomes:
Location.search(:geo => [53.348962, 83.777988], :order => "geodist DESC").size
It's also worth pointing out in this example that the coordinates being supplied in the above example are in the incorrect format. They're in degrees rather than radians: http://pat.github.io/thinking-sphinx/geosearching.html. To transform them you can do:
def degrees_to_radians(degrees)
degrees * Math::PI / 180
end
Hope that helps!
I think there is a method within ruby or rails that does this but I can't remember where to find it or how to search for it, so I was hoping stackoverflow's collective wisdom might help.
I don't mind writing a method to do this, but I'm sure someone has a better solution.
number_to_human(1200, :format => '%n%u', :units => { :thousand => 'K' })
# 1200 => 1.2K
If your number happens to be 1223 the accepted answer output would be 1.22K, include the precision parameter to reduce this to 1.2K. Also, if your number could be a wide range of numbers in the millions and billions, then best to cater for these also:
number_to_human(1200, :format => '%n%u', :precision => 2, :units => { :thousand => 'K', :million => 'M', :billion => 'B' })
# => "1.2K"
number_to_human(1223, :format => '%n%u', :precision => 2, :units => { :thousand => 'K', :million => 'M', :billion => 'B' })
# => "1.2K"
number_to_human(1223456789, :format => '%n%u', :precision => 2, :units => { :thousand => 'K', :million => 'M', :billion => 'B' })
# => "1.2B"
Take a look at Rails Number Helper,
The method number_to_human_size might be what you need.
I have set :precision => 8, :scale => 2 in decimal of migration but when i input 1923.423453 it is still 1923.4 . It should be 1923.42 ... right?
t.decimal :value , :precision => 8, :scale => 2 , :default => 0
Apparently all sqlite options are dropped on migration.
Here's the lighthouse ticket targeting milestone 3.0.4 to fix this issue:
https://rails.lighthouseapp.com/projects/8994/tickets/2872-patch-sqlite3-adapter-drops-decimal-columns-precision-scale-when-migration-tries-to-alter-them
sprintf("%g", [float]) allows me to format a floating point number without specifying precision, such that 10.00 is rendered as 10 and 10.01 is rendered as 10.01, and so on. This is neat.
In my application I'm rendering numbers using the Rails NumberHelper methods so that I can take advantage of the localization features, but I can't figure out how to achieve the above functionality through these helpers since they expect an explicit :precision option.
Is there a simple way around this?
Why not just use Ruby's Kernel::sprintf with NumberHelper? Recommended usage with this syntax: str % arg where str is the format string (%g in your case):
>> "%g" % 10.01
=> "10.01"
>> "%g" % 10
=> "10"
Then you can use the NumberHelper to print just the currency symbol:
>> foo = ActionView::Base.new
>> foo.number_to_currency(0, :format => "%u") + "%g"%10.0
=> "$10"
and define your own convenience method:
def pretty_currency(val)
number_to_currency(0, :format => "%u") + "%g"%val
end
pretty_currency(10.0) # "$10"
pretty_currency(10.01) # "$10.01"
I have solved this by adding another method to the NumberHelper module as follows:
module ActionView
module Helpers #:nodoc:
module NumberHelper
# Formats a +number+ such that the the level of precision is determined using the logic of sprintf("%g%"), that
# is: "Convert a floating point number using exponential form if the exponent is less than -4 or greater than or
# equal to the precision, or in d.dddd form otherwise."
# You can customize the format in the +options+ hash.
#
# ==== Options
# * <tt>:separator</tt> - Sets the separator between the units (defaults to ".").
# * <tt>:delimiter</tt> - Sets the thousands delimiter (defaults to "").
#
# ==== Examples
# number_with_auto_precision(111.2345) # => "111.2345"
# number_with_auto_precision(111) # => "111"
# number_with_auto_precision(1111.2345, :separator => ',', :delimiter => '.') # "1,111.2345"
# number_with_auto_precision(1111, :separator => ',', :delimiter => '.') # "1,111"
def number_with_auto_precision(number, *args)
options = args.extract_options!
options.symbolize_keys!
defaults = I18n.translate(:'number.format', :locale => options[:locale], :raise => true) rescue {}
separator ||= (options[:separator] || defaults[:separator])
delimiter ||= (options[:delimiter] || defaults[:delimiter])
begin
number_with_delimiter("%g" % number,
:separator => separator,
:delimiter => delimiter)
rescue
number
end
end
end
end
end
It is the specific call to number_with_delimiter with the %g option which renders the number as described in the code comments above.
This works great for me, but I'd welcome thoughts on this solution.