#include < iostream >
template< class T >
T func1(T t) { return t; }
auto func2(auto t) { return t; }
int main() {
std::cout << func1(1) << func1(2.2) << func2(3) << func2(4.4);
}
autoauto.cpp:6:18: note: deduced return type only available with -std=c++1y or -std=gnu++1y
g++ --std=c++14 autoauto.cpp ./a.out 12.234.4
Jo en Bug. So assigment subroutine und gfort 4.8 4.9. Vllt geht es in 5.0 ja wieder.
Als ich gestern etwas mit OpenCV gearbeitet habe, bin ich auf eine
interesannte Seite gestossen [1] . Es wird dort von normailsierten RGB
geredet. Dabei wird getrennt für jeden Kanal, der Pixelwert durch die
Summe des Pixels über alle 3 Kanäle geteilt.
R’ = R/(R+G+B)
G’ = G/(R+G+B)
B’ = B/(R+G+B)
Dabei geht die Lichtinformation im Bild verloren. Ich finde das eine
interesannte Ausgangslage für weitere Berechnungen. Oft ist doch nur die
Farbe einzelner Objekte wichtig, nicht aber wie sie beleuchtet wurden.
Es sind nur noch 2 Byte pro Pixel, statt 3 Byte, notwenig.
R' + G' + B'=1
B' = 1 - R' - G'
Ein Angabe von 2 der 3 Werte ist also hinreichend. Damit kann der Farbort
charakterisiert werden, nicht aber die absolute Intensit¨t des Farbreizes. Das
heißt die Länge des Farbvektors wird nicht angegeben.
[1] http://www.aishack.in/tutorials/normalized-rgb/
#include
#define CACHE 256
enum { h_unknown = 0, h_yes, h_no };
unsigned char buf[CACHE] = {0, h_yes, 0};
int happy(int n)
{
int sum = 0, x, nn;
if (n < CACHE) {
if (buf[n]) return 2 - buf[n];
buf[n] = h_no;
}
for (nn = n; nn; nn /= 10) x = nn % 10, sum += x * x;
x = happy(sum);
if (n < CACHE) buf[n] = 2 - x;
return x;
}
int main()
{
int i, cnt = 8;
for (i = 1; cnt || !printf("\n"); i++)
if (happy(i)) --cnt, printf("%d ", i);
printf("The %dth happy number: ", cnt = 1000000);
for (i = 1; cnt; i++)
if (happy(i)) --cnt || printf("%d\n", i);
return 0;
}
from http://rosettacode.org/wiki/Happy_numbers#C
This is a short of http://www.stroustrup.com/Myths-final.pdf
Myth 1: “To understand C++, you must first learn C”
C is almost a subset of C++, but it is not the best subset to learn first because C lacks the notational
support, the type safety, and the easier-to-use standard library offered by C++ to simplify simple tasks.
Consider a trivial function to compose an email address:
Busted!
Myth 2: “C++ is an Object-Oriented Language”
3. Myth 2: “C++ is an Object-Oriented Language”
C++ supports OOP and other programming styles, but is deliberately not limited to any narrow view
of “Object Oriented.” It supports a synthesis of programming techniques including object-oriented and
generic programming. More often than not, the best solution to a problem involves more than one style
(“paradigm”). By “best,” I mean shortest, most comprehensible, most efficient, most maintainable, etc.
Busted!
Myth 3: “For reliable software, you need Garbage Collection”
In short:
Never use new or delete. Use some classes which does the memory management for you, e.g. std::vector. For short living object, create them on the stack, Instead on the heap with new. Use destructor to clean up memory (and other resources like file handles) if the lifetime of an object comes to an end.
If you have to pass an object around, don't use raw pointer. If it is possible, don't use pointer at all. If there exist only one owner at a time, use the move magic with rvalue reverences. If the object is shared by more than one owner, use std::shared_pointer to store a pointer. It implements a reference counting and deletes the object of nobody owns them anymore. Use auto and make_shared<> for syntactic sugar.
Naked deletes are dangerous – and unnecessary in general/user code. Leave deletes
inside resource management classes, such as string, ostream, thread, unique_ptr, and shared_ptr.
For resource management, I consider garbage collection a last choice, rather than “the solution” or an ideal:
1.Use appropriate abstractions that recursively and implicitly handle their own resources. Prefer such objects to be scoped variables.
2. When you need pointer/reference semantics, use “smart pointers” such as unique_ptr and
shared_ptr to represent ownership.
3. If everything else fails (e.g., because your code is part of a program using a mess of pointers
without a language supported strategy for resource management and error handling), try to
handle non-memory resources “by hand” and plug in a conservative garbage collector to handle
the almost inevitable memory leaks.
Busted!
Myth 4: “For efficiency, you must write low-level code”
I have seen sort run 10 times faster than qsort. How come? The C++ standard-library sort is
clearly at a higher level than qsort as well as more general and flexible. It is type safe and parameterized
over the storage type, element type, and sorting criteria. There isn’t a pointer, cast, size, or a byte in
sight. The C++ standard library STL, of which sort is a part, tries very hard not to throw away information. This makes for excellent inlining and good optimizations.
Generality and high-level code can beat low-level code. It doesn’t always, of course, but the sort/qsort comparison is not an isolated example. Always start out with a higher-level, precise, and type safe version of the solution. Optimize (only) if needed.
Busted!
Myth 5: “C++ is for large, complicated, programs only”
C++ is a big language. The size of its definition is very similar to those of C# and Java. But that does not
imply that you have to know every detail to use it or use every feature directly in every program.
After all, C++ is designed for flexibility and generality, but not every
program has to be a complete library or application framework.
Busted!
Read the paper for detailed examples.
Busted!!
Whats the difference between between save, static, global, local and parameter variables?
Save and static are two words for the same thing.
I found a nice definition of what save do in the Fortran 77 Standard [1]
Within a function or subroutine subprogram, an entity specified by a SAVE statement does not become undefined as a result of the execution of a RETURN or END statement in the subprogram
subroutine func()
implicit none
real, save :: time
time = time + 1
write(*,*) time
end subroutine
program test
implicit none
integer :: i
do i = 1, 10
call func()
end do
end
1.00000000
2.00000000
3.00000000
4.00000000
5.00000000
6.00000000
7.00000000
8.00000000
9.00000000
10.0000000
You can count how often a subroutine is called. If you ever want to do this... I can not recommend to do it in this way.
As you may have noticed, I have not initialized the time variable with an start value.
You can do this with the data instruction.
subroutine func()
implicit none
real :: time
data time/100/
time = time + 1
write(*,*) time
end subroutine
101.000000
102.000000
103.000000
104.000000
105.000000
106.000000
107.000000
108.000000
109.000000
110.000000
The save specifier is not needed by using the data keyword.
This may result in confusion, because not everybody knows exactly what the data specifier does.
Again: do not use it.
The greatest pitfall with static variables is this:
real :: time = 0
If you initialize a variable by the declaration, it become a static variable! That really really hurts. You want be a good programer and always zero your variables and then you crash the hole program :D
Lets talk about parameters. Many programmers declare they constans with the save attribute.
I can not recommend this.
First: Constants does not change. Variables with save attribute can change.
real, save :: PI = 3.14...
PI = 4
All fine ;)
If you use parameter instead of save the compiler can detect this issue.
real, parameter :: PI = 3.14...
PI = 4
PI = 4
1
Error: Named constant 'pi' in variable definition context (assignment) at (1)
Second: Fortran is a high performance language. You can easily vectorize assigments using the forall constrcut.
All functions called from the forall constrcut must be declared as pure. to ensure that they have no side effects.
function func() result(val)
implicit none
real, save :: PI = 3.14
real :: val
val = PI
end function
forall( i = 1:100 ) A(i) = func()
forall( i = 1:100 ) A(i) = func()
1
Error: Reference to non-PURE function 'func' at (1) inside a FORALL block
And a pure function can not have static variables
pure function func() result(val)
implicit none
real, save :: PI = 3.14
real :: val
val = PI
end function
real, save :: PI = 3.14
1
Error: SAVE attribute at (1) cannot be specified in a PURE procedure
Using parameter solves the issue
pure function func() result(val)
implicit none
real, parameter :: PI = 3.14
real :: val
val = PI
end function
forall( i = 1:100 ) A(i) = func()
$ ifort -O2 -c save.f90 -vec-report3
save.f90(19): (col. 25) remark: LOOP WAS VECTORIZED
The last thing I talk about are global variables.
They can be accessed and overwritten from everywhere by everyone anytime. Happy bug chasing...
One way to create global variables in Fortran is using the COMMON keyword. I allready wrote about that..
[1] http://www.fortran.com/fortran/F77_std/rjcnf-8.html#sh-8.9
Here is my way to supress the "unused dummy argument" warning. I'm searched a long time but did not find a solution which works on any compiler and newer fortran standard.
In C/C++ it is very easy. Just write (void)variable; But this just trigger an "Unclassifiable statement" error.
#define UNUSED(x) if(size( (/(x)/) ) < 0) continue
program main
implicit none
type testtype
integer :: x
end type
type(testtype) :: x
type(testtype), pointer :: y => null()
integer :: z
UNUSED(x)
UNUSED(y)
UNUSED(z)
end program
$ gfortran -Wall -Wextra -fcheck=all -g test.F90 $ ./a.out $
hf
Ja wirklich. Windows ist fürn Arsch. Und nicht erst seit heute. Diese Erfahrung mach ich jetzt schon seit 15 Jahren. Immer wieder.
Typisches Scenario:
Man wacht morgens auf und schaltet das Laptop ein. "Piiieep Pip Pip", schwarzer Bildschirm. Laptop kaputt (Nvidia Bug (google it!)). Wurde schon einmal repariert. Jetzt endgültig gestorben.
Und wie es Murphy will, muss man ganz dringed weiter arbeiten, denn der Abgabetermin ist bald. Ach kein Problem, wir bauen die Festpatte einfach in den großen Rechner ein und kaufen bei Gelegeheit ein neues Laptop.
Festplatte ausbauen geht dank Levono in 30 Sekunden und einbauen geht genauso schnell.
Anschalt:
Bios Screen, Window Logo, *reboot.
Biso Screen, Windows reparieren - ja, 15min warten *reboot*
Bios Screen, Window Logo, *reboot.
Biso Screen, Windows reparieren - ja, 30min!! warten *reboot*
Bios Screen, Window Logo, *reboot.
Biso Screen, Windows reparieren - NEIN! Normal starten, bitte, endlich, bitte!
Bios Screen, Window Logo, *reboot.
Biso Screen, Windows reparieren - ja, keine Ahnung wie lange, bin weg gegangen...
"Ihr Windows konnte nicht repariert werden" Wenden sie sich an ein Admin der eine Neuinstallation macht...
Bei den manuellen Reperaturoptionen ist mir aufgefallen, dass die Festplatte als D: erkannt wurde und nicht C: AAAh HA! Es ist ja bekannt, dass sich Windows selbst umbringt wenn es nicht von C: aus startet. Also DVD Laufwerk abgestöpselt und (nach 3 weiteren Fehlversuchen) im Bios von IDE nach AHCI umgestellt und siehe da, es bootet.
Naja, nach weiteren fümf Minuten.
Ok, fassen wir zusammen. Um 9Uhr habe ich angefangen. Jetzt ist 11Uhr. Macht zwei Stunden. Jetzt fehlt nur noch der neue Grafikkartentreiber...
Und unter Linux? Denk es euch. Eine Minute um die Festplatte zu wechseln und auch evtl. den Grafikkartenteriber neu installieren.
Also Windows ist fürn Arsch, und das schreib ich bestimmt alle 2 Jahre. Ich sollte meine älteren Posts mal ausgraben...
Sehr nette Idee. Müsste man nur noch herausfinden wie man diese Cluster erkennt.
SOME ASPECTS OF PATTERN RECOGNITION BY COMPUTER
by ADOLFO GUZMAN-ARENAS
B.S., Instituto Politecnico Nacional (Mexico), 1965;
"The alpha-Lambda transformation.
The following scheme is useful in detecting undesired lines when dealing with rectliniear bodies. Given an array containing elementary segments (a small number of points plus a direction associated to them), as indicate in figure 'LITTE SEGMENTS', as we associate with each segment a pair of numbers, alpha is the angle that this segment forms with the x-axis, and lambda if the distance of the (extended) line from the origin.
That is to say, we convert the figure to an array of points (see figure 'CLUSTERING'). In the alpha-lambda space, points which fall close together are over the same line, so that frequency count will eliminate the spurious segments, as desired. Clouds with the same alpha are parallel lines, and this fact could be used in order to look for parallel lines.
Smooth curved lines could also be detected by this method, if we use a fancier criteria for the detection of clusters (1).
(1) Work in the area is:
1. Evan L. Ivie. PhD Thesis [18].
2. Probably a conventional pattern clasifier will do it. See N. J. Nilsson [26].
[18] Ivie, E. L., Search Procedures based on Measure of Relatedness Between Documents, Project MAC Technical Report MAC-TR-29 (M.I.T. Ph.D. Thesis), June 1966.
[26] Nilsson, N.J., Learning Machines, McGraw Hill, 1965."
Powered by WordPress