[Gridflow-dev] autocasting of grids

[Mathieu Bouchard]

This mail is about different number types (as seen in the first table of
http://gridflow.ca/latest/doc/architecture.html) and how to make them
easier to use.



from IRC:
------------------8<--------cut-here--------8<------------------

<ClaudiusMaximus> matju: the last time i tried casting was with 0.7.6 and
I got all sorts of mess with "mismatched inlet types" or some such
message, i had casts all over by the end of it

<matju> ClaudiusMaximus: yeah, there is no automated casts at all in
GridFlow. i have a good reason. But if you do have an excellent
bulletproof plan for introducing autocast in GridFlow, please post it to
gridflow-dev.

------------------8<--------cut-here--------8<------------------

I reiterate that someday GridFlow will need automatic casting between
different number types, so that it becomes less annoying to use number
types other than int32 (the default).

However there are a few problems with that. The main reason I haven't done
anything on that topic is that once one model of autocasting has been
implemented, it's very hard to change our minds and implement another
model. So I have stuck with the completely explicit model that raises an
error for every mismatch.

The kind of decisions that have to be taken are like: if I add a uint8
with an int32, what should be the type of the result? is it the same as
adding an int32 with a uint8 ?

Think of something that makes patches as simple as possible: even if it's
not the most obvious or commonplace model, the chosen model ought make
things simpler and more concise, on a large scale. In case you haven't
thought of it, it should make it easy to create abstractions that support
multiple number types with as little effort as possible. Currently it's
possible _if_ you use $1 to select an explicit number type every
time; then you write ( $1 # ... ) all over the place in your patch. Well,
that's not backwards-compatible with the way many abstractions and other
classes work, and I wouldn't like to reserve $1 for the number type
anyway. There ought to be another way.

Additionally, if a given grid is cast at runtime, and that grid is
temporarily constant (that is, a right-inlet value), then that takes time.
The cast value shouldn't replace the original one, because that can cause
problems. It may save time to cache the casted value, but then it may take
an appreciable amount of space in RAM.

Ideally I would begin implementing mechanisms of autocasting right away,
while we'd have a discussion and decision about what would be the policy
of autocasting, and then I'd implement the policy. But I'm not too sure
about how many people here are willing to discuss about it, or have
anything to say about it. (Don't be shy!)

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju