Scale

[heckj]

Scale

While working on VisualChannel, after adding the relevant dependency, I started to add in the
property for a scale and realized the generics need to be aligned:

var scale: LinearScale.DoubleScale // input=Double, output=Float

A scale has an InputType and OutputType - and we need InputType to match PropertyType from above. And OutputType should probably just be CGFloat since we'll be using it in that context.

Since the property types could be one of Double, Date, Int, or String - we need scales that take all of those kinds of values as input types so that we can appropriately constrain the generics.

The two "OutputTypes" that are relevant for our use cases are "CGFloat" for drawing stuff in a GraphicsContext and Color - or some color representation anyway - that can be converted or cast into to a SwiftUI color instance. Since we're doing CoreGraphics dependencies anyway, then maybe CGColor.
Added issue https://github.com/swiftviz/SwiftViz/issues/11, with the color pieces partially noted earlier as an improvement in https://github.com/swiftviz/SwiftViz/issues/8 as well.

[heckj]

Development Log: I pushed Scale notably farther, resetting quite a bit of the earlier implementation to work more cleanly with a declarative style usage, while still maintaining the convenience methods for imperative usage. The top level of what's now SwiftVizScale has the protocol Scale that provides the very basic type constraint for any kind of scale. Extending from that there's ContinousScale, which covers the previous Linear, Logarithmic, and Power scales that both scale and enable type conversion. To enable that type conversion more seamlessly, I made a "convertibleFromDouble" protocol and conformed it to the specific types needed for this - Int, Float, CGFloat, and Double, and set that as a generic constraint within ContinuousScale.

I also created discrete scales - for grouping from category values (String) into a continuous range, either as bands (useful for bar charts) or points (matching scatterplot type output) - both loosely replicated from D3 Band Scale and Point Scale concepts. There is no common "discrete scale" protocol, but these both do conform to the more general Scale protocol.

To support using the scales in an incrementally more configured fashion (basic setup -> add config -> fully configured and usable), the implementations default to returning nil on scale and invert if not configured, and the configuration is all set to be enabled using modifier-style functions that create a new copy of the scale with the additional configuration in place and retaining the specific type. In addition, I set the domains (previously required arguments) to default values for the scales (empty category lists for the discrete scales) so that the scales could be determined "per mark" and "visual channel".

Still to do with scales that we'll want for supporting chart:

• Adding a Date specific scales: Date scale Scale#4
• Adding Color scales: Color Scales Scale#6

In addition, there might be notable value in adding a quantizing scale, specifically to use to break a color range into quantized segments to use as category or ordinal style indicators, and as soon as Color scales are baseline enabled, that'll beg the development of color schemes, which likely fit best within Scale as well. Three different kinds of schemes are in common use - diverging schemes (gradient or quantized with a clear center value), gradient schemes (including quantized), and categorical schemes (all contrasting values).

[heckj]

With the scale implementations in Chart, I've found a few places where things are working quite as smoothly as I'd hoped, and I have a sort of lingering, pending quandary to resolve.

The first involves using Marks with independent data, but in the same chart. It seems to beg the question of if the domains for the scales involved in rendering those marks should be independent or if there should be a means to merge them. Within any specific scale, we can do that - but when you start mixing scales (discrete scales for bar charts vs. continuous scales for line or scatterplot like charts) it gets awkward. The scale implementations support updating a domain, but discrete and continuous work extremely differently - so there's likely no way to really merge those together in any meaningful way.

The second is this idea of "ticks". Right now there's a protocol TickScale which is sort of a 'mixin' concept to Scale (on the Continuous Scales anyway) that allows two operations:

• getting a list of tick values from scale's applied domain - either in "nice" values, or just directly based on the range and stepping through with a requested number of ticks.
• validating a list of tick values that a user provides, checking them against the domain (and discarding them if they're outside that domain range), and then generating the string label for the tick and a location given a range into which to place them.

While the set of ticks, and their labels can be determined when the domain is completely set, the specific locations can't be fully identified until a range value is available so that we can interpolate where they should be displayed.

I just simplified the Tick implementation (with swiftviz/Scale#20), but I'm wondering if the implementation isn't implemented correctly. Right now it's all built over continuous scales, but there's a need for the discrete scales (Band and Point) to provide ticks there as well. In the discrete cases, every value of the domain is a default case, and the labels should match the center of the area being provided (I think...) - so maybe it makes sense to just include "ticks" into the results of a scale more generally. In the case of "band" scales, the band itself might include the tick. I'm uncertain (from this close distance) if I'm coupling things too closely, too loosely, of if there's a better design that would make more sense.