SERVING THE QUANTITATIVE FINANCE COMMUNITY

  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 13
 
User avatar
list1
Posts: 1696
Joined: July 22nd, 2015, 2:12 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 21st, 2016, 9:52 pm

LOL!

Floats seem like the more treacherous type.  They pretend to be real but they aren't!  The big ones can't be added to the little ones.  The closer two floats are, the noisier the differences.  If you try to take one to infinity, it just stops.  They can't handle most of the rational numbers and they can't handle any of the irrational ones.
How do you distinguish between twin floats? No way.
Those least significant bits make a most significant difference, what?

Floats aren't even commutative!

a + (b+c) != (a+b)+c
This property in general is better to call associative of addition.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 21st, 2016, 9:53 pm

How do you distinguish between twin floats? No way.
Those least significant bits make a most significant difference, what?

Floats aren't even commutative!

a + (b+c) != (a+b)+c
This property in general is better to call associative of addition.
Right! Brain glithc!
 
User avatar
list1
Posts: 1696
Joined: July 22nd, 2015, 2:12 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 21st, 2016, 10:34 pm

Unfortunately, it is common for many people including me too.
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 21st, 2016, 10:58 pm

Unfortunately, it is common for many people including me too.
Triskaidekaphobia?
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
list1
Posts: 1696
Joined: July 22nd, 2015, 2:12 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 22nd, 2016, 2:26 am

No,  I think excessive pressure of excessive knowledge 
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 22nd, 2016, 2:44 pm

No,  I think excessive pressure of excessive knowledge 
Over-abstraction?
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

December 22nd, 2016, 3:10 pm

No,  I think excessive pressure of excessive knowledge 
Over-abstraction?
Under-abstraction!

(The more cross-linked the knowledge, the greater the constraints on that piece of knowledge, and the less DOF to mis-remember it.)
 
User avatar
ISayMoo
Posts: 2368
Joined: September 30th, 2015, 8:30 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 11:50 am

Author says:
Was simpler than this:

    stuff = [ x for x in xs if condition(x) ]
But everybody knows that it should be
stuff = filter(condition, xs)
No?
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 4:20 pm

Author says:
Was simpler than this:

    stuff = [ x for x in xs if condition(x) ]
But everybody knows that it should be
stuff = filter(condition, xs)
No?
Depends if you are a little or Big Endian. 
How long will it take for languages to emerge ..

Quants would be much happier doing this
integer i, n, sum

     sum = 0
     do 10 i = 1, n
        sum = sum + i
        write(*,*) 'i =', i
        write(*,*) 'sum =', sum
 10  continue
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
katastrofa
Posts: 9665
Joined: August 16th, 2007, 5:36 am
Location: Alpha Centauri

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 4:25 pm

Author says:
Was simpler than this:

    stuff = [ x for x in xs if condition(x) ]
But everybody knows that it should be
stuff = filter(condition, xs)
No?
boost::filter_iterator
std::copy_if
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 4:44 pm

The functional style is elegant (e.g. iterators) but not suitable for numerical analysis  where you want/need explicit indexes in many cases.

It is a Procrustean bed.

Different strokes for different folks.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 5:27 pm

The functional style is elegant (e.g. iterators) but not suitable for numerical analysis  where you want/need explicit indexes in many cases.

It is a Procrustean bed.
You'd be surprised how often an elegant functional form can found. After a while of working that way, it becomes entirely natural and loops seem like brute force hacks.

Maybe it's a mindset difference like that with pure math versus engineering math?
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 6:39 pm

The functional style is elegant (e.g. iterators) but not suitable for numerical analysis  where you want/need explicit indexes in many cases.

It is a Procrustean bed.
You'd be surprised how often an elegant functional form can found.  After a while of working that way, it becomes entirely natural and loops seem like brute force hacks.

Maybe it's a mindset difference like that with pure math versus engineering math?
Nothing surprises me, anymore.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 13th, 2017, 7:10 pm

The functional style is elegant (e.g. iterators) but not suitable for numerical analysis  where you want/need explicit indexes in many cases.

It is a Procrustean bed.
You'd be surprised how often an elegant functional form can found.  After a while of working that way, it becomes entirely natural and loops seem like brute force hacks.

Maybe it's a mindset difference like that with pure math versus engineering math?
Nothing surprises me, anymore.
What about the Spanish Inquisition!?!?!!??
 
User avatar
Cuchulainn
Posts: 63205
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

January 14th, 2017, 10:58 am

The principle of linguistic relativity holds that the structure of a language affects its speakers' world view or cognition. Popularly known as the Sapir–Whorf hypothesis, or Whorfianism, the principle is often defined to include two versions. The strong version says that language determines thought, and that linguistic categories limit and determine cognitive categories, whereas the weak version says that linguistic categories and usage only influence thought and decisions.

I suppose we can translate as: give someone a hammer and everything becomes a nail. So after years working with a particular programming style everything begins to look the same. i.e. each new problem will be 'fitted' to that style. i.e. Spanish Inquisition style.

The answer is to use a style based on the requirements of the problem and needs of the organisation and not on the whims/preferences of the developer.

Some loopies and algies even get married!
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On