Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ChrisRainman]

Is there an expression that allows to calculate an integer value of a decimal value for calculated fields?

I am playing a bit around with calculated fields in combination with the MATH function. Like the "hidden" POW function I hope there might be also a function for integer like INT. Would be great if this could be added!

What was an alternative option - at least for my needs - if it was possible to define of what data type calculated fields are. For internal fields I can define the data types. For calculated not.

[ChrisRainman]

What about options to allow defining a data type for calculated fields or - better - adding a function to transform vaues into integers?

By the way:
the data type for 5 star fields should be handled as integer, or? Currently, in view schemes the operators for such fields (I added album rate) seem to handle those fields as string, so I receive "is / contains / does not contain..." instead of "equal / less than..."

[gappie]

What about options to allow defining a data type for calculated fields or - better - adding a function to transform vaues into integers?

i would like that also.
at this moment mc treads a calculated field as a string, i think. the result is that when you put such a field under for instance an album thumb, the result is <varies>, not 20.1 avg, or something like that.

 
gab

[pbair]

FormatNumber() will round decimal numbers to the nearest whole number.  If what you need is to truncate the decimal part then you can use FormatNumber() to do that, too...with a little help:


Where YourNumber is >=0:
FormatNumber(Math(FormatNumber(Math(YourNumber+0.5))-1))

YourNumber = 5.789 results in 5
YourNumber = 5.089 results in 5


Where YourNumber is <0, the following will need to be used:
FormatNumber(Math(FormatNumber(Math(YourNumber-0.5))+1))


In a more general sense, the first expression above can be used as a RoundUp() function and the second expression as a RoundDown() function for positive values. (other way around for negative values)

[ChrisRainman]

In a more general sense, the first expression above can be used as a RoundUp() function and the second expression as a RoundDown() function for positive values. (other way around for negative values)

I was not aware of that possibilities.  :)Thanks that helps already.

Anyway, like gappie showed with an example - for all field types it should be possible to set the data type.

[gappie]

Bump 
it would be sweet if we could set the data type for calculated fields, or when there are numbers it treads them as numbers, so that the <varies> will be an average?

please
 
gab

[gappie]

Bump  
it would be sweet if we could set the data type for calculated fields, or when there are numbers it treads them as numbers, so that the <varies> will be an average?

please
 
gab

ok.. found it.  
apparently you first have to make the field integer or what ever, save the field, and then set it to the calculation again. it seems like it has no influence, but averages are calculated instead of [varies].

dont know why i never tried it.
im happy
 
gab

edit: now if only average would take 0 or empty values into account.  
edit2: only thing that helps is making sure that its never 0 in a calculation, but for instance 0.000001, works also when value is defined as an integer.

[ChrisRainman]

ok.. found it.  
apparently you first have to make the field integer or what ever, save the field, and then set it to the calculation again. it seems like it has no influence, but averages are calculated instead of [varies].

dont know why i never tried it.
im happy
 
gab

  me too now! I am also wondering why I never tried that before. I doubt that this feature is available by purpose - but who cares. Anyway, the fields to chose the data type should changable when selecting user-defined fields. As it is now, only by reading this thread users would find out how to set data types for calculated fields.

[gappie]

it is interesting how the rules from smartlist change when changing the data type for the calculated library fields. instead of contains, starts with, etc you get is greater then, etc.

it makes a lot more differences than i thought.

lets call this a well hidden feature. 

 
gab

[gappie]

this seems to be important also for listed field calculations http://yabb.jriver.com/interact/index.php?topic=55132.0

the good news is that this does make calculated list fields possible showing nestings.  
http://yabb.jriver.com/interact/index.php?topic=45104.0
http://yabb.jriver.com/interact/index.php?topic=47572.msg328995#msg328995

 
gab

edit: as a test, for the ones who are interested, i made a new field, a list field.. close, reopen the field and made it calculated and puted in the expression:

Code: [Select]

mid([year],0,3)0\[year]&datatype=[list] this give a list with the years nested in the decades.

or this gives a new interesting way to look through a huge list with the dates of images:

Code: [Select]

formatdate([date,0],yyyy\MM\dd)&datatype=[list] i think this a nice new toy..