Re: Curious Omission In New-Style Formats
Op 15-07-16 om 08:06 schreef Marko Rauhamaa: > Ian Kelly : > >> On Jul 14, 2016 11:37 AM, "Marko Rauhamaa" wrote: >>> Where do you get the idea that the common usage is "wrong?" What do >>> you use as a standard? >> Is it "wrong" to consider some usages "wrong"? By what standard? >> >> I'm not interested in arguing over philosophy, so I won't. > Common usage among educated speakers ordinarily is the yardstick for > language questions. But educated about what exactly? Each time someone talks about "a steep learning curve" in order to indicate something is difficult to master, he is using it wrong, because actual steep learning curves indicate something can be mastered quickly. Now I suspect most people who talk about steep learning curves are educated, they just aren't educated about learning curves and so I think common usage among educated speakers is inadequate as a yard stick. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Antoon Pardon writes: > Op 15-07-16 om 08:06 schreef Marko Rauhamaa: >> >> Common usage among educated speakers ordinarily is the yardstick for >> language questions. > > But educated about what exactly? > > Each time someone talks about "a steep learning curve" in order to > indicate something is difficult to master, he is using it wrong, > because actual steep learning curves indicate something can be > mastered quickly. > > Now I suspect most people who talk about steep learning curves are > educated, they just aren't educated about learning curves and so I > think common usage among educated speakers is inadequate as a yard > stick. I think I see your point, but I think it's also easy to think the axes of the metaphor so that it makes sense: c , o , s, t . . l e a r n i n g First two steps l-e plain sailing. Next two steps a-r steep climb. Cost is the effort that makes the learner experience the learning as steep. (Spending more *time* without ever paying much attention may not be the best of ideas - it may be the worst of ideas - if the goal is to learn but it still fits the graph: cost goes up for little or no gain.) Perhaps more proper to call that a cost-to-learn curve or something? But when it becomes unwieldy, it gets shortened to something shorter, and here the more informative component has won. Maybe. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Antoon Pardon : > Op 15-07-16 om 08:06 schreef Marko Rauhamaa: >> Common usage among educated speakers ordinarily is the yardstick for >> language questions. > > But educated about what exactly? In this case we are talking about those people who actively talk about significand/mantissa. By and large, they call the thing mantissa. I'm not at all irritated or confused by that (even if my opinion mattered). I *am* irritated by Americans using "Km" for kilometer and "msec" for millisecond (even though my opinion doesn't matter). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Op 15-07-16 om 11:20 schreef Marko Rauhamaa: > Antoon Pardon : > >> Op 15-07-16 om 08:06 schreef Marko Rauhamaa: >>> Common usage among educated speakers ordinarily is the yardstick for >>> language questions. >> But educated about what exactly? > In this case we are talking about those people who actively talk about > significand/mantissa. By and large, they call the thing mantissa. I think there is an important difference between actively talking about something and being educated (about it). I have known people who actively talked about negative feedback while what they actually meant was a vicious circle that technically was possitive feedback but with results they wanted to avoid. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Fri, 15 Jul 2016 06:40 pm, Jussi Piitulainen wrote: > Antoon Pardon writes: > >> Op 15-07-16 om 08:06 schreef Marko Rauhamaa: >>> >>> Common usage among educated speakers ordinarily is the yardstick for >>> language questions. >> >> But educated about what exactly? >> >> Each time someone talks about "a steep learning curve" in order to >> indicate something is difficult to master, he is using it wrong, >> because actual steep learning curves indicate something can be >> mastered quickly. That's not necessarily the case. See below. >> Now I suspect most people who talk about steep learning curves are >> educated, they just aren't educated about learning curves and so I >> think common usage among educated speakers is inadequate as a yard >> stick. > > I think I see your point, but I think it's also easy to think the axes > of the metaphor so that it makes sense: > > c , > o , > s, > t . . > l e a r n i n g > > First two steps l-e plain sailing. Next two steps a-r steep climb. Cost > is the effort that makes the learner experience the learning as steep. > (Spending more *time* without ever paying much attention may not be the > best of ideas - it may be the worst of ideas - if the goal is to learn > but it still fits the graph: cost goes up for little or no gain.) > > Perhaps more proper to call that a cost-to-learn curve or something? > But when it becomes unwieldy, it gets shortened to something shorter, > and here the more informative component has won. Maybe. "Learning curve" or "experience curve" is not just an metaphor, it is an actual technical term. See the Wikipedia article: https://en.wikipedia.org/wiki/Learning_curve Now, there are a couple of ways that we can interpret the idiom of "steep learning curve". One is the way Wikipedia interprets it: as a mistake. According to this conventional explanation, people have *wrongly* imagined a curve like this: (for best results, view using a fixed width font like Courier) K x nx ox w l x e d g x e + Effort or cost or time needed to gain that knowledge or skill as being "hard to learn" at the beginning, when in fact it shows the opposite: with just a little bit of effort, you can learn a lot. But (so goes the conventional explanation) people think of steep in the sense of climbing a steep mountain, and think that it shows that the learning process is really hard at the start. I believe Wikipedia is wrong. I think that there is a natural interpretation of "steep learning curve" which matches *both* the idiomatic and technical meanings, with the same graph. Remember that the English idiom of a steep learning curve is not just hard to learn. It means that something takes a lot of effort to gain mastery over, after which things become easier. Learning Ancient Etruscan is hard for beginners and experts alike, because there is so little information available about Ancient Etruscan that even the experts can hardly be said to have mastered the language. That would not often be described as a steep learning curve, as it lacks the sense of getting easier with time. Learning Etruscan might have a curve like this: K n x o x w x l x e x d x g x e + Effort or cost or time It's hard at the beginning, because you don't know the language; then it gets a bit easier, for a while, then it gets difficult again because you run out of information about the language. Here is a curve that matches the common idiom. It is (1) steep, (2) requires a lot of effort for very little progress at the beginning, and (3) becomes easier with time: K x n x o x w x l x e x d x g x e + Effort or cost or time Mastery makes the going easy, but it takes a long time to see any real progress. You can interpret the "steepness" in two ways: it's steep (easy) for experts, and if you turn your head to the side, it's steep (hard, like climbing a steep mountain) at the beginning). Another way to interpret it is to ask, what's the *cost* (in time, or effort) to gain a certain amount of knowledge? That's equivalent to swapping the X and Y axes: Cx o x sx t · x o r · t x i m e + Knowledge gained That's not the conventional layout of the axis, but it does make sense, and it's more likely that people have this reversed layout in mind when thinking about "steepness of learning" than it is that they were thinking about the original curve and misinterpreting the meaning of the gradient. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Op 15-07-16 om 10:40 schreef Jussi Piitulainen: > Antoon Pardon writes: > >> Op 15-07-16 om 08:06 schreef Marko Rauhamaa: >>> Common usage among educated speakers ordinarily is the yardstick for >>> language questions. >> But educated about what exactly? >> >> Each time someone talks about "a steep learning curve" in order to >> indicate something is difficult to master, he is using it wrong, >> because actual steep learning curves indicate something can be >> mastered quickly. >> >> Now I suspect most people who talk about steep learning curves are >> educated, they just aren't educated about learning curves and so I >> think common usage among educated speakers is inadequate as a yard >> stick. > I think I see your point, but I think it's also easy to think the axes > of the metaphor so that it makes sense: > > c , > o , > s, > t . . > l e a r n i n g Only for someone who is not very familiar with how we graphically represent results. The cost/effort is always put on the X-ax because that is what we directly control and also because that is what always increases. You can't unspent time in trying to master something. We make this choice because we want a mathematical function. What if you have a set back? How do you show that on your graph? Ask people if they prefer a steep or shallow pay check curve. Most seem very quick in choosing for the steep curve. -- Antoon -- https://mail.python.org/mailman/listinfo/python-list
math.frexp
I'm experimenting with various implementations of product(values). Here's a naive version that easily suffers from overflow: from functools import reduce from operator import mul def product_naive(values): return reduce(mul, values) py> product_naive([2, 4, 5]) 40 py> product_naive([1e200, 1e200, 1e200]) inf So I started experimenting with math.frexp, but I'm having trouble understanding what I'm doing wrong here. Help on built-in function frexp in module math: frexp(...) frexp(x) Return the mantissa and exponent of x, as pair (m, e). m is a float and e is an int, such that x = m * 2.**e. If x is 0, m and e are both 0. Else 0.5 <= abs(m) < 1.0. If x and y are both floats, then given: m1, e1 = math.frexp(x) m2, e2 = math.frexp(y) Then x*y = m1*m2 * 2.0**(e1 + e2). We can test that: py> from math import frexp py> x = 2.5 py> y = 3.5 py> x*y 8.75 py> m1, e1 = math.frexp(x) py> m2, e2 = math.frexp(y) py> m1*m2 * 2.0**(e1 + e2) 8.75 Looks good to me. So let's try a less naive version of product(): def product_scaled(values): scale = 0 prod = 1.0 for a in values: m1, e1 = math.frexp(a) m2, e2 = math.frexp(prod) scale += (e1 + e2) prod *= (m1*m2) return (prod * 2.0**scale) py> product_scaled([2.5, 3.5]) # expected 8.75 2.734375 What am I doing wrong? -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Op 15-07-16 om 12:56 schreef Steven D'Aprano: > On Fri, 15 Jul 2016 06:40 pm, Jussi Piitulainen wrote: > >> Antoon Pardon writes: >> >>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa: Common usage among educated speakers ordinarily is the yardstick for language questions. >>> But educated about what exactly? >>> >>> Each time someone talks about "a steep learning curve" in order to >>> indicate something is difficult to master, he is using it wrong, >>> because actual steep learning curves indicate something can be >>> mastered quickly. > That's not necessarily the case. See below. I think it does. > > "Learning curve" or "experience curve" is not just an metaphor, it is an > actual technical term. See the Wikipedia article: > > https://en.wikipedia.org/wiki/Learning_curve I know and the technical term precedes the metaphor. > Remember that the English idiom of a steep learning curve is not just hard > to learn. It means that something takes a lot of effort to gain mastery > over, after which things become easier. Yes things/practicing become easier, mastering even further does not. > Here is a curve that matches the common idiom. It is (1) steep, (2) requires > a lot of effort for very little progress at the beginning, and (3) becomes > easier with time: > > > K x > n x > o x > w x > l x > e x > d x > g x > e > + Effort or cost or time I think you are making things up now. I have never seen an actual learning curve with that shape. All learning curves I have seen show the law of diminishing (marginal) returns. > Another way to interpret it is to ask, what's the *cost* (in time, or > effort) to gain a certain amount of knowledge? That's equivalent to > swapping the X and Y axes: Which you don't expect because if swapping axes was common, most people would understand that talking about steep or shallow curves would be meaningless since you wouldn't know whether is was steep with standaard ax positions or steep with swapped ax posititions. > > Cx > o x > sx > t > · x > o > r > · > t x > i > m > e > + Knowledge gained > > > > That's not the conventional layout of the axis, but it does make sense, and > it's more likely that people have this reversed layout in mind when > thinking about "steepness of learning" than it is that they were thinking > about the original curve and misinterpreting the meaning of the gradient. No, that is what people come up with afterwards. If you just start a conversation about how people learn and how long it would take to get some mastery and how we could present progress in a graph, virtually everyone uses the conventional axes layout. This talk about swapped axes only come from people who used the steep learning curve metaphor, when you then try to show them what an actual steep learning curve implies. -- https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
On Fri, Jul 15, 2016 at 9:39 PM, Steven D'Aprano wrote:
> py> from math import frexp
> py> x = 2.5
> py> y = 3.5
> py> x*y
> 8.75
> py> m1, e1 = math.frexp(x)
> py> m2, e2 = math.frexp(y)
> py> m1*m2 * 2.0**(e1 + e2)
> 8.75
>
>
> Looks good to me. So let's try a less naive version of product():
>
>
> def product_scaled(values):
> scale = 0
> prod = 1.0
> for a in values:
> m1, e1 = math.frexp(a)
> m2, e2 = math.frexp(prod)
> scale += (e1 + e2)
> prod *= (m1*m2)
> return (prod * 2.0**scale)
>
>
> py> product_scaled([2.5, 3.5]) # expected 8.75
> 2.734375
>
You're chaining your product twice. (Also your scale, although that
appears to be correct.) Changing it to "prod = m1 * m2" gives 8.75.
But what do you gain by this? You're still stuffing the result back
into a float at the end, so all you do is change from getting
float("inf") to getting OverflowError. How can you make it not
overflow?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Steven D'Aprano writes: [in response to my attempt to understand "steep learning curve"] > "Learning curve" or "experience curve" is not just an metaphor, it is > an actual technical term. See the Wikipedia article: > > https://en.wikipedia.org/wiki/Learning_curve > > > Now, there are a couple of ways that we can interpret the idiom of > "steep learning curve". One is the way Wikipedia interprets it: as a > mistake. [- -] Ouch. Next time I hear anyone use the phrase, if I need to know whether they mean "easy to learn" or "hard to learn" or something else, I think I'll ask them... Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Antoon Pardon writes: > Op 15-07-16 om 10:40 schreef Jussi Piitulainen: >> Antoon Pardon writes: >> >>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa: Common usage among educated speakers ordinarily is the yardstick for language questions. >>> But educated about what exactly? >>> >>> Each time someone talks about "a steep learning curve" in order to >>> indicate something is difficult to master, he is using it wrong, >>> because actual steep learning curves indicate something can be >>> mastered quickly. >>> >>> Now I suspect most people who talk about steep learning curves are >>> educated, they just aren't educated about learning curves and so I >>> think common usage among educated speakers is inadequate as a yard >>> stick. >> I think I see your point, but I think it's also easy to think the axes >> of the metaphor so that it makes sense: >> >> c , >> o , >> s, >> t . . >> l e a r n i n g > > Only for someone who is not very familiar with how we graphically > represent results. The cost/effort is always put on the X-ax because > that is what we directly control and also because that is what always > increases. You can't unspent time in trying to master something. We > make this choice because we want a mathematical function. > > What if you have a set back? How do you show that on your graph? Nice points, thank you. You may be simply right on this, and I may have learnt something. > Ask people if they prefer a steep or shallow pay check curve. Most > seem very quick in choosing for the steep curve. I'm not at all sure how I would answer. By asking what is meant? Because to me it sounds like a trick question to begin with. There's an old story they tell in my family about a child who begs for bread from a house. The lady of the house asks if they want a one-hand slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the poor hungry child asks for the two-hand slice, they get a slice so thin that it needs to be held with both hands. That's mean. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote: > No, that is what people come up with afterwards. If you just start a > conversation about how people learn and how long it would take to get > some mastery and how we could present progress in a graph, virtually > everyone uses the conventional axes layout. _Why_ do you think this? The natural way to graph progress vs effort is to have progress on the horizontal access and effort on the vertical axis, because that's what you get when you're climbing a literal hill, the only context in the universe where "vertical" and "horizontal" aren't arbitrarily assigned but are real spatial dimensions. The only reason to do it the other way is an association with time and the convention of using time for the horizontal axis. > This talk about swapped axes only come from people who used the steep > learning curve metaphor, when you then try to show them what an actual > steep learning curve implies. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Antoon Pardon writes: > No, that is what people come up with afterwards. If you just start a > conversation about how people learn and how long it would take to get > some mastery and how we could present progress in a graph, virtually > everyone uses the conventional axes layout. This talk about swapped > axes only come from people who used the steep learning curve metaphor, > when you then try to show them what an actual steep learning curve > implies. Or from people who try to be charitable when other people use it. At least I like to think that that's what I did. (I'm not at all inclined to do that about certain other terms, but those discussions are also not inclined to go anywhere.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Op 15-07-16 om 15:39 schreef Random832: > > On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote: > >> No, that is what people come up with afterwards. If you just start a >> conversation about how people learn and how long it would take to get >> some mastery and how we could present progress in a graph, virtually >> everyone uses the conventional axes layout. > _Why_ do you think this? The natural way to graph progress vs effort is > to have progress on the horizontal access and effort on the vertical > axis, because that's what you get when you're climbing a literal hill, > the only context in the universe where "vertical" and "horizontal" > aren't arbitrarily assigned but are real spatial dimensions. No that is not the natural way. That is the way you pick afterwards if you want your graph to resemble the metaphor. But it is not the way people "naturally" graph these numbers, if the metafor was not put into their head in first place. Certainly not people who actually study these kind of things. > The only reason to do it the other way is an association with time and > the convention of using time for the horizontal axis. No the reason is, we prefer the graph to be a function. That is for every x at most one y. Using the axes the other way around would mean that set backs would result in multiple y values for the same x. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Op 15-07-16 om 15:38 schreef Jussi Piitulainen: > Antoon Pardon writes: > >> No, that is what people come up with afterwards. If you just start a >> conversation about how people learn and how long it would take to get >> some mastery and how we could present progress in a graph, virtually >> everyone uses the conventional axes layout. This talk about swapped >> axes only come from people who used the steep learning curve metaphor, >> when you then try to show them what an actual steep learning curve >> implies. > Or from people who try to be charitable when other people use it. At > least I like to think that that's what I did. Sure, you can be charitable when other people use it. IME that doesn't contradict that when you somehow find yourself in need of actually graphing these kind of numbers you are likely to follow the conventional layout. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Fri, 15 Jul 2016 11:13 pm, Jussi Piitulainen wrote: > Steven D'Aprano writes: > > [in response to my attempt to understand "steep learning curve"] > >> "Learning curve" or "experience curve" is not just an metaphor, it is >> an actual technical term. See the Wikipedia article: >> >> https://en.wikipedia.org/wiki/Learning_curve >> >> >> Now, there are a couple of ways that we can interpret the idiom of >> "steep learning curve". One is the way Wikipedia interprets it: as a >> mistake. > > [- -] > > Ouch. Next time I hear anyone use the phrase, if I need to know whether > they mean "easy to learn" or "hard to learn" or something else, I think > I'll ask them... You really don't need to. "Steep learning curve" in ordinary English ALWAYS means that it is hard to make progress and then gets easier once you have mastered it. Its a common idiom. If you're talking to an actual expert in the field about an actual graph, then it might be worth asking them what they mean. And the chances are they will mean exactly the same thing as ordinary people, and they'll just say "turn your head to the side, see how steep the graph is at the start". That's my prediction. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote: > There's an old story they tell in my family about a child who begs for > bread from a house. The lady of the house asks if they want a one-hand > slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the > poor hungry child asks for the two-hand slice, they get a slice so thin > that it needs to be held with both hands. That's mean. Ha, that's exactly the same story my grandmother (who was Estonian-Russian) used to tell me. If you don't mind me asking, what nationality are you? -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Steven D'Aprano writes: > On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote: > >> There's an old story they tell in my family about a child who begs for >> bread from a house. The lady of the house asks if they want a one-hand >> slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the >> poor hungry child asks for the two-hand slice, they get a slice so thin >> that it needs to be held with both hands. That's mean. > > > Ha, that's exactly the same story my grandmother (who was > Estonian-Russian) used to tell me. If you don't mind me asking, what > nationality are you? Finnish. Karelian enough that it probably is the exact same story. -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
On Fri, Jul 15, 2016 at 10:39:05AM +1000, Steven D'Aprano wrote:
> About seven years ago, the senior technical manager at my work chose hg over
> git. When he left to go to greener pastures, the dev team took about 30
> seconds to to reverse his decision and migrate to git, after which the
> level of VCS-related screw-ups and queries went through the roof.
Git used to have much sharper edges than Mercurial, but that is
pretty much a thing of the past. With Git you pretty much can't
permanently lose history unless you try really, really hard.
It'll always be there in the reflog for a period of several days
minimum (I think 2 weeks by default?) and if you're worried about
it you can configure it to put that off for months or years...
On the other hand, I have had Mercurial bugs repeatedly lose work
of mine. The kind of bugs that aren't easy to reproduce so nearly
impossible to report and nearly impossible to fix. The ecosystem
of "extensions" makes this problem inevitable. You depend on
extensions, typically third-party extensions for the first few
years of their life, for all of the power-user stuff, and the
extensions have as much power to corrupt or lose history as the
main library does. And of course, they have the potential to
alter the behavior of the core library making reporting bugs that
much more difficult ("ok, but which extensions, official or
unofficial, do you have installed?"). Now instead of one team
writing bugs you have N teams writing them in isolation.
Combined with their failure to accomodate the distributed
development model properly you now have a bunch of incompatible
ideas for managing branches and history editing and they still
haven't gotten it all right yet (but they're getting closer the
more and more they model the design after Git).
> To give you an idea of how screwed up things are, even though I'm not one of
> the developer team, and have never pushed a thing into the code
> repositories (I have pushed into documentation repos), somehow according
> to "git blame" I'm responsible for a bunch of code.
The user name and email fields are not controlled in either Git
or Mercurial so anybody can commit code under your name without
you being involved. That would be pretty unprofessional though...
I can't imagine Git magically pulling your name out of nowhere
when it looks up the author of commits that are responsible for
lines of code... Maybe you should report that to the mailing list
and get to the bottom of it... I suspect that the explanation has
nothing to do with any bugs in Git.
Regards,
--
Brandon McCaig
Castopulence Software
Re: Were is a great place to Share your finished projects?
On Sat, Jul 16, 2016 at 1:39 AM, Brandon McCaig wrote: > [regarding Mercurial] > Combined with their failure to accomodate the distributed > development model properly you now have a bunch of incompatible > ideas for managing branches and history editing and they still > haven't gotten it all right yet (but they're getting closer the > more and more they model the design after Git). I've never managed to get Mercurial's branching system into my head (and then you have the people saying "don't use hg branches at all, just use named tags" or somesuch), but the git branching system is extremely simple. In fact, all of git is very simple. To anyone who is having trouble with comprehending git, I strongly recommend this video. It assumes you have a basic understanding of git commands (or can pause the video and look up a git-hg Rosetta Stone), but you don't need expert-level knowledge. In fact, it's aimed at people ages 4 and up... https://www.youtube.com/watch?v=1ffBJ4sVUb4 >> To give you an idea of how screwed up things are, even though I'm not one of >> the developer team, and have never pushed a thing into the code >> repositories (I have pushed into documentation repos), somehow according >> to "git blame" I'm responsible for a bunch of code. > > The user name and email fields are not controlled in either Git > or Mercurial so anybody can commit code under your name without > you being involved. That would be pretty unprofessional though... If you're paranoid, you can have git sign your commits, in which case anyone could commit code under your name, but not using your private key. You can then tell people to be suspicious of any commits they can't cryptographically verify. > I can't imagine Git magically pulling your name out of nowhere > when it looks up the author of commits that are responsible for > lines of code... Maybe you should report that to the mailing list > and get to the bottom of it... I suspect that the explanation has > nothing to do with any bugs in Git. There are a few possibilities. If someone copied a slab of code from the documentation repo straight into the code repo (maybe you provided examples or something), git might detect that and recognize the copying. In that case, you'd be (correctly) responsible for that code, and the author would be a two-part "originally authored" pointing to your docs commit and "moved or copied here by" pointing to the commit that actually incorporated it. But if the repositories are completely separate, this is unlikely. More likely, someone might be able to cherry-pick the commit itself, if there is a corresponding file in code; again, this would have a two-part authorship marker "author" and "committer", because every git commit has this. (This is something Mercurial lacks. Every commit is blamed to the person with the commit-bit who pushed it, rather than the person who actually wrote the code. Obviously the committer is important, but so is the author.) If you want to get to the bottom of it, I would advise exploring the commits that are tagged with your name. Do they look like changes you made? Did you provide a patch file that someone else committed? And, who committed the changes - can you email that person to ask for clarification? The beauty of git is that all the information is right there, if you just look at it - 'git show 142857' will answer most of the above questions, and add "--format=full" or "--format=fuller" [1] to get the committer's info. Dig around... have fun! [1] I mean, not "fuller", just... more formatful. Wait, what? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
On Fri, 15 Jul 2016 09:48 pm, Chris Angelico wrote:
>> py> product_scaled([2.5, 3.5]) # expected 8.75
>> 2.734375
>>
>
> You're chaining your product twice. (Also your scale, although that
> appears to be correct.) Changing it to "prod = m1 * m2" gives 8.75.
D'oh!
Thanks! I needed some fresh eyes on that, because I have been staring at it
for two days.
> But what do you gain by this? You're still stuffing the result back
> into a float at the end, so all you do is change from getting
> float("inf") to getting OverflowError. How can you make it not
> overflow?
If the result is too big to be represented as a float at the end of the
product, then of course it will overflow. But this can give some protection
against overflow of intermediate values. Consider multiplying:
2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0
Mathematically, the answer should be 6. In principle, by rescaling when
needed to prevent overflow (or underflow), product() should be able to get
something very close to 6, if not exactly 6.
But I'm not actually writing a general product() function. I'm doing this
for geometric mean, so I return the scaling exponent and the mantissa[1]
separately, and then take the nth-root of them individually, before
combining them into the final result. Here's an example from my test suite.
I can take the geometric mean of:
[2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990]
and get to within a relative error of 1e-14 of the correct answer, 2**950:
py> geometric_mean([2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990])
9.516908214257811e+285
py> 2.0**950
9.516908214257812e+285
Here's one that's exact:
py> geometric_mean([2e300, 4e300, 8e300, 16e300, 32e300])
8e+300
[1] I don't care what it's actually called :-)
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
On Fri, 15 Jul 2016 21:39:31 +1000, Steven D'Aprano wrote: > prod *= (m1*m2) Should be: prod = m1*m2 or: prod *= m1 (in the latter case, there's no point in decomposing prod). Of course, if the result overflows, it's going to overflow whether you use the naive approach or frexp(); in the latter case, it's the 2.0**scale which will overflow. One advantage of processing the scale separately is that you can use e.g. return ((int(prod * 2**53) * (2**(scale-53))) if scale >= 53 else prod * 2**scale) which will return a (long) integer if the exponent is such that the fractional bits are lost. -- https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano wrote: > If the result is too big to be represented as a float at the end of the > product, then of course it will overflow. But this can give some protection > against overflow of intermediate values. Consider multiplying: > > 2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0 > > > Mathematically, the answer should be 6. In principle, by rescaling when > needed to prevent overflow (or underflow), product() should be able to get > something very close to 6, if not exactly 6. I was under the impression that appropriate reordering of the elements could prevent over/underflow and maximize accuracy, but that may be a mistaken memory. However... > But I'm not actually writing a general product() function. I'm doing this > for geometric mean, so I return the scaling exponent and the mantissa[1] > separately, and then take the nth-root of them individually, before > combining them into the final result. ... this makes a lot of sense. In effect, I *think*, you're basically doing the multiplication on something rather larger than a 64-bit IEEE float, then taking the nth-root, and then combine them and convert back to float. Is this about right? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
On Fri, Jul 15, 2016, at 12:32, Steven D'Aprano wrote: > I can take the geometric mean of: > > [2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990] > > and get to within a relative error of 1e-14 of the correct answer, > 2**950: > > py> geometric_mean([2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990]) > 9.516908214257811e+285 > py> 2.0**950 > 9.516908214257812e+285 > > Here's one that's exact: > > py> geometric_mean([2e300, 4e300, 8e300, 16e300, 32e300]) > 8e+300 My own attempt gave an exact result for both test cases. from math import frexp as _frexp, ldexp def frexp(x): if type(x) is tuple: m, e1 = x m, e2 = _frexp(m) return m, e1 + e2 else: return _frexp(x) def _mul(a, b): ma, ea = frexp(a) mb, eb = frexp(b) return frexp((ma * mb, ea + eb)) def _product(values): return reduce(_mul, values) def geometric_mean(values): n = len(values) pm, pe = _product(values) me, re = divmod(pe, n) pm = ldexp(pm, re) return ldexp(pm**(1./n), me) -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
Chris Angelico : > I've never managed to get Mercurial's branching system into my head > (and then you have the people saying "don't use hg branches at all, > just use named tags" or somesuch), but the git branching system is > extremely simple. In fact, all of git is very simple. To anyone who is > having trouble with comprehending git, I strongly recommend this > video. It assumes you have a basic understanding of git commands (or > can pause the video and look up a git-hg Rosetta Stone), but you don't > need expert-level knowledge. In fact, it's aimed at people ages 4 and > up... I use git daily but don't really use branches, and need to ask a coworker about the branching commands. Also, reverting changes in git keeps baffling me (I need to check the source code of emacs' vc-mode to figure out how it's done). Anyway, all of this has reminded me that bitkeeper is now free. I've never tried it so let's see if it is everything Sun's Teamware was. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
Marko Rauhamaa : > Anyway, all of this has reminded me that bitkeeper is now free. I've > never tried it so let's see if it is everything Sun's Teamware was. Hm, ran into compilation trouble. Maybe I should wait till bk is available for Fedora. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: math.frexp
Steven D'Aprano writes: > But this can give some protection against overflow of intermediate > values. Might be simplest to just add the logarithms. Look up Kahan summation for how to do that while minimizing loss of precision. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote: > > On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote: >> >> How about “mantissa length”, then. That sufficiently neutral for you? > > That makes even less sense for integers. Perhaps you would prefer the more gender-neutral term “persontissa” ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Sat, Jul 16, 2016 at 9:35 AM, Lawrence D’Oliveiro wrote: > On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote: >> >> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote: >>> >>> How about “mantissa length”, then. That sufficiently neutral for you? >> >> That makes even less sense for integers. > > Perhaps you would prefer the more gender-neutral term “persontissa” ... I would laugh, but gender issues are extremely significand to a lot of people... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Thursday, July 14, 2016 at 5:24:50 AM UTC+5:30, Peter Otten wrote: > Lawrence D’Oliveiro wrote: > > And there are still those who think that Python’s lax acceptance of > > non-boolean values as booleans is a good idea... > > I don't think this particular problem serves as an argument for stricter > handling of boolean expressions because the fix I was going to apologise for the snark Then I see thats not my words; I said something along similar lines Doesn't mean python needs to change Just that suggesting that python's bool notion is straightforward is an unnecessary lie – especially to newbies. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On 07/15/2016 09:04 PM, Rustom Mody wrote: Just that suggesting that python's bool notion is straightforward is an unnecessary lie – especially to newbies. Python's boolean concept is as simple as it gets -- what is not straightforward about it? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On Thursday, June 30, 2016 at 10:52:50 PM UTC+5:30, Steven D'Aprano wrote: > Okay, if you think that automata cannot be empty, I'll accept that. In that > case, then I'll change my answer and say that __bool__ for automata should > simply return True. All automata should be truthy. > I am not sure with what tone of voice you are saying that If ... “return True” is about as good -- ie useful -- as (say) def __bool__(self): from random import random return int(2*random()) then I think we agree But then there is a well-established behavior pattern in python captured by the contexts that raise AttributeError/NameError/TypeError etc viz For things that are undefined we are told politely they are undefined IOW Why say something is useless and define it rather than just leave undefined something that is ill-defined. If on the other hand you are giving that “return True”as a serious useful definition? If both you and Chris tripped up on a right definition of an “empty” automaton and regex respectively, I believe it demonstrates that getting boolishness for an arbitrary type right is at least non-trivial. [FWIW My belief: In general its nonsensical] -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote: > On 07/15/2016 09:04 PM, Rustom Mody wrote: > > > Just that suggesting that python's bool notion is straightforward is an > > unnecessary lie – especially to newbies. > > Python's boolean concept is as simple as it gets -- what is not > straightforward about it? I thought the other thread "Operator precedence/boolean logic" demonstrated that. Ive added a further continuation there – where this topic is more relevant -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
From other thread: On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote: > On 07/15/2016 09:04 PM, Rustom Mody wrote: > > > Just that suggesting that python's bool notion is straightforward is an > > unnecessary lie – especially to newbies. > > Python's boolean concept is as simple as it gets -- what is not > straightforward about it? And to expand on my On Saturday, July 16, 2016 at 11:18:48 AM UTC+5:30, Rustom Mody wrote: > FWIW My belief: In general its nonsensical C's 0 is false; rest-of-universe is true is a mess Python increases the mess by making the false-y candidates also non-singleton This seems to work for container-like objects like lists,strings,sets, etc with None and 0 being somewhat elliptical analogues But when we allow __bool__ to be available for any and every thing and give it some implicit random definition, this is just plain nonsense. [What is the bool-nature -- aka Buddha-nature -- of graphs question remains yet answered] -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote: > > On 07/15/2016 09:04 PM, Rustom Mody wrote: > >> Just that suggesting that python's bool notion is straightforward is an >> unnecessary lie – especially to newbies. > > Python's boolean concept is as simple as it gets -- what is not > straightforward about it? The fact that it led to the aforementioned bug. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Sat, Jul 16, 2016 at 4:19 PM, Lawrence D’Oliveiro wrote: > On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote: >> >> On 07/15/2016 09:04 PM, Rustom Mody wrote: >> >>> Just that suggesting that python's bool notion is straightforward is an >>> unnecessary lie – especially to newbies. >> >> Python's boolean concept is as simple as it gets -- what is not >> straightforward about it? > > The fact that it led to the aforementioned bug. The difference between ints and floats can lead to bugs, too. Which one should we eliminate? Tuple augmented assignment can lead to extremely confusing bugs. Let's abolish augmented assignment. Or tuples? Operator precedence leads to bugs when people don't respect it. Eliminate it; all operators function at the same precedence, with middle-to-outside associativity (as popularized by the "if/else" ternary operator). There. Now we have a bug-free language. Tongue removed from cheek... The Python policy is a *lot* easier to work with than REXX's policy is. In REXX, if you put a value in an IF statement that isn't its canonical True or False (in its case, "1" and "0"), you get a run-time error. Python lets you use None, False, 0, etc, as falsey, and if you really want a comparison, you put it in there. How is this a problem? As demonstrated elsewhere, the problem isn't the boolification. The problem is that an 'if' was used where exception handling would have been far better. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
