Merry Xmas and a Happy New Year

Hello, dearest Fractview user,

I wish you a merry christmas, and thank you all for the rising numbers in users, improving reviews and all these lovely images on Facebook, Instragram, DeviantArt and many more. In case you don’t have a christmas tree, I attach two fractals that use a (simple) christmas tree as an orbit trap. Although the version using the mandelbrot set is not that spectacular (until you light it, but that is only allowed on christmas eve 😉 ), there are amazing julia sets. See my favorite phoenix set for yourself:

xmas phoenix.png

Switch on lights to obtain an amazing 3d effect.

I hope you can enjoy your holidays with your loved ones. For the new year, there are some amazing updates pending (no color cycling yet, but how about orbit traps in lyapunov fractals?).

Cheers,

Karl

Advertisements
Posted in Fractals | Leave a comment

Fractview Release of 3.2.2, DeviantArt-Group and perspectives

So, I released version 3.2.2 some days ago, and I hope that you enjoy the increased stability, the tutorial and the import-export function of favorites. Again, here is a link to some of my exports. You can download it onto your phone and then import it in Favorites.

These are actually my favorite images that I generated with Fractview so far that also are calculated in a reasonable amount of time. And speaking of favorite images, Matthew, who helped a lot with feedback during the release of Version 3.2.2, started a Fractview-group on DeviantArt.

I also removed many feedback messages that I think were mostly annoying (it is good to know that Fractview draws the mandelbrot set in less than 1 second, but I think that the progress bar is enough feedaback).

And some new types: Geometric shapes for the Fold-Program, two variations of the Simonbrot fractal and distance estimation for the mandelbrot set (also in Fold).

About the import/export

Technically, the export format is Json, and Fractview now uses the gson library to export data. So, you can easily manipulate these files and re-import them (the icons take up most of it, it is a PNG-file encoded as Base64). You also can find online Json Editors.

The import/export function works fast and reliable in my experience (takes a few seconds if you import/export 1000 entries). There are no directories or tags to arrange your collection but you can set a common prefix for all selected entries (if you import a new collection, the imported entries are automatically selected) and this way simulate a file structure.

About the tutorial

The tutorial is work in progress and it will be extended in the future. Please help me improving it by providing feedback on typos, grammar mistakes etc… I will add a few more pages in the not-too-distant future, for instance a list of all functions that are supported by Fractview.

About the increased stability and some numbers

First, apologies to all Intel users. I don’t know why Renderscript (the GPU-programming-language used by Android) does not work on Intel phones but I am afraid it is out of my hands. For all others, there are already 1500 installations of the new version and no crash report yet. According to the google play store, there are currently 4556 users. On average there are about 50 new users per month (welcome).

What is next?

Next, I will not work on Fractview for some weeks :D. These last weeks I definitely spent too much time on it. There was a lot of code polishing and the code base of Fractview is now nice and solid for further extensions. So, after a break I will work on new features. This is a list of some ideas that I currently have. It is not complete and not all features will be implemented.

Version 3.3

Minor changes: Fix all crashes that come up until then, add further fractals to the presets.

Then the following improvements:

  • Parameter editor: Yes, it is actually annoying: Tap “Edit”, tap the value, change value, tap ok, tap ok. So, high priority is to integrate the parameters in the main view using some transparent swipeable view. So, tap “Edit”, tap value, tap ok and already see changes in the background. Swipe away edit view.
  • Show wait-dialog when importing/exporting large collections.
  • Allow to copy/paste parameters directly from the context menu.
  • Show a coordinate system: This will be fun, some maths.
  • Allow to export sources and palettes similar to Favorites import/export.
  • Improve Source Editor. If you use the source editor, you have my heart-felt apologies.
  • Allow variable maps in derivations (necessary for generic distance estimation).
  • And, I want a new icon (suggestions are welcome).

Version 3.4

A render-mode for really arbitrary large images that are rendered in some background demon. Maybe even support for videos (but on the other hand, it is still a mobile phone… but who knows…).

Version 3.5

I am currently re-implementing the Meelan compiler. Hence, there will be some improvements for the programs that generate fractals.

  • Better descriptions of parameters
  • Syntax highlighting for the source editor
  • Better support for syntax errors.
  • Classes
  • More possiblilties to merge fractals.
  • It should be possible to create some kind of fractal-toolbox – for example use fold and orbit traps and combine it with lyapunov fractals.
  • Dragging parameters on-screen
  • Maybe a split-screen approach to view Julia sets next to mandelbrot sets.

Version 3.9

Preparation for version 4

  • Change the drawing procedure to automatically use super-sampling and depth information (3D).

Version 4

Allow do change colors and lights by using drag-and-drop gestures. This would be sooo cool and I hope that Fractview will reach this point within a year or so.

Lots of dreams, but we will see where the journey is taking us. For now I am very happy that Fractview gives joy to so many people.

And there is no picture here. Huh. So, here is a green one. Remember when I used geometric shapes in the Fold Program? In this picture I use the z-value as one point on the line that I use for the shape. This leads to very nice curvey images. You will find this image also in my favorite 16.fractview1479425740.png

Posted in Uncategorized | Leave a comment

Release candidate for 3.2.2 – Quickstart Tutorial and some of my favorites

In the next days I will publicly publish version 3.2.2 of Fractview. This version will bring improvements on the precision of functions (still 32 bit but the number range is now much higher), the export function for favorites and a tutorial. Since copy/paste of the tutorial into wordpress and keep it up-to-date is a lot of work, please check it out on github. Please tell me about typos and suggestions.

There were some improvements on handling multiple imports/exports. I thought of adding a tag-system or directory structure, but in the end, I just allow to export/edit multiple entries based on common prefixes. This is good enough to simulate a small directory structure while still being not too over-complicated.

And in order to test it, here are my personal favorites, a nice selection of 16 fractals that I collected over the last years. Some of them you will also find on deviantArt.

Collection of 16 of my favorites

Download this text file (it is a Json file, icons are in PNG format, encoded as Base64), then select “Import collection” from favorites.

The new version is very stable on my phone, so I call it “Release candidate”. There might be some additional fractal types but it is definitely feature complete.

And if you missed the link above:

Link to the quickstart tutorial

And, some people asked whether I accept dontations, yes, I do, just follow this link.

— Karl

Posted in Fractals, Updates | Leave a comment

Update, new Beta-Version 3.2.2

EDIT: For some people the updated app crashes right after start (this is something that Intel users unfortunately always experienced). This is caused by renderscript and it is already fixed with the next update. I did not find the bug (it works on my phone ‘unfortunately’) but I had to deactivate the increased precision of some functions  😦

I just released a new beta version. The new big thing is the tutorial. You find instructions on how to use the app there. I will release the other articles also in the blog soon and hope that you provide some reviews on them.

Another maybe not so big thing (but much bigger for others) is the new Export/Import function in the favorites. First, you can select multiple items in the Favorites view.

Screenshot_20170803-103523.png

It works very similar to other android apps like Google Photo.

By selecting “Export” in the menu, a text file is shared to a location of your desire. Using “import” you can reimport this text file or import collections from others.

Technical stuff: The format I use is json (in detail I use the gson library), hence it is easy to edit. But careful, faulty entries are silently ignored during import (here is some space for improvement).

What else? I managed to increase the precision of the sqrt function and therefore also the rad function [EDIT: Due to crashes on some devices this feature was deactivated]. Other functions are still restricted to single precision but at least, exp and log now return valid results for double values. This is in particular important for exp. For a large bailout a function containing exp will soon create transparent artifacts that mean that the calculation returned an invalid value (like infinity). Now, exp works for much larger values (left is before, right is after):demo_new_exp.png

This is btw the fold preset with the function is “(exp z – E z) p” and a mandelinit of 1 (first derivation of function is “(exp z – E) p” and this is 0 for z = 1).

There are two/three new fractal types and simpler functions for the perpendicular types. The new “generic lambda” preset is the lambda fractal but it uses the “max_power” parameter in mandelinit and function. It is a lovely fractal. The other ones are the two Simonbrot variations that give rise to amazing julia sets. Thanks for the hint about them.

Internally, there were lots of changes, code polishing to increase the over-all stability, some dialogs changed a bit. For the final release there will be some corrections/improvements on the tutorial and also on the descriptions in the Demo/Preset pane but apart from that the app should be quite stable.

I hope you enjoy the update,

— Karl

P.S.: I just played around with this exp-fractal above and you should definitely take a look at its islands. The following image looks like it comes right out of Mandelbrot’s vegetable garden:exp zoom.png

And since the beta version has this lovely import function, you can test it and import this image.

Posted in Updates | Leave a comment

Tutorial: Part 1: Quickstart

I currently spend too much time programming and not enough time to explain all the possibilities of Fractview. Yet, I guess the bad reviews that point out that the app is not that easy to use have a point, so the next version, beta will be rolled out in hopefully around two weeks, will contain a tutorial. I am still a single person, so please don’t hope for a fancy interactive guide but rather a nice webview that explains some features. And since this is something that all 4446 users will see, I hope that you can help me: I will publish the tutorial here and ask you for comments whether you consider it appropriate, whether there are spelling mistakes or some sentence has a bad structure (years of teaching computer science in german leaves its traces).

So, let’s start with Part 1. It is complete apart from two screenshots of the Presets/Demo menu (I will rename it to “Demo” in the next version) and the Favorites menu – in both there is some polishing going on.

EDIT: Since it requires a lot of work to keep the tutorial up-to-date, please use the following link: Fractview Tutorial on Github

 

— Karl

Posted in Updates | Leave a comment

3.2.1… update!

Hello, just rolling out a minor update and although it only brings minor changes, it should be a major relief for most.

So, what changed? First, bug fixes.

Some small issues like the cancel button on the waiting dialog when you save the image. But there were some annoying crashes that should be fixed now:

Crash when image size is too large

The app does not restrict the image size, and I keep it this way. But there were two bugs that caused a crash either when the image was larger that what the UI can handle (around 8000×6000) or when there was not enough memory available.

Both should be gone. On my Nexus 5X, I now can try to set the image size to 90000×50000 and a friendly error message tells me that this is too much instead of a crash. The largest I get right after starting the app is 9000×5000 (no kidding) which slows down the UI a lot but it works. I’ll attach an image as a proof. Image sizes around 4000×3000 right after start should not be a problem. I guess that if the app runs for some time or you run memory consuming background apps, the app might not match these numbers, but at least, you now can try without risking a crash.

Crash when saving a palette with an empty name

Second, if you saved a palette with an empty name, the palette editor crashed when you wanted to load one. This should not happen anymore.

Crash when entering a too large integer

And third, another annoying bug, if you enter an integer with more than 8 digits, the app crashes. The crash is gone. There will be some further update on this topic in the future though.

New features: UI Settings and fractal types

There are two new options in UI-Settings: “Confirm zoom” means that you have to tap the image to confirm your scale setting, and “Deactivate zoom” deactivates all interactions with the fractal view.

Also, I added some perpendicular fractal types.

What’s next?

There are some things in progress: back up all favorites, allow to add a favorite when you save an image, and the underlying compiler for my little program language receives a lot of attention currently. Apart from that I have a lot of ideas, and I hope I will find the time to implement some of them. On my GitHub page you can find a list of issues that I want to fix. As usual, please tell me if you miss anything.

Btw some statistics: until October my app had around 300 users. Around Christmas the number skyrocketed beyond 2000. Now there are 4400 active users and great reviews. Thanks to all of you, also for your feedback and reviews.
Enjoy the update,

Karl

P.S. here is the 9000×5000 picture. Set image size right after start up, be patient with the UI and not too much interaction. It took me 2 minutes to enter the filename 😀

Btw, it is a zoom into the MinMax Orbit Trap with the trapfn “dist(z, znext)”.

a.png

Posted in Updates | 5 Comments

About syntax trees and dynamic binding/polymorphism

I am interested in Parsers, Syntax trees, term rewriting and all that. And whenever I implement
some syntax tree, I stumble across one programming problem: We all know of the advantages of polymorphism over instanceof in object oriented programming languages like Java, right? And we all know the numerous examples of double-dispatch to illustrate how to overcome limitations due to static binding of overloaded methods. Right?

But what do I do if I want to implement a syntax tree that automatically performs simple calculations? This was a concrete problem in Meelan. Since I am currently redesigning the compiler, I am thinking about this problem again for the millionth time, but this time I want to do it systematically.

Assume the expression x + (2 + 1). An abstract syntax tree (instance of some trait/interface ITree) would create the following tree:

branching[op[+], id[x], branching[op[+], int[2], int[1]]]

The numbers would be instances of some class IntLeaf and x of some IdLeaf.

(In the following I use a pseudo code mix of Scala, Java, Groovy, C++ etc…)

interface ITree {
    ITree add(ITree other) {
        return new Branch(this, other) 
        // create new node with left=this and right=other
    }
}

class Branch: ITree(ITree l, r) {}    

In order to get the desired behaviour, that two IntLeafs are implicitly added, I could create a new node as follows:

// in IntLeaf:

public IntLeaf add(ITree that) {
    if(that instanceof IntLeaf) {
        return new IntLeaf(this.value + ((IntLeaf) that).value);
    } else {
        return super.add(that);
    }
} 

But instanceof is ugly [citation needed], for the very least, as soon as I add a RealLeaf for real values (doubles or floats) things get extremely messy. To be honest, dynamic binding is great…

Dynamic binding

… because there I simply write things like this and it works out-of-the-box.

interface ITree {
    ITree add(ITree other)
        return new Branch(this, other)
}

class Leaf: ITree {} // for stuff like IDs.

class IntLeaf: ITree {
    int value

    IntLeaf add(IntLeaf other)
        return new IntLeaf(this.value + other.value)
}

But with static binding, things are more complex…

Static binding

For static binding (for overloaded methods), considering all the possibilities, this is the best I could come up with: Create a visitor interface. For IntLeaf use a special subclass of visitor, and the visitor interface is aware that there are IntLeafs around:

interface ITree {
    createVisitor() {
        return new Visitor(this)
    }

    ITree add(ITree other)
        other.visitor().visitAdd(this)

}

class Branch: ITree(ITree l, r) {}

class Leaf: ITree {}

class IntLeaf: ITree {
    int value

    createVisitor() {
        return new IntVisitor(this)
    }

    ITree add(ITree other)
        other.visitor().visitAddInt(this)
}

class Visitor(ITree tree) {
    visitAdd(ITree other) {
        return new Branch(tree, other)
    }

    visitAddInt(IntLeaf intLeaf) {
        return visit(intLeaf)
    }

}

class IntVisitor(IntLeaf tree) : Visitor(tree) {
    visitAddInt(IntLeaf intLeaf) {
        return new IntLeaf(intLeaf.value + tree.value);
    }
}

39 lines compared to 13 if we had dynamic binding. But not that bad I guess (or is it just my brain that is already used to such messy things?)

Make operations more generic

Let’s make things more generic. Instead of add I use a method eval that takes some operator and the arguments for this operator. How would things change? Not that much to be honest. It stays pretty much the same.

Dynamic binding

interface ITree {
    ITree eval(Op op, ITree other)
        return new Branch(op, this, other)
}

class IntLeaf: ITree {
    int value

    IntLeaf eval(Op op, IntLeaf other) {
        // disclaimer: this is how it would work if java/C++ etc.. was fully dynamic
        return op(this.value + other.value)
    }
}

Static binding

In fact, this part is remarkably painless.

interface ITree {
    createVisitor() {
        return new Visitor(this)
    }

    ITree eval(Op op, ITree other)
        other.visitor().visit(op, this)
}

class Branch: ITree(ITree l, r) {}

class Leaf: ITree {}

class IntLeaf: ITree {
    int value

    createVisitor() {
        return new IntVisitor(this)
    }

    ITree eval(Op op, ITree other)
        other.visitor().visitInt(Op op, this)
}

class Visitor(ITree tree) {
    visit(Op op, ITree other) {
        return new Branch(op, tree, other)
    }

    visitInt(Op op, IntLeaf intLeaf) {
        return visit(op, intLeaf)
    }
}

class IntVisitor(IntLeaf tree) : Visitor(tree) {
    visitInt(Op op, IntLeaf intLeaf) {
        return op(intLeaf.value + tree.value);
    }
}

Add another type Real

Now, let’s make things messy. In fractview there are further types, Real and Cplx. Let’s add Real for starters. Observe that we can easily add integers and reals (doubles/floats) and obtain a real. I could use some interface like RealLike to indicate that IntLeaf could also return a real value, maybe I will, but I rather want to focus on polymorphism here.

Dynamic binding

I guess people who claim that duck typing has too much drawbacks should reconsider…

interface ITree {
    ITree eval(Op op, ITree other) {
        return new Branch(op, this, other)
    }
}

class IntLeaf: ITree {
    int value

    IntLeaf eval(Op op, IntLeaf other) {
        return op(this.value + other.value)
    }

    RealLeaf eval(Op op, RealLeaf other) {
        return op(this.value + other.value)
    }
}

class RealLeaf: ITree {
    double value

    RealLeaf eval(Op op, RealLeaf other) {
        return op(this.value + other.value)
    }

    RealLeaf eval(Op op, IntLeaf other) {
        return op(this.value + other.value)
    }
}

28 lines.

Static binding, using instanceof

How to do things in a programming language with static binding? First, back to instanceof: I have to modify the eval method in IntLeaf. Easy in Scala with pattern matching, yet I somehow think that once I’ve implemented a method I want to be
done with it and keep it the way it is.

// in IntLeaf:

public IntLeaf eval(Op op, ITree that) {
    if(that instanceof IntLeaf) {
        return op(this.value, ((IntLeaf) that).value);
    } else if(that instanceof RealLeaf) {
        return op(this.value, ((RealLeaf) that).value);
    } else {
        return super.add(that);
    }
} 

And RealLeaf will look similar. Not that nice…

Maybe things get better if I use some RealLike interface for everything that can be converted to a real. But this is not on what I want to focus here now.

Static binding

Adding a real type is remarkably painless. The modifications to be done are clean and straight forward.

interface ITree {
    createVisitor() {
        return new Visitor(this)
    }

    ITree eval(Op op, ITree other) {
        other.visitor().visit(op, this)
    }
}

class Branch: ITree(ITree l, r) {}

class Leaf: ITree {}

class IntLeaf: ITree {
    int value

    createVisitor() {
        return new IntVisitor(this)
    }

    ITree eval(Op op, ITree other) {
        other.visitor().visitInt(Op op, this)
    }
}

class RealLeaf: ITree {
    double value

    createVisitor() {
        return new RealVisitor(this)
    }

    ITree eval(Op op, ITree other)
        other.visitor().visitReal(Op op, this)
}

class Visitor(ITree tree) {
    visit(Op op, ITree other) {
        return new Branch(op, tree, other)
    }

    visitInt(Op op, IntLeaf leaf) {
        return visit(op, leaf)
    }

    visitReal(Op op, RealLeaf leaf) {
        return visit(op, leaf)
    }
}

class IntVisitor(IntLeaf tree) : Visitor(tree) {
    visitInt(Op op, IntLeaf leaf) {
        return op(leaf.value + tree.value);
    }

    visitReal(Op op, RealLeaf leaf) {
        return op(leaf.value + tree.value);
    }
}

class RealVisitor(RealLeaf tree) : Visitor(tree) {
    visitInt(Op op, IntLeaf intLeaf) {
        return op(leaf.value + tree.value);
    }

    visitReal(Op op, RealLeaf leaf) {
        return op(leaf.value + tree.value);
    }
}

70 lines. Before the ratio was 3/1, now it is a bit less.

(this article will be extended and edited during development of Meelan)

Posted in Meelan, Programming | Leave a comment