1. LONG Re: another one bites the dust
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
-
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
-
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
-
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
-
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
