[Q] how to unflatten a flat-array

[Randy Kramer]

/void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/3rd-planet/fa
reast/jp/tky/shigetomi.takuhiko.5618

I appreciate you including your fully-qualified URL, but it would be more
convenient (for cut and paste) if you included the protocol as well (http://
or whatever). ;-)

Randy Kramer

(I hope that's perceived as an attempt at humor.)

 

[SHIGETOMI, Takuhiko]

thank you, David. it helps me a lot.

irb(main):003:0> require 'enumerator'
=> true
irb(main):004:0> [1,2,3,4,5,6].each_cons(2) {|x| p x }
[1, 2]
[2, 3]
[3, 4]
[4, 5]
[5, 6]
=> nil
irb(main):005:0> [1,2,3,4,5,6].each_cons(3) {|x| p x }
[1, 2, 3]
[2, 3, 4]
[3, 4, 5]
[4, 5, 6]

this is just one of what i had been seeking in vain for !!

oh .. 'enumerator' .. i should open my eyes wider.
and i found again that it is very valuable to ask before inventing.

/void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[Robert Klemme]

greetings, Daniel. true. 'next' works.


on the other hand, and as your reference 'cannot easyily go
backwards', 'next' forgets current object unless any variable on
outside of the yieldee block.

how about writing a special yielder like as below ..

any-enumerable-object.sliding_each do |prev,this,next|
...
end

- could be really useful?
- any other good name?

Like this?

module Enumerable
def each_window(size)
wind = []
each do |x|
wind << x
wind.shift if wind.size > size
yield *wind if wind.size == size
end
self
end
end

?> %w{aa bb cc dd ee ff gg hh ii jj kk}.each_window(3) {|*a| p a}
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
=> ["aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh", "ii", "jj", "kk"]
print pre, ">", here, "<", post, "\n"}
aa>bb<cc
bb>cc<dd
cc>dd<ee
dd>ee<ff
ee>ff<gg
ff>gg<hh
gg>hh<ii
hh>ii<jj
ii>jj<kk
=> ["aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh", "ii", "jj", "kk"]

Kind regards

robert

 

[Robert Klemme]

Uh, forget that. Enumerator is already there. +1 for having to look
closer at it.

robert

 

[SHIGETOMI, Takuhiko]

greetings, Randy. i much appreciate you for pointing it out.
and sorry to my fully qualified signature, since i am in a quite
complicated world. i guess you too.

is this good to you? qssp stands for quantum slipstream protocol

qssp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[SHIGETOMI, Takuhiko]

correction to my reply.

this is just one of what i had been seeking in vain for !!

while i was in my regeneration cycle, i found that this is not the ideal
behavior for me.

irb(main):003:0> require 'enumerator'
=> true
irb(main):004:0> [1,2,3,4,5,6].each_cons(2) {|x| p x }
[1, 2]
[2, 3]
[3, 4]
[4, 5]
[5, 6]
=> nil
irb(main):005:0> [1,2,3,4,5,6].each_cons(3) {|x| p x }
[1, 2, 3]
[2, 3, 4]
[3, 4, 5]
[4, 5, 6]

what i am expecting is as below.

[1,2,3.4.5.6].sliding_each(2) {|x| p x}
[nil,1]
[1,2]
[2,3]
[3,4]
[4,5]
[5,6]
[6,nil]

on the other hand, it is easy by like this.

[ nil, enumeratee, nil ].flatten.each_cons(2) { |x| p x }

q2hdp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/
3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[Guest]

?> %w{aa bb cc dd ee ff gg hh ii jj
kk}.each_window(3) {|*a| p a}
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
=3D> ["aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh",
"ii", "jj", "kk"]

Am I the only one who thinks this seems a little
peculiar?

If I were writing something using this sort of=20
functionality, I think I'd need and expect=20
output something like:

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

Admittedly, it'd be hard to that reasonably with a
variable-size window of even length. But for a
previous-current-next arrangement, it seems to make
more sense to say "there is no previous" with a nil
than to basically skip the first item.

-Morgan


=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[SHIGETOMI, Takuhiko]

greetings, Morgan. i concur with your point.

If I were writing something using this sort of
functionality, I think I'd need and expect
output something like:

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

Admittedly, it'd be hard to that reasonably with a
variable-size window of even length. But for a
previous-current-next arrangement, it seems to make
more sense to say "there is no previous" with a nil
than to basically skip the first item.

true.
what i am focusing on is 'current'. 'previous' and/or 'next' is not the
primary interest but often help 'current' to be dealt with
correctly/easily.

bxwp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/
3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[William James]

?> %w{aa bb cc dd ee ff gg hh ii jj
kk}.each_window(3) {|*a| p a}
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
=> ["aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh",
"ii", "jj", "kk"]

Am I the only one who thinks this seems a little
peculiar?

If I were writing something using this sort of
functionality, I think I'd need and expect
output something like:

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

Admittedly, it'd be hard to that reasonably with a
variable-size window of even length. But for a
previous-current-next arrangement, it seems to make
more sense to say "there is no previous" with a nil
than to basically skip the first item.

module Enumerable
def each_with_neighbors
wind = [nil]
each do |x|
wind << x
wind.shift if wind.size > 3
yield *wind if wind.size == 3
end
wind << nil
yield *wind[-3,3] if wind.size > 2
self
end
end

%w{aa bb cc dd ee ff gg hh ii jj kk}.each_with_neighbors {|*a| p a}
-->
[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

 

[Robert Klemme]

%w{aa bb cc dd ee ff gg hh ii jj

kk}.each_window(3) {|*a| p a}
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
=> ["aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh",
"ii", "jj", "kk"]

Am I the only one who thinks this seems a little
peculiar?

If I were writing something using this sort of
functionality, I think I'd need and expect
output something like:

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

Well, it depends. If, for example, you would want to make a plot that
used averaged values (i.e. to smooth the curve) you would not want to see
those lines containing nil values IMHO.

Admittedly, it'd be hard to that reasonably with a
variable-size window of even length. But for a
previous-current-next arrangement, it seems to make
more sense to say "there is no previous" with a nil
than to basically skip the first item.

It's not that hard to do.

Kind regards

robert

 

[Randy Kramer]

bxwp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/
3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

;-)

Ok, so what's bxwp://?

(In any case, the link seems to be down. I wonder what traceroute would tell
me--local probem (sol) or something more major? ;-)

Randy Kramer

 

[SHIGETOMI, Takuhiko]

sorry, Randy.

(In any case, the link seems to be down. I wonder what traceroute would tell
me--local probem (sol) or something more major? ;-)

it's not a technology of ours. and it is not 3-dimensional.

Ok, so what's bxwp://?

i support several ftl(faster-than-light) protocols...

qssp: quantum slipstream protocol
q2htp: quantum-2 hyper-drive protocol
bxwp: borg trans-warp protocol
cigp: caretaker's inter-galactic protocol
xnfp: xeelee night-fighter protocol
...
some of the others are under implementation

xnfp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/
3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[Randy Kramer]

i support several ftl(faster-than-light) protocols...

qssp: quantum slipstream protocol
q2htp: quantum-2 hyper-drive protocol
bxwp: borg trans-warp protocol
cigp: caretaker's inter-galactic protocol
xnfp: xeelee night-fighter protocol

I'm speechless, I had no idea this technology had been implemented
already. ;-)

Randy Kramer

 

[SHIGETOMI, Takuhiko]

this is a midnight talk from far east.
maybe i should go back to ruby.
let me explain the background of my original question.
i am going to write a bytesteream/textstream scanner.
i have uptaken many useful ideas and codes from many good-hearted guys
including you, but i am still seeking an efficient way for
scanning/traversing a large size of textstream.
while i am thinking whether i should write this part in c-language or
not, i will do write a pilot version in ruby.

I'm speechless, I had no idea this technology had been implemented
already. ;-)

'why do you think so 3-dimensional?' the queen said to locutus.

this time, i am on: vaadwaur subspace corridor protocol.
the followings are not implemented so far.

fsbmp: fluidic space bio-mechanical protocol
qcfcp: q-coninuum finger-clicking protocol

vscp://void/3d/universe/milky-way-galaxy/orion-arm/sol-solar-system/
3rd-planet/fareast/jp/tky/shigetomi.takuhiko.5618

 

[Simon Kröger]

greetings, William. i'm sorry, your way is beyond my light-weight brain.

ary = [1,2,3,4,5,6,7,8]
f=nil
t=ary.partition{f=!f}
p t[0].zip(t[1])

but it works...

$ irb
irb(main):001:0> ary = [1,2,3,4,5,6,7,8]
=> [1, 2, 3, 4, 5, 6, 7, 8]
irb(main):002:0> f=nil
=> nil
irb(main):003:0> t=ary.partition{f=!f}
=> [[1, 3, 5, 7], [2, 4, 6, 8]]
irb(main):004:0> p t[0].zip(t[1])
[[1, 2], [3, 4], [5, 6], [7, 8]]
=> nil

i'd like you use a terrestrial language, or beam me your universal
translator.

Muhahaha...

p ary.zip((0...ary.size).to_a).partition{|o|(o[1]%2).zero?}.
map{|a|a.transpose[0]}

erm, sorry, could not resist

But transpose make the example above shorter (and perhaps even
more readable):

f=nil
p ary.partition{f=!f}.transpose

cheers

Simon

 

[Guest]

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

=20
Well, it depends. If, for example, you would want
to make a plot that
used averaged values (i.e. to smooth the curve) you
would not want to see
those lines containing nil values IMHO.

It seems like it depends on the application then. Most
of the ones I can visualize involve processing each
item in order, with the previous and next values used
for something if they're available, but items still
need to be processed if there isn't a previous or
next.

=20
It's not that hard to do.

Hmmm, maybe I should say "It's hard to decide what the
output should look like.

As in, for someone who wants those nils like I do,
should the first set of arguments from each_window(4)
be something like

[nil, "aa", "bb", "cc"]

or

[nil, nil, "aa", "bb"]

?

It's obvious with odd length windows, the current item
should always be the middle one. And with the kind
that
doesn't use nils, defining one item as the current one
probably isn't meaningful anyway, so it's not an
issue.

-Morgan

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

 

[Robert Klemme]

[nil, "aa", "bb"]
["aa", "bb", "cc"]
["bb", "cc", "dd"]
["cc", "dd", "ee"]
["dd", "ee", "ff"]
["ee", "ff", "gg"]
["ff", "gg", "hh"]
["gg", "hh", "ii"]
["hh", "ii", "jj"]
["ii", "jj", "kk"]
["jj", "kk", nil]

Well, it depends. If, for example, you would want
to make a plot that
used averaged values (i.e. to smooth the curve) you
would not want to see
those lines containing nil values IMHO.

It seems like it depends on the application then.

That's what I meant.

It's not that hard to do.

Hmmm, maybe I should say "It's hard to decide what the
output should look like.

As in, for someone who wants those nils like I do,
should the first set of arguments from each_window(4)
be something like

[nil, "aa", "bb", "cc"]

or

[nil, nil, "aa", "bb"]

I'd prefer

[nil, nil, nil, "aa"]

same on the other end: the last window is the one with the last element on
pos 0 and the rest filled with nils.

It's obvious with odd length windows, the current item
should always be the middle one. And with the kind
that
doesn't use nils, defining one item as the current one
probably isn't meaningful anyway, so it's not an
issue.

I think there's a subtle difference: I think of this as a window slid over
the sequence and you focus more on the current with previous and next. IMHO
both are valid but they obviously differ in what they output. Plus, with
your notion (or, what I believe to have recognized as your notion) even
number of elements does not make sense. So we probably have

#each_window(size)
#each_context(elements_on_each_side) # the number indicates how many
elements before and after we see

Is any of this worthwhile to be put into Enumerable?

Kind regards

robert