SuperCard to LiveCode Migration Questions

[Author]

I am thinking of migrating from SuperCard to LiveCode.

1. Is LiveCode a 64 bit application and environment on the MacOS? Will the IDE and any apps created in the IDE run under Catalina MacOS?
2. Does LiveCode support vector polygons? Can a user define via code a polygon as a list of x,y coordinates in real time?
3. What are the numerical precision limits in LiveCode math functions?
4. Does LiveCode support application output to iOS?
5. What find, offset, and sorting functions are available for item delimitated text exist in LiveCode?
6. Is there performance parity between LiveCode and SuperCard execution speeds?

Thank you,

Author

[FourthWorld]

I am thinking of migrating from SuperCard to LiveCode.

Welcome.

1. Is LiveCode a 64 bit application and environment on the MacOS? Will the IDE and any apps created in the IDE run under Catalina MacOS?

Yes and yes.

2. Does LiveCode support vector polygons? Can a user define via code a polygon as a list of x,y coordinates in real time?

Yes, with a nice addition I don't recall in SC during my 10 years with that excellent tool: in LiveCode, polygon points have one pair on each line, which makes them more readable and easier to traverse. But even better, you can use a blank line between points lists to create discontiguous shapes.

Another nice feature of LC's polygons is that they have a variety of properties for drawing markers at the polygon's corners, which can be great for making charts.

And all graphic objects have a wide range of effects that can be applied to them, including drop shadows, inner glow, outer glow, dashed lines, your choice of curved or angled end points, and many others. Some years ago LC switched from their internal set of graphics primitives to use Google's open source Skia library, where so many of these details come along for the ride.

3. What are the numerical precision limits in LiveCode math functions?

LiveCode uses 64-bit IEEE 754 floating-point representation for numbers. This provides around 16 digits of decimal precision.

Our community has libraries available for math requiring larger numeric ranges.

I know that HyperCard used the same IEEE 754 for its math, as implemented in Apple's SANE. I don't know what SC currently uses.

4. Does LiveCode support application output to iOS?

Yes.

5. What find, offset, and sorting functions are available for item delimitated text exist in LiveCode?

All the ones SC supports IIRC, plus a few others. In addition to characters, words, items, and lines, LC also supports bytes, and a trueWord chunk type that's like word but without the old HC rules, using standard Unicode natural-language parsing routines to handle true word boundaries (e.g. independent of punctuation, quotes, etc.).

Also, in LC delimiters can be multi-character, rather than the single-character delimiters needed for most xTalks.

LC also has some very nice field properties not found in SC (at least not when I was using SC daily), like paragraph-level formatting, numbered lists, row and column grid lines, and a lot more. This is only peripherally related to your question, but worth introducing because of course after we manipulate text we'll want to display it, and the rich field options make a lot of text display/formatting tasks much easier.

6. Is there performance parity between LiveCode and SuperCard execution speeds?

This is hard for me to say, for three reasons:

a) It's been more than a decade since I ran comparative benchmarks in both programs on the same machine.

b) Truly meaningful comparisons will want to take full advantage of each language's features, and over the years I've found myself using LC-specific features to achieve the same outcomes but through different means. For example, associative arrays play a big role in LC, and while I know Mark Lucas used to have an array external for SC (I used to public that for him along with ListMaster and others) I don't know if those are now part of the SC engine. Same with the aforementioned field properties, a few object model differences, and LC's accommodation for multiple OSes.

c) Both LC's lead engineer, Mark Waddingham, and SC's lead engineer, Mark Lucas, are friends of mine for many years, and given how invested programmers are in optimization I'd want to answer that very carefully.

All that said, if you can think of a particular goal you'd like to test it might be fun for each of us to craft a solution for each and we can find out.

[dunbarx]

Richard.

3. What are the numerical precision limits in LiveCode math functions?
6 digits IIRC, which I believe is the same as SC, no? Our community has libraries available for math requiring deeper precision.

17 digits, or so, no? Only the default numberFormat, which is a display aid, not a limitation, is set to six digits.

This was so in HC, and I can only assume the same in SC, though I never used that program.

Craig

[FourthWorld]

Richard.

3. What are the numerical precision limits in LiveCode math functions?
6 digits IIRC, which I believe is the same as SC, no? Our community has libraries available for math requiring deeper precision.

17 digits, or so, no? Only the default numberFormat, which is a display aid, not a limitation, is set to six digits.

This was so in HC, and I can only assume the same in SC, though I never used that program.

That one was off the top of my head, and referring only to places to the right of the decimal.

Is 17 both sides, or does HC go 17 to the right?

Either way, your general observation fits my recollection, that LC's precision is roughly on par or better than HC's, which seems a reasonable hunch given that HC was based on the very old Mac Toolbox SANE library, and a lot has happened with both OSes and chips since those days.

Do you know offhand if this is included in the Limitations page of the LC User Guide? This seems the sort of thing we should make easy to find.

[FourthWorld]

A little homework turned up this comment from then-LC-engineer Peter Brett:

LiveCode uses 64-bit IEEE 754 floating-point representation for numbers. This provides around 16 digits of decimal precision, which should be enough for most users' financial calculations.

And the Wikipedia page for SANE describes it as:

Standard Apple Numerics Environment (SANE) was Apple Computer's software implementation of IEEE 754 floating point arithmetic.

So LC and HC use the same underlying math specification.

I don't know what SC uses currently, but given how widely IEEE 754 is used I'd be surprised if Mark Lucas has had time to integrate anything with greater precision. Anything that uses a larger numeric range is rarely needed, less so in scripting languages that support extensibility for specialized needs. And like LC there are so many higher priorities that affect a much larger set of users just staying up with ongoing OS changes.

I'll update my original reply to reflect what I've learned. Thanks for prompting the homework.

[dunbarx]

Richard.

Yes, I remember SANE. 64 bits , in base 2, is about 17 decimal digits. Depends on the actual final value how many decimals digits one might extract from any given calculation, whether that value can be expressed in 17, or only in 16.

Craig