1. LONG Re: another one bites the dust
- Posted by Joel Crook <joel at MAIL.K-A.COM> Mar 26, 2000
- 598 views
IAN SMITH WROTE: >It really bothers me when people piss and moan because Euphoria isn't like >C/C++ or Pascal. THE WHOLE BLOODY POINT OF EUPHORIA IS THAT IT ISN'T LIKE >OTHER LANGUAGES. Everytime i check my email and read a message like the one >Joel Crook left and others that contain several underlying insults on RDS >and Euphoria Programmers I burst in to tantrums and swearing fits; if i only >had a tape record 5 minutes ago from writing this. I think the point that is being missed by Mr. Smith and others is C/C++ and Pascal are PRODUCTION languages. Most commercial OSs and Applications are written in these languages. You don't need to be like them to be successful but you DO need to get along with them. The more you get along with them the more sucessful you'll be I attempted to write something in Euphoria that Rob ultimately said wasn't possible because the source code (from C -- source below) used C's "approximations" and that it would not work in Euphoria because Euphoria "is more accurate." Yet two weeks later I hear him defend the inaccuracies of floating point atoms and the Float() function!!! >Chris.B, I commend you for putting Joel Crook in his place. It seems from your remarks neither Chris B. nor you have had to produce "time on target code" and more than likely won't ever be put in that position. I don't like C or C++ or over kill OOP'd Pascal. As I said before Euphoria would be much more ideal if an optimizing compiler were available and it supported types native to C or Pascal. Then (as you can now) pick and choose what you want in your program and still have a small file size. But file i/o s/b part of the core language, saying "it won't be faster seems to me an excuse (it is too much work or a limitation on the part of the programmer's knowledge.) Please tell the list Mr. Bensler or Mr Smith, What size are the applications you wrote as an executable? I seem to recall in TP 7.0 I can write a "hello world" compiled exe program in about 4000 bytes. How big would that executable file be in Euphoria? Can you easily call commercial libraries? Can you easily port your old code into Euphoria because it supports more traditional data types or allows you to build those data types without having to build contorted structures? I hate BASIC but in less three hours I was able to port a C program (the language of obfuscation) into XBasic and have it working. I was NEVER able to port that same code into Euphoria. Explain Mr. S. and Mr B., Why can I easily port between those two languages and NOT be able to get the same code running in Euphoria. >PS:I am really disgusted with the amount of flaming that goes on with this >list,IE: the major insult that Jiri Babor deliverd to four people about some >stupid message, that kept going and going .. ugh. >everyone should realize that this is a list for learning and enlightenment, >not a elementary school playground. >i hope a lot of people read this. >Ian Smith. I can only hope you'll listen to your own advice. Please note: I don't give a hoot what you think of me --- the points I have been trying to make are not aimed at indivuals to "hurt them" but to make them think. If it hurts to be made to think then you should not be attempting to write programs. Mr B. You are a language chauvinist but only because you don't really know any better. Tell you what Mr. B... since you're looking for a project: Port the following 31 lines of C (about 50 it you count the comments) into Euphoria. When you are done you will have 8 different types of Random Number Generators. Don't Snear! If you can't do it then you'll be forced to admit that there is something that Euphoria can't do... And just think you can prove how much smarter than me you are. Until you give it a try you won't know what the limits of your language of choice is... the full transcript of this source and original commentary is available at: http://www.io.com/~ritter/NEWS4/RANDC.HTM or specifically this code: #include <stdio.h> /*The defines are "macros" of the RNGs*/ /*UC is an unsigned character type ie a byte*/ #define znew (z=36969*(z&65535)+(z>>16)) #define wnew (w=18000*(w&65535)+(w>>16)) /*MWC is a multiply with carry RNG using znew and wnew*/ #define MWC ((znew<<16)+wnew ) ? #define SHR3 (jsr^=(jsr<<17), jsr^=(jsr>>13), jsr^=(jsr<<5)) /* The cong RNG is the standard one used in most languages today*/ /*Cong RNG based on Park & Miller , CACM ,31:10 (Oct 1988) */ /*(z) = 16807 * z ( mod 2**31 - 1) */ /* I believe this is the 'type' of RNG Euphoria uses */ #define CONG (jcong=69069*jcong+1234567) /* FIB is the classic Fibonacci sequence */ #define FIB ((b=a+b),(a=b-a)) /*KISS combines 3 different RNG and passes all the diehard tests*/ #define KISS ((MWC^CONG)+SHR3) #define LFIB4 (c++,t[c]=t[c]+t[UC(c+58)]+t[UC(c+119)]+t[UC(c+178)]) #define SWB (c++,bro=(x<y),t[c]=(x=t[UC(c+34)])-(y=t[UC(c+19)]+bro)) #define UNI (KISS*2.328306e-10) #define VNI ((long) KISS)*4.656613e-10 #define UC (unsigned char) /*a cast operation*/ typedef unsigned long UL; /* Global static variables: */ static UL z=362436069, w=521288629, jsr=123456789, jcong=380116160; static UL a=224466889, b=7584631, t[256]; /* Use random seeds to reset z,w,jsr,jcong,a,b, and the table t[256]*/ static UL x=0,y=0,bro; static unsigned char c=0; /* Example procedure to set the table, using KISS: */ void settable(UL i1,UL i2,UL i3,UL i4,UL i5, UL i6) { int i; z=i1;w=i2,jsr=i3; jcong=i4; a=i5; b=i6; for(i=0;i<256;i=i+1) t[i]=KISS; } /* This is a test main program. It should compile and print 7 0's. */ int main(void){ int i; UL k; /*these settable values are required to get the results expected*/ for(i=1;i<1000001;i++){k=LFIB4;} printf("%u\n", k-1064612766U); for(i=1;i<1000001;i++){k=SWB ;} printf("%u\n", k- 627749721U); for(i=1;i<1000001;i++){k=KISS ;} printf("%u\n", k-1372460312U); for(i=1;i<1000001;i++){k=CONG ;} printf("%u\n", k-1529210297U); for(i=1;i<1000001;i++){k=SHR3 ;} printf("%u\n", k-2642725982U); for(i=1;i<1000001;i++){k=MWC ;} printf("%u\n", k- 904977562U); for(i=1;i<1000001;i++){k=FIB ;} printf("%u\n", k-3519793928U); } Joel "When the code works perfectly, the program is obsolete." -- "The Gosple According to St. Murphy"
2. Re: LONG Re: another one bites the dust
- Posted by Robert Craig <rds at ATTCANADA.NET> Mar 26, 2000
- 563 views
- Last edited Mar 27, 2000
Joel Crook writes: > I attempted to write something in Euphoria that Rob > ultimately said wasn't possible because the > source code (from C -- source below) used C's > "approximations" and that it would not work in Euphoria > because Euphoria "is more accurate." I checked my sent items to you, and I never said what you wanted to do was impossible in Euphoria. I gave you some suggestions on how to do it, using and_bits(), remainder and the like. Nor did I say that Euphoria "is more accurate". I said, and I quote: "In C, calculations that result in a value that is too big for 32-bits, quietly overflow with no compiler or run-time error. Many random number generators take advantage of this fact. In Euphoria, values are automatically converted to 8-byte floating-point format when 4-byte integers are not large enough to hold the result. Euphoria gives you the correct answer. C quietly overflows and gives you the wrong answer. However C programmers are used to this, and they exploit it." There is *no* mathematical algorithm that can be calculated in C++ or any other language that can't be calculated in Euphoria. (This is based on computer science theory from over 50 years ago.) I admit that what you are doing is painful. It's because you are converting code that exploits an idiosyncracy of one language that doesn't exist in the other. Similarly, there are many things that you could write in 5 minutes in Euphoria that would take you 5 hours to convert to C++. > Yet two weeks later > I hear him defend the inaccuracies of floating point atoms > and the Float() function!!! If you are fleeing Euphoria because it uses IEEE binary floating-point, think again. C++ and almost all other languages use the exact same floating-point hardware, and will give you exactly the same problems with 0.1 and with floor(). Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: LONG Re: another one bites the dust
- Posted by Chris Bensler <bensler at MAIL.COM> Mar 26, 2000
- 545 views
- Last edited Mar 27, 2000
I think you missed the point of my previous post, Joel. I was chastising you for even bothering with EU. You are quite obviously far beyond the limits of EU. On the other hand, it is perfectly suited for me! I've ported some DJGPP to EU, but that was very basic. I have a copy of GCC. And it looks quite intruiging. But for me, there's no point yet. I can do everything I need in EU. When I do reach the limits of EU, I will move on also. BUT, I will do it with taste, tact and appreciation! --Mr.B ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
4. Re: LONG Re: another one bites the dust
- Posted by Everett Williams <rett at GVTC.COM> Mar 26, 2000
- 554 views
- Last edited Mar 27, 2000
Robert Craig wrote: >Joel Crook writes: >> I attempted to write something in Euphoria that Rob >> ultimately said wasn't possible because the >> source code (from C -- source below) used C's >> "approximations" and that it would not work in Euphoria >> because Euphoria "is more accurate." Rather than express some sense of the loss that an apparently able programmer represents to the list, you have to pick a really debateable point and worry it to death. The uncomfortable issues of communication with the "production" languages of the world is just glossed on by. As a programmer and a technician, my hat is off to you. As a businessman with any sense of commitment and honor toward his paying customers, you are a thin-skinned, tactless ingrate. >I checked my sent items to you, and I never said what >you wanted to do was impossible in Euphoria. I gave you >some suggestions on how to do it, using and_bits(), >remainder and the like. Nor did I say that Euphoria >"is more accurate". I said, and I quote: > > "In C, calculations that result in a value that is too big > for 32-bits, quietly overflow with no compiler or run-time > error. Many random number generators take advantage > of this fact. I believe that this is a reflection of the underlying hardware handling on more than one piece of hardware. C has a habit of being close to the hardware in this fashion. Also, it maintains the type of variables in a much more strict fashion than Euphoria. > In Euphoria, values are automatically converted to > 8-byte floating-point format when 4-byte integers are > not large enough to hold the result. > > Euphoria gives you the correct answer. > C quietly overflows and gives you the wrong answer. > However C programmers > are used to this, and they exploit it." And your solution, as has been pointed out in great detail lately, has as many unexpected side effects as C with less user control. We can't set error traps. We can't prevent the conversion. We're stuck with the "hidden" process and cannot be certain of all the points that it is triggered. Rather a clearly documented error that is actually reflective of the hardware than a loosely defined "solution" that has problems that no one can track for sure. >There is *no* mathematical algorithm that can be calculated >in C++ or any other language that can't be calculated in Euphoria. >(This is based on computer science theory from over 50 years ago.) Cheap shot. Shall we go back to Turing machines. The question is at what cost and with what reliability when we are reliant on non-explicit handling by the great keeper of secrets. >I admit that what you are doing is painful. >It's because you are converting code that exploits an >idiosyncracy of one language that doesn't exist in the other. >Similarly, there are many things that you could write in >5 minutes in Euphoria that would take you 5 hours to convert >to C++. Precious few that matter. We all admit that sequences are a work of genius. It's just that like a lot of genius items, they are not always practical. The huge area of fixed form arrays(note, that I did not say fixed length), or maybe I should say, anything that would like to use columns requires much too painful practices in Euphoria. Sequences appear to be a superset of almost all other data forms. Now if we will all bow down to that thought, will you provide us some of those "practical", "predictable" subsets that have proven so useful in most programs written in the last 50 years. If we could set the type of some of the elements of a sequence, that would yield even more capabilities without harm to the overall concept. Right now, there is almost zero non-Euphoria data that can be dealt with natively in Euphoria without peek and poke or even more convoluted regular Euphoria code. So, the front 45% and back 45% of most programs that deal with that type of data are concerned with the conversion process. The middle 10% actually does real work. And I must say, that middle 10% is wonderful stuff. Clear, straightforward, almost self-documenting code surrounded by miles of four letter words. If all the world used Euphoria type data, then I think you should feel free to ignore those poor, benighted few using other forms. How soon is that going to happen? >> Yet two weeks later >> I hear him defend the inaccuracies of floating point atoms >> and the Float() function!!! > >If you are fleeing Euphoria because it uses IEEE binary >floating-point, think again. C++ and almost all other languages >use the exact same floating-point hardware, and will give you >exactly the same problems with 0.1 and with floor(). > Now that you have beaten with your usual thoroughness the same dead horse that was beaten to death for miles on the list recently, why not admit whatever tiny points your customer might have and offer to him(and the rest of the list) some hope that you have noticed the elephants that are double-parked all around you. Everett L.(Rett) Williams rett at gvtc.com
5. Re: LONG Re: another one bites the dust
- Posted by Mark Brown <mabrown at SENET.COM.AU> Mar 27, 2000
- 573 views
- Last edited Mar 28, 2000
Joel Crook wrote..... > Please tell the list Mr. Bensler or Mr Smith, What size are the applications > you wrote as an executable? I seem to recall in TP 7.0 I can write a "hello > world" compiled exe program in about 4000 bytes. > Um, the conversion of the C++ Morfit "Gouraud Shading" example to Euphoria resulted in a Euphoria bound executable of 251 Kbytes. The same program in C++ as compiled by Morfit is 325 Kbytes. How big in Pascal I wonder? The programs do exactly the same job and the source code is very close to identical. Performance difference is not noticable on my Celeron. The EU source also includes our rather large wrapper includes. I know that this is a trivial example, but then, "hello world" was quoted and I don't think this is less trivial than that. I'm not a C programmer so I guess there is some compiler jiggery-pokery that would result in a smaller C++ executable ???? Mark