@UnrelatedString Wish I had more data, but it certainly doesn't seem like a bad idea to switch to that way. I think I was influenced by FizzBuzz which does favor the other way (one of the only few problems that that is so)
@UnrelatedString Hey, btw I finally gathered data on iogii for broadcasting 1d to 2d which way would have been better more frequently. I had 55 programs (I ignored trivial ones) and only about 10 was it even relevant. But it does seem that broadcasting it to rows rather than columns is more frequently useful, so you were right!
@UnrelatedString BTW I was thinking about this more and actually generating prefixes on list of lists with :l}k isn't doing any broadcasting. Both sides have 1 extra rank from what is needed for a take operation, so it just does a zip. The reason :l}k worked without the explicit R is because in this case the only the left arg had excess rank so the right hand side broadcasted. Strings in iogii are just vectors so no special behavior here. Sorry took me so long to realize that.
Yeah I think it would theoretically be better, but so far hasn't come up. It isn't really more complicated but I do like people not having to use the capitalization system at all if they don't want to. I'll make a note though could be worth changing
@UnrelatedString I've flip flopped on this so many times... I think I agree, but I'll change it and test it out on a bunch of examples and see how often that made things worse
@UnrelatedString For your case: "asdf","123";Rl}k gets what you want, and would be the default case if I did it the other way. But if you wanted it the way the it is now and I changed it, then you would need to do ;R, any thoughts?
@UnrelatedString I was thinking about the broadcasting from 1d to 2d or 2d to 3d. My reasoning for the current behavior is that by repeating at the highest rank it reduces the chance of needing to use two chars R,. Although I think repeating at the lowest rank might be more intuitive/useful.
I guess I was hoping to show that the whole idea of iogii/atlas is that you don't need iteration. Everything is just list manipulating and it is easy to combine list since zip/map is implicit in vectorization, so a whole bunch of concepts are unified
sn* turns spaces into spaces and everything else into "". E ... append does a cummulative append, mult by sn to ignore spaces unless it was a space. Final * to insert those between original characters
Also btw for the fizzbuzz you could use [] or ; (but they will be same length since ; will need a > in this case), there are a couple of op substitutions you could do to get 26B but that is best I can do and it is same approach
@lyxal in iogii there isn't a concept of time so that wouldn't make sense, but you could achieve the same thing by just having a separate iterate, which problem is that for I could try to give a concrete example?
@lyxal Very true, most of the time dup and mdup are preferred. [] is global btw and there is no such thing as time since it just generates a graph of values
@lyxal BTW the reason is that there are other alternatives to duplicating values (dup, =, and []), so this would only really be needed when using a value 2+ times, which shouldn't be too often. Also the reason I used last value is because [] is already good at using first value, and this could also make it useful for circular programming
@lyxal What's the use case? There's no way to do this but shouldn't be a need either since you can keep each part of the zip separately and then if need to use the values together just use them together since every op is vectorized. If it was for something like sorting you could just use a list instead of a tuple (use append/cons to create). I have to go now but can give more info tomorrow if needed
@UnrelatedString Yeah I had thought about some sort of system where list length is pseudo determined at compile time and matches could be made that wouldn't be affected by coincidences. I guess for this language definitely want to keep it simple so would never dabble into that level of inference. I'm glad you share that hatred of length dependent behavior, I've been bitten by it with real code in Matlab before, so annoying.
@UnrelatedString iogii would be pretty awkward for 6 distinct inputs too (or even >1 for that matter). I should add ability to take parsed args similarly to how nibbles does, but now am just targetting stdin for use at golf.shinh.org. Does parsing input need to count towards bytes on this site? Or can you pretend the code is a function and the inputs went before it? Like if the challenge was sum the input numbers the program would need to be }_ (readAll sum) or if it could just be _ (sum)?
@UnrelatedString Yeah it is unclear which would be more useful most of the time (expand removing initial value or not) - I went with the current way since you can always remove it easily with tail. Can always wait and see how it tends to be used in practice and change later. There isn't a universal shortest way to get an empty list, but in practice I've never needed it. You can use the nil op, or "" for strings, or 0jt for ints, or E>H if we don't change the behavior of expand.
In a non lazy language you could try to make list sizes match up when choosing the broadcasting rule but since iogii is lazy I always use the same rule - which I think is the best rule. I should add a section to the nitty gritty to help make more intuitive.
