LangWart: Method congestion from mutate multiplicty

C

Chris Angelico

Spoil sport. Fancy not wanting rr's views on string theory :)

Is that Unicode string theory or ASCII string theory?

Can I get a ringside seat at the debate between Rick and jmf on which
kind of string theory was the wronger decision?

ChrisA
(And on whether "wronger" is permitted on this forum. Have at it,trolls!)
 
M

Mark Lawrence

Is that Unicode string theory or ASCII string theory?

Can I get a ringside seat at the debate between Rick and jmf on which
kind of string theory was the wronger decision?

I guess that the black market would put the price beyond the pocket of
the average Python programmer.
ChrisA
(And on whether "wronger" is permitted on this forum. Have at it,trolls!)

<incoming, take cover>

And I'll allow wronger as you're the righter.

</incoming, take cover>
 
R

Rick Johnson

Rick said:
Rick wrote:
[...]
Steven, the definition of flatten (as relates to sequences) is very, VERY
simple:

Return a new sequence that is the result of reducing
a nested sequence of sequences into a single depth
sequence.

Very, VERY simple until you actually implement this function, and discover
that it does too much e.g.

I would implement it as a method of sequence types, but i digress!
flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])
=> [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']

So people who have *actually programmed*, instead of just talking about
programming, have discovered that in practice you need to treat some
sequences as primitives that don't get expanded.

Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything.

However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!


I'm not convinced that flattening immutable types is a good idea anyway, because heck, they're designed to be immutable! I suppose if we are not flattening "in-place" it really would not matter though. Creating a new immutable object that is the result of reordering an existing immutable object's values is not mutation.
 
C

Chris Angelico

Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten()on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything.

However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!

So...

flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

? I think that's even more unexpected.

ChrisA
 
R

Rick Johnson

So...
flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

I think that's even more unexpected.

Why? Are you over-analyzing? Show me a result that /does/ make you happy.

Do you remember when i was talking about how i attempt to intuit interfacesbefore reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuitionis your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need totest. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper.

You can't procrastinate over this method forever because NEWSFLASH you will/never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON!

Infinite recursion anyone?

while obj.repeat is True:
obj.lather()
obj.rinse()
obj.repeat = True
 
R

Rick Johnson

So...
flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

I think that's even more unexpected.

Why? Are you over-analyzing? Show me a result that /does/ make you happy.

Do you remember when i was talking about how i attempt to intuit interfacesbefore reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuitionis your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need totest. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper.

You can't procrastinate over this method forever because NEWSFLASH you will/never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON!

Infinite recursion anyone?

while obj.repeat is True:
obj.lather()
obj.rinse()
obj.repeat = True
 
M

Mark Janssen

So...
flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

I think that's even more unexpected.

Why? Are you over-analyzing? Show me a result that /does/ make you happy.

Do you remember when i was talking about how i attempt to intuit interfaces before reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

You can't procrastinate over this method forever because NEWSFLASH you will /never/ find a perfect flatten algorithm that will please /everyone/, sojust pick the most logical and consistent, and MOVE ON!

Yeah, this is where one has to consider the idea of a unified data
model (a sort of OOPv2). Right now, it's all confused because people
are using their own internal, subconscious ideas of data. There are
natural ways of working with data that ***actually map onto the world
we all share*** and there are other ways which are purely abstract and
not-pragmatic however "pure". (Apart from this, there is the
ultra-concrete data model, like C, which only maps onto the machine
architecture). This is where pretty much every computer language is
today.

What I'm suggesting I think is somewhat novel. The first version of
OOP was too concrete in the sense that it was actually trying to make
real-world objects in the machine (class Chevy(Car):). This is
ridiculous. There needs to be a refactor of the OOP paradigm. In
practice OOP never was used to represent real-world objects. It came
to model virtual world objects, a very different world with different
relationships. It became the evolution of the data type itself. The
unified object model needs to do for OOP what arithmetic did for
number: defined a very basic and general set of operations on the
concept of "quantificiation". But here were trying to do that not for
quantification but for structures.

My suggestion is to create the "fractal graph" data type to end (and
represent) all data types. (Keep all the special, high-speed matrix
ideas in SciPi/VPython.) But generally, re-arrange the data model
around the fractal graph for efficiency and start watching the magic
happen.

markj
pangaia.sf.net
 
R

Rick Johnson

[...]
Yeah, this is where one has to consider the idea of a unified data
model (a sort of OOPv2). Right now, it's all confused because people
are using their own internal, subconscious ideas of data.

Indeed!

The current paradigms lack concrete structures which will prevent these ever-long bickering over minutiae. Our current paradigms are actually self-defeating because they allow too much "interpretation" of what is correct, andwhat is incorrect. It's like the early pioneer days, cowboys everywhere. We need Wyatt Earp!
There are
natural ways of working with data that ***actually map onto the world
we all share*** and there are other ways which are purely abstract and
not-pragmatic however "pure". (Apart from this, there is the
ultra-concrete data model, like C, which only maps onto the machine
architecture). This is where pretty much every computer language is
today.

What I'm suggesting I think is somewhat novel. The first version of
OOP was too concrete in the sense that it was actually trying to make
real-world objects in the machine (class Chevy(Car):). This is
ridiculous. There needs to be a refactor of the OOP paradigm. In
practice OOP never was used to represent real-world objects. It came
to model virtual world objects, a very different world with different
relationships. It became the evolution of the data type itself.
The
unified object model needs to do for OOP what arithmetic did for
number: defined a very basic and general set of operations on the
concept of "quantificiation". But here were trying to do that not for
quantification but for structures.

Most people in the this group would probably consider this to be a fantastical idea. But aren't ALL great ideas fantastical?

From as long as man has existed he has wanted to fly like a bird -- whetherhis wish was based on logistical expeditiously or simply a primitive egotistical rebelliousness to overcome the limits of his own physiology.

It's no surprise that the initial attempts were naive at best and resulted in total embarrassment. When he attempted to borrow some "flight attributes" of his feathered friends by "taring-and-feathering" himself, he did /look/ like a bird, however, when he executed the "perfect 10" swan-dive from his second story cave dwelling, only to bounce his face off the granite welcome mat, he was reminded by his audience of the one bird-like feature he already had... his brain!

You see, early man wanted to fly, and knew /somehow/ it was possible, however, his folly was to attempt flight by borrowing attributes of the bird /directly/. In reality, even if could borrow /every/ flight specific attributeof the bird: light weight frame from hollow bones, large lung capacity, aerodynamic body shape and wing structure, features, etc. He would then be /himself/ a bird, and NOT a /human/ flying. Besides, a human changing into a bird is impossible... or is it?[3]

[Warning: Slight tangent curve ahead!]

I think a lot of the failure of achieving flight "hinged" around the superfluous complexity of articulated wings-- of which is something that we have trouble replicating even today with our advancements in mechanical, hydraulic, and computing technology. But articulating wings are another fine example of how "intelligent design" will always beat the pants off "evolution". The simple technology of combining "fixed wings" with "brute force propulsion" can overcome the complex design of articulating wings and gain maintainability in the process. It seems the bird should have developed a squid-like air propulsion emanating from his anus instead of articulating wings and large breast muscles; But i digress!

RR: "A billion years worth of "dice rolling" is no replacement one human imagination! Evolution, you have created your replacement; prepare for your deprecation!"

[Back to the beaten path!]

What early man failed to realize is that he should create a model of the bird, and then hitch a ride on the model! This is an example if utilizing an /indirect/ approach to solving the problem of "human flight".

However, it is still possible to solve the problem directly. Although this direct approach involves man manipulating atomic structures (using nano-technology) and then transforming cognitive state from one entity into anotherentity (or in-place if we're really good![1]); AKA: "Shapeshifting"

But some rules require too much time to hack, so while the brute algorthim is chewing away for the next 100 years, we need to follow these steps:
0. Start the brute force algorithm (study nano-tech, computing)
1. in the short term use the indirect approach (aeroplane)
2. until the direct approach becomes attainable (shapeshifting)
My suggestion is to create the "fractal graph" data type to end (and
represent) all data types. (Keep all the special, high-speed matrix
ideas in SciPi/VPython.) But generally, re-arrange the data model
around the fractal graph for efficiency and start watching the magic
happen.

This is interesting. I would love to learn more about your ideas in this direction. Do you have any writings on the subject matter?

============================================================
REFERENCES:
============================================================

[1]: because creating a temporary entity and then destroying it could have some moral concerns at worst and possible loss of government funding[2] at best.

[2]: Of course that depends on how moral the government in question is.

[3]: I don't believe anything is impossible. If a human mind can imagine something, that something can be made reality; IF the human (or descendants) are willing to invest the time required to achieve the dream.

It is our very imagination that creates the future. If you want Distopia, then just keep reading/writing/evangelizing about it, and if enough people accept it, it will be true! If you want utopia, well then forget about it! The universe will not allow such abominations!

Utopian environments do not propagate struggles that are life threatening; heck they probably don't contain any struggles at all! Just a bunch of fat a$$es racing around on motorized chairs down the highway of slothfulness togorge on selfishness at the next "evolutionary dead end" buffet!

Only struggles that hang the very life of these lazy lifeforms in the balance will get their attention and force them to play the "war games" of survival, which in-turn spins the cogs of evolution to the benefit of, well, of....? Hmm. Who benefits from this eternal struggle?

Lifeforms themselves are but pawns in the game /slaved/ to play or die, andevolution is the game itself, but who benefits? A good question that should haunt your nightmares for some time to come, sweet dreams folks!
 
R

Rick Johnson

[...]
Yeah, this is where one has to consider the idea of a unified data
model (a sort of OOPv2). Right now, it's all confused because people
are using their own internal, subconscious ideas of data.

Indeed!

The current paradigms lack concrete structures which will prevent these ever-long bickering over minutiae. Our current paradigms are actually self-defeating because they allow too much "interpretation" of what is correct, andwhat is incorrect. It's like the early pioneer days, cowboys everywhere. We need Wyatt Earp!
There are
natural ways of working with data that ***actually map onto the world
we all share*** and there are other ways which are purely abstract and
not-pragmatic however "pure". (Apart from this, there is the
ultra-concrete data model, like C, which only maps onto the machine
architecture). This is where pretty much every computer language is
today.

What I'm suggesting I think is somewhat novel. The first version of
OOP was too concrete in the sense that it was actually trying to make
real-world objects in the machine (class Chevy(Car):). This is
ridiculous. There needs to be a refactor of the OOP paradigm. In
practice OOP never was used to represent real-world objects. It came
to model virtual world objects, a very different world with different
relationships. It became the evolution of the data type itself.
The
unified object model needs to do for OOP what arithmetic did for
number: defined a very basic and general set of operations on the
concept of "quantificiation". But here were trying to do that not for
quantification but for structures.

Most people in the this group would probably consider this to be a fantastical idea. But aren't ALL great ideas fantastical?
From as long as man has existed he has wanted to fly like a bird -- whetherhis wish was based on logistical expeditiously or simply a primitive egotistical rebelliousness to overcome the limits of his own physiology.

It's no surprise that the initial attempts were naive at best and resulted in total embarrassment. When he attempted to borrow some "flight attributes" of his feathered friends by "taring-and-feathering" himself, he did /look/ like a bird, however, when he executed the "perfect 10" swan-dive from his second story cave dwelling, only to bounce his face off the granite welcome mat, he was reminded by his audience of the one bird-like feature he already had... his brain!

You see, early man wanted to fly, and knew /somehow/ it was possible, however, his folly was to attempt flight by borrowing attributes of the bird /directly/. In reality, even if could borrow /every/ flight specific attributeof the bird: light weight frame from hollow bones, large lung capacity, aerodynamic body shape and wing structure, features, etc. He would then be /himself/ a bird, and NOT a /human/ flying. Besides, a human changing into a bird is impossible... or is it?[3]

[Warning: Slight tangent curve ahead!]

I think a lot of the failure of achieving flight "hinged" around the superfluous complexity of articulated wings-- of which is something that we have trouble replicating even today with our advancements in mechanical, hydraulic, and computing technology. But articulating wings are another fine example of how "intelligent design" will always beat the pants off "evolution". The simple technology of combining "fixed wings" with "brute force propulsion" can overcome the complex design of articulating wings and gain maintainability in the process. It seems the bird should have developed a squid-like air propulsion emanating from his anus instead of articulating wings and large breast muscles; But i digress!

RR: "A billion years worth of "dice rolling" is no replacement one human imagination! Evolution, you have created your replacement; prepare for your deprecation!"

[Back to the beaten path!]

What early man failed to realize is that he should create a model of the bird, and then hitch a ride on the model! This is an example if utilizing an /indirect/ approach to solving the problem of "human flight".

However, it is still possible to solve the problem directly. Although this direct approach involves man manipulating atomic structures (using nano-technology) and then transforming cognitive state from one entity into anotherentity (or in-place if we're really good![1]); AKA: "Shapeshifting"

But some rules require too much time to hack, so while the brute algorthim is chewing away for the next 100 years, we need to follow these steps:
0. Start the brute force algorithm (study nano-tech, computing)
1. in the short term use the indirect approach (aeroplane)
2. until the direct approach becomes attainable (shapeshifting)
My suggestion is to create the "fractal graph" data type to end (and
represent) all data types. (Keep all the special, high-speed matrix
ideas in SciPi/VPython.) But generally, re-arrange the data model
around the fractal graph for efficiency and start watching the magic
happen.

This is interesting. I would love to learn more about your ideas in this direction. Do you have any writings on the subject matter?

============================================================
REFERENCES:
============================================================

[1]: because creating a temporary entity and then destroying it could have some moral concerns at worst and possible loss of government funding[2] at best.

[2]: Of course that depends on how moral the government in question is.

[3]: I don't believe anything is impossible. If a human mind can imagine something, that something can be made reality; IF the human (or descendants) are willing to invest the time required to achieve the dream.

It is our very imagination that creates the future. If you want Distopia, then just keep reading/writing/evangelizing about it, and if enough people accept it, it will be true! If you want utopia, well then forget about it! The universe will not allow such abominations!

Utopian environments do not propagate struggles that are life threatening; heck they probably don't contain any struggles at all! Just a bunch of fat a$$es racing around on motorized chairs down the highway of slothfulness togorge on selfishness at the next "evolutionary dead end" buffet!

Only struggles that hang the very life of these lazy lifeforms in the balance will get their attention and force them to play the "war games" of survival, which in-turn spins the cogs of evolution to the benefit of, well, of....? Hmm. Who benefits from this eternal struggle?

Lifeforms themselves are but pawns in the game /slaved/ to play or die, andevolution is the game itself, but who benefits? A good question that should haunt your nightmares for some time to come, sweet dreams folks!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top