This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?
Python 2.3.2 (#1, Oct 20 2003, 01:04:35)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright" , "credits" or "license" for more information. d1 = {'a':1}
d2 = {'b':2}
d3 = {'c':3}
l = [d1, d2, d3]
d4 = reduce(lambda x, y: x.update(y), l)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update' d4 = reduce(lambda x, y: x.update(y), l, {})
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update'
- Steve.
Jul 18 '05
226  12702 
David Eppstein <ep******@ics.u ci.edu> wrote: The argument is that reduce is usually harder to read than the loops it
replaces, and that practical examples of it other than sum are sparse
enough that it is not worth keeping it just for the sake of
functional-language purity.
One argument in favor of reduce that I haven't seen anywhere yet is
that it is a kind of bottleneck. If I can squeeze my algorithm through
a reduce that means that I have truly streamlined it and have removed
superfluous cruft. After having done that or other code mangling
tricks -like trying to transform my code into a one liner- I usually
have no mental problems refactoring it back into a wider frame.
So some things have a use case because they require a special way of
thinking, and impose certain restrictions on the flow of my code.
Reduce is an important cognitive tool, at least it has been such for
me during a certain time frame, because nowadays I can often go
through the mental hoop without needing to actually produce the code.
I would be reluctant to deny others the chance to learn how not to use
it.
Anton
Bob Gailer wrote:
... The use of zip(seq[1:], [:-1]) to me is more obscure, and
Very obscure indeed (though it's hard to say if it's _more_ obscure without
a clear indication of what to compare it with). Particularly considering
that it's incorrect Python syntax, and the most likely correction gives
probably incorrect semantics, too, if I understand the task (give windows
of 2 items, overlapping by one, on seq?).
memory/cpu-expensive in terms of creating 3 new lists.
Fortunately, Hettinger's splendid itertools module, currently in Python's
standard library, lets you perform this windowing task without creating any
new list whatsoever.
Wen seq is any iterable, all you need is izip(seq, islice(seq, 1, None)),
and you'll be creating no new list whatsoever. Still, tradeoffs in
obscurity (and performance for midsized lists) are quite as clear.
Alex
"Dave Brueck" <da**@pythonapo crypha.com> writes: Of course I am not joking. I see no good coming from the mantra, when
the mantra should be instead what I said it should be:
"small, clean, simple, powerful, general, elegant"
It's really a matter of taste - both "versions" mean about the same to me
(and to me both mean "get rid of reduce()" ;-) ).
No, my mantra plainly states to keep general and powerful features
over specific, tailored features. reduce() is more general and
powerful than sum(), and would thus clearly be preferred by my
mantra.
The mantra "there should be only one obvious way to do it" apparently
implies that one should remove powerful, general features like
reduce() from the language, and clutter it up instead with lots of
specific, tailored features like overloaded sum() and max(). If so,
clearly this mantra is harmful, and will ultimately result in Python
becoming a bloated language filled up with "one obvious way" to solve
every particular idiom. This would be very bad, and make it less like
Python and more like Perl.
I can already see what's going to happen with sum(): Ultimately,
people will realize that they may want to perform more general types
of sums, using alternate addition operations. (For intance, there may
be a number of different ways that you might add together vectors --
e.g, city block geometry vs. normal geometry. Or you may want to add
together numbers using modular arithmetic, without worrying about
overflowing into bignums.) So, a new feature will be added to sum()
to allow an alternate summing function to be passed into sum(). Then
reduce() will have effectively been put back into the language, only
its name will have been changed, and its interface will have been
changed so that everyone who has taken CS-101 and knows off the top of
their head what reduce() is and does, won't easily be able to find it.
Yes, there are other parts of The Zen of Python that point to the
powerful and general, rather than the clutter of specific and
tailored, but nobody seems to quote them these days, and they surely
are ignoring them when they want to bloat up the language with
unneccessary features like overloaded sum() and max() functions,
rather than to rely on trusty, powerful, and elegant reduce(), which
can easily and lightweightedly do everything that overloaded sum() and
max() can do and quite a bit more.
To me, there is never *one* obviously "right way" to do anything
Never? I doubt this very much. When you want to add two numbers in a
programming language, what's your first impulse? Most likely it is
to write "a + b".
Or b + a. Perhaps we should prevent that, since that makes two
obviously right ways to do it!
Having said that though, part of the appeal of Python is that it hits the
nail on the head surprisingly often: if you don't know (from prior
experience) how to do something in Python, your first guess is very often
correct. Correspondingly , when you read someone else's Python code that uses
some feature you're not familiar with, odds are in your favor that you'll
correctly guess what that feature actually does.
All of this falls out of "clean", "simple", and "elegant".
And that is why I wouldn't be sad if reduce() were to disappear - I don't
use reduce() and _anytime_ I see reduce() in someone's code I have to slow
way down and sort of rehearse in my mind what it's supposed to do and see if
I can successfully interpret its meaning (and, when nobody's looking, I
might even replace it with a for-loop!).
C'mon -- all reduce() is is a generalized sum or product. What's
there to think about? It's as intuitive as can be. And taught in
every CS curiculum. What more does one want out of a function?
|>oug
In article <%F************ *******@news2.t in.it>,
Alex Martelli <al*****@yahoo. com> wrote: The use of zip(seq[1:], [:-1]) to me is more obscure, and
Very obscure indeed (though it's hard to say if it's _more_ obscure without
a clear indication of what to compare it with). Particularly considering
that it's incorrect Python syntax, and the most likely correction gives
probably incorrect semantics, too, if I understand the task (give windows
of 2 items, overlapping by one, on seq?).
memory/cpu-expensive in terms of creating 3 new lists.
Fortunately, Hettinger's splendid itertools module, currently in Python's
standard library, lets you perform this windowing task without creating any
new list whatsoever.
Wen seq is any iterable, all you need is izip(seq, islice(seq, 1, None)),
and you'll be creating no new list whatsoever. Still, tradeoffs in
obscurity (and performance for midsized lists) are quite as clear.
If I'm not mistaken, this is buggy when seq is an iterable, and you need
to do something like
seq1,seq2 = tee(seq)
izip(seq1,islic e(seq2,1,None))
instead.
--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Douglas Alan <ne****@mit.edu > wrote in message news:<lc******* *****@gaffa.mit .edu>... Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.
I don't know what your definition of beautiful is, but reduce is the
equivalent of Haskell's foldl1, a function not even provided by most
of the other functional languages I know. I can't see how someone
could consider it "beautiful" to include a rarely-used and
limited-extent fold and not provide the standard folds.
You want to make Python into a functional language? Write a
functional module. foldl, foldr, etc; basically a copy of the Haskell
List module. That should give you a good start, and then you can use
such facilities to your heart's content.
Me? I love functional programming, but in Python I'd much rather read
a for loop than a reduce or probably even a fold. Horses for courses,
you know?
Jeremy
Alex Martelli <al***@aleax.it > writes: no disagreement, reduce is in line with that philosophy sum is a
shortcut and as others have said is less general.
'sum' is _way simpler_: _everybody_ understands what it means to sum a
bunch of numbers, _without_ necessarily having studied computer science.
Your claim is silly. sum() is not *way* simpler than reduce(), and
anyone can be explained reduce() in 10 seconds: "reduce() is just like
sum(), only with reduce() you can specify whatever addition function
you would like."
The claim, made by somebody else, that _every_ CS 101 course teaches the
functionality of 'reduce' is not just false, but utterly absurd: 'reduce',
'foldl', and similar higher-order functions, were not taught to me back when
_I_ took my first university exam in CS [it used Fortran as te main
language],
Then you weren't taught Computer Science -- you were taught Fortran
programming. Computer Science teaches general concepts, not specific
languages.
they were not taught to my son in _his_ equivalent course [it used
Pascal], and are not going to be taught to my daughter in _her_
equivalent course [it uses C].
Then your children were done a great diservice by receiving a poor
education. (Assuming that is that they wanted to learn Computer
Science, and not Programming in Pascal or Programming in C.)
Python's purpose is not, and has never been, to maximize the generality
of the constructs it offers.
Whoever said anything about "maximizing generality"? If one's mantra
is "small, clean, simple, general, powerful, elegant", then clearly
there will come times when one must ponder on a trade-off between, for
example, elegant and powerful. But if you end up going and removing
elegant features understood by anyone who has studied Computer Science
because you think your audience is too dumb to make a slight leap from
the specific to the general that can be explained on one simple
sentence, then you are making those trade-off decisions in the
*utterly* wrong manner. You should be assuming that your audience are
the smart people that they are, rather than the idiots you are
assuming them to be.
But not with the parts that I quoted from the "spirit of C", and I
repeat them because they were SO crucial in the success of C as a
lower-level language AND are similarly crucial in the excellence of
Python as a higher-level one -- design principles that are *VERY*
rare among computer languages and systems, by the way:
I sure hope that Python doesn't try to emulate C. It's a terrible,
horrible programming language that held back the world of software
development by at least a decade.
Keep the language small and simple.
Provide only one way to do an operation.
It is not true these principles are rare among computer languages --
they are quite common. Most such language (like most computer
languages in general) just never obtained any wide usage.
The reason for Python's wide acceptance isn't because it is
particularly well-designed compared to other programming languages
that had similar goals of simplicity and minimality (it also isn't
poorly designed compared to any of them -- it is on par with the
better ones) -- the reason for its success is that it was in the right
place at the right time, it had a lightweight implementation, was
well-suited to scripting, and it came with batteries included.
|>oug
> >> Of course I am not joking. I see no good coming from the mantra, when the mantra should be instead what I said it should be: "small, clean, simple, powerful, general, elegant" It's really a matter of taste - both "versions" mean about the same to
me (and to me both mean "get rid of reduce()" ;-) ).
No, my mantra plainly states to keep general and powerful features
over specific, tailored features.
And I disagree that that's necessarily a Good Thing. Good language design is
about finding that balance between general and specific. It's why I'm not a
language designer and it's also why I'm a Python user.
reduce() is more general and
powerful than sum(), and would thus clearly be preferred by my
mantra.
Yes, and eval() would clearly be preferred over them all.
The mantra "there should be only one obvious way to do it" apparently
implies that one should remove powerful, general features like
reduce() from the language, and clutter it up instead with lots of
specific, tailored features like overloaded sum() and max().
I completely disagree - I see no evidence of that. We're looking at the same
data but drawing very different conclusions from it.
I can already see what's going to happen with sum(): Ultimately,
people will realize that they may want to perform more general types
of sums, using alternate addition operations.
Not gonna happen - this _might_ happen if Python was a design-by-committee
language, but it's not.
Yes, there are other parts of The Zen of Python that point to the
powerful and general, rather than the clutter of specific and
tailored, but nobody seems to quote them these days,
'not quoting' != 'not following'
and
'what gets debated on c.l.py' != 'what the Python developers do'
Having said that though, part of the appeal of Python is that it hits
the nail on the head surprisingly often: if you don't know (from prior
experience) how to do something in Python, your first guess is very
often correct. Correspondingly , when you read someone else's Python code that
uses some feature you're not familiar with, odds are in your favor that
you'll correctly guess what that feature actually does.
All of this falls out of "clean", "simple", and "elegant".
Not at all - I cut my teeth on 6502 assembly and there is plenty that I
still find clean, simple, and elegant about it, but it's horrible to program
in.
And that is why I wouldn't be sad if reduce() were to disappear - I
don't use reduce() and _anytime_ I see reduce() in someone's code I have to
slow way down and sort of rehearse in my mind what it's supposed to do and
see if I can successfully interpret its meaning (and, when nobody's looking, I
might even replace it with a for-loop!).
C'mon -- all reduce() is is a generalized sum or product. What's
there to think about? It's as intuitive as can be.
To you, perhaps. Not me, and not a lot of other people. To be honest I don't
really care that it's in the language. I'm not dying to see it get
deprecated or anything, but I do avoid it in my own code because it's
non-obvious to me, and if it were gone then Python would seem a little
cleaner to me.
Obviously what is intuitive to someone is highly subjective - I was really
in favor of adding a conditional operator to Python because to me it _is_
intuitive, clean, powerful, etc. because of my previous use of it in C. As
much as I wanted to have it though, on one level I'm really pleased that a
whole lot of clamoring for it did not result in its addition to the
language. I *like* the fact that there is someone making subjective
judgement calls, even if it means I sometimes don't get my every wish.
A good programming language is not the natural by-product of a series of
purely objective tests.
And taught in
every CS curiculum.
Doubtful, and if it were universally true, it would weaken your point
because many people still find it a foreign or awkward concept. Besides,
whether or not something is taught in a CS program is a really poor reason
for doing anything.
-Dave
"Dave Brueck" <da**@pythonapo crypha.com> writes: And I disagree that that's necessarily a Good Thing. Good language
design is about finding that balance between general and
specific. It's why I'm not a language designer and it's also why I'm
a Python user.
It's surely the case that there's a balance, but if you assume that
your audience is too stupid to be able to be able to cope with
reduce(add, seq)
instead of
sum(seq)
then you are not finding the proper balance.
reduce() is more general and powerful than sum(), and would thus
clearly be preferred by my mantra.
Yes, and eval() would clearly be preferred over them all.
And, damned right, eval() should stay in the language!
The mantra "there should be only one obvious way to do it" apparently
implies that one should remove powerful, general features like
reduce() from the language, and clutter it up instead with lots of
specific, tailored features like overloaded sum() and max().
I completely disagree - I see no evidence of that. We're looking at
the same data but drawing very different conclusions from it.
Well, that's the argument you seem to be making -- that reduce() is
superfluous because a sum() and max() that work on sequences were
added to the language.
I can already see what's going to happen with sum(): Ultimately,
people will realize that they may want to perform more general types
of sums, using alternate addition operations.
Not gonna happen - this _might_ happen if Python was a design-by-committee
language, but it's not.
According to Alex Martelli, max() and min() are likely to be extended
in this fashion. Why not sum() next?
All of this falls out of "clean", "simple", and "elegant".
Not at all - I cut my teeth on 6502 assembly and there is plenty
that I still find clean, simple, and elegant about it, but it's
horrible to program in.
I think we can both agree that not all of programming language design can
be crammed into a little mantra!
C'mon -- all reduce() is is a generalized sum or product. What's
there to think about? It's as intuitive as can be.
To you, perhaps. Not me, and not a lot of other people.
Well, perhaps you can explain your confusion to me? What could
possibly be unintuitive about a function that is just like sum(), yet
it allows you to specify the addition operation that you want to use?
Of course, you can get the same effect by defining a class with your
own special __add__ operator, and then encapsulating all the objects
you want to add in this new class, and then using sum(), but that's a
rather high overhead way to accomplish the same thing that reduce()
lets you do very easily.
I *like* the fact that there is someone making subjective
judgement calls, even if it means I sometimes don't get my every wish.
Likewise.
A good programming language is not the natural by-product of a series of
purely objective tests.
And taught in every CS curiculum.
Doubtful, and if it were universally true, it would weaken your point
because many people still find it a foreign or awkward concept.
I doubt that anyone who has put any thought into it finds it a foreign
concept. If they do, it's just because they have a knee-jerk reaction
and *want* to find it a foreign concept.
If you can cope with modular arithmetic, you can cope with the idea of
allowing people to sum numbers with their own addition operation!
Besides, whether or not something is taught in a CS program is a
really poor reason for doing anything.
No, it isn't. CS is there for a reason, and one should not ignore the
knowledge it contains. That doesn't mean that one should feel
compelled to repeat the mistakes of history. But fear of that is no
reason not to accept its successes. Those who don't, end up inventing
languages like Perl.
|>oug
Douglas Alan: Then you weren't taught Computer Science -- you were taught Fortran
programming. Computer Science teaches general concepts, not specific
languages.
I agree with Alex on this. I got a BS in CS but didn't learn about
lambda, reduce, map, and other aspects of functional programming
until years later, and it still took some effort to understand it.
(Granted,
learning on my own at that point.)
But I well knew what 'sum' did.
Was I not taught Computer Science? I thought I did pretty well
on the theoretical aspects (state machines, automata, discrete math,
algorithms and data structures). Perhaps my school was amiss in
leaving it out of the programming languages course, and for
teaching its courses primarily in Pascal. In any case, it contradicts
your assertion that anyone who has studied CS knows what
reduce does and how its useful.
Then your children were done a great diservice by receiving a poor
education. (Assuming that is that they wanted to learn Computer
Science, and not Programming in Pascal or Programming in C.)
Strangely enough, I didn't see an entry for 'functional programming'
in Knuth's "The Art of Computer Programming" -- but that's just
programming. ;)
But if you end up going and
removing elegant features understood by anyone who has studied Computer Science
because you think your audience is too dumb to make a slight leap from
the specific to the general that can be explained on one simple
sentence, then you are making those trade-off decisions in the
*utterly* wrong manner. You should be assuming that your audience are
the smart people that they are, rather than the idiots you are
assuming them to be.
Your predicate (that it's understood by anyone who has studied
CS) is false so your argument is moot. In addition, I deal with a
lot of people who program but didn't study CS. And I rarely
use reduce in my code (even rarer now that 'sum' exists) so would
not miss its exclusion or its transfer from builtins to a module.
Andrew da***@dalkescie ntific.com
Douglas Alan wrote: Your claim is silly. sum() is not *way* simpler than reduce(), and
anyone can be explained reduce() in 10 seconds: "reduce() is just like
sum(), only with reduce() you can specify whatever addition function
you would like."
Maybe reduce() can be explained in 10 seconds to someone who has used
sum() a few times, but that has no bearing whatsoever on trying to
explain reduce() to someone if sum() is not available and hasn't
been used by them.
they were not taught to my son in _his_ equivalent course [it used
Pascal], and are not going to be taught to my daughter in _her_
equivalent course [it uses C].
Then your children were done a great diservice by receiving a poor
education. (Assuming that is that they wanted to learn Computer
Science, and not Programming in Pascal or Programming in C.)
I'm sorry, but from a pure CS viewpoint, reduce() is way off the
radar screen. Especially for a 101 course. If either of my daughters
wanted to discuss reduce() while taking such a course, I'd want to
see the curriculum to figure out what they _weren't_ being taught.
You should be assuming that your audience are the smart people
that they are, rather than the idiots you are assuming them to be.
Ignorance is not stupidity. I have yet to see a language which
can be used by stupid people with consistent success; however I
have seen a great deal of evidence that Python can be used very
successfully by ignorant people. It gently eases them in and
allows them to perform useful work while slowly reducing their
ignorance.
I sure hope that Python doesn't try to emulate C. It's a terrible,
horrible programming language that held back the world of software
development by at least a decade.
I used to hate C. But then, when it borrowed enough good concepts
from Pascal and other languages, and the compilers got smart enough
to warn you (if you cared to see the warnings) about things like
"if (x = y)" I stopped using Modula-2. C held software back 10
years in the same manner as Microsoft did, e.g. by helping to
standardize things to where I can buy a $199 system from WalMart
which would cost over $20,000 if everybody kept writing code like
the pointy-headed ivory tower academics thought it ought to be written.
For certain problem domains (where domain includes the entire system
of software, hardware, real-time constraints, portability, user
expectations, maintainability by a dispersed team, etc.), C is an
excellent implementation language. But don't take my word for it --
open your eyes and look around. Could there be a better implementation
language? Sure. Would C acquire the bare minimum features needed
to compete with the new language? Absolutely.
(But I freely admit I'm a luddite: I prefer Verilog to VHDL, as well.)
The reason for Python's wide acceptance isn't because it is
particularly well-designed compared to other programming languages
that had similar goals of simplicity and minimality (it also isn't
poorly designed compared to any of them -- it is on par with the
better ones) -- the reason for its success is that it was in the right
place at the right time, it had a lightweight implementation, was
well-suited to scripting, and it came with batteries included.
I'd vote this as the statement in this group most likely to start
a religious flamewar since the lisp threads died down.
I'm not particularly religious, but I _will_ bite on this one:
1) In what way was it at the "right place at the right time?" You
didn't name names of other languages, but I'll bet that if you can
name 5 which are similar by your criteria, at least two of them
were available when Python first came out.
2) What part of "lightweigh t implementation, well suited to scripting"
contradicts, or is even merely orthorgonal to "particular ly well-designed"?
3) Do you _really_ think that all the batteries were included when
Python first came out? Do you even think that Python has more batteries
_right_ _now_ than Perl (via CPAN), or that some competing language
couldn't or hasn't already been designed which can coopt other languages'
batteries?
I can accept the premise that, for Python to enjoy the acceptance
it does today, Guido had to be lucky in addition to being an excellent
language designer. But if I were to accept the premise that Python's
popularity is due to sheer luck alone, my only logical course of action
would to be to buy Guido a plane ticket to Vegas and front him $10,000
worth of chips, because he has been extremely lucky for many years now.
Pat This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Tom Anderson |
last post by:
Comrades,
During our current discussion of the fate of functional constructs in
python, someone brought up Guido's bull on the matter:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
He says he's going to dispose of map, filter, reduce and lambda. He's
going to give us product, any and all, though, which is nice of him.
|
by: clintonG |
last post by:
At design-time the application just decides to go boom claiming it can't
find a dll. This occurs sporadically. Doing a simple edit in the HTML for
example and then viewing the application has caused the application to go
boom. Sometimes the page will compile and run using F5 and others not.
So I do the web search tango looking around the blogs and the tuts and
determine I should go into Temporary ASP.NET Files and delete the directory...
|
by: mai |
last post by:
Hi everyone,
i'm trying to exhibit FIFO anomaly(page replacement algorithm),, I
searched over 2000 random strings but i couldnt find any anomaly,, am
i I doing it right?,, Please help,,,The following is the code,,
#include <iostream>
#include <string>
#include <stdio.h>
#include <stdlib.h>
#include <ctime // For time()
|
by: cnb |
last post by:
This must be because of implementation right? Shouldn't reduce be
faster since it iterates once over the list?
doesnt sum first construct the list then sum it?
-----------------------
reduce with named function: 37.9864357062
reduce with nested, named function: 39.4710288598
reduce with lambda: 39.2463927678
sum comprehension: 25.9530121845
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
