012 == 10

Of course it does.

What say we deprecate leading zero octal along with 1.f and 3. ? Robin
Stocker points out in the github commit comments that python did it:
since they have summarized why, I will refer you to their PEP.

http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.

Re: 012 == 10

Ugh, this legacy just bit me today.  

Re: 012 == 10

On Fri, Nov 11, 2011 at 9:04 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.

sigh, for me it was Pepsipcola 

Re: 012 == 10

On Fri, Nov 11, 2011 at 12:04, Paul Phillips wrote:
> Of course it does.
>
> What say we deprecate leading zero octal along with 1.f and 3. ? Robin
> Stocker points out in the github commit comments that python did it:
> since they have summarized why, I will refer you to their PEP.
>
>  http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
>
> Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.

I completely agree. I'd much rather have stuff like embedded
underscores in numeric literals than the octal notation and numeric
literals ending with dot. I'd get rid of numeric literals starting
with dot too -- people will write 40-letters-long identifiers but save
one characters in three-characters numbers.

Re: 012 == 10

How could any real programmer need more than six characters?  These people must be quiche eaters...

with dot too -- people will write 40-letters-long identifiers but save
one characters in three-characters numbers.


--
Daniel C. Sobral

I travel to the future all the time.

Re: 012 == 10

On Fri, Nov 11, 2011 at 23:45, Erik Engbrecht wrote:
> How could any real programmer need more than six characters?  These people
> must be quiche eaters...

Who said anything about real programmers? MMS Forth only recognized
the first three letters, and people were happy enough with that. MUMPS
was usually happy with a single letter, though some commands required
two. And, of course, APL proves a single character is sufficient.

But if you are going to the trouble of using a language that requires
12 lines to encapsulate a value, it would be petty to save on
identifier length. And pettier to save on number length. :-)

>
>> with dot too -- people will write 40-letters-long identifiers but save
>> one characters in three-characters numbers.
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>

Re: 012 == 10

On Fri, Nov 11, 2011 at 10:58 AM, Daniel Sobral wrote:
> I'd get rid of numeric literals starting
> with dot too -- people will write 40-letters-long identifiers but save
> one characters in three-characters numbers.

Hmm, I hadn't thought of doing that. I sort of agree, but a little
analysis of my neighborhood collection of repos convinces me it's off
the table. Especially this:

val die = new DenseProportions(List(.1, .2, .3, .2, .2))

I know if I had to sprinkle 0s over that line because some overly
enthusiastic deprecator had deemed it necessary on general principles,
I would at the very least do some muttering.

).apply(.753) must be_==(.753)
).apply(.753) must be_==(5)
+ .5 * (math.log(sigma2) + normPiece));
+ .5 / (sigma2));
.5 * (1 + erf((x - mu) / sqrt2 / sigma));
alam = math.max(tmplam,.1 * alam)
assert((beta(0) - .1878).abs < 1E-3, beta)
assertClose(a dot b, .90249);
assertClose(a.t * b, .90249);
def cdf(x: Double) = .5 * (1 + erf( (x - mu)/sqrt2 / sigma));
def entropy = .5 * math.log(2 * math.Pi * variance);
def entropy = log(sigma) + .5 * log1p(log(math.Pi * 2));
if (disc < 0.0) tmplam =.5 * alam
if (tmplam > .5 * alam) tmplam =.5 * alam
if(!occupied(pos) && load >= index.size * .75) {
if(Rand.uniform.get < .5) {
lazy val defaultInitWeights = Counter(featureIndex.map{ f =>
(f,initialValueForFeature(f) + math.log(.02 * math.random + 0.99))});
regularization: Double=.1,
result = x*(y - 1) - y*0.5 + .9189385332046727417803297;
s += ds * (.99 * scaleXF)
std <- arbitrary[Double].map {x => math.abs(x) % 8.0 + .1}) yield new
Gaussian(mean,std);
std <- arbitrary[Double].map{x => math.abs(x) % 8.0 + .1}
tmplam =.2 * alam
val die = new DenseProportions(List(.1, .2, .3, .2, .2))
val mag = 1 - gamma(.5,x*x)/sqrt(Pi);
val startingA = .5 / ( math.log(stats.mean) - stats.meanOfLogs)
val stdev = Math.pow(variance,.5)
val x0 = DenseVector(.2,.2);
val z = ((_: Double) + .5) :: ( (_: Char).isUpper) :: HNil
while((x + dx*alpha).valuesIterator.exists(_ < 0)) alpha *= .8;
x += dx * (.99 * scaleXF)
z += dz * (.99 * scaleZF)

Re: 012 == 10

On Nov 11, 1:41 pm, Paul Phillips wrote:
> On Fri, Nov 11, 2011 at 10:58 AM, Daniel Sobral wrote:
> > I'd get rid of numeric literals starting
> > with dot too -- people will write 40-letters-long identifiers but save
> > one characters in three-characters numbers.
>
> Hmm, I hadn't thought of doing that.  I sort of agree, but a little
> analysis of my neighborhood collection of repos convinces me it's off
> the table.  Especially this:
>
>   val die = new DenseProportions(List(.1, .2, .3, .2, .2))
>

I second this. Whenever I need a simple command line calculator I
always use the Python interpreter over the Ruby one, and one of the
main reasons for this is that Python allows float literals that start
with a '.' while Ruby requires you to put a 0 up front. It's seems
like it would be a minor thing, but I find it very annoying in Ruby.
If the parser can unambiguously handle floats with no leading 0, then
consider that a strength!

Re: 012 == 10

Well... identifiers can't start with a digit, so I suppose is unnecessary.

On Fri, Nov 11, 2011 at 17:41, Paul Phillips wrote:
> On Fri, Nov 11, 2011 at 10:58 AM, Daniel Sobral wrote:
>> I'd get rid of numeric literals starting
>> with dot too -- people will write 40-letters-long identifiers but save
>> one characters in three-characters numbers.
>
> Hmm, I hadn't thought of doing that.  I sort of agree, but a little
> analysis of my neighborhood collection of repos convinces me it's off
> the table.  Especially this:
>
>  val die = new DenseProportions(List(.1, .2, .3, .2, .2))
>
> I know if I had to sprinkle 0s over that line because some overly
> enthusiastic deprecator had deemed it necessary on general principles,
> I would at the very least do some muttering.
>
>
> ).apply(.753) must be_==(.753)
> ).apply(.753) must be_==(5)
> + .5 * (math.log(sigma2) + normPiece));
> + .5 / (sigma2));
> .5 * (1 + erf((x - mu) / sqrt2 / sigma));
> alam = math.max(tmplam,.1 * alam)
> assert((beta(0) - .1878).abs < 1E-3, beta)
> assertClose(a dot b, .90249);
> assertClose(a.t * b, .90249);
> def cdf(x: Double) = .5 * (1 + erf( (x - mu)/sqrt2 / sigma));
> def entropy = .5 * math.log(2 * math.Pi * variance);
> def entropy = log(sigma) + .5 * log1p(log(math.Pi * 2));
> if (disc < 0.0) tmplam =.5 * alam
> if (tmplam > .5 * alam) tmplam =.5 * alam
> if(!occupied(pos) && load >= index.size * .75) {
> if(Rand.uniform.get < .5) {
> lazy val defaultInitWeights = Counter(featureIndex.map{ f =>
> (f,initialValueForFeature(f) + math.log(.02 * math.random + 0.99))});
> regularization: Double=.1,
> result = x*(y - 1) - y*0.5 + .9189385332046727417803297;
> s += ds * (.99 * scaleXF)
> std <- arbitrary[Double].map {x => math.abs(x) % 8.0 + .1}) yield new
> Gaussian(mean,std);
> std <- arbitrary[Double].map{x => math.abs(x) % 8.0 + .1}
> tmplam =.2 * alam
> val die = new DenseProportions(List(.1, .2, .3, .2, .2))
> val mag = 1 - gamma(.5,x*x)/sqrt(Pi);
> val startingA = .5 / ( math.log(stats.mean) - stats.meanOfLogs)
> val stdev = Math.pow(variance,.5)
> val x0 = DenseVector(.2,.2);
> val z = ((_: Double) + .5) :: ( (_: Char).isUpper) :: HNil
> while((x + dx*alpha).valuesIterator.exists(_ < 0)) alpha *= .8;
> x += dx * (.99 * scaleXF)
> z += dz * (.99 * scaleZF)
>

Re: 012 == 10

If you take that further, one could consider `3.14` as a specialized instance of `3: Int` calling `def 14: Double`,or say a syntax sugar of `3.decimal(14)`, which then could be applied to `n.5` and `Seq(x, y, z) map {_.5}` on arbitrary class that implements `def decimal(d: Int)`.
-eugene

On Friday, November 11, 2011 2:41:45 PM UTC-5, Paul Phillips wrote:
On Fri, Nov 11, 2011 at 10:58 AM, Daniel Sobral <dcso [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> I'd get rid of numeric literals starting
> with dot too -- people will write 40-letters-long identifiers but save
> one characters in three-characters numbers.

Re: 012 == 10

On Fri, Nov 11, 2011 at 06:04:36AM -0800, Paul Phillips wrote:
> What say we deprecate leading zero octal along with 1.f and 3.

Agreed!

Glad you looked into how Python resolved this--I think they get a lot
of things right with their numeric types.

Re: 012 == 10

As long as I can still embed 0xDEADC0DE bits randomly throughout RAM, I'll be a happy C++ developer....
On Fri, Nov 11, 2011 at 9:04 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Of course it does.

What say we deprecate leading zero octal along with 1.f and 3. ? Robin
Stocker points out in the github commit comments that python did it:
since they have summarized why, I will refer you to their PEP.

 http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.

Re: 012 == 10

I agree. As mentioned on the other thread it would be nice to see binary literals and/or literal separators too, but I guess that needs much more lobbying.

Re: 012 == 10



On Fri, Nov 11, 2011 at 3:04 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Of course it does.

What say we deprecate leading zero octal along with 1.f and 3. ?

+1
 
 Robin
Stocker points out in the github commit comments that python did it:
since they have summarized why, I will refer you to their PEP.

 http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Re: 012 == 10

Get's my vote. I was once bitten by octal syntax in Java, so now I'm twice shy.

On Fri, Nov 11, 2011 at 8:04 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Of course it does.

What say we deprecate leading zero octal along with 1.f and 3. ? Robin
Stocker points out in the github commit comments that python did it:
since they have summarized why, I will refer you to their PEP.

 http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Too bad that the first word that comes to mind when PEP meets SIP is dyspepsia.

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland