jbante

Members

624

34

1. Circumference of an Oval

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 )

3. Circumference of an Oval

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.)
4. Circumference of an Oval

Try this custom function for a reasonably exact calculation.
5. Circumference of an Oval

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.
6. Circumference of an Oval

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?
7. combinations or ...

What you're describing is the knapsack problem. The Wikipedia pages includes descriptions of several approaches to solving it for you to consider.
8. Google map, select records addresses from a delimited polygon bounds.

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.
9. Converting KB,MB,GB to readable numbers

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.
10. Converting KB,MB,GB to readable numbers

Try this custom function.

12. Quartile Ranks

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.
13. IOException when reading container data

Thank you for the update!
14. IOException when reading container data

Is there an estimate of when a production version of a new build might be available? Weeks? Months?
15. Quartile Ranks

If you sort the records by contribution, you can set the quartile for each record with the calculation: Ceiling ( Get ( RecordNumber ) / Get ( FoundCount ) * 4 )
16. IOException when reading container data

The 5.06 build goes back to working normally in my tests on Mac & Windows clients. I'm reluctant to put this on the server without knowing how production-ready this build is.
17. IOException when reading container data

Now running ScriptMaster v5.052, I get the exact same error in all three contexts (Mac client, Windows client, Windows server).
18. IOException when reading container data

Is there a ScriptMaster version "5.052"? I just downloaded it fresh from 360Works yesterday, and it's only 5.05 (no 2).

20. better way to go through data

XSLT seems to me like it would probably be the fastest. Exporting the CSV to disc and importing can also be advantageous if your schema is already a convenient match for that or you're willing to adapt your schema for that. The built-in JSON functions have many virtues. Execution speed is not one of them. In every test I've run, GetValue on return-delimited lists leaves the built-in JSON functions in the dust. The MBS plug-in handles JSON differently in a way that makes it much faster (MBS does what I was hoping FileMaker would do with an in-memory data structure), if you're into plug-ins. If you like sticking with return-delimited lists, you can make the processing of a large list go faster by pruning the list as you go: Set Variable [ \$value ; GetValue ( \$list ; 1 ) ] Set Variable [ \$list ; Replace ( \$list ; 1 ; Length ( \$value ) + 1 ; "" )] This makes the parsing of the whole list work in roughly O ( N^1.5 ) time, rather than O ( N^2 ).
21. JSON Array payloads for faster syncing

The new JSON functions have many admirable advantages for performing certain operations. Speed is not one of them. (Unless the serialized data format is JSON, there's nothing you can do to change that, and the only alternative parsing method is other built-in FileMaker functions.)
22. Virtual list using JSON

I have now. The 16.0.2 update does not change the performance characteristics of the JSON functions relative to return-delimited lists or repeating variables.
23. Virtual list using JSON

The JSON functions in FileMaker 16 have constraints the SortValues and UniqueValues do not. The JSON parsing functions check that the input they're trying to parse is in fact completely valid JSON. FileMaker has to do this to be able to return an error result when appropriate. You can't know if the outer-most structure in a JSON string is correctly terminated without starting at the beginning, checking every inner structure, and getting all the way to the end. Due to how the JSON format works, this requires stepping through the entire string for every single operation. (This could be resolved by FileMaker using a more efficient internal data structure for JSON in place of the raw string, but performance tests from a few folks suggest that FileMaker isn't doing this.) In comparison, the GetValue function only has to parse as many newline characters as it takes to get to the value you want, and it can ignore everything in a string after that point. With repeating variables, there doesn't need to be any parsing at all (depending on how you do it) — you can just use the whole content of the variable (repetition). The JSON writing functions have a similar constraint. They validate any JSON you had to start with, and then the JSON writing functions are somewhat fastidious in organizing the contents of their JSON outputs. You can make parsing nested structures in JSON less slow by parsing out inner structures, then getting the details from the inner structures, rather than pulling from the outer structure for every inner detail. This reduces how much total work FileMaker spends validating the JSON for each read. When speed is more important than simple code, do this: Let ( [ _dictionary0 = JSONGetElement ( \$json ; 0 ) ; _0a = JSONGetElement ( _dictionary0 ; "a" ) ; _0b = JSONGetElement ( _dictionary0 ; "b" ) ; _dictionary1 = JSONGetElement ( \$json ; 1 ) ; _1a = JSONGetElement ( _dictionary1 ; "a" ) ; _1b = JSONGetElement ( _dictionary1 ; "b" ) ] ; ... ) Not this: Let ( [ _0a = JSONGetElement ( \$json ; "[0].a" ) ; _0b = JSONGetElement ( \$json ; "[0].b" ) ; _1a = JSONGetElement ( \$json ; "[1].a" ) ; _1b = JSONGetElement ( \$json ; "[1].b" ) ] ; ... ) And for writing JSON, add as much in each JSONSetElement call as you can, rather than using many separate calls. Do this: JSONSetElement ( "[]" ; [ "[0].a" ; 1 ; JSONNumber ] ; [ "[0].b" ; 2 ; JSONNumber ] ; [ "[1].a" ; 3 ; JSONNumber ] ; [ "[1].b" ; 4 ; JSONNumber ] ) Not this: Let ( [ _json = JSONSetElement ( "[]" ; "[0].a" ; 1 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[0].b" ; 2 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].a" ; 3 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].b" ; 4 ; JSONNumber ) ] ; ... ) While these patterns make FileMaker's JSON functions less slow, it isn't enough to make them competitive with return-delimited lists or repeating variables for speed.
24. Virtual list using JSON

Technically, it could be done. As Wim mentioned, performance is a major constraint. The JSON functions are slow compared to the built-in functions for return-delimited lists, and very slow compared to repeating variables.
25. San Diego Workforce Partnership RFQ

"The San Diego Workforce Partnership (SDWP) seeks a contractor to support our team of FileMaker developers in the development, maintenance, and improvement of SDWP’s custom software suite." Quotes are due by 16 June 2017 at 5 p.m. PDT. http://workforce.org/rfps/2017/06/06/rfq-filemaker-pro-consulting-services
×

Important Information

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