[Q] how to unflatten a flat-array

[David_A_Black3 (David A. Black)]

Hi --

greetings, Daniel. true. 'next' works.

You can't easily go backwards, but skipping to the next is
as easy as saying `next'.

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?

This might help you on this:

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]

David

···

On Mon, 29 Aug 2005, SHIGETOMI, Takuhiko wrote:

--
David A. Black
dblack@wobblini.net

[Randy_Kramer]

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.)

···

On Monday 29 August 2005 07:05 am, SHIGETOMI, Takuhiko wrote:

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

[Robert]

SHIGETOMI, Takuhiko wrote:

greetings, Daniel. true. 'next' works.

You can't easily go backwards, but skipping to the next is
as easy as saying `next'.

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"]

%w{aa bb cc dd ee ff gg hh ii jj kk}.each_window(3) {|pre,here,post|

print pre, ">", here, "<", post, "\n"}

bb<cc
cc<dd
dd<ee
ee<ff
ff<gg
gg<hh
hh<ii
ii<jj
jj<kk

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

Kind regards

    robert

[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_K1 (Robert K.)]

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

[Thomas_Morgan]

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.

-Morgan

···

--- Robert Klemme <bob.news@gmx.net> wrote:

?> %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"]

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

[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

[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

[W_James]

agemoagemo@yahoo.com wrote:

> ?> %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 <bob.news@gmx.net> wrote:

[Robert]

agemoagemo@yahoo.com wrote:

%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

···

--- Robert Klemme <bob.news@gmx.net> wrote:

[Randy_Kramer]

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

···

On Tuesday 30 August 2005 12:48 am, SHIGETOMI, Takuhiko wrote:

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

[Thomas_Morgan]

> [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. 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.

> 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.

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

···

--- Robert Klemme <bob.news@gmx.net> wrote:

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

Yahoo Mail - Organized Email

[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

[Robert]

agemoagemo@yahoo.com wrote:

[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.

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.

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

···

--- Robert Klemme <bob.news@gmx.net> wrote:

[Randy_Kramer]

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

Randy Kramer

···

On Tuesday 30 August 2005 08:34 am, SHIGETOMI, Takuhiko wrote:

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

[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

[Randy_Kramer]

I've been told that StringScanner is a good approach. Here are some links.

   * [[http://www.ruby-doc.org/core/classes/StringScanner.html][Module:
StringScanner]]

   * [[http://www1.u-netsurf.ne.jp/~brew/mine/en/strscan/usage.html][Usage]]
   
   * [[http://www1.u-netsurf.ne.jp/~brew/mine/en/strscan/reference.html\]
[StringScanner Reference Manual]]

   * [[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/128575\]
[I've recently written a JSON parser based on Ruby's StringScanner class]]

BTW, I don't think I can keep up with your faster-than-light protocols, so I'm
going to bow out of that discussion.

Randy Kramer

···

On Tuesday 30 August 2005 02:55 pm, SHIGETOMI, Takuhiko wrote:

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.