For usenet. (N) = 1000.
Please give your working out.
And more importantly the number of calculations you use.
The winner gets to kiss my ass, when I present mine.
Algorithm:
1) Open URL: <http://primes.utm.edu/lists/small/1000.txt>
2) There they are!
> Please give your working out.
See above.
> And more importantly the number of calculations you use.
No calculations were performed.
> The winner gets to kiss my ass, when I present mine.
No thanks.
So you think you can calculate, without calculating?
Oh, O.K, next.
MatLab has a pretty cool algorithm. Roughly speaking it is:
1) They create an array of integers from 1 to N.
2) For each integer, i, from 2 to root-N (I think), they "zero" every
i-th element.
3) What's left over are the prime numbers.
Pretty cool!
Dwib
In the Sieve of Erastothenes the second step is
2) For each prime number (i.e.number not struck out by previous passes)
from 2 to root(N).
Wikipedia gives a more efficient algorithm - the Sieve of Atkin.
>
>Pretty cool!
>
>Dwib
>
--
alias Ernest Major
doh!
Isn't that the Sieve of Erastothenes - or something very close to it?
>
> Dwib
>
Unspecified requirement. lol
Isn't that always the way? You spend the time and effort to provide a
solution to the stated problem, only to find that you weren't given
all of the requirements up front. Damned scope creep.
Yes. It has only been known for 2200+ years. now, so spinny probably
never heard of it.
Sorry, but you won, you have to.
I think he just wanted to trick you into kissing him on the ass.
Well, pucker up.
Am I correct in thinking that for PI(1000) this takes 301 calculations?
The old "ass kiss" trick... Doesn't this group have the "designated
kisser" rule? Please?
You didn't say you wanted a calculation, you said you wanted
an algorithm. He provided one. (Perhaps you're a bit vague
on the meaning of "algorithm"?)
>Oh, O.K, next.
--
Bob C.
"Evidence confirming an observation is
evidence that the observation is wrong."
- McNameless
You can't read.
> you said you wanted an algorithm.
Yes.
> He provided one.
No.
> (Perhaps you're a bit vague on the meaning of "algorithm"?)
I know it doesn't mean "list".
algorithm: A finite set of unambiguous instructions performed in a
prescribed sequence to achieve a goal, especially a mathematical rule or
procedure used to compute a desired result. Algorithms are the basis for
most computer programming. (The American Heritage Science Dictionary)
What I provided was a finite set of unambiguous instructions performed
in a prescribed sequence to achieve a goal. It's clear that you wanted a
mathematical rule or procedure, but that isn't what you asked for. You
have no one else to blame for your own use of imprecise language.
>> > > The winner gets to kiss my ass, when I present mine.
>>
>> > No thanks.
>>
>> Sorry, but you won, you have to.
>>
>> I think he just wanted to trick you into kissing him on the ass.
>> Well, pucker up.
>
>The old "ass kiss" trick... Doesn't this group have the "designated
>kisser" rule? Please?
http://www.youtube.com/watch?v=fDp7pkEcJVQ
--
You will not swear by my name with intent to deceive
and thus profane the name of your God. I am Yahweh.
(Lev. 19:12)
Congratulations on finding the fastest algorithm in the world for
calculating PI(x).
When do you publish?
All hail the new math-genius/boon-head.
Idiot, you did NOT ask for the fastest algorithm to calculate the
function you describe. You DID ask for the fastest algorithm to FIND
all primes below the specified value of 1000. The fastest way is
1: Enter into your Google search field:
"primes under 1000"
2: Click "I'm feeling lucky"
Another Boon-head.
Quote "Quickest algorithm to find all primes below (N). "
It's called a "prime counting function" or PI(x).
Hitting google doesn't cut it. (Unless your a BOON-HEAD).
Oh, You are!
Not quite.
> > >> >>>>> Quickest algorithm to find all primes below (N).
> > >> >>>>> For usenet. (N) = 1000.
The algorithm you were given was correct. It's running time is O(1).
>
> It's called a "prime counting function" or PI(x).
That's not what you asked for, though.
>
> Hitting google doesn't cut it. (Unless your a BOON-HEAD).
Six months in the lab will save you six hours in the library.
>
> Oh, You are!
David
Apart from that, your question, like your original post to this thread,
is ill-posed. The number of calculations is implementation dependent; it
also depends on what is defined as a calculation. (How many calculations
did you assign to the calculation of floor(root(1000))?)
Also, why did you pick such a tidgy number for measurement of speed? -
an algorithm that is faster for PI(1000) might be left behind in the
dust for PI(1000000000).
--
alias Ernest Major
n / log log n = 301
> Also, why did you pick such a tidgy number for measurement of speed? -
> an algorithm that is faster for PI(1000) might be left behind in the
> dust for PI(1000000000).
I know of no such prime counting function.
I picked a small number, so the workin out doesnt have to be pages
long.
You ought to check your assumptions as well. Wikipedia says that the
Sieve of Atkins uses O(N/log log N) calculations. That means that in the
asymptotic limit the number of calculations is proportional to N/log log
N. The constant of proportionality is not 1.
>
>
>
>> Also, why did you pick such a tidgy number for measurement of speed? -
>> an algorithm that is faster for PI(1000) might be left behind in the
>> dust for PI(1000000000).
>
>I know of no such prime counting function.
You see why your claims of intelligence and erudition don't garner much
credence?
You could look through the archives of sci.math, and the discussions of
James Harris's prime counting function. You might learn something,
provided your apply suitable skepticism to Mr. Harris's contributions.
>I picked a small number, so the workin out doesnt have to be pages
>long.
>
Are you suggesting that the algorithms be executed by hand?
--
alias Ernest Major
There is also the problem of an additive constant. The value might be
something like 10000000000000000000 + 1000000000*N/log log N which is
still O(N/log log N).
Nothin wrong with it. It's an computer algorithm using a base 2
logarithm.
n / log_2 log_2 n = 301
If it isn't, then 2095 calculations is pretty steep, and my algorithm
is better
than I thought.
> >> Also, why did you pick such a tidgy number for measurement of speed? -
> >> an algorithm that is faster for PI(1000) might be left behind in the
> >> dust for PI(1000000000).
>
> >I know of no such prime counting function.
>
> You see why your claims of intelligence and erudition don't garner much
> credence?
>
> You could look through the archives of sci.math, and the discussions of
> James Harris's prime counting function. You might learn something,
> provided your apply suitable skepticism to Mr. Harris's contributions.
All I read was that he was a loon ball. Could you provide a link to
(the
/ his) actual function?
> >I picked a small number, so the workin out doesnt have to be pages
> >long.
>
> Are you suggesting that the algorithms be executed by hand?
Yes.
No, he doesn't. You should see the contortions he went through trying
to argue that the Earth has one pole.
Thanks john.
Anyway. Back yo PI(x).
>On Oct 8, 11:46 pm, Bob Casanova <nos...@buzz.off> wrote:
>> On Wed, 8 Oct 2008 09:48:17 -0700 (PDT), the following
>> appeared in talk.origins, posted by spintronic
>> <spintro...@hotmail.com>:
>>
>>
>>
>>
>>
>> >On Oct 8, 5:43 pm, Caranx latus <kar...@sympatico.ca> wrote:
>> >> On Oct 8, 12:33 pm, spintronic <spintro...@hotmail.com> wrote:
>>
>> >> > Quickest algorithm to find all primes below (N).
>>
>> >> > For usenet. (N) = 1000.
>>
>> >> Algorithm:
>> >> 1) Open URL: <http://primes.utm.edu/lists/small/1000.txt>
>> >> 2) There they are!
>>
>> >> > Please give your working out.
>>
>> >> See above.
>>
>> >> > And more importantly the number of calculations you use.
>>
>> >> No calculations were performed.
>>
>> >> > The winner gets to kiss my ass, when I present mine.
>>
>> >> No thanks.
>>
>> >So you think you can calculate, without calculating?
>>
>> You didn't say you wanted a calculation,
>
>You can't read.
Really? Then the request for "Quickest algorithm to find all
primes below (N)" wasn't yours? Sure looks like it was...
>> you said you wanted an algorithm.
>Yes.
>> He provided one.
>No.
>> (Perhaps you're a bit vague on the meaning of "algorithm"?)
>I know it doesn't mean "list".
No, it means "set of instructions to perform a task", which
he gave you in two steps (although I would have phrased step
2 as "Read list"). In formal math it almost always refers to
a set of calculations, but that isn't a requirement for the
general term, and it's certainly not how it's used in
processor opcode instructions.
You didn't ask for "the fastest algorithm in the world for
calculating PI(x)", you asked for the "quickest algorithm to
find all primes below (N)". See the word "find"? Do you
suppose it might have a different meaning from "calculate"?
And BTW, where did you get the terminology "PI(x)" as
meaning "Primes below N"? I don't recognize it.
>When do you publish?
>
>All hail the new math-genius/boon-head.
>Do you ever admit it when you make a mistake
Hasn't happened yet (the admission, that is).
> or is this denial with insults
>sprinkled over it your invariable response to those who point out your
>errors?
That would be a "yes".
Am I winning?
> Hey, even mosquitos provide food for dragonflies. Gain a useful
> function.
What do you gain out of our symbiotic relationship?
Don't fight it. I am feeding on your brain cell as we speak.
Lol.
Funny. This whole thread is dedicated to that purpose.
> you asked for the "quickest algorithm to
> find all primes below (N)".
Same thing.
> See the word "find"?
And?
> Do you suppose it might have a different meaning from "calculate"?
Not when *find = calculate*.
As in when *dig = search*.
> And BTW, where did you get the terminology "PI(x)" as
> meaning "Primes below N"? I don't recognize it.
Thats because your thick.
Really? I could have sworn you asked for the "Quickest
algorithm to find all primes below (N)", which was provided.
>> you asked for the "quickest algorithm to
>> find all primes below (N)".
>Same thing.
Nope; an algorithm is not a function, it's a set of
instructions.
>> See the word "find"?
>And?
>> Do you suppose it might have a different meaning from "calculate"?
>Not when *find = calculate*.
Really? Then go calculate a rock to crawl under.
>As in when *dig = search*.
And other irrelevant comments...
>> And BTW, where did you get the terminology "PI(x)" as
>> meaning "Primes below N"? I don't recognize it.
>Thats because your thick.
No, it's because you don't know how to pose an unambiguous
question. And that's "you're".
> >> you asked for the "quickest algorithm to
> >> find all primes below (N)".
> >Same thing.
>
> Nope; an algorithm is not a function, it's a set of
> instructions.
Good for you.
Now that you perfectly understand the challenge perhaps
you could astound everyone on Talk Origin's and show
us, the fast "prime counting function" around.
Woops. Thought not. Never mind, you'll get over it.
> >> And BTW, where did you get the terminology "PI(x)" as
> >> meaning "Primes below N"? I don't recognize it.
> >Thats because your thick.
>
> No, it's because <snip>
No. It really *is* because you'r thick.
http://mathworld.wolfram.com/PrimeCountingFunction.html
QOUTE: "The prime counting function is the function PI(x).
The prime counting function is the function giving the number
of primes less than or equal to a given number x".
QUOTE: "The notation PI(n) for the prime counting function .."
>On Oct 10, 11:13 pm, Bob Casanova <nos...@buzz.off> wrote:
>> On Fri, 10 Oct 2008 10:34:21 -0700 (PDT), the following
[attributions missing]
[Me]
>> >> you asked for the "quickest algorithm to
>> >> find all primes below (N)".
[spinnie]
>> >Same thing.
>> Nope; an algorithm is not a function, it's a set of
>> instructions.
>Good for you.
Thanks; glad to see you finally admit an error.
<snip irrelevantia>
>> >Thats because your thick.
<snip spelling lesson>
>No. It really *is* because you'r thick.
*Almost* got it that time. Try adding an "e".
>http://mathworld.wolfram.com/PrimeCountingFunction.html
>
>QOUTE: "The prime counting function is the function PI(x).
>The prime counting function is the function giving the number
>of primes less than or equal to a given number x".
>
>QUOTE: "The notation PI(n) for the prime counting function .."
Thanks for the info. If you had asked for this (instead of
for an algorithm) you'd probably have a few answers by now.
> Now that you perfectly understand the challenge perhaps
> you could astound everyone on Talk Origin's and show
> us, the fast "prime counting function" around
<snip>
Thought not. Such a loser.
After that bit of flailing around, your citation lists which
algorithms are fastest.
http://mathworld.wolfram.com/PrimeCountingFunction.html
"The following table is taken from Riesel (1994), where O(x) is
asymptotic notation."
I have no hope whatsoever that you can understand the information
presented there.
That being said, the simplest algorithm for the original question you
posed, $\pi(1000)$, is still enumeration and it still runs in $O(1)$.
All of the other algorithms listed will also run in $O(1)$ for this
problem.
The reason why was covered in your undergraduate Algorithms class. I
hope you were able to drop it before the midterm.
> The prime counting function is the function giving the number
> of primes less than or equal to a given number x".
>
> QUOTE: "The notation PI(n) for the prime counting function .."
That's not particularly accurate. "pi(n)" would be acceptable, and $
\pi(n)$ would give us some reason to think you knew what you were
talking about. "Pi(n)" would have been completely wrong. "PI(n)"
just looks like you're not to be trusted around a C preprocessor.
Oh, you'd be suprised.
How does 17 calculations sound?
Yipty do.
\pi(1000)
Wack it in here.
http://www.forkosh.com/mimetex.html
Actually if you put $\pi(n)$
You get flaff all.
<snip>
> Oh, you'd be suprised.
>
> How does 17 calculations sound?
It sounds like you managed to drop undergrad Algorithms before the
midterm. Overall, I'd say that was a sound decision.
Algorithm performance is not measured in operations. See
_Introduction to Algorithms_ by Cormen, Leiserson, Rivest (yes, *that*
Rivest) and Stein. I have the 2nd edition, but since this is really
basic stuff any edition should work. You'll want chapter 3.
You should also know that algorithm implementation performance is also
not measured in terms of operations. Had you taken a compilers class,
you would have learned (among many other useful things) that one of
the most basic optimizations a compiler can perform is called "loop
unrolling" which will increase the size of the code (while decreasing
the number of instructions actually executed -- will wonders never
cease).
All that being said, the Intel architecture provides a single assembly
language instruction that solves the problem you've posed. So you're
only off by a factor of 17.
Works fine.
>
> Actually if you put $\pi(n)$
>
> You get flaff all.
Really? Works for me.
Then you miss out on a tremendous opportunity.
Never mind.
If you want dollar signs maybe. Most (all) don't.
The dollars signs put the TeX processor in math mode and are removed
from the output. If you wanted to leave the dollar signs in, try
escaping them as follows:
$\$\pi(n)\$
HTH,
Garamond
I think that's best.
Here is a gift. upto 1715.
May take you a while to work out.
In fact, quite a while.
It's beta. I have the final working product.
Enjoy.
#include <iostream>
#include <conio.h>
#include<math.h>
#include<time.h>
using namespace std;
/************************Place Function Calls Here!
**********************/
/*The Round Down Algorithm*/
unsigned int Rounddown(unsigned int rounddown)
{
unsigned int result;
unsigned int quot1,rem,odev;
div_t div_result;
div_result = div(rounddown,3);
quot1 = div_result.quot;
rem = div_result.rem;
div_result = div(quot1,2);
odev = div_result.rem;
/***********************************Even's************************/
if(odev == 0)
{
if(rem == 0)
{
quot1--;
result = (quot1*3)+2;
}
if(rem == 1)
{
result = (quot1*3)+1;
}
if(rem == 2)
{
result = (quot1*3)+1;
}
}
/*******************************ODD's**************************/
if(odev == 1)
{
if(rem == 0)
{
quot1--;
result = (quot1*3)+1;
}
if(rem == 1)
{
quot1--;
result = (quot1*3)+1;
}
if(rem == 2)
{
result = (quot1*3)+2;
}
}
rounddown = result;
return rounddown;
}/*End Of Rounddown Algorithm*/
/
***************************************************************************/
/*The Remove Any Remainder's Algorithm*/
long double Remove(long double remove)
{
long double quot1,rem1;
div_t div_result;
div_result = div(remove,1);
quot1 = div_result.quot;
rem1 = div_result.rem;
remove = quot1;
return remove;
}/*End Of Remove Remainder's Algorithm*/
/
*********************************************************************************/
/************************Finish ALL Function Calls!
**************************/
void main()
{
int exit=1;
do
{system("cls");
long int div3,sqroot=0,rounddown,input,Tinput,maxlog,input2,templog;
long double y,x;
div_t div_result;
cout<<"\n\n\n";
cout << "\n\n\n\n\tThis Program Is The Property Of Paul Blackburn
Copyright 2008 \n";
//getche();
cout<<"\n\n\n\n\t This Program Counts The Number Of Primes Below
Your Imput! \n";
cout<<"\n\n\t\t\tPlease Entert A Number! \n";
cin>>input;
rounddown = input;
cout<<"Input = "<<input;Tinput = input;
cout<<"\n\n\n";
rounddown = input;
input = Rounddown(rounddown);
y = input;
/****************************Div input by 3 &
Rounddown*************************************/
long int result,max=0,remove;
div3 = (y/3);
remove = div3;
div3 = Remove(remove);
result = div3; cout<<"\nInput div 3 = "<<result;
/**************************Start The
Algorithm's**********************************/
/*Find Max 'N'*/
x = sqrt(y);
rounddown = x;
sqroot = Rounddown(rounddown);//25
remove = sqroot/3;
max = Remove(remove);//8
/*Create The Array*/
long int *box1 = new long int[max],addo=-1,adde=0;
long int add=0;long iClock = 600000L;
clock_t start, finish;
double duration;
start = clock();
while(iClock--);
do
{
addo = addo+2;adde = adde+2;
if(add<max)
{
box1[add] = (addo*3)+2;
}
add++;
if(add<max)
{
box1[add] = (adde*3)+1;
}
add++;
}while(add<=max);add=0;
/************The Logarithm Function*********************/
long double logg10,logg5,remlog; int
long double input1;
input1 = input;input2=input;
logg10 = log10(input1);
cout<<"\nLog = "<<logg10;
logg5 = logg10/log10(5.0);
cout<<"\nLogf = "<<logg5;
templog = logg5;
remlog = logg5-templog;
cout<<"\nRemlog = "<<remlog;
maxlog = logg5-remlog;
cout<<"\nMAXLOG = "<<maxlog;cout<<"\n";
/************END LOG*****************************************/
/*Now The Math Bit*/
/**************************************Put Main Here!
***************************************/
long int duds=0,dupes=0,total=0,a=0,b=maxlog-1;
long int *newaray = new long int[maxlog];
do
{
newaray[a] = 1;
if(a==0)
{
cout<<"\n\t\tNewArray = ";
}
cout<<"["<<newaray[a];cout<<"]";cout<<" ";
a++;
}while(a<maxlog);
a=0;
long int *movearay = new long int[maxlog];
do
{
movearay[a] = -1;
if(a==0)
{
cout<<"\n\t\tMoveArray = ";
}
cout<<"["<<movearay[a];cout<<"]";cout<<" ";
a++;
}while(a<maxlog);
maxlog--;
/******ARRAY FINISHED**********HERE IS THE MAIN MAIN
PROGRAMME**************/
add=0;
cout<<"\n\n";
long int
addon=0,rebuild=0,quot2=0,rem2=0,factorial=1,multiply=1,multiply2=0,multiply3=0,add1=0,print=0,move
= maxlog-1,maxlogtemp=0,movetemp=0,temp=0,stop=0,primes=0;
//Math int's
long int
box2=1,boxtemp,box2div=1,takeaway=0,final=0,go=0,oddeven=0,stop1=0,sweep=0,stop3=0,next=0,times=-1,plusminus=0;
do
{go=0;times++;
/**************************************************************/
if((newaray[maxlog]<=sqroot)&&(final<=box2div))
{
do
{box2=1;
newaray[maxlog]=box1[add];print=0;
cout<<"\nArray = ";
do
{
cout<<"["; cout<<""<<newaray[print];
cout<<"]";
//This is the effect we need
//
//[1][1][1][1][5] = * 1
//[1][1][1][5][5] = * 1
//[1][1][1][5][7] = * 2
//[1][1][5][5][5] = * 1
//[1][1][5][5][7] = * 3
//[1][1][5][7][11] = * 4
//[1][1][7][7][7] = * 1
if((newaray[print]!=newaray[print+1])&&(print<=(maxlog-1)))
{
multiply3++;
//Rule 1 If this >=2 multiply++;
if(multiply3>=2)
{
multiply++;//cout<<"~";
}
}
/*/ if(newaray[print]!=1)
{
multiply2++;
Rule 2 If this >=3 multiply1++;
if(multiply2>=3)
{
multiply++;
}
}*/
quot2 = (multiply-1)/2; //=8
rebuild = quot2*2; //=16
rem2 = (multiply-1)-rebuild; //=1
addon = rem2+quot2; //=9
//cout<<"\nQuot2 = "<<quot2;cout<<" rebuild = "<<rebuild;cout<<" rem
= "<<rem2;cout<<"\n\tAddon = "<<addon;
factorial = ((1+(multiply-1))*(quot2))+ addon;//cout<<"\n\n\t
\tFactorial = "<<factorial;getche();
if(multiply3==1)
{
multiply=1;
}
multiply2=0;
box2 = box2*newaray[print];
print++;
/
*********************************************************************/
}while(print<=maxlog);
rounddown = (input/box2);
boxtemp = Rounddown(rounddown);
remove = boxtemp/3;
box2div = Remove(remove);
final = box2div-takeaway;
if((newaray[0]==box1[0])&&(final<=1))
{
stop3=1;
cout<<"\n\n\t\tSTOP!!!!!!!!!!";
}
if(takeaway>=box2div)
{
newaray[maxlog]=sqroot;
}
go++;
if(oddeven == 0)
{
takeaway++;
}
if((go>=2)&&(oddeven>=1))
{
takeaway++;
}
/****************************The Working Out***********************/
if(box2div>=takeaway)
{//cout<<"\n\nSweep = "<<sweep;
if(times==0)
{
cout<<" 1) Final = "<<final;cout<<" Times = "<<multiply;
cout<<" Sweep = "<<sweep;cout<<" Mltply = "<<multiply;cout<<" Fact
= "<<factorial;
dupes = dupes+final;
}
if(final>=1)
{
if((sweep==0)&&(times>=1))
{
final = (multiply*final);
if(multiply>=2)
{
final = final-factorial;//cout<<"\n Multiply ="<<multiply;
}
cout<<" 2) Final = "<<final;cout<<"\tTimes = "<<multiply;
cout<<" Sweep = "<<sweep;cout<<" Mltply = "<<multiply;cout<<" Fact
= "<<factorial;
dupes = dupes+final;
}
if((sweep==1)&&(times>=1))
{
final = (multiply*final)-factorial;//change 2 to X.
cout<<" 3) Final = "<<final;cout<<"\tTimes = "<<multiply;
cout<<" Sweep = "<<sweep;cout<<" Mltply = "<<multiply;cout<<" Fact
= "<<factorial;
dupes = (dupes+final);
}
}
}
multiply=1;multiply2=0;multiply3=0;
/********************************************************************/
if((sweep==0)&&(takeaway>=box2div))
{
stop1=1;
}
sweep=1;stop=1;add++;
}while((box2div>=takeaway)&&(newaray[maxlog]<sqroot));
}
oddeven=1;
/
***********************************************************************************/
sweep=0;
if(stop1==1)
{
if(box2div>=2)
{
do
{
move--;cout<<"\t1Here";
}while((newaray[move]==newaray[move+1]));
stop=0;stop1=0;sweep=0;
}
if(box2div<=1)
{
do
{
move--;cout<<"\t\t2Here";
}while((movearay[move]!=-1)&&(move>=1));
stop=0;stop1=0;sweep=0;
}
}
if(plusminus==0)
{
if(dupes>=1)
{
cout<<"\n\t\tTotal = -"<<dupes;//dupes=0;
primes = primes-dupes;
cout<<"\tDiff = "<<primes;
}
dupes=0;
}
if(plusminus==1)
{
if(dupes>=1)
{
cout<<"\n\t\tTotal = +"<<dupes;//dupes=0;
primes = primes+dupes;
cout<<"\tDiff = "<<primes;
}
dupes=0;
}
if(movearay[move]==-1)
{
if(plusminus==1)
{
plusminus--;//dupes=0;
}
else
if(plusminus==0)
{
plusminus++;//dupes=0;
}
}
movearay[move]++;
newaray[move]=box1[movearay[move]];
maxlogtemp=move;
do
{
movearay[maxlogtemp]=movearay[move];
newaray[maxlogtemp]=newaray[move];
maxlogtemp++;
}while(maxlogtemp<=maxlog);
move=maxlog-1;
add=movearay[move];
cout<<"\n";
getche();
final=0;
takeaway = movearay[move]+1;
/
***********************************************************************************/
}while(stop3!=1);
/
**************************************************************************************/
delete[]newaray;
newaray=0;
delete[]movearay;
movearay=0;
/*********************************END CLOCK********************/
cout<<"\n\n\n\nTotal Duds = "<<duds;
cout<<"\n\n\n\nTotal Dupes = "<<dupes;
cout<<"\nResult = "<<result;
total = result+primes+2;
cout<<"\n\n\t\t\tTotal Primes = "<<total;
finish = clock();
duration = (double)(finish - start)/CLOCKS_PER_SEC;
cout<<"\n\t"<<duration;cout<<" seconds";
/*Delete The Array*/
iClock=0;duration=0;
delete[]box1;
box1=0;
getche();
/
*********************************************************************************/
cout<<"\n\n\nPress 0 to exit";
cin>>exit;
}while(exit!=0);
getche();
}
<snip>
Lines 7-75 are a poor reimplementation of features already found in
the language itself or in the standard library.
For example, to find the floor (or, as you put it "Rounddown") of the
square root of an integer, try something like this:
#include <math.h>
...
unsigned int x=7, sqrt_x;
sqrt_x = (int)sqrt(x);
...
That's it. The int x is automatically promoted to a double, and
casting the result to an int is done by truncation.
If you wanted the result to be a double, you could either do one more
cast:
(double)( (int) sqrt(x) )
or, more readably,
floor(sqrt(x))
You might also find the math library functions fmod() and modf()
useful.
If you'd like to make these changes, I'd be happy to review the
results off-list (unless anybody else wants to see this thread
continued).
1. If you want to use an object-oriented language at this point, use
Python or Ruby. If you want to use a compiled language, use C. C++
is fine as a second language, but there's not much to recommend it as
a first language.
2. _The C Programming Language_ by Kernighan & Ritche
3. _The Standard C Library_ by P. J. Plauger
4. _Expert C Programming: Deep C Secrets_ by Van Der Linden
5. Read other people's code (GNU source is readily available). Read
anything published by O'Reilly & Assoc. Read the moderated usenet
language newsgroups. Read your language documentation. Read your
compiler documentation. Read the source code for your compiler. Read
your program's assembler output. Read you processor architecture
documentation. Read the bash man page. Find people who know what
they're doing, ask them what they're reading, and read that. Read
everything Don Knuth ever wrote. Read _The Mythical Man Month_ and
_Peopleware_ and _Code Complete_ and _The Art of Unix Programming_ and
_The Turing Omnibus_ and, just to annoy someoneN, _Neural Networks for
Pattern Recognition_. Once you've digested all that, treat yourself
to _Hacker's Delight_ and _How Not To Program in C++_.
6. Write less, read more. Six months in the lab will save you six
hours in the library.
Garamond
No.
> For example, to find the floor (or, as you put it "Rounddown") of the
> square root of an integer, try something like this:
No. Its *My* "floor function" and you have no idea what it means.
> That's it. The int x is automatically promoted to a double, and
> casting the result to an int is done by truncation.
Doubles or prescision desimals dont work with this program.
> If you wanted the result to be a double, you could either do one more
> cast:
No. I dont.
> (double)( (int) sqrt(x) )
>
> or, more readably,
>
> floor(sqrt(x))
>
> You might also find the math library functions fmod() and modf()
> useful.
No. No amount of floating point prescision is good enough.
Do you not think Iv'e done all this?
> If you'd like to make these changes, I'd be happy to review the
> results off-list (unless anybody else wants to see this thread
> continued).
Why don't you look at the methods used, or ask your math prof
has he ever seen them b4, or try with pen & paper to
write quicker solutions with the pi(x) functions on the link.
You wont be able to.
And here, class, is the difference between showing and telling. When
I say "This is wrong", I provide line numbers and suggestions for how
to correct the issue. Spinny just yelps.
>
> > For example, to find the floor (or, as you put it "Rounddown") of the
> > square root of an integer, try something like this:
>
> No. Its *My* "floor function" and you have no idea what it means.
That's generally considered to be the fault of the programmer. I'm
afraid you don't get to decide what "floor function" means for
integers or doubles, nor do you have a whole lot of wiggle room with
the meaning of "Rounddown". You either made an error naming the
function, implementing the function, or both. If it's the former, you
could have mitigated the error with comments, but I'd still mark it
wrong if this was a homework assignment.
>
> > That's it. The int x is automatically promoted to a double, and
> > casting the result to an int is done by truncation.
>
> Doubles or prescision desimals dont work with this program.
>
You're the one calling sqrt(). Are you sure this is your code?
> > If you wanted the result to be a double, you could either do one more
> > cast:
>
> No. I dont.
>
> > (double)( (int) sqrt(x) )
>
> > or, more readably,
>
> > floor(sqrt(x))
>
> > You might also find the math library functions fmod() and modf()
> > useful.
>
> No. No amount of floating point prescision is good enough.
>
I'm not sure that you know what precision means. If no amount of
precision is good enough for your algorithm, doesn't your algorithm
fail?
> Do you not think Iv'e done all this?
Since you're unable to explain this code, my best guess is that you've
copied it from somebody else, probably a student.
>
> > If you'd like to make these changes, I'd be happy to review the
> > results off-list (unless anybody else wants to see this thread
> > continued).
>
> Why don't you look at the methods used, or ask your math prof
> has he ever seen them b4, or try with pen & paper to
> write quicker solutions with the pi(x) functions on the link.
>
> You wont be able to.
Well, I'm a little busy this week. Here's the top of my to-do list.
1. Given n ions (were n is on the order of 50,000,000) in a cubic
lattice of dimensions 2^m x 2^m x 2^m (where m ranges from 8-64),
implement an algorithm where each timestep takes on the order O(n*m).
2. Given a processor with dynamic voltage scaling, model the
performance of a benchmark at frequency f given the execution time and
two (thanks, Intel) performance counters at frequency f'.
3. Convert my linear programming algorithm that schedules frequencies
for minimal energy usage on a cluster to work in units of individual
timesteps or global synchronization points instead of whole programs.
1 is getting debugged (trees are cool, but they're really hard to get
right), 2 is accurate to within 4% (mostly) but I'd like to shrink
that, and 3 won't involve much more than a lot of brain-dead text
processing. If you're willing to pitch in a bit and help, I'll see if
I can dig up a faster algorithm than what Wolfram has listed. Deal?
#1 would probably be the easiest.
(I realize you intended it as a pathetic little dig, but algorithms
are mostly developed on pencil and paper, or on a whiteboard, or while
in the shower. My graduate algorithms prof is quite proud of the fact
that he stopped programming years ago.)
Garamond
Sorry, but I didn't post this; some loser did.
>Thought not.
No surprise; it's apparently a foreign concept.
> And here, class, is the difference between showing and telling. When
> I say "This is wrong", I provide line numbers and suggestions for how
> to correct the issue. Spinny just yelps.
How could you possibly know something is wrong when you don't even
understand how
it works?
I have an idea, since you obviously think you know more than the
person who wrote the code
with a 10 minute glance.
Implement the changes you describe, and come back with an apology
when the program gives you incorrect results.
Tell me, using floats, if I get a result ending (inter.decimal) = (n.
5)
Do you round up or down?
Sometimes you need one sometimes you need the other.
Again (from the person who wrote the program) *floats* don't work.
It's not that hard once you know what you are doing.
> > > For example, to find the floor (or, as you put it "Rounddown") of the
> > > square root of an integer, try something like this:
>
> > No. Its *My* "floor function" and you have no idea what it means.
>
> That's generally considered to be the fault of the programmer.
Sigh,
> I'm afraid you don't get to decide what "floor function" means for
> integers or doubles, nor do you have a whole lot of wiggle room with
> the meaning of "Rounddown".
1) If I wanted, your "floor function" I would have said "floor
function".
You have spotted something round, said you need an egg, but I wanted
a beechball.
> You either made an error naming the function,
No. There *IS* no function for what that code does. Because IT DOES
NOT
EXIST. It's NEW MATH.
> > > That's it. The int x is automatically promoted to a double, and
> > > casting the result to an int is done by truncation.
>
> > Doubles or prescision desimals dont work with this program.
>
> You're the one calling sqrt(). Are you sure this is your code?
sqrt() is not in the RoundDown algorithm.
And sqrt(y) [float] is *CONVERTED* to an integer
x = sqrt(y);
rounddown = x;
sqroot = Rounddown(rounddown);//25
remove = sqroot/3;
max = Remove(remove);
Because *floats* DON'T work.
.
> > > If you wanted the result to be a double, you could either do one more
> > > cast:
>
> > No. I dont.
>
> > > (double)( (int) sqrt(x) )
>
> > > or, more readably,
>
> > > floor(sqrt(x))
>
> > > You might also find the math library functions fmod() and modf()
> > > useful.
>
> > No. No amount of floating point prescision is good enough.
>
> I'm not sure that you know what precision means.
I know enough to realise there is no precision with floating point
numbers.
> If no amount of precision is good enough for your algorithm, doesn't your
> algorithm fail?
If tollerance to precision was not a problem, do you think there
would
be a need for "int" in C++?
Neither do people who know what they are talking about.
E.G saying $$ puts tex in math mode when it aready is.
> > Do you not think Iv'e done all this?
>
> Since you're unable to explain this code, my best guess is that you've
> copied it from somebody else, probably a student.
Loon.
Garmond Screams
"''I don't understand' ergo 'my best solution is to scream
you could not have possibly wrote this, it's beyond my
comprehension''".
> > > If you'd like to make these changes, I'd be happy to review the
> > > results off-list (unless anybody else wants to see this thread
> > > continued).
>
> > Why don't you look at the methods used, or ask your math prof
> > has he ever seen them b4, or try with pen & paper to
> > write quicker solutions with the pi(x) functions on the link.
>
> > You wont be able to.
>
> Well, I'm a little busy this week. Here's the top of my to-do list.
<snip> yawn.
> (I realize you intended it as a pathetic little dig, but algorithms
> are mostly developed on pencil and paper, or on a whiteboard, or while
> in the shower. My graduate algorithms prof is quite proud of the fact
> that he stopped programming years ago.)
Yes, hense when asked is this implemented on paper I earlier said
"yes"
because the math, algorithms and charts are on paper here right in
front of me.
It's amazing what a bit of learning can do.
If I see a function named "foo" and there's a well-defined, accepted
way of doing "foo", and the function itself does something wildly
different, I don't need to know what the function does in order to
know it's wrong. It's the same process that I use when evaluating a
proof. If there's a contradiction, I don't need to understand the
rest of the proof: it's wrong.
>
> I have an idea, since you obviously think you know more than the
> person who wrote the code
> with a 10 minute glance.
>
> Implement the changes you describe, and come back with an apology
> when the program gives you incorrect results.
I showed you how to do that already. Integer division truncates, so
there's no need to round down. Use the floor() function for doubles.
If what you were trying to do was something other than "Rounddown",
your error is in naming the function.
>
> Tell me, using floats, if I get a result ending (inter.decimal) = (n.
> 5)
> Do you round up or down?
Depends on what your algorithm needs.
floor() will round that down. ceil() will round that up. round()
will round that to the nearest integer (halfway cases away from
zero). I'm not sure what the difference is between that and
nearbyint(), but I'll leave that to you to figure out.
>
> Sometimes you need one sometimes you need the other.
Yes, indeed. In fact, this happens so often that function that allow
you to do this have been provided for you in the standard library.
>
> Again (from the person who wrote the program) *floats* don't work.
Show, don't tell.
>
> It's not that hard once you know what you are doing.
I don't seem to be the one having difficulty here.
>
> > > > For example, to find the floor (or, as you put it "Rounddown") of the
> > > > square root of an integer, try something like this:
>
> > > No. Its *My* "floor function" and you have no idea what it means.
>
> > That's generally considered to be the fault of the programmer.
>
> Sigh,
>
> > I'm afraid you don't get to decide what "floor function" means for
> > integers or doubles, nor do you have a whole lot of wiggle room with
> > the meaning of "Rounddown".
>
> 1) If I wanted, your "floor function" I would have said "floor
> function".
>
> You have spotted something round, said you need an egg, but I wanted
> a beechball.
>
> > You either made an error naming the function,
>
> No. There *IS* no function for what that code does. Because IT DOES
> NOT
> EXIST. It's NEW MATH.
"Rounddown" is new math?
>
> > > > That's it. The int x is automatically promoted to a double, and
> > > > casting the result to an int is done by truncation.
>
> > > Doubles or prescision desimals dont work with this program.
>
> > You're the one calling sqrt(). Are you sure this is your code?
>
> sqrt() is not in the RoundDown algorithm.
>
> And sqrt(y) [float] is *CONVERTED* to an integer
> x = sqrt(y);
> rounddown = x;
> sqroot = Rounddown(rounddown);//25
> remove = sqroot/3;
> max = Remove(remove);
>
> Because *floats* DON'T work.
> .
>
Why don't they work? Show, don't tell.
>
>
> > > > If you wanted the result to be a double, you could either do one more
> > > > cast:
>
> > > No. I dont.
>
> > > > (double)( (int) sqrt(x) )
>
> > > > or, more readably,
>
> > > > floor(sqrt(x))
>
> > > > You might also find the math library functions fmod() and modf()
> > > > useful.
>
> > > No. No amount of floating point prescision is good enough.
>
> > I'm not sure that you know what precision means.
>
> I know enough to realise there is no precision with floating point
> numbers.
Precision is measured in bits. For those following along at home:
http://en.wikipedia.org/wiki/Floating_point
>
> > If no amount of precision is good enough for your algorithm, doesn't your
> > algorithm fail?
>
> If tollerance to precision was not a problem, do you think there
> would
> be a need for "int" in C++?
Integers also have precision. I don't know what "tolerance to
precision" means, but I don't think you do either.
http://en.wikipedia.org/wiki/Precision_(computer_science)
>
> Neither do people who know what they are talking about.
>
> E.G saying $$ puts tex in math mode when it aready is.
>
> > > Do you not think Iv'e done all this?
>
> > Since you're unable to explain this code, my best guess is that you've
> > copied it from somebody else, probably a student.
>
> Loon.
> Garmond Screams
> "''I don't understand' ergo 'my best solution is to scream
> you could not have possibly wrote this, it's beyond my
> comprehension''".
Did you write it?
>
>
>
>
>
> > > > If you'd like to make these changes, I'd be happy to review the
> > > > results off-list (unless anybody else wants to see this thread
> > > > continued).
>
> > > Why don't you look at the methods used, or ask your math prof
> > > has he ever seen them b4, or try with pen & paper to
> > > write quicker solutions with the pi(x) functions on the link.
>
> > > You wont be able to.
>
> > Well, I'm a little busy this week. Here's the top of my to-do list.
> <snip> yawn.
> > (I realize you intended it as a pathetic little dig, but algorithms
> > are mostly developed on pencil and paper, or on a whiteboard, or while
> > in the shower. My graduate algorithms prof is quite proud of the fact
> > that he stopped programming years ago.)
>
> Yes, hense when asked is this implemented on paper I earlier said
> "yes"
> because the math, algorithms and charts are on paper here right in
> front of me.
Good. What's the algorithm you're trying to implement in Rounddown?
You've got it in front of you, right?
Garamond
You really have no clue do you?
> > How could you possibly know something is wrong when you don't even
> > understand how
> > it works?
>
> It's amazing what a bit of learning can do.
I don't know wether to laugh or cry.
You are obviously educated to some basic level, but you are willing
to forego what you may learn, with what you think you know.
SIMPLE TEST.
Have you (or anyone in your class / any of your professors) found
a way to calculate \pi(1000) on paper in less than 17 calculations?
Let me save you the trouble.
No. You haven't.
> If I see a function named "foo" and there's a well-defined, accepted
> way of doing "foo",
There you go. (Well accepted, defined)
None apply.
*******************************************************************
Look at the program, type in "1000".
Now ask yourself, (why does input div/3 = 332)?
Surely it should be 333.3333333 Or
floor = 333?
You see, you have 0 idea how this works.
> > Tell me, using floats, if I get a result ending (inter.decimal) = (n.
> > 5)
> > Do you round up or down?
>
> Depends on what your algorithm needs.
Hmm, so If it needs 100 precision, and you say
"throw a float" then you are wrong.
That's why arbitrary-precision libraries exist.
http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
I can recommend the GNU Multiple-Precision Library based on personal
experience.
Who decides "up or down"? The library?
Thanks for the time. But it's very simple.
If you are correct. Its quite an easy change, and you should be able
to
implement it asap.
If I am correct, your implementations won't work.
I don't care either way.
Just that I know you are wrong.
You could easily prove me wrong though. (Good Luck).
I know what you're trying to ask. I've given you the benefit of the
doubt and explained how to ask it correctly. Since you didn't learn
anything, I'm going to answer the question exactly as written.
I can do this in a single assembly language instruction: memcpy.
Gosh, it must be frustrating for you not to understand why that's the
correct answer. Nothing a little reading won't cure, of course.
_Introduction to Algorithms_, Cormin et al., 2nd ed, chapter 3.
>
> Let me save you the trouble.
>
> No. You haven't.
I just did. I think it's cute that you can't figure out why this is a
correct answer.
>
> > If I see a function named "foo" and there's a well-defined, accepted
> > way of doing "foo",
>
> There you go. (Well accepted, defined)
>
> None apply.
>
> *******************************************************************
>
> Look at the program, type in "1000".
>
> Now ask yourself, (why does input div/3 = 332)?
>
> Surely it should be 333.3333333 Or
> floor = 333?
>
> You see, you have 0 idea how this works.
I understand the function you call "rounddown" doesn't. That's a bug.
Did you write this code?
Simple test.
You obviously in 1 day believe you know how this program works.
Take the number "996" and run "996/3".
Why would this program output
"Input div 3 = 331"?
You see "class" knows why.
Where "stupididity" doesn't.
Now I don't want to start beating you around the head.
But don't ask for it either.
>
>I can do this in a single assembly language instruction: memcpy.
Just a nit, not to detract from your overall goal but to keep it
scrupulously correct---
memcpy, of course, is part of the C language library and is not an
assembly language instruction. There may be CPUs with single
instructions to move data from a source address to a destination
address, incrementing both addresses, and repeating for a set count
but of course they are useless without other instructions to set the
addresses and count into registers.
The library follows standard mathematical convention. If your
algorithm requires a different convention, try something like:
double round_towards_zero(double x){ return x-floor(x) != .5 ?
round(x) : floor(x); }
This isn't production quality code -- you'd want to handle the
negative number case, among other things -- but I think it shows that
you didn't need to reinvent the wheel.
>
> Thanks for the time. But it's very simple.
>
> If you are correct. Its quite an easy change, and you should be able
> to
> implement it asap.
Implement which -- a slight modification to rounding? See above. A
one-instruction count of primes less than 1000? I don't see much
point in implementing that. Reverse engineering the clot of code you
called Rounddown? It's buggy -- why would I bother?
>
> If I am correct, your implementations won't work.
>
> I don't care either way.
Not a graceful way to concede, but accepted nonetheless.
>
> Just that I know you are wrong.
And that's the important thing, isn't it. Not that the code is
correct, not that you've learned anything, but that you're able to
hold on to that feeling of certainty regardless of any evidence to the
contrary.
>
> You could easily prove me wrong though. (Good Luck).
Let me know when you've fixed the bugs I've pointed out.
Garamond
> I can do this in a single assembly language instruction: memcpy.
That ''memcpy'' is an assembly language instruction should come as
something of a surprise to the guys who wrote the ISO-C89/99
standard...
Methinks you are referring to REP STOSB or something simular. But no
all the world's an Intel machine...
Seconded con gusto!
You (as well as Kleuskes & Moos) are absolutely correct -- nice catch!
> > Who decides "up or down"? The library?
>
> The library follows standard mathematical convention. If your
> algorithm requires a different convention, try something like:
Why would I?
If the library is standard, my algorithm isn't. Why would I follow
your suggestion to try a "standard" approach?
You really have no Idea whats going on, do you?
I'm not trying to be nasty, but you dont.
Have you actually run this program yet?
What sense did you make of the (apparent) garbled results?
How does it work?
You have no idea, do you?
> but I think it shows that you didn't need to reinvent the wheel.
Ah, we are getting somewhere.
I did need to reinvent the wheel. Lets see if you can work out why.
> > Thanks for the time. But it's very simple.
>
> > If you are correct. Its quite an easy change, and you should be able
> > to
> > implement it asap.
>
> Implement which
Your suggestions. Please try to keep up.
> > If I am correct, your implementations won't work.
>
> > I don't care either way.
>
> Not a graceful way to concede, but accepted nonetheless.
Only a fool thinks hes won, when he's just had his head rammed up his
ass.
But if you can't think, (with the smell 'n' headache) No prob.
> > Just that I know you are wrong.
>
> And that's the important thing, isn't it.
No, it's totally irrelivant.
"Primes" are primes. They were before I was alive, and they will be
after you
are compost.
If I am on the same side as truth once in a while, that is irrelivant
too.
> > You could easily prove me wrong though. (Good Luck).
>
> Let me know when you've fixed the bugs I've pointed out.
Let me know when you are educated enough to realise some bugs are
butterflies.
You are absolutely correct -- I had remembered seeing that instruction
and thinking "wow, trying to predict how long that will take at
compile time is going to be difficult." I filed that away as how
memcpy would probably be implemented, thus my confusion.
I had the Intel documentation not three feet away on my desk. Oh,
well -- thanks for catching it.
(Of course, REP MOVS will copy the entire list of primes in ASCII or
using the numeric values. If all you're interested in is the count,
then a store is sufficient.)
Garamond
Methinks you mean "run-time". At compile time, it takes as long as the
compiler takes... But now i'm really picking nits. Which is a highly
sociable pasttime amongst primates, i'm told.
> I filed that away as how memcpy would probably be implemented, thus my confusion.
On machines that support such instructions, yes. Many, however, don't.
> I had the Intel documentation not three feet away on my desk. Oh,
> well -- thanks for catching it.
>
> (Of course, REP MOVS will copy the entire list of primes in ASCII or
> using the numeric values. If all you're interested in is the count,
> then a store is sufficient.)
Both REP STOSB and REP MOVS require that you _know_ the count in
advance, unless i'm very much mistaken. Which, of course is a distinct
possibility, since the last time I wrote x86 assembly is quite a while
ago. Last assembly i wrote was for the good old Z80 (yes, it's STILL
around!)
> Garamond
Another old geezer that probably does embedded systems stuff! I
guess you are as louse ridden as I am, given all the nits waiting for
picking.
memcpy also requires a known count in advance. That is unless you do
your C programming the old-fashioned way and just allow yourself to
just overwrite any old stuff that happened to be in the rest of
memory. The good stuff should be down at the bottom and anything
important in high memory is burned into ROM so no problem.
<furious, yet not quite serious, indignation>
Old geezer!? Old GEEZER? I'm STILL Mrs. Kleuskes & Moos!
</furious, yet not quite serious, indignation>
But yes, i'm doing embedded stuff. And what's worse, i like it. But i
allready told you allbeit a loooong time ago. That's how I know you
wrote software for the Apollo program (IIRC). I'm the girl who wrote
software for pacemakers.
> memcpy also requires a known count in advance.
True.
> That is unless you do
> your C programming the old-fashioned way and just allow yourself to
> just overwrite any old stuff that happened to be in the rest of
> memory. The good stuff should be down at the bottom and anything
> important in high memory is burned into ROM so no problem.
Ahhh... I see you have a machine that goes 'ping', too! Nope, i'm from
the generation that required memory to remain untouched apart from the
target range.
I was doing performance prediction work at the time (I still am, in a
slightly different context). I thought that one could establish some
sort of worst-case bound on execution time by counting cycles per
instruction -- at least at the basic block level. Then I found out
that, with instructions like these, cycles per instruction is just not
that easy to pin down (nevermind all the pipeline and cache effects).
Anyway, it was a good excuse to give up on that line of attack.
>
> > I filed that away as how memcpy would probably be implemented, thus my confusion.
>
> On machines that support such instructions, yes. Many, however, don't.
>
> > I had the Intel documentation not three feet away on my desk. Oh,
> > well -- thanks for catching it.
>
> > (Of course, REP MOVS will copy the entire list of primes in ASCII or
> > using the numeric values. If all you're interested in is the count,
> > then a store is sufficient.)
>
> Both REP STOSB and REP MOVS require that you _know_ the count in
> advance, unless i'm very much mistaken. Which, of course is a distinct
> possibility, since the last time I wrote x86 assembly is quite a while
> ago. Last assembly i wrote was for the good old Z80 (yes, it's STILL
> around!)
<flip flip flip> "Repeats a string instruction the number of times
specified in the count register ((E)CS) or until the indicated
condition of the ZF flag is no longer met." I'll certainly defer to
your expertise, but I think that lets you get away with supplying the
count dynamically.
So I'll see your nit and raise you one _Intel 64 and IA-32
Architectures Software Developer's Manual Volumee 2B: Instruction Set
Reference, N-Z_.
Garamond
>
> > Garamond
Still on the nits (which is a far more interesting topic than the
original!) ...
.... Assuming you specify that the region to be copied contains exactly
one value of zero and it occurs only at the end. In other words, the
entire region is one long 'string' (in the old fashioned sense of that
idea). That is why it is a string operation, not a memcpy operation
unless you use the count.
Besides I just browsed my bookshelves for the instruction repertoires
of the Burroughs Datatron 205, the IBM 1620, and the Motorola 6909 and
none of these seem to have anything remotely similar.
Yes, I vaguely seem to recall your information. The problem with
having an 8 bit nervous system is that you can only address 64K of
memory and frequent dumps are in order. And it was the Mariner Mars
thingie but way back in '61. No CPU chips, no integrated circuits back
then. And even transistor circuitry was still pretty iffy! That was
a much easier task than yours. If you have a bug in your code, people
die. If I had a bug it just wasted a few billions of dollars of NASA
budget.
(6809 CPU of course, to try to avoid the oncoming flames)
Oh dear, this could be fun....
>
> .... Assuming you specify that the region to be copied contains exactly
> one value of zero and it occurs only at the end. In other words, the
> entire region is one long 'string' (in the old fashioned sense of that
> idea). That is why it is a string operation, not a memcpy operation
> unless you use the count.
Right. So (for illustration purposes only), strcpy could be
implemented with REPZ, memcpy() with REP, and.... I'm going to go with
REPZ for strncpy().
>
> Besides I just browsed my bookshelves for the instruction repertoires
> of the Burroughs Datatron 205, the IBM 1620, and the Motorola 6909 and
> none of these seem to have anything remotely similar.
Here's the algo (translated to C-ish notation):
[Skipping address size stuff]
while (CountReg != 0) {
Service pending interrupts (if any);
Execute associated string instruction;
CountReg--;
if( (prefix == REPZ || prefix == REPE) && ZF==0) break;
if( (prefix == REPNZ || prefix == REPNE) && (ZF==1) break;
}
So yes, I think this'll handle both strcpy and memcpy. Unless that
wasn't the nit we were picking at, in which case I'll just stomp my
foot and declare I'm right.
Garamond
I just recalled some thingamajig flying in space, eventhough i'm
equipped with the 16-bit version. It impressed me hugely. Still does,
b.t.w. I wasn't even born back then.
> That was
> a much easier task than yours. If you have a bug in your code, people
> die. If I had a bug it just wasted a few billions of dollars of NASA
> budget.
Which is the reason i quit that job. It gave me knots in my stomach,
just thinking about it. Fortunately, there were hardware failsafe
mechanisms, but still. I prefer burning a couple of billions every day
of the week. I should have become a Wall-street banker!
The usual reason for using standard terminology/conventions in any
field is to be able to communicate. You, on the other hand, seem to
want to make communication impossible by various means (using standard
terminology in a different way without saying what you're doing,
refusing to say what your point is, etc.). This allows you to respond
to sensible statements with things like "That's not what I meant. What
an idiot."
My guess is that you are a 14 year old wanker who has not interest in
a real discussion of anything (probably because you don't know enough
about anything to have a real discussion), but just gets his kicks by
annoying others.
<snip rest of bs>
memcpy in old style C is much more elegant:
memcpy(char *dest, char* source, int count)
{ while (count- -) *dest++ = *source++; }
Still no single machine language (assembler) equivalent!
>I should have become a Wall-street banker!
At least until last week.
No no no no -- The code I showed you IS one assembly language
instruction (e.g. opcode F3A4, instruction REP MOVS m8, m8), and it
replaces that whole block of C code. Really. This is straight out of
Intel's documentation.
http://download.intel.com/design/processor/manuals/253667.pdf
Page 4-331 or thereabouts. Yes, back in your day (and my day)
assembly language instructions did one thing and did it well. Now
they come with multiple lines of supporting pseudocode to explain what
happens.
(The Itanium had a single assembly instruction that emulated the vi
editor.)
(Ok, I was kidding about that last one.)
Emulating EDLIN would have been far more impressive!
OK, I see your point. And I used those instruction prefixes (and even
taught them) way back when. Still, the "single instruction" must be
preceded by loading the count register and the source and destination
address registers.
> > I have an idea, since you obviously think you know more than the
> > person who wrote the code
> > with a 10 minute glance.
>
> > Implement the changes you describe, and come back with an apology
> > when the program gives you incorrect results.
>
> I showed you how to do that already.
No.
1) No changes need to be made.
2) You have not implemented any changes, If you had,
you will (assuming you have the brain power) realise that
the program ceases to function correctly.
> Integer division truncates, so there's no need to round down.
You obviously think this function "rounds down" to the nearest
integer. Let me save you some head-banging. It *doesn't*.
It rounds down to the nearest "prime or pseudo prime".
> Use the floor() function for doubles. If what you were trying to
> do was something other than "Rounddown", your error is in
> naming the function.
No. I get to name the function, since it's my invention.
You want to name something, I suggest you buy a dog.
> > Tell me, using floats, if I get a result ending (inter.decimal) = (n.
> > 5)
> > Do you round up or down?
>
> Depends on what your algorithm needs.
Well obviously you dont know, since you have no idea how this program
works.
> floor() will round that down. ceil() will round that up. <snip>
yes, yes, yes. Tell me something I don't know.
> > Again (from the person who wrote the program) *floats* don't work.
>
> Show, don't tell.
You are having trouble with much simpler concepts. Lets work through
them
before you attempt elementary stuff, eh?
> > It's not that hard once you know what you are doing.
>
> I don't seem to be the one having difficulty here.
You are. Your just to ignorant to know.
> > > You either made an error naming the function,
>
> > No. There *IS* no function for what that code does. Because IT DOES
> > NOT
> > EXIST. It's NEW MATH.
>
> "Rounddown" is new math?
Let me ask a very simple question.
*If* this was suppose to be a "floor function", why would it do this:
101 -> |_101_|
100 -> |_97_|
99 -> |_97_|
98 -> |_97_|
97 -> |_97_|
96 - > |_95_|
95 -> |_95_|
94 -> |_91_|
93 -> |_91_|
92 -> |_91_|
91 -> |_91_|
Let me guess. You have no idea.
> > > Since you're unable to explain this code, my best guess is that you've
> > > copied it from somebody else, probably a student.
>
> > Loon.
> > Garmond Screams
> > "''I don't understand' ergo 'my best solution is to scream
> > you could not have possibly wrote this, it's beyond my
> > comprehension''".
>
> Did you write it?
Of course I wrote it. It would not be posted by me if I didn't.
> > Yes, hense when asked is this implemented on paper I earlier said
> > "yes"
> > because the math, algorithms and charts are on paper here right in
> > front of me.
>
> Good. What's the algorithm you're trying to implement in Rounddown?
> You've got it in front of you, right?
Any prime number is either 1/3 or 2/3 from a whole number. We can
follow a
simple pattern.
All odd integers + 2/3 * 3
All even integers + 1/3 *3
0.666*3 = 2
1.666*3 = 5
2.333*3 = 7
3.666*3 = 11
4.333*3 = 13
5.666*3 = 17
6.333*3 = 19
7.666*3 = 23
8.333*3 = 25.
With this simple rule we have eliminated 17 integers in our search
for primes below 25. Thats why it's so efficient.
The "round-down" algorithm "floors" to either a "prime" or what I call
a "pseudo prime". (25 is one example here)
Now, that's 1 function explained.
Not true. It is used by both. Originally just assembly
Most OS's under 64bit arch use the "memcpy()" aka "baseline" function for
buffer and hardware performance using assembly.
rcopy_x is more upto date and gives better performance on mulit processors
imho.
However C and C++ routines do use memcpy to call on the assembly sub
routines and is it used in C C++ compilers.
Incorrect
"That's not unexpected because on most operating systems, memcpy is a
function written in assembly language to squeeze all of the performance
possible out of the underlying hardware."
http://developers.sun.com/solaris/articles/x86_assembly_lang.html
"memcpy is already written in highly-optimized assembly language"
www.codeguru.com/forum/archive/index.php/t-353353.html
"the memcpy() function and the memmove() function by the use of hand coded
assembly language."
http://support.microsoft.com/kb/835774
However, C and C++ will use memcp and others like memcp to call on assembly
subroutines
But memcp is best known in assembly.
HTH
--
A cup of coffee and some truth with:
·.¸Adman¸.·
^^^^^^^^^^^
My List of confirmed liars
1) J.J. O'Shea
Don't fret!! YOU can be added to the list too!
baseline is too slow. use rcopy on newer machines. faster, in some cases
rcopy will be much faster
>
> Gosh, it must be frustrating for you not to understand why that's the
> correct answer. Nothing a little reading won't cure, of course.
> _Introduction to Algorithms_, Cormin et al., 2nd ed, chapter 3.
>
actually, he is doing quite well.
Once again you demonstrate you utter ignorance. Name one platform on
which memcpy is a
> Most OS's under 64bit arch use the "memcpy()" aka "baseline" function for
> buffer and hardware performance using assembly.
I've never heard "memcpy" called "baseline". That makes no sense. But
why should that surprise anyone?
> rcopy_x is more upto date and gives better performance on mulit processors
> imho.
It's also not standard and therefore quite useless. You _do_ know what
standards are all about, do you?
> However C and C++ routines do use memcpy to call on the assembly sub
> routines and is it used in C C++ compilers.
"memcpy" (if it's implemented in assembly) _is_ the assembly
subroutine, moron. It's also part of the C standard library (stdlib)
and therefore cstdlib as it's called in C++.
OOOOhhhh.... Wait-a-bleeding-New-York-minute! I know what this is
about! You aren't getting the ATTENTION you crave... That's it... Of
course!
Well, there's a good little trollie... Now go and play with your
little friends while the grown-up talk.
Nope.
> "That's not unexpected because on most operating systems, memcpy is a
> function written in assembly language to squeeze all of the performance
> possible out of the underlying hardware."
>
> http://developers.sun.com/solaris/articles/x86_assembly_lang.html
See? Or do you just google without actually UNDERSTANDING what it is
you've found?
> "memcpy is already written in highly-optimized assembly language"
Righty-ho... I fully concur. Absolutely correct. You just don't
understand it.
> www.codeguru.com/forum/archive/index.php/t-353353.html
>
> "the memcpy() function and the memmove() function by the use of hand coded
> assembly language."
Yup... But that STILL does not make it an assembly instruction. Just a
part of the C standard library _written_ (usually) in assembly. There
_is_ a difference, quite subtle, but nevertheless very important.
> http://support.microsoft.com/kb/835774
>
> However, C and C++ will use memcp and others like memcp to call on assembly
> subroutines
>
> But memcp is best known in assembly.
Show me one platform which actually supports it as an assembly
instruction. Besides, you should NEVER trust microsoft documentation.
There's too many 'features' (some call them bugs) in it and too many
things they just don't tell you.
> HTH
It helps showing you haven't got a clue about programming. Thanks.
You just amply demonstrated you haven't got a clue about software and/
or programming, so who are you to say he's doing "well"?
Well, I do. A function is not useless simply because it is nonstandard.
If your software is intended to be supported on multiple platforms,
you will likely have more work to do if you use nonstandard library
functions.
Library functions, whether standard or nonstandard, are tools. Like any
other tool, you have to know when to use them and when *not* to use them.
I have just undertaken an exhaustive study and discovered the amazing
fact that EVERYthing done on a computer executes in machine
language!! Imagine that. No matter whether we think we are writing
in C++ or Python or FORTRAN or even RPG, FORTH, COBOL or whatever, it
turns out that when the computer executes it, is always in machine
language.
So it turns out that there is absolutely no distinction to be made
between your phrase "a single assembly language instruction" and
madman's concept "written in highly-optimized assembly language". Who
cares how many actual machine instructions get executed anyway? Did
you really think the word "single" was all that important?
It is as a replacement for a standard function, which is what was
suggested. If non-standard functions would be useless perse, any form
of software development would be futile. So that's not what was
intended.
> If your software is intended to be supported on multiple platforms,
> you will likely have more work to do if you use nonstandard library
> functions.
You can choose to do without any form of standard libary, the ISO C
standard neatly allows for freestanding implementations, and as a
matter of fact, that's my usual professional playground. However, that
was _not_ was was suggested by spinnie.
> Library functions, whether standard or nonstandard, are tools. Like any
> other tool, you have to know when to use them and when *not* to use them.
<shrug>
Sure, pal. Whatever you say. You're the Guru. Let me bow down and kiss
your feet for such words of wisdom.
Yes. So? I suppose you know firsthand why _writing_ it in machine
language is such a tedious, time consuming and error prone job. Guesss
what, me too. Been there, done that, got bored with it.
I surmise you've fiddled the switches manually and gnawed your teeth
when realising you hadn't clocked your input into core memory
manually, missed a switch in the address block, stumbled in the hall
with a stack of cards, misplaced a crucial role of paper tape. You
should know why assembly was invented and how it differs from machine
language.
> Imagine that. No matter whether we think we are writing
> in C++ or Python or FORTRAN or even RPG, FORTH, COBOL or whatever, it
> turns out that when the computer executes it, is always in machine
> language.
That's all true. It wasn't what i had in mind, but still. Ultimately
it's absolutely true. It was not, however, written in machine
language.
> So it turns out that there is absolutely no distinction to be made
> between your phrase "a single assembly language instruction" and
> madman's concept "written in highly-optimized assembly language".
You're giving the madman too much credit. That concept isn't his, he's
merely quoting someone, the documentation of some implementaion of the
C stdlib version of memcpy.
However, since humanity used to program in machine language, the
computer-science world has thrown in loads of effort trying to figure
out how to avoid having to write programs in machine language.
Assembly was the first step, things like algol followed and later a
plethora of other languages. All for that one single purpuse: to avoid
having to write software in machine language.
> Who cares how many actual machine instructions get executed anyway? Did
> you really think the word "single" was all that important?
Yes. In order to be a function taking three arguments in the c
standard library it has to do a bit more that just move the data. Even
if it's very cleverly inlined as in some cases it is.
But then again, i may have underestimated the little credit, and
(subcontiously) completed 'memcp' to 'memcpy'. 'memcp' could very well
be an assembly instruction (a language primitive, not the resulting
opcodes, register selectors and immediate data) on some archaic
architecture, but not something i'm familiar with.
None of this supports your original claim that memcpy was a _single_ assembly
instruction.
Mark
> HTH
>
>Yes. So? I suppose you know firsthand why _writing_ it in machine
>language is such a tedious, time consuming and error prone job. Guesss
>what, me too. Been there, done that, got bored with it.
>
>I surmise you've fiddled the switches manually and gnawed your teeth
>when realising you hadn't clocked your input into core memory
>manually, missed a switch in the address block, stumbled in the hall
>with a stack of cards, misplaced a crucial role of paper tape. You
>should know why assembly was invented and how it differs from machine
>language.
>
You are, of course, quite correct. In my little attempt at humor I
completely elided over the rather significant detail that assembler is
not machine language.
It is striking how much we share in experience notwithstanding the
enormous difference in age and number of X chromosomes. My first
'real' computer experience came during the Eisenhower administration
when I stood at the console of the CalTech computer center main
computer toggling in by hand the binary values necessary to compute 2
plus 2. Not surprisingly, the computer produced 4 as the result.
Generations later, when I didn't have enough money to buy a real lab
computer, I wrote assembler routines for my Z80 S-100 bus system, hand
translated to hex, and punched it onto tape with my trusty ASR-33
teletype. Fortunately I wisely burned a primitive "operating system"
(really just a debug monitor") into PROM so I didn't have to boot
from front panel switches. It was able to load programs from paper
tape and even load and store data on a cassette tape recorder. Many,
many generations later, with "real" operating systems like CP/M, I
could use actual assembler with symbols and macros and all the other
trappings of computer language that separate it from real machine
code. Microsoft was really important in those days -- MASM and LINK
were the only way to write software.
And there is a reason why the last 8 columns on those IBM cards were
'reserved'. That is where you numbered your deck so after a spill on
the hallway you could run the stuff through the sorter and get back to
normal!
> But then again, i may have underestimated the little credit, and
Apologies.
<smile>
My beginnings are much humbler, i'm afraid. The first thing i
programmed was a texas-instruments calculator at about 13. There were
32 instructions available, no text, just numbers. Eversince, i've been
hooked.
Later I had a thing called a "microprofessor II" which looked like a
videocasette-case (the rented-movie type) with a hexadecimal keypad, a
rudimentary form of something basicish, a one line led-display (a 'w'
looked like an 'a' upside down, IIRC) and a monitor program running on
a Z-80 and 1 k of RAM. In storesI used to elbow my way forward (i
played defence on the local waterpolo-team) to get hold of the first
demonstration types (ZX-81/Spectrum, Acorn Atom, C64, that kind of
thing) and saved up until i could buy one.
<snip>
I have an idea.
Why don't you guys go kiss/cuddle in your own thread?
I could even start it up for you.
Now, if you have anything to say about my program, I am all ears.
If not go away.
I suspect, you have nothing to say, because it is beyond your
comprehension.
> Why don't you guys go kiss/cuddle in your own thread?
Oh... And by the way, who gave you the idea that it's YOUR thread?