Rails - Jul 2006 - Reading floating points into a field stored as Integers

Hi, I''m trying to follow the "AWDR" example of storing
certain types of
numbers (in my case, percentages not money) as integers in the 
database.  I understand from the Depot application how to format the 
output to have 2 places (or n places for that matter) decimal.

Now, I"m wondering about the input.  It''s more natural for people
to
enter numbers as "11.23" if that''s what it means rather than
1123.
What''s the correct way to fix this?  Should I read the numbers as 
entered by the user and multiply by 100 and type cast to integer (ouch, 
my C programming is showing)

Thanks,
mohit.

As of yesterday, the new beta version of AWDWR references the use of  
BigDecimal in Edge Rails, and says don''t bother with integers.  So,  
if you''re just getting started, I would "rake
rails:freeze:edge" and
not bother with integers.

            - dan
-- 
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>



On Jul 22, 2006, at 12:06 PM, Mohit Sindhwani wrote:
> Hi, I''m trying to follow the "AWDR" example of storing
certain
> types of numbers (in my case, percentages not money) as integers in  
> the database.  I understand from the Depot application how to  
> format the output to have 2 places (or n places for that matter)  
> decimal.
>
> Now, I"m wondering about the input.  It''s more natural for
people
> to enter numbers as "11.23" if that''s what it means
rather than
> 1123.  What''s the correct way to fix this?  Should I read the  
> numbers as entered by the user and multiply by 100 and type cast to  
> integer (ouch, my C programming is showing)
>
> Thanks,
> mohit.
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Thanks Dan!

That reminds me!  I need to update my PDF!  I''m not sure if the new 
version of AWDWR covers how BigDecimal can be used in migrations.  My 
first feeling was that portable migrations are rather scant on data 
types :-|

For example, there is only one integer type which maps to int(11) on 
MySQL.  I have 18 fields in my model that take a value between 1 and 5.  
It seems a bit of a waste.  But, I''m just going along for now - will 
drop the tables, change the migrations and re-apply later when I am done 
with the first quick prototype to see where I''m heading.

Cheers
Mohit.



Dan Kohn wrote:
> As of yesterday, the new beta version of AWDWR references the use of 
> BigDecimal in Edge Rails, and says don''t bother with integers. 
So, if
> you''re just getting started, I would "rake
rails:freeze:edge" and not
> bother with integers.
>
>            - dan
> --Dan Kohn <mailto:dan@dankohn.com>
> <http://www.dankohn.com/>  <tel:+1-415-233-1000>
>
>
>
> On Jul 22, 2006, at 12:06 PM, Mohit Sindhwani wrote:
>
>> Hi, I''m trying to follow the "AWDR" example of
storing certain types
>> of numbers (in my case, percentages not money) as integers in the 
>> database.  I understand from the Depot application how to format the 
>> output to have 2 places (or n places for that matter) decimal.
>>
>> Now, I"m wondering about the input.  It''s more natural
for people to
>> enter numbers as "11.23" if that''s what it means
rather than 1123.
>> What''s the correct way to fix this?  Should I read the numbers
as
>> entered by the user and multiply by 100 and type cast to integer 
>> (ouch, my C programming is showing)
>>
>> Thanks,
>> mohit.
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

Yep, by using migrations, you''re trading some potential optimizations  
available from one kind of database for the ability to trivially  
switch between databases.  I think worrying about those extra 10  
digits is likely a case of premature optimization, given the price of  
disk drives.

            - dan
-- 
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>



On Jul 22, 2006, at 12:29 PM, Mohit Sindhwani wrote:
> Thanks Dan!
>
> That reminds me!  I need to update my PDF!  I''m not sure if the
new
> version of AWDWR covers how BigDecimal can be used in migrations.   
> My first feeling was that portable migrations are rather scant on  
> data types :-|
>
> For example, there is only one integer type which maps to int(11)  
> on MySQL.  I have 18 fields in my model that take a value between 1  
> and 5.  It seems a bit of a waste.  But, I''m just going along for
> now - will drop the tables, change the migrations and re-apply  
> later when I am done with the first quick prototype to see where  
> I''m heading.
>
> Cheers
> Mohit.
>
>
>
> Dan Kohn wrote:
>> As of yesterday, the new beta version of AWDWR references the use  
>> of BigDecimal in Edge Rails, and says don''t bother with
integers.
>> So, if you''re just getting started, I would "rake  
>> rails:freeze:edge" and not bother with integers.
>>
>>            - dan
>> --Dan Kohn <mailto:dan@dankohn.com>
>> <http://www.dankohn.com/>  <tel:+1-415-233-1000>
>>
>>
>>
>> On Jul 22, 2006, at 12:06 PM, Mohit Sindhwani wrote:
>>
>>> Hi, I''m trying to follow the "AWDR" example of
storing certain
>>> types of numbers (in my case, percentages not money) as integers  
>>> in the database.  I understand from the Depot application how to  
>>> format the output to have 2 places (or n places for that matter)  
>>> decimal.
>>>
>>> Now, I"m wondering about the input.  It''s more
natural for people
>>> to enter numbers as "11.23" if that''s what it
means rather than
>>> 1123.  What''s the correct way to fix this?  Should I read
the
>>> numbers as entered by the user and multiply by 100 and type cast  
>>> to integer (ouch, my C programming is showing)
>>>
>>> Thanks,
>>> mohit.
>>>
>>> _______________________________________________
>>> Rails mailing list
>>> Rails@lists.rubyonrails.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>>

I agree with you!  I''ve made a note in my programming log that it can
be
optimized and has been marked for a later point in the development :-)  
though I have to admit that it does bother me a bit since I come from a 
C and assembly language background in which 10 extra bytes x 18 fields = 
180 extra bytes per record would be considered career-ending :-)

Cheers
Mohit.

Dan Kohn wrote:
> Yep, by using migrations, you''re trading some potential
optimizations
> available from one kind of database for the ability to trivially 
> switch between databases.  I think worrying about those extra 10 
> digits is likely a case of premature optimization, given the price of 
> disk drives.
>
>            - dan
> --Dan Kohn <mailto:dan@dankohn.com>
> <http://www.dankohn.com/>  <tel:+1-415-233-1000>
>
>
>
> On Jul 22, 2006, at 12:29 PM, Mohit Sindhwani wrote:
>
>> Thanks Dan!
>>
>> That reminds me!  I need to update my PDF!  I''m not sure if
the new
>> version of AWDWR covers how BigDecimal can be used in migrations.  My 
>> first feeling was that portable migrations are rather scant on data 
>> types :-|
>>
>> For example, there is only one integer type which maps to int(11) on 
>> MySQL.  I have 18 fields in my model that take a value between 1 and 
>> 5.  It seems a bit of a waste.  But, I''m just going along for
now -
>> will drop the tables, change the migrations and re-apply later when I 
>> am done with the first quick prototype to see where I''m
heading.
>>
>> Cheers
>> Mohit.
>>
>>
>>
>> Dan Kohn wrote:
>>> As of yesterday, the new beta version of AWDWR references the use
of
>>> BigDecimal in Edge Rails, and says don''t bother with
integers.  So,
>>> if you''re just getting started, I would "rake
rails:freeze:edge" and
>>> not bother with integers.
>>>
>>>            - dan
>>> --Dan Kohn <mailto:dan@dankohn.com>
>>> <http://www.dankohn.com/>  <tel:+1-415-233-1000>
>>>
>>>
>>>
>>> On Jul 22, 2006, at 12:06 PM, Mohit Sindhwani wrote:
>>>
>>>> Hi, I''m trying to follow the "AWDR" example
of storing certain
>>>> types of numbers (in my case, percentages not money) as
integers in
>>>> the database.  I understand from the Depot application how to 
>>>> format the output to have 2 places (or n places for that
matter)
>>>> decimal.
>>>>
>>>> Now, I"m wondering about the input.  It''s more
natural for people
>>>> to enter numbers as "11.23" if that''s what
it means rather than
>>>> 1123.  What''s the correct way to fix this?  Should I
read the
>>>> numbers as entered by the user and multiply by 100 and type
cast to
>>>> integer (ouch, my C programming is showing)
>>>>
>>>> Thanks,
>>>> mohit.