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 int
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
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 la
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
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 talk
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
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,
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 a
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():
>
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
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
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 conventio
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
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
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
>> every
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://e
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 as
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
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
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 righ
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 e
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
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
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*
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
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
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
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 te
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 sens
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 strict
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/
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 sur
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 -- wh
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 si
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
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 new
36 matches
Mail list logo
