Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Approximate state machines?!

Approximate state machines?!

Scheduled Pinned Locked Moved The Lounge
designperformancetutorialvisual-studiocom
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    H Offline
    honey the codewitch
    wrote on last edited by
    #1

    So I have this embedded SVG mess I'm working on, and being embedded, compromises are often to be made. One of them is that I don't validate the SVG beyond what I need to parse it. This reduces flash space requirements, and sometimes memory requirements, and can also reduce power/increase execution speed in the margins, although sometimes with more dramatic effect. Consider the following values for the transform attribute. There can be multiple in a list separated by spaces:

    rotate(-10 50 100)
    translate(-36 45.5)
    skewX(40)
    skewY(10)
    scale(1 0.5)
    matrix(0 0 1 0 1)

    Also the space delimiters above may or may not be commas, just to keep things fun, and some of the arguments presented above are not necessarily required The above would do six transformations in series, as each transformation is presented along with the others, separated by whitespace, resulting in 5 matrix multiplications. The issue is parsing it. I don't want to validate all this, because I don't care. So I do things like this:

    switch(**current) {
    case 'X':
    ttype = TRANS_SKEW_X;
    state = -1; // -1 parses until (
    break;
    case 'Y':
    ttype = TRANS_SKEW_Y;
    state = -1; // -1 parses until (
    break;
    case 'k':
    case 'e':
    case 'w':
    ++(*current);
    break;
    default:
    return FMT_ERROR;
    }

    That's all a single state in a larger state machine (not pictured). I've "compressed" (lossy) the parsing of skewX vs skewY into two states, with the final state being shown. Normally you need like N+1 states where N is the number of characters in the phrase you are parsing. Here, it will except sekwX for example, but what are the odds that you DIDN'T mean skewX on top of the odds that it happens in the first place? It's a compromise. This is a renderer, not a validator. But it got me thinking about approximated state machines like this, and I'm trying to sort of float some codeish equations in my head for how to represent them algorithmically, and I'm not seeing it. I've got "concepts of a plan", is all. That won't get me far. But it's interesting to me, the idea of compressing state machines in order to approximately match text. I can easily see the use in embedded.

    Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups