Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


jbante last won the day on May 16 2019

jbante had the most liked content!

Community Reputation

143 Excellent

1 Follower

About jbante

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
  • OS Version

FileMaker Partner

  • Certification

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Many people use "developer" and "programmer" interchangeably. Many other people distinguish between "developer" and "programmer" different ways. One way to distinguish between them that is somewhat unique to the FileMaker community is that a "programmer" just does programming logic (data schema, scripts, calculations), whereas a "developer" is also skilled at user interface design. The US Bureau of Labor Statistics (BLS) does make a distinction in it's Standard Occupational Classification (SOC): In short, according to the BLS, a "computer programmer" implements a specification written by someone else, whereas a "software developer" is also involved in the discovery and design that would lead to such a specification. Most of the FileMaker community falls solidly in the "developer" category, according to this scheme. (Note that I'm using the 2018 revision to the SOC scheme, which does not make a distinction between "applications" and "systems" developers like the 2010 SOC did. FileMaker developers would definitely be "applications" developers in the older scheme.) Please don't take the BLS definition as an authoritative tie-breaker. Like modern dictionaries, the SOC system is more descriptivist than prescriptivist: it tells you what the BLS tends to observe in the wild; it's not a mandate for what the "correct" difference is.
  2. FileMaker has used fixed-point arithmetic for a long time.
  3. For folks with a background emphasizing data analysis, there are examples of folks pulling FileMaker data into R and Python by hosting a FileMaker database through an ODBC connection. There isn't much training to be had on this except the documentation for FileMaker, R, and Python on how to use ODBC connections. For folks with a background emphasizing software development, there are examples of folks using a plugin to crunch numbers using Java (with the 360Works plugin) or JavaScript (with the BaseElements plugin) libraries. For the price of more labor setting things up, there are also examples of setting up analytical functions in a web micro-service running libraries in some other programming language, and accessing that from FileMaker using the Insert from URL script step. My background emphasizes math, and, for a combination of reasons, I like implementing analytical methods natively in FileMaker without plugins or external web services. Personal health issues have limited how much I could invest in that, but I do try to come up with something when specific requests come up on the forums and I'm having a good day. Unfortunately, very few FileMaker developers are comfortable with the numerical methods involved in any non-trivial technique, so I don't have much help in that regard. (To be fair, most of the R and Python communities aren't comfortable with those methods, either; but they still found a way to support the folks who are.) The training on this amounts to knowing FileMaker scripting and calculations well, and the literature on numerical methods. Folks have been implementing data visualizations more sophisticated than the built-in charts for many years with web viewers. We haven't made as much progress on this as I'd like. FileMaker as a tool in general is typically favored for applications where the app owners are more interested in minimizing the work it takes to build their minimum viable product than investing the effort it takes to build FileMaker-native analytical functions worth sharing. The desire comes up from time to time, but there isn't much in the way of publicly shared case studies to show the community that good things are possible and inspire folks to want more. So, please tell us more about what kind of archaeology analysis you want to do in FileMaker. Start another thread with something specific!
  4. I realized the potential confusion with that this morning and re-named the parameters to "radius1" and "radius2". You should be passing ( width / 2 ) and ( length / 2 ) as the parameters (the order doesn't matter): EllipseCircumference ( width / 2 ; length / 2 )
  5. So you're asking about how to copy my calculation into your file as a custom function? FileMaker's help documents how to make custom functions in general. Copy the calculation code for the EllipseCircumference custom function from GitHub. Open your file in FileMaker Pro Advanced. Open File > Manage > Custom Functions... In the "Manage Custom Functions" dialog, click the "New..." button in the bottom-left corner. In the "Edit Custom Function" dialog, paste the function code into the function calculation box. Set the "Function Name" and "Function Parameters" to match the header comment in the function calculation. Click "OK" in the "Edit Custom Function" dialog, and click "OK" in the "Manage Custom Functions" dialog to save the function. You can then use the EllipseCircumference custom function in any calculation (field, script, data viewer) in that file. The approximate calculations mentioned earlier in this thread are all wrong, by about a factor of two. The first reference link in the thread gave an incorrect formula. The correct form of the approximation is: 2 * Pi * Sqrt ( ( radius1 ^ 2 + radius2 ^ 2 ) / 2 ) (Or diameter/2 in place of the radiuses.) This approximation is exact when the axes are equal (i.e. for a circle). The relative error of this grows up to about 11% as the ellipse gets extremely stretched out. This is a much better approximation (now also available in custom function form), if you really want a simple formula instead of the more exact custom function: 4 * ( radius1 + radius2 ) * ( Pi / 4 ) ^ ( 4 * radius1 * radius2 / ( radius1 + radius2 ) ^ 2 ) This approximation is always within about 0.1% or better. Still, I'd only use this if the exact calculation is too slow for a particular application.
  6. I believe the moderators of this forum prefer that transactional conversations happen in private messages. Aside from that, I'm not sure exactly what you mean by "teach me the function". Do you want to understand how the math works? I think that's much more than a 1-2 hour conversation, and there's plenty of other information linked to from the Wikipedia page for ellipses that can steer you in the right direction. Do you want a script version of the same thing? That could be done pretty easily, but this is a use where I think a custom function is a less clumsy solution to use. (I'll grant you that my implementation might look more complicated than absolutely necessary, but that's my pattern when I don't want any helper functions to depend on or extra parameters that are only there to pass information between recursions.)
  7. Try this custom function for a reasonably exact calculation.
  8. It looks like the calculation you found is approximating the circumference of an ellipse as the circumference of a circle with radius half-way between the circles that inscribe and circumscribe the ellipse. You could calculate upper and lower bounds as the circumferences of those 2 circles. The Wikipedia page includes some more bounds. Combining them in FileMaker might look like: lowerBound = Max ( Pi * ( width + height ) ; 4 * Sqrt ( width^2 + height^2 ) ) upperBound = Min ( 2 * Pi * Max ( width ; height ) ; 4 * ( width + height ) ; Pi * Sqrt ( 2 * ( width^2 + height^2 ) ) ) If those numbers are close enough for your comfort, then there you go. I imagine they might still be too loose with 500,000 pieces to cut. I thought the exact calculation looks a little fun to me, so I might take a crack at that later.
  9. Calculating the circumference of an ellipse is complicated. Any simple formula you find is likely to be an approximation, so it's natural to expect that they won't all get the same answer. How close is close enough for your app?
  10. What you're describing is the knapsack problem. The Wikipedia pages includes descriptions of several approaches to solving it for you to consider.
  11. I made a solution once that works in the other direction: given a point, find which polygons in the database contain it. There are a couple ways to do this, but the way that executed fastest was to decompose each polygon into geohashes covering the same region in advance, then calculate the geohash for the point of interest and perform an exact match find on the geohash. (When it's important to keep the database small, you can decompose regions into different-precision geohashes depending on what's necessary to cover the shape of the region, then finding a region for a point consists of attempting finds at multiple resolutions until it gets a match.) This assumed that the regions of interest are already in the database. But you're asking for a solution to a different problem: given a polygon, find which points in the database are contained by it. Start by looking at the "point in polygon" problem. I specifically recommend starting with the winding number algorithm. That's fine if you already have a small number of records to check. If you have more than a handful of points in your database, it will probably be unacceptably slow to check every single one. You could solve that by doing a find for points within the bounding box of the polygon, then checking each record in that constrained set with the winding number algorithm. This blog post I wrote a few years ago discusses how to find within a bounding box. If it's worth it to you to experiment with more complication options to achieve better speed, look into the point location problem, and trapezoidal decomposition in particular. The idea is that you might decompose your polygons into strictly vertical slabs, perform finds for the bounding boxes of the slabs, and check if the found points are actually in those slabs (which is much faster than the general point in polygon solutions because we can take advantage of the known shape of the slabs). This gets gnarly very fast, especially when you start handling non-convex polygons. You also don't want to be performing a huge number of numerical range finds in a single find request. FileMaker starts to choke on the complexity of the request. Extending a found set for each slab would probably work better.
  12. While you're editing the custom function, you need to set what the parameters are before the calculation will recognize the "bytes" and "precision" tokens, which would be undefined otherwise.
  13. Then use stored number fields instead of calculation fields, and set each quartile field in a script that does separate sorts before setting each quartile field. A script also potentially makes it easier to handle ties, to address LaRetta's point.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.