Thread: why>?

and for the record?

it's impossible to enter one formula into multiple cells at once. you
enter it into one cell and then copy and paste it into a trillion
different cells.

the mere fact that databases require one calculation per FIELD and
excel requires a different formula for every single cell?

it's PROOF that databases are inherently more efficient and effective.

-Aaron


Harlan Grove wrote:
> aaron.kempf@gmail.com wrote...
> >a few dozen formulas?
> >
> >you surely mean a few dozen formulas PER CELL right?
> ...
>
> Clueless as always. A cell can have only one formula.
>
> If I want to invert a matrix in Excel, it's *ONE* formula entered into
> several cells at once using an array formula. If the matrix is N-by-N,
> that's 1/N^2 formulas per cell.
>
> >databases are inherently more efficient since you don't need to copy
> >and paste the same formula hour after hour after hour
>
> You fail to understand that some function calls are no different than
> using arithmetic operators. Think of all the times you need to copy &
> paste +, -, * and / into queries!
>
> >i'll look at that example; but a cartesian and a pivot can achieve
> >anything that you want
>
> Except operate on matrices in the standard linear algrbraic operations.
> Let's make this simpler mathematically but much more difficult for a
> database implementation: matrix multiplication. Here's a little
> example.
>
> Matrix A
> 8 -1 -2
> 3 10 2
> -2 -3 -9
> 2 -2 -7
>
> Matrix B
> -4 0
> -4 -8
> -1 1
>
> Matrix C = A * B [or =MMULT(A,B) as an Excel formula)
> -26 6
> -54 -78
> 29 15
> 7 9
>
> Good luck managing that with nothing more than SQL and MDX queries.
> Since you don't know what linear algebra is, here's a link to show you
> how matrix multiplication works.
>
> http://mathworld.wolfram.com/MatrixMultiplication.html

Aaron,

I think you are looking Excel from different view point, something very
similar to a Roman general (year 200 BC) complaining about kitchen
knife not capable of chopping head of enemy. Knife and sword has their
role in human life and they serve their purpose very well at
appropriate place.

Excel (& Lotus 1-2-3) did their job very well. These applications
actually brought something very similar to programming capabilities to
an average computer user. I know I have to request a programming chap
to write a simple Wall thickness calculation program and took ages to
build and later on to extend.

With Excel it is not so. Simply start writing formula and you are at
your destination. What is better than copy and paste if this formula is
extending multiple rows?

Surely, I would not resort to Excel even for 10000+ rows of records and
data processing. With good experience one can build excellent reports &
queries in Access instead.

I can understand your hate for Excel, and it is right with your
perception, as it is not capable of handling relational database,
database containing multi million rows etc. etc., for which it is not
designed. 65K rows are quite sufficient if you really try to understand
the real purpose of spread sheet.

I am sure none of the bank or credit card company would have ever
thought of using Excel as there business solution.

I am not advocating a spread program in any way, but trying to explain
the real purpose and amount of ease it brought to an average user.

Nimish

matrix multiplication is easy

take the tables you're trying to multiply-- and multiply them togehter

the start is that i keep my data in a database; so i dont need to go
through all the effort of inserting it.

I can do anything in a database that you can with excel
and then i can RE-USE IT TOMORROW.

Excel is wasteful because you can't leverage existing workbooks.. it's
a one-off bullshit.. you never ACCELERATE with spreadsheets.

with databases? I stand on the shoulders of giants



Harlan Grove wrote:
> aaron.kempf@gmail.com wrote...
> >it's not what spreadsheets are DESIGNED to do?
> >
> >spreadsheets-- Microsoft Excel-- wasn't designed to do anything.
>
> No, it's just that you can't understand what they were designed to do.
>
> Part of what procedural and functional programming languages (and
> spreadsheet formulas are in the latter set) are meant to do is
> mathematical calculations involving lots of iteration through strictly
> ordered data collections (vectors, arrays, matrices, tensors, ordered
> lists).
>
> SQL, OTOH, was designed from set theoretic notions of data in which
> strict ordering usually wouldn't apply. SQL was designed with a very
> strong focus on commutative mathematical operations. No harm in that
> given it's primary intended use, which involves mostly counting and
> summing and simple descripting statistics (averages, maximums,
> minimums). However, that design has poor to horrible tools for dealing
> with strictly ordered data collections like matrices. If you don't
> believe so, show us how to perform matrix multiplication on two
> matrices in a SQL query.
>
> >I mean seriously here. Can you seriously pull your sour grapes
> >bullshit about 'how you don't need feature A'-- when everyone knows
> >you're really dying for that feature??
> ...
>
> What feature? I don't produce reports. When I need data from databases,
> I can use the import external data functionality or the SQL.REQUEST
> add-in function. I also know how to use array formulas (and, unlike
> you, I also know what they are), so I don't need to use anywhere near
> as many formulas to get particular results that you would.
>
> >Of course you wish that multiple people could read and write the same
> >spreadsheet at the same time.
> ...
>
> Nope. If I were dealing with a data entry application, I wouldn't use
> Excel as the final destination. As for READING from Excel files, it's
> already possible for many people to access the same file at the same
> time. You just don't know how to set it up to avoid annoying prompts.
>
> >Don't pull your sour grapes about how it wasn't designed to do this.
> ...
>
> Spreadsheets are different than databases. Most people realize this.
> You may be the only one so irremediably dim to be unable to realize it.
> All you seem to know is how to use databases. All you can figure out to
> do in Excel is to try using it as a database, and Excel does make a
> poor database. You can't conceive of using it for anything else because
> you have no concept for doing anything else. You have no idea of what
> you don't know, and you're millitantly committed to remaining ignorant.

aaron.kempf@gmail.com wrote...
>you don't produce reports?
>
>i strongly disagree-- . . .
....

Of course you do because that's all YOU know how to do. To you even
used toilet paper is a report, no doubt one you proudly show others.

Gems of rhetoric.

You really know how to show yourself off, don't you?

my knowledge and experience says that Excel is a waste of friggin time.



Harlan Grove wrote:
> aaron.kempf@gmail.com wrote...
> >im not the one-trick pony
> ...
>
> More like a donkey lame on one side, so you keep walking in circles.
> Since that's all you can do, you rant about everyone else walking in
> straight lines and getting somewhere.
>
> Go on, show us the breadth of your knowledge and experience.

again *******-- I know exactly what my problem is.

SOME DIPSHIT ACCESS PROGRAM MANAGER MADE ACCESS 2000 NEED A PATCH TO
WORK WITH SQL 2000.

I WANTED TO RE-INSTALL THAT PATCH.
BUT IT WASNT AVAILABLE ANY LONGER.

it's realllllly realllly cut and dry.


I was building databases while you were still eating leftover corn out
of your mommas' skanky snatch




Jay Petrulis wrote:
> aaron.kempf@gmail.com wrote:
> > my knowledge and experience says that Excel is a waste of friggin time.
> >
> >
>
> Once again, a simple request for ANY details goes unheeded.
>
> Speaking of a waste of time, you have had nearly a year to come up with
> a matrix inversion process in Access. All that was asked of you was to
> do so using a specific, small matrix.
>
> We hear over and over Access is scalable and multi-user, and easily
> overcomes the 65536 row limit. Nobody disputed these benefits to using
> a database. BUT...the question was to invert a 3x3 matrix! You cannot
> do it, so why is it so important to have the scalablity in this case?
>
> What about the efficiency gain? I would enter the data in 9 contiguous
> cells (say A1:C3), select an additional 9 contiguous cells (A5:C7), and
> array-enter =MINVERSE(A1:C3). The results could easily be checked by
> selecting an additional 9 cells (A9:C11) and array-entering
> =MMULT(A1:C3,A5:C7).
>
> To replicate this process on another 3x3 matrix, all I would need to do
> is re-enter the new values in the original matrix. Those data points
> could be resulting from formulae, could be imported from another
> source, or could be keyed in.
>
> In thirty seconds, I could have inverted more 3x3 matrices than you
> have done in nearly a year. Using VBA and/or dynamic formulae, I could
> have changed the size of the matrix to invert automatically. Not a
> problem when using an appropriate tool.
>
> So, how is the database superstar coming along with this? Please tell
> us once more how efficient you are as compared to the spreadsheet dorks
> you spit on? Care to revise the relative merit, and corresponding
> payscale recommendations, of the DBA-guru vs. the lowly spreadsheet
> user? How much would your productivity been worth here?
>
> Rather than *** Excel, revisit some of your postings in the database
> newsgroups. Perhaps if you looked at them again, you would realize
> that you are not very good with Access, either.
>
> Here...
> http://groups.google.com/group/micro...d050c3943165c8
>
> Notice that two responders try to help, but you don't listen. Finally,
> they give up.
>
> Here is one of Kevin3NF's last comments:
> "You know....I think I'm done here. I'm a really patient guy, and I
> understand frustration but I'm just tired of having to pick through
> your
> ranting and raving against Microsoft to find a nugget of information
> that I
> might be able to use to help you."
>
> Norman follows up with this spot-on assessment:
> "Just like Kevin, I am now really think that you really do not know
> what you
> are talking about (not meant to be rude here). It is very clear your
> problem
> is, as I suspected, you do not know SQLServer/MSDE while claiming
> Access ADP is a good platform and MS did not do good enough on it.
> Look, you cannot even describe what your problem is."
>
> In your parlance...
>
> i mean seriously

and again.

if your companies spent HALF the effort in the database world as they
did in the Excel world?

all you Excel kids would be out of a job.

a single database developer can do more work than HUNDREDS of Excel
dorks.

I am building an application right now?? It replace a complex
spreadmart that spans 5,000 WORKSHEETS.

12 monkeys sitting around and randomly punching on a keyboard get more
work done than 100,000 spreadsheet jockeys





Jay Petrulis wrote:
> aaron.kempf@gmail.com wrote:
> > my knowledge and experience says that Excel is a waste of friggin time.
> >
> >
>
> Once again, a simple request for ANY details goes unheeded.
>
> Speaking of a waste of time, you have had nearly a year to come up with
> a matrix inversion process in Access. All that was asked of you was to
> do so using a specific, small matrix.
>
> We hear over and over Access is scalable and multi-user, and easily
> overcomes the 65536 row limit. Nobody disputed these benefits to using
> a database. BUT...the question was to invert a 3x3 matrix! You cannot
> do it, so why is it so important to have the scalablity in this case?
>
> What about the efficiency gain? I would enter the data in 9 contiguous
> cells (say A1:C3), select an additional 9 contiguous cells (A5:C7), and
> array-enter =MINVERSE(A1:C3). The results could easily be checked by
> selecting an additional 9 cells (A9:C11) and array-entering
> =MMULT(A1:C3,A5:C7).
>
> To replicate this process on another 3x3 matrix, all I would need to do
> is re-enter the new values in the original matrix. Those data points
> could be resulting from formulae, could be imported from another
> source, or could be keyed in.
>
> In thirty seconds, I could have inverted more 3x3 matrices than you
> have done in nearly a year. Using VBA and/or dynamic formulae, I could
> have changed the size of the matrix to invert automatically. Not a
> problem when using an appropriate tool.
>
> So, how is the database superstar coming along with this? Please tell
> us once more how efficient you are as compared to the spreadsheet dorks
> you spit on? Care to revise the relative merit, and corresponding
> payscale recommendations, of the DBA-guru vs. the lowly spreadsheet
> user? How much would your productivity been worth here?
>
> Rather than *** Excel, revisit some of your postings in the database
> newsgroups. Perhaps if you looked at them again, you would realize
> that you are not very good with Access, either.
>
> Here...
> http://groups.google.com/group/micro...d050c3943165c8
>
> Notice that two responders try to help, but you don't listen. Finally,
> they give up.
>
> Here is one of Kevin3NF's last comments:
> "You know....I think I'm done here. I'm a really patient guy, and I
> understand frustration but I'm just tired of having to pick through
> your
> ranting and raving against Microsoft to find a nugget of information
> that I
> might be able to use to help you."
>
> Norman follows up with this spot-on assessment:
> "Just like Kevin, I am now really think that you really do not know
> what you
> are talking about (not meant to be rude here). It is very clear your
> problem
> is, as I suspected, you do not know SQLServer/MSDE while claiming
> Access ADP is a good platform and MS did not do good enough on it.
> Look, you cannot even describe what your problem is."
>
> In your parlance...
>
> i mean seriously

aaron.kempf@gmail.com wrote...
>I don't need to show details.
>
>I'm right.. . . .

And you've proven to yourself in your own demented little mind that
you're right. You'll go on believing you know something, and the rest
of use who've NEVER seen anything workable from you will go on
believing you're just an ignorant kid working out his hostility online
because your lack of technical skills is exceeded by your lack of
social skills.

My 9-year-old claims to know a lot too. We adults tend to discount
juvenile claims and pretentions. Claimed proficiency without
substantiation is childish. That's why more than a few people have
speculated about your immaturity.

>a) doesn't have decent validation

Granted. This is one of its weakest points. However, not every
application requires validation, and validation can be added with code.

>b) doesn't scream re-use

Formula and macro libraries aren't that difficult to create and
maintain, but they're more likely to be used by developers (as I'd
define developers) than infrequent Excel users or those Excel users who
use 'turnkey' spreadsheet models.

>c) doesn't allow for multi-users

Granted with respect to simultaneous multiple-user entry in the same
file. However, that class of applications isn't what spreadsheets were
designed to do. I wouldn't try to use Word or PowerPoint for that sort
of thing either.

>d) doesn't have simple reporting capability

It has the simplest reporting capability possible: literal WYSIWYG.
It's automatic facilities for more complicated reporting procedures
such as section breaks in which it's weak.

>e) doesn't allow parameters -- like databases do.
....

It does, but it requires either programming to accept commandline
parameters or defined name or cell entries. Spreadsheets were NEVER
intended to be batch processing tools. They were ALWAYS intended for
interactive use. They can be (mis)used for batch processing, but it
shouldn't come as a surprise that they're cumbersome at it.

and for the record?

I would rather hire your 9 year old RETARDED SON than ANYBODY that uses
Excel for ANYTHING.

-Aaron


Harlan Grove wrote:
> aaron.kempf@gmail.com wrote...
> >I don't need to show details.
> >
> >I'm right.. . . .
>
> And you've proven to yourself in your own demented little mind that
> you're right. You'll go on believing you know something, and the rest
> of use who've NEVER seen anything workable from you will go on
> believing you're just an ignorant kid working out his hostility online
> because your lack of technical skills is exceeded by your lack of
> social skills.
>
> My 9-year-old claims to know a lot too. We adults tend to discount
> juvenile claims and pretentions. Claimed proficiency without
> substantiation is childish. That's why more than a few people have
> speculated about your immaturity.
>
> >a) doesn't have decent validation
>
> Granted. This is one of its weakest points. However, not every
> application requires validation, and validation can be added with code.
>
> >b) doesn't scream re-use
>
> Formula and macro libraries aren't that difficult to create and
> maintain, but they're more likely to be used by developers (as I'd
> define developers) than infrequent Excel users or those Excel users who
> use 'turnkey' spreadsheet models.
>
> >c) doesn't allow for multi-users
>
> Granted with respect to simultaneous multiple-user entry in the same
> file. However, that class of applications isn't what spreadsheets were
> designed to do. I wouldn't try to use Word or PowerPoint for that sort
> of thing either.
>
> >d) doesn't have simple reporting capability
>
> It has the simplest reporting capability possible: literal WYSIWYG.
> It's automatic facilities for more complicated reporting procedures
> such as section breaks in which it's weak.
>
> >e) doesn't allow parameters -- like databases do.
> ...
>
> It does, but it requires either programming to accept commandline
> parameters or defined name or cell entries. Spreadsheets were NEVER
> intended to be batch processing tools. They were ALWAYS intended for
> interactive use. They can be (mis)used for batch processing, but it
> shouldn't come as a surprise that they're cumbersome at it.

aaron.kempf@gmail.com wrote...
>im not scared to include details.
>
>I'm not an inferior Excel user.

No one's going to take your word alone for this.

>for starters, you can't email databases around.. you email a smart file
>that connects to the database.

You CAN e-mail .MDB files. And when you're dealing with people outside
your company or client's company, there's unlikely to be ANY way for
those outsiders to connect to any of the internal databases. Yes, some
databases could be available through the Internet, but then there's
security issues. Hardly something non-DBAs can provide outsiders.

>Access is an nimble aircraft carrier-- it launches reports; portable
>reports for emailing.
....

Nice metaphor. How nimble is your Aircraft carrier in shallow creeks or
inland lakes?

>Excel is an ancient-*** dreadnought.
....

It could be misused as such, but when used correctly for its indended
problem domain it's a row boat with oars AND a small outboard motor.
Much more maneurverable and faster under some conditions.

aaron.kempf@gmail.com wrote...
>yeah multiple people CAN edit the same form / report at the same time.
....

You can't even read carefully. I didn't mention FORMS at all. I
mentioned QUERIES and report LAYOUTS. So if multiple people can EDIT
the same report LAYOUT, how does Access or SQL Server resolve
conflicts? Or did you forget to mention locking mechanisms that would
prevent multiple people from changing the same object at the same time?

>I can tell who entered which data; when and where.
....

And in Excel it's possible to track changes. It's a PITA to deal with,
but it's there.

>I don't need a billion copies of the same formulas.

No, you seem to make do with zero, e.g., your matrix math formulas.

aaron.kempf@gmail.com wrote...
>if I could EXTRACT all the formulas in a spreadsheet without using
>Excel Automation?
....

The question remains why anyone other than you would want to do this as
opposed to saving worksheets as text files.

>I should be able to pull:
>
>a) raw data

Cells that remain constants may be selected on their own.

>b) formulas

Cells that contain formulas may be selected on their own.

>c) calculations

And what's the distinction you're trying to make between formulas and
calculations?

>out from any spreadsheet in the world without using Excel automation.

Simple. Without VBA it's a manual process, but not too difficult. To
pull cells containing constants,

1. open the file in question,
2. run Edit > GoTo, click Select Special, choose formulas, click OK,
3. press [Delete],
4. repeat in other worksheets as needed,
5. save the workbook using a different filename.

To pull cells containing formulas, follow the same procedure, but in
step 2 choose constants rather than formulas.

>I can pull the schema from a database without using VBA. Why can't I
>do the same thing with Excel??

Because spreadsheets aren't databases. Spreadsheets aren't designed
around tables as the exclusive fundamental object. Spreadsheets are
multiple grids of autonomous cells. A spreadsheet 'schema' is its
formulas in the same way that the 'schema' for a program's variables is
the source code.