Filemaker if dropdown contains text alter calculation - field

I am fairly sure stuff like this has been answered but I am losing my hair at the moment with this. I am using Filemaker Pro 13
I have been landed with the job of updating some templates, I have done this before but all I was doing was updating the visual side of things. Now I am wanted to dynamically update some labels and calculations depending on a 'Company selected(drop down with custom values that are all text).
Currently all costs are multiplied by 2. So if original cost = $4 then customer cost is $8. However if 'Company 4' is selected rather than being multiplied by 2 it needs to be multiplied by 1.5.
I currently have two functions that I am trying to use this functionality on a field box.
First function:
If (Company: = "Comp4"; 1;0)
Second function:
If (${Function1}; ${$Cost}*1.5; ${$Cost}*2 )
This does not work, hence the answering of this question. As far as I could understand if statements work as (Condintion; If true do X; Else do Y;). This may be the problem? I do come from a programming background but this program is irritating me beyond belief at the moment.
If this has been answered before then I offer my sincerest apologies.
Thank you for any answers or help pointing me into the right direction.
Edit: Just tried this:
If (ValueCount(FilterValues(Company;"Comp4"));${$Cost}*1.5; ${$Cost}*2)
This was to no avail. Ideally if I could fit this into one function that would be great but so far I am still failing.
Edit 2:
With regards to the function / functions not working. I would often only get the ${$Cost}*2 side of things would happen however the ${$Cost}*1.5 would not even when "Comp4" was selected. This made me think that it was either the system was not detecting "Comp4" was selected or I need to look elsewhere to find the value I need to look at.
Edit 3: Real values and calculations used
Currently used and working so to speak ( Just does the *2 aspect of things)
Field Name: x2$Charges
Calculation: ${$Charges}*2. - $Charges is the 'cost' fields (10 of them).
What I want to do is when a specific company is selected rather than doing cost *2 I want to do cost *1.5.
The check for said company is :
Field Name: x2CheckSSL
Calculation: If(Sales Rep.|Distributor: = "SSL";1.5;2)
Where Sales Rep.|Distributor: is 'Company'

It's difficult to tell what is wrong with your syntax, because we don't know the exact names of your fields. Also, "this does not work" is not a good description of a problem.
The fact that you have constructs like ${$Cost} indicates that you have invalid field names.
If you had fields named Company and Cost, then a calculation field (defined in the same table as these two fields) =
If ( Company = "Comp4" ; 1.5 ; 2 ) * Cost
should provide the expected result.
On a more general level, this is not a good approach to take. All of these factors {"Comp4", 1.5, 2} are data and should not be hard-coded into a calculation formula.
Properly, every company should have a markup value stored in its own record, and this would be looked up into a field when you select a company. Alternatively, only some (preferred) companies would have a markup, while others would use a default value stored in a preferences table.
In addition, the Company field in this table (Invoices?) should really be CompanyID and store only the (meaningless) ID of the selected company.
Added:
This is a suggestion how to perform a quick fix to your current problem, following the clarifications made in comments.
The following fields are being assumed:
• $Charges - Number[10]
• Sales Rep.|Distributor: - Text
• x2$Charges - Calculation[10] = [see formula below]
Change the calculation formula of x2$Charges to =
If ( Extend (Sales Rep.|Distributor: ) = "SSL" ; 1.5 ; 2 ) * ${$Charges}
There is no need for the x2CheckSSL field.
IMPORTANT:
You should not use repeating fields for this. I suggest that as soon as possible you rewrite your solution and fix the flaws dscovered here, namely:
Rename your fields to valid (and reasonable*) names ;
Convert repeating fields to records in a related table;
Use lookups instead of hard-coding data in calculations.
(*) e.g. not names that end with ":"

IF statement works exactly as you described and I do not see why you need two different functions. I do not understand your syntax - ${$Cost}. Are you trying to add "$" to your output?
Let's say you have a field for selection as "slelect_company" in Companies table/layout and you stored cost in a variable called $cost
You calculation will be:
If (Companies::slelect_company = "Comp4"; $Cost*1.5; $Cost*2 )
If you set the field to output result, use formatting to add $ sign
If you set the label on the layout to show the output, use this:
If (Companies::slelect_company = "Comp4"; "$" & $Cost*1.5; "$" & $Cost*2 )
If you have more than one check, you can use Case - similar to switch in the other languages

Rather than putting your calculation in a function try creating a new calculation field and put your calculation there. When the record is committed you will see the value of this calculation field change and you will know if your function is working.
To do this
Go to File->Manage->Database
Type in a new field name and select "calculation" as the type and press create.
Enter your calculation e.g. if(Companies::select_company = "Comp4"; Companies::Cost * 1.5; Companies::Cost * 2)
The calculation engine will tell you what the errors are when you try to press okay after typing the calculation.
If it never detects the condition "Comp4" then there is an error in your string comparison, perhaps a trailing space, or an uppercase character or similar.

Related

Replace user created blanks with 0's

I made a binary calculator with bitwise functions (bitand, bitor, bitxor, ect.) in google sheets (yes I am aware that there are built in functions to do this, this seemed more fun). It is an 8 bit calculator, and I currently have addition and subtraction implemented. Multiplication is planned, but seems way too hard at the moment
One of the things I came across is once a calculation is done, the user has to manually 0 out the addends/minuend and subtrahend one digit at a time. I would like to optimize this process.
I can easily create a script that will input 0 into all the cells and hook that up to a button. I have a feeling that's the route I'm going to have to go. But I want to challenge myself in making cool stuff, so I want the coolest solution.
My question is: is there a way I can do this without a script attached? I've been experimenting with ARRAYFORMULA and VLOOKUP, but I don't have a clear answer yet.
Expected behavior:
User inputs their calculation. User records the answer. User selects both 8 bit binary numbers (currently residing in A1:H2) and presses backspace. Google Sheet automatically translates those blank cells to 0's.
take a look into custom internal formatting. any text can be converted to "0"
then see shifted arrays:
={"", "x"}
formula from G9 will print "0" into H9. also, you can anytime enter value in H9 to "overwrite" the zero and after you don't need the entered value you just clear it with backspace or delete key and it will be filled with "0" again.
also, note that after you enter value in H9, G9 will error out and such error cant be suppressed so see hidden cells:
not sure if it's cool enough but it works (with compromises)

Finding duplicate cases, string-variable, SPSS

Being a novel on SPSS I am struggling with finding duplicate cases based on a string-variable in a dataset containing approx 33,000 cases.
I have a variable named "nr" that is supposed to be unique id for every case. However, it turns out that some cases might have two different values in "nr" entered,the only difference being the last character. Resulting in a case being shown as two separate rows.
The structure of the var "nr" is a as follows: XX-XXXXXXX-X or X-XXXXXXX-X i.e 2-7-1 characters or 1-7-1 characters.
I would like to sort out all cases that have a "nr" equal to another case except for the last character.
To illustrate, with a succesfull syntax I would hopefully be able to sort cases like these out from the whole dataset:
20-4026988-2
20-4026988-3
5-4026992-5
5-4026992-8
20-4027281-2
20-4027281-3
Anyone have an idea on how to make a syntax for this? Would be so grateful for any input!
I suggest to create a new variable without that last character, and then look for the doubles:
* first creating some sample data to play with.
data list list/ID (a15).
begin data.
20-4026988-2
12-2345678-7
20-4026988-3
5-4026992-5
5-4026992-8
12-1234567-1
20-4027281-2
6-1234567-1
20-4027281-3
end data.
* now creating the new variable and counting the occurrences of each shortened ID.
string ShortID (a15).
compute ShortID=char.substr(ID,1,char.rindex(ID,"-")).
* also possible: compute ShortID=char.substr(ID,1,char.length(rtrim(ID))-1).
aggregate out=* mode=add /break=ShortID/occurrences=n.
* at this point you can filter based on the number or `occurrences` or sort them.
sort cases by occurrences (d) ShortID.
After removing the last character, you can use Data > Identify Duplicate Cases to find the dups. It as a number of useful options for this.

Is it possible to tweak Solr hit relevance score based on length of content?

I have a Rails app using sunspot to do searches against a table with records of varying sizes. I want to adjust the score of the hit depending on how large a certain field is. This is to punish articles that have very little content but happens to have the term being searched for showing up at the top. Is that possible?
One technique: compute the body length at insertion time and give the whole document a Boost based on its higher length - you'd supply this Boost manually, for each document at index-time.
See this FAQ: http://wiki.apache.org/solr/SolrRelevancyFAQ#How_can_I_increase_the_score_for_specific_documents
This mailing list thread seems to kind of answer your question - and brings up another point that you might be thinking about this wrong.
http://osdir.com/ml/solr-user.lucene.apache.org/2010-05/msg00916.html
This quote is illustrative: "I have to ask, though, why you want to sort this way? The relevance calculations already factor in both term frequency and field length. What's
the use-case for sorting by field length given the above?"

Trouble with custom validation of Rails app

I'm making a web app where the point is to change a given word by one letter. For example, if I make a post by selecting the word: "best," then the first reply could be "rest," while the one after that should be "rent," "sent", etc. So, the word a user enters must have changed by one letter from the last submitted word. It would be constantly evolving.
Right now you can make a game and respond just by typing a word. I coded up a custom validation using functionality from the Amatch gem:
http://flori.github.com/amatch/doc/index.html
Posts have many responses, and responses belong to a post.
here's the code:
def must_have_changed_by_one_letter
m = Amatch::Sellers.new(title.strip)
errors.add_to_base("Sorry, you must change the last submitted word by one letter")
if m.match(post.responses.last.to_s.strip) != 1.0
end
When I try entering a new response for a test post I made (original word "best", first response is "rest") I get this:
ActiveRecord::RecordInvalid in ResponsesController#create
Validation failed: Sorry, you must change the last submitted word by one letter
Any thoughts on what might be wrong?
Thanks!
Looks like there are a couple of potential issues here.
For one, is your if statement actually on a separate line than your errors.add_to_base... statement? If so, your syntax is wrong; the if statement needs to be in the same line as the statement it's modifying. Even if it is actually on the correct line, I would recommend against using a trailing if statement on such a long line; it will make it hard to find the conditional.
if m.match(post.responses.last.to_s.strip) != 1.0
errors.add_to_base("Sorry, you must change the last submitted word by one letter")
end
Second, doing exact equality comparison on floating point numbers is almost never a good idea. Because floating point numbers involve approximations, you will sometimes get results that are very close, but not quite exactly equal, to a given number that you are comparing against. It looks like the Amatch library has several different classes for comparing strings; the Sellers class allows you to set different weights for different kinds of edits, but given your problem description, I don't think you need that. I would try using the Levenshtein or Hamming distance instead, depending on your exact needs.
Finally, if neither of those suggestions work, try writing out to a log or in the response the exact values of title.strip and post.responses.last.to_s.strip, to make sure you are actually comparing the values that you think you're comparing. I don't know the rest of your code, so I can't tell you whether those are correct or not, but if you print them out somewhere, you should be easily able to check them yourself.

How should I present a cost field to the user, and store it in the database?

Right now I have two fields for cost. One for dollars and one for cents. This works, but it is a bit ugly. It also doesn't allow the user to enter the term "free" or "no cost" if they want. But if I only have one field, I might have to make my parser a bit smarter. What do you think?
On the server side, I combine dollars and cents to store them as decimals in my database. Mainly so that I can gather statistics (cost averages, etc.) quickly.
Do you think it is better to store the cost as a string? Then whenever I actually use the cost for stats or other purposes, I would convert it to a decimal at that point. Or am I on the right track?
There is a rule in database design that states that "atomic data" should not be split. By this rule a price, or cost is such an example of atomic data and therefore it should never be split among multiple columns just like you shouldn't split a phone number among multiple columns (unless you really have a very good reason for it - very rare)
Use a DECIMAL data type. Something like DECIMAL(8,3) should work and it's supported by all ANSI SQL compliant database products!
You can consult Joe Celko's "Thinking In Sets" book for a discussion of this topic. See section 1.6.2, pages 21-22.
EDIT -
It seems from your question that you are also concerned with how to accept user's input in a form that resembles the price (xxxx.xx) - hence the two input boxes, for the whole dollars, and the pennies.
I recommend using a single input box and then doing input validation using Regular Expressions to match your format (i.e. something like [0-9]+(.[0-9]{1,3})? would probably work but could be improved). You could then parse the validated string to a Decimal type in your language, or just pass it as a string into your database - SQL will know how to cast it to a DECIMAL type.
Keep the whole cost as decimal. If it's free, then keep the cost as 0. In presentation if cost is zero - write "free" instead of 0.
I generally store the cost as the lowest unit (pennies) and then convert it to whole dollars later.
So a cost of $4.50 gets stored as 450. Free items would be -1 pennies. You could store free things as 0 pennies as well, this gives you the flexibility to use 0 and -1 to mean two slightly different things (free vs no sale?).
It also makes it easier to support countries that don't use cents if you choose to go that route.
As for presenting the data entry field, I personally don't like it when I have to keep switching fields for tiny things (like when they break up phone numbers into 3 fields, or IP addresses into 4). I'd present one field, and let the users type the decimal point in themselves. That way, your users don't have to tab (or click, if they are unfamiliar with tab) to the next field.
Use cents, use 450 for $4.50 this will save you problems that are arising very often
from the fact that floating point operations are not safe. Just try the following expression in irb:
0.4 - 0.3 == 0.1 will return false. All because of floating point representation
innacuracies.
In my models I'm always using:
attr_accessor :price_with_cents
def price_with_cents
self.price/100.00
end
def price\_with\_cents==(num)
self.price = (num.to_f * 100.00).to_i
end
And the name of column is just price and integer type.
I don't have much experience with decimal columns and their representation in ruby (which can be float that is problematic as i've shown at the begining).
Don't allow garbage to make it to your database. If you're expecting a dollar amount on a field, than make sure it's valid before it gets in there. This will allow you to report better on the data and allow simpler formatting on output.
I suggest making this a single field with validation on update or insert.
if field != SpecialFreeTag then
try to convert to decimal
if fail then report to user
otherwise accept value
Use try parse or regular expressions to help with the validation.
I would store the cost as decimal with the scale being no less than 2 and maybe even 3-5. If something is bought in bulk the unit cost could easily include fractions of a cent. Free items have a cost of 0. If the cost is unknown then allow null values also.

Resources