S.o.s!!

[Siamanto]

Re: S.o.s!!

OF COURSE they are multi-dimensional and complex problems When I say "algorithm", of course I am NOT talking about a one dimensional sort of integers

Instead of conveniently hiding, why don't you?
1- Functionally specify the problem
2- Describe a solution: architecture and technology
3- Show that the challenge is algorithmic in nature

Running away will not help you.

[Siamanto]

Re: S.o.s!!

You are confusing the application domain of the computing problem I have asked you and the essence of the computing problem I have posed. The application domain could easily have been optimizing the UPS or fedex package delivery strategy and then, would you again belittle the challenge as it only applies to the package deliverers?

No, I'm not confusing the application domain and the software solution and, yes, similar optimization algorithms are used by UPS, Fedex or Call Center scheduling.
I said it and repeat: They may be of great value for the application domain but they are small scale projects, from an IT perspective, and have little IT value.

I would say the application domain (whether it be electrical engineering and semiconductor or not) is less relevant. The main question is, is the ALGORITHMIC question I have posed above a challenge or not?

How many times simple statements should be repeated before you understand them - I've even put it in bold in my previous post? Lets's repeat: I've said: "As I have promised, I will come back to it once we sort out the existing open questions."
Let's see if you will repeat the same question???

[Sip]

Re: S.o.s!!

You've been asked to show it and, instead, you started talking about a different project. Such complex problems are "multi-dimensional" in nature and you may be surprised how algorithms may not be the challenge.

OF COURSE they are multi-dimensional and complex problems When I say "algorithm", of course I am NOT talking about a one dimensional sort of integers

[Sip]

Re: S.o.s!!

All the projects that you have described so far are small scale projects from an IT point of view that may be of great value to Electrical Engineering and the Semi-conductor/Electronics sectors; but not IT per se.

You are confusing the application domain of the computing problem I have asked you and the essence of the computing problem I have posed. The application domain could easily have been optimizing the UPS or fedex package delivery strategy and then, would you again belittle the challenge as it only applies to the package deliverers?

I would say the application domain (whether it be electrical engineering and semiconductor or not) is less relevant. The main question is, is the ALGORITHMIC question I have posed above a challenge or not?

[Siamanto]

Re: S.o.s!!

I think they are algorithmic in nature.

You've been asked to show it and, instead, you started talking about a different project.
Such complex problems are "multi-dimensional" in nature and you may be surprised how algorithms may not be the challenge.

Certainly this last one I have posed you is a purely algorithmic question.

Yes, it is; however, as I have explained in my previous post, it is of little IT value and is not an IT challenge. But, as I have promised, I will come back to it once we sort out the existing open questions.

The web search one is much more complex as there needs to be infrastructure to collect, store, and process the data so I would agree that talking about that can get quite confusing about where the "enterprise infrastructure" stops and where the "search algorithm" begins.

The point right now is whether there are challenging algorithms and hence, whether algorithms can pose a challenge or not.

In any architecture, the distinctions and boundaries between what is the "search engine" and/or "search algorithm" and "enterprise infrastructure" - whatever is your Technology Stack or IT Infrastructure - are well defined and clear.
Over and over, you're just telling me that you've never been exposed to enterprise grade projects.

[Siamanto]

Re: S.o.s!!

By the way, Siamanto, before you get too far in the insults you are about to throw at me, think of only ONE of the small sub problems here ...

Pointing out to your lack of understanding of the IT world is not equivalent to "insults."
For the record, based on the that examples you have given so far - in this thread or others - I would say that your world is "Electrical Engineering" and that explains why you have no appreciation of the challenges that face IT in 2007. All the projects that you have described so far are small scale projects from an IT point of view that may be of great value to Electrical Engineering and the Semi-conductor/Electronics sectors; but not IT per se.

Not a challenge? Then maybe we should think about doing a Startup ... I can smell the millions !!!! $$$$$$$

Why don't you? Now that the Real Estate sector is retreating, the retired money will eventually - a year or two? - be invested in other sectors and Technology is probable candidate. Good timing? I wish you all the success.

[Sip]

Re: S.o.s!!

I think they are algorithmic in nature. Certainly this last one I have posed you is a purely algorithmic question. The web search one is much more complex as there needs to be infrastructure to collect, store, and process the data so I would agree that talking about that can get quite confusing about where the "enterprise infrastructure" stops and where the "search algorithm" begins.

The point right now is whether there are challenging algorithms and hence, whether algorithms can pose a challenge or not.

[Siamanto]

Re: S.o.s!!

Fair enough. I will give you a very concrete example in the form of input, output, and constraints. Then you tell me if you think it is a challenge or not.

I will gladly answer your question; but, only after we answer the question:
"Are the challenges in the four problems that you have enumerated earlier are algorithmic in nature or not?"
Let's not jump from one discussion to another; we close the open ones before starting new ones.

[Sip]

Re: S.o.s!!

By the way, Siamanto, before you get too far in the insults you are about to throw at me, think of only ONE of the small sub problems here ... for example the packing problem:

Input: Bunch of rectangles of various dimensions
Output: A packing of these rectangles in the smallest possible area
Constraints: You can rotate the boxes at 90 degree increments and you can mirror them horizontally or vertically. The boxes may NOT overlap once placed.

Not a challenge? Then maybe we should think about doing a Startup ... I can smell the millions !!!! $$$$$$$

[Sip]

Re: S.o.s!!

Fair enough. I will give you a very concrete example in the form of input, output, and constraints. Then you tell me if you think it is a challenge or not.

Input: an RTL (register transfer level) description of the next generation microprocessor. If you don't know what RTL is, think of it as a bunch of registers (places to store bits) connected to each other through logic elements (gates, modules, even more complex cores -- but all essentially boxes with wires going in and wires coming out). You can get this RTL by compiling some HDL (hardware description language such as VHDL or Verilog).

Output: A mask to send to the fab to fabricate the physical chip.

Goal: Minimize area of the chip (directly related to cost and power consumption)

Constraints: There are strong limits on the interconnect (wires), the number of transistors you can cram in a given area, and the layers you can put on top of the chip (interconnect layers). There are also constraints on the clock and how it is distributed (i.e. can't introduce too much skew due to wire delays), as well as the maximum segment length of each wire before you have to put a repeater (and delay the signal by one clock cycle) in order to keep the max delay along any path smaller than the chip clock pulse. Of course there are MANY other constraints but let's just stick to these.

Do you think solving this is a challenge or not?

Some of the tasks: These are what have to be done (not necessarily in order):

1. Partitioning - decide what "bigger module" goes where roughly on the chip.
2. Detailed placement - Layout every module and transistor exactly.
3. Routing - Decide how the interconnect will be wired - let's say you have 5 layers to go through each with varying delays and complexity.
3.1 - Decide on routing of buses, buffer placement, and coarse routing
3.2 - Detailed routing - exact placement of every interconnect
4. Clock distribution - can't introduce too much skew. Power constraints.

Hint: We are talking billions of transistors now and keep in mind interconnect has NOT been scaling the same as feature size (i.e. number of transistors vs number of available wires). You can ignore heat dissipation, capacitance effects between wires that are close, and noise and voltage parasitics for now.