Re: Proposal for 'math.e' (2007-08-23)
- Posted by CChris <christian.cuvier at ag?iculture.gou?.fr> Aug 29, 2007
- 682 views
Kat wrote: > > CChris wrote: > > > > > > Hey, nice to see you back around! > > Thanks! > > > Indeed, accessing 64/128 bit integer would require some builtin support, and > I have no idea</font></i> > > whether all supported C compilers support it. For accessing large integers, > I use word64.e at</font></i> > > <a > > href="http://oedoc.free.fr/Fichiers/ESL/">http://oedoc.free.fr/Fichiers/ESL/</a> > > Nice! and you cleverly disguised a poke64() as a conversion > to a memory location in word_to_int64(). > > Question: line 947 in word64.e says: > -- Description: Stores 8 bits at address from input word. > Did you mean 8*bytes* ? > Yep, lol > I like function sprint_word(word w), that's also going to be quite > handy during testing. Have you tested this library to death for > accuracy? It looks like it will be really handy when i can sit > back down at the computer for productive work. > I don't have tested it a lot further than what is in the test file. And I havedn't looked at the code for 18-24 months. As you can see, it was to be possibly included in the ESL, with some minimalist ayatollahs being against. ESL doesn't have any activity, so the files in that directory were left in limbo. I advertise for one or another from time to time, when there's an opportunity. So it was tested, but I wouldn't swear it is 100% bug free, just 97%. > > As for string execution, did you look at Matt's OOEu variant? > > Yes, i did, and i like OOEU a lot. OOEU's oop-ish if you like, > but it isn't if you don't want. I like that implementation of classes a lot. > As an Eiffel programmer, OOP is not a problem for me > But.. it can be *extremely* slow at some things. I suspect converting > it to the newer Eu versions would speed it up, since most of the lag > seems to be in memory allocation when dealing with dozens of megabytes > of data coming in. > This one is tough. One supposedly easy answer would be "let's have a native array of bytes/words/doublewords type", so as to avoid the costly conversion. But the type system of Eu is highly optimised, and a complete, detailed examination would be needed to see if this addition is possible while keeping performance at its current level. When I suggested that, I got some jeers and sneers, so smart, so I haven't looked much further into the matter. > I hope all of OOEU appears in some form in openeu, with appropriate > credits to Matt. > Me too, but... I am not optimistic. CChris > Kat