Hi folks,
GridFlow 0.7.0 gets multiple numeric types and MMX support.
But I need some advice on numeric types.
I have three numeric types: uint8, int16, and int32. Currently all conversions must be explicit, using [@cast] objects (save for some special funky classes like @store)
Similarly, all grid-literals must have their type specified, if it's not the default int32.
e.g. some possible msgbox contents:
"1" : int32 scalar "list int16 # 1" : int16 scalar "1 2" : int32 vector of size 2 "list int16 1 2" : int16 vector of size 2 "3 3 # 1 0 0 0" : int32 3x3 identity matrix "3 3 int16 # 1 0 0 0" : int16 3x3 identity matrix "240 320 3 # 0" : 240x320 RGB 32:32:32 black picture "240 320 3 uint8 # 0" : 240x320 RGB 8:8:8 black picture
the "list" prefix is there because typenames are not valid selectors; it is to be omitted inside objboxes, because there are already list delimiters there. e.g.
add some red to a rgb 8:8:8 picture [@ + {uint8 64 0 0}] in jmax [@ + ( uint8 64 0 0 )] same in puredata
as you can see, the notation is quite cumbersome, and @cast itself can be cumbersome; some patches may require considerable changes to accept a different numeric type as input.
the reason i did it like that is because, if i choose a numeric conversion policy right now, and it occurs to me that it's the wrong policy, then it'll be quite some trouble to change it later.
now i see a few different possible policies. Given a two-input operator being given two values of different types:
C-style: the result has the same type as the bigger type of the two input types. there is some hierarchy between the types. there are obvious facts, like uint8 < int16 < int32, but some cases are not obvious, such as uint8 vs int8, and int32 vs float32, where each type of the pair includes values that don't precisely exist in the other type, so one of the two types is arbitrarily considered bigger.
jMax-style: left inlet decides the type. (I thought jMax was "right inlet decides the type", but I rarely get to play with floats, so I forgot)
other: right inlet decides the type.
other: keep casting completely explicit.
different policies have different advantages. For example, jMax-style makes it easy for abstractions to support multiple types in left-inlet with minimal effort from the abstraction-creator (often without any patch modification). it's the one i prefer, but i want to know whether other people have other preferences (and _why_...)
I thought it could be possible to specify extra options about casting and such, as keyword arguments. Keyword arguments come in pairs and are put after the end of the normal argument list, requiring all regular optional arguments to be present. One of the possible keywords would be cast_to, which would appear in different flavours, e.g.:
[@ + 42] [@ + 42 cast_to left] [@ + 42 cast_to right] [@ + 42 cast_to biggest]
else, [@cast] could have its type argument modifiable through inlet 1, where another object written like [@type] or [@typeof] or [@nt] (standing for numeric type) would give a type symbol (like "uint8") through outlet 0 when given a grid in inlet 0. This would allow for completely arbitrary user-defined type policies.
i'm writing all of this in case some of you have comments and suggestions. so _please_ reply if you have something to say.
thanks in advance,
Mathieu Bouchard http://artengine.ca/matju