HP-239 Subject: Re: Program lanquage translation Translating programming languages... Within a language family, the hard part usually isn't related to syntax. The hard part is mapping libraries, especially when the target language doesn't have a standard function for a particular feature. This usually involves looking around until you find or recreate the functionality you need. Also unusual uses of pointers can be tricky. I've seen a few programs that could translate C/C++ to and from Java, etc. Going between language families can be much harder. Often, a particular approach that is comfortable on one language is quite roundabout and awkward on another. threshold of pain), translating a program to a new language can be a very good way of learning that language. BTW, what is this decompile of which you speak? Hopefully you have access to the original source code, right? === Subject: Re: Program lanquage translation Every time I've written source code in the past in some language, I have to compile it into the file needed ie. exe, com. I assumed that programs written for the hp followed the same procedure. Needless to say, if I wanted to work on a program compiled for DOS, I would need to decompile, make the change and recompile it. Obviously I know little or nothing about HP programming and the remarks from are probably the best. Simply re-write it all. >Translating programming languages... >Within a language family, the hard part usually isn't related to syntax. > The hard part is mapping libraries, especially when the target >language doesn't have a standard function for a particular feature. >This usually involves looking around until you find or recreate the >functionality you need. Also unusual uses of pointers can be tricky. >I've seen a few programs that could translate C/C++ to and from Java, etc. >Going between language families can be much harder. Often, a particular >approach that is comfortable on one language is quite roundabout and >awkward on another. >threshold of pain), translating a program to a new language can be a >very good way of learning that language. >BTW, what is this decompile of which you speak? Hopefully you have >access to the original source code, right? >Later, > === Subject: Re: Program lanquage translation > Translating programming languages... Rewrite -- === Subject: HP49g+ Infrared Port posting-account=GPLzXA0AAAATuRns6LaJGVCWJnvPLYOO How do I use my hp49g+ infrared port, where the heck inthe guide or manual is infrared port connections covered? Whats my calculator's name that others should send to. === Subject: Re: OPEN FIRE 2.1 OPENFIRE now 2.2 -see details in the NEWS section and in the OPEN FIRE readme file http://fly.cc.fer.hr/~/openfire stay tuned -we're just starting === Subject: Re: OPEN FIRE 2.1 There is only 2.1 as says the Subject line Will you please update your site and then post a new message with OPEN FIRE 2.2 > OPENFIRE now 2.2 > -see details in the NEWS section and in the OPEN FIRE readme file > http://fly.cc.fer.hr/~/openfire > stay tuned > -we're just starting > === Subject: OPENFIRE 2.21 , have you tried PZB and ICE-CUBE ? -now it's 2.21 -added some features for Lilian which will be very usefull to general public by the way new recommended value for palette (for all who might be interested is: #B730) === Subject: Re: OPENFIRE 2.21 cq1rij$s3a$1@ls219.htnet.hr... > by the way new recommended value for palette > (for all who might be interested is: #B730) Maybe put this value on your web page instead of: SET4 -set palette of 4 gray shades out of 16 possible, -expects User binary on STK1 (like #F840) for palette definition -you will be interested to use this in nice palette effects GET4 -reads the current palette -returns User binary (like : #F840) === Subject: Re: OPENFIRE 2.21 > a .8ecrit dans le message de >> by the way new recommended value for palette >> (for all who might be interested is: #B730) > Maybe put this value on your web page instead of: > SET4 > -set palette of 4 gray shades out of 16 possible, > -expects User binary on STK1 (like #F840) for palette definition > -you will be interested to use this in nice palette effects > GET4 > -reads the current palette > -returns User binary (like : #F840) and the news should have the link, too: http://fly.srk.fer.hr/~/openfire/ -- === Subject: Re: Moving from HP48 to latest HP49G+ > Explain then why the hp 49g+ keyboard (both hardware and software) > is - after testing - so fun-da-mentally ?&/%?/(!&%??%)( My guess is that the HP49G+ is poorly designed and not thoroughly tested - something you wouldn't have dreamt of from HP several years ago. It's simply a sh*tty product. It's a bit like leading a football match by an obscene amount of points, and then in the last second being disqualified on a minor technicality. Had HP aced the keyboard on the 49G+, it would have been one killer product - the calc that ended high-end graphic/scientific calcs before the step into PDA-world. Yeah, well, they should also respond a bit faster with software updates, but that's obviously not nearly as important as the keyboard issue. I only objected against your statement that *all* products today are just meant to be thrown away rather than being repaired. That may well be the case for the HP49G+, but it's certainly not the norm and hopefully it won't be until we have nanotech products that can simply be instructed to reform into something else. === Subject: Re: Moving from HP48 to latest HP49G+ X > I only objected against your statement that *all* products today are for consumers: yes(*); for companies: no > just meant to be thrown away rather than being repaired. That may well > be the case for the HP49G+, but it's certainly not the norm and > hopefully it won't be until we have nanotech products that can simply > be instructed to reform into something else. (*) except flat/house, car/motorcycle _anything_ else is too cheap to be repaired (unless there is such a modular design that) (it is the broken part that can thrown away) Do we agree to agree now? :-D === Subject: Re: Moving from HP48 to latest HP49G+ >> just meant to be thrown away rather than being repaired. That may well >> be the case for the HP49G+, but it's certainly not the norm and >> hopefully it won't be until we have nanotech products that can simply >> be instructed to reform into something else. >(*) >except flat/house, car/motorcycle >_anything_ else is too cheap to be repaired Not really. On monday 6th this month my dish-washer said no-no. The tecnician came and some time later he reported that the whole electronic (all steering-parts and the program-chooser with keyboerd) inside was broken. Cost of repair: about EUR 400,- For the machine had cost DM 2.500,- i.e. nearly EUR 1.800,- i ordered the repair and repair parts. Because of: an machine with the same features would have cost nearly the same, i.e. about EUR 2.000,- -- an this i couldn't afford, because i've got a new kitchen just two weeks before the dish-washer broke down. Anyway, i think you have to differ: - would you throw away your washing-machine when it breaks down? ok, you can do so, and sometimes it is the only correct way -- when the cost for buying the machine where somewhat about 400,- /500 Euro, not more. but i guess even you wouldn't throw away a machine, that cost >=1.000 EUR Volker -- Besides, i'm of the opinon, that TCPA has to be stopped === Subject: Re: Moving from HP48 to latest HP49G+ > just meant to be thrown away rather than being repaired. That may well > be the case for the HP49G+, but it's certainly not the norm and > hopefully it won't be until we have nanotech products that can simply > be instructed to reform into something else. >>(*) >>except flat/house, car/motorcycle >>_anything_ else is too cheap to be repaired > Not really. > On monday 6th this month my dish-washer said no-no. The tecnician > came and some time later he reported that the whole electronic (all > steering-parts and the program-chooser with keyboerd) inside was > broken. > Cost of repair: about EUR 400,- > For the machine had cost DM 2.500,- i.e. nearly EUR 1.800,- i ordered > the repair and repair parts. > Because of: an machine with the same features would have cost nearly > the same, i.e. about EUR 2.000,- -- an this i couldn't afford, because > i've got a new kitchen just two weeks before the dish-washer broke > down. > Anyway, i think you have to differ: > - would you throw away your washing-machine when it breaks down? > ok, you can do so, and sometimes it is the only correct way -- when > the cost for buying the machine where somewhat about 400,- /500 Euro, > not more. > but i guess even you wouldn't throw away a machine, that cost >=1.000 > EUR X No, not, because the carbage payments are very high here I guess I would order the parts: it's a modular design have you really read the thread: I already talked about modular designs The repair man will throw away the elctronics and install a new module === Subject: Re: Moving from HP48 to latest HP49G+ >No, not, because the carbage payments are very high here >I guess I would order the parts: it's a modular design A kind of a modular design, ok. >have you really read the thread: indeed, i have. >I already talked about modular designs >The repair man will throw away the elctronics and install a new module ok. Another example: i get tv per satellite. Four years ago i couln't realy switch of my satellite-receiver. I took it to my selller and got it repared. Ok, i had to pay somewhat about DM 80,- but the problem was, that i couldn't find any suitable other analouge-receiver, an those i found where at DM 100,- As i said although i let the seller repair my old one because it is a very good one. But, of course, most time it is cheaper to throw away rather then repair. Volker -- Besides, i'm of the opinon, that TCPA has to be stopped === Subject: Helsinki 2005 would be a great idea! Friday for (Super)Apex and back in Sunday, Correct? When? 12:00-16:00 Helsinki-Cairo time Place: very likely HP-Finland (including sauna) Spending the night: A) Partying all night B) at my flat C) hotel === Subject: Re: Quolity vs. Affordable (read: CCC) >Fluorecent Orange or Pink would be great if you ever lost your >calculator in the bush. Not very practical in the office enviroment >though, haha. >> Incorrect. You could find it much faster, in the chaos on your >> desktop... >not enough, I need a some kind of bluetooth remote control >to make it beep and flash leds, so I can find it. ;-)) Volker -- Besides, i'm of the opinon, that TCPA has to be stopped === Subject: Re: Quolity vs. Affordable (read: CCC) > With CPUs getting faster and gaster there's no need for specialised > HW like a FPU anymore I agree completely. The internal optimizations in e.g. the ARM core also renders much of the specialized processors obsolete. Just the latencies involved in transferring data between two processors will kill any advantages it might have had (in a small computation device like a calc or a PDA). In heavier DAQ equipment you don't use FPUs either - you use cus DSPs and FPGAs (maybe ASICs). That's the way to go if you have a big budget and need alot of number crunching power. But it'd be a waste in a calc. So much time is wasted inputting data anyway. A good multi-threaded OS would be nice though === Subject: Re: Quolity vs. Affordable (read: CCC) >>With CPUs getting faster and gaster there's no need for specialised >>HW like a FPU anymore > I agree completely. The internal optimizations in e.g. the ARM core > also renders much of the specialized processors obsolete. Just the > latencies involved in transferring data between two processors will > kill any advantages it might have had (in a small computation device > like a calc or a PDA). > In heavier DAQ equipment you don't use FPUs either - you use cus > DSPs and FPGAs (maybe ASICs). That's the way to go if you have a big > budget and need alot of number crunching power. But it'd be a waste in > a calc. So much time is wasted inputting data anyway. A good > multi-threaded OS would be nice though > c/- & JYA All this as I once said depends on what you want out of your handheld: * Yes I'd love a multi-threaded O/S, but .. * I also want to have that number crunching capacity in my handheld - for numerics/ modelling yes! ... but not only for this: ...imagine running a real windowing system like Fresco on a handheld (yeah I know, it chews up memory) - but Fresco for one makes extensive use FP instructions, and without an FPU (for the confines of a handheld), you just wouldn't get that real-time interactivity you expect because all floating point instructions need to be emulated. So why would you want to use something like Fresco I hear you say, and I say why not ... why shouldn't I be able to choose my own windowing system - why should I be stuck with what the unit came packaged with. It would be nice to have a desktop in a handheld wouldn't it ... I just ask people to think what they might otherwise consider unthinkable, I don't want a toy I want a truly capable machine in my hand to fashion and use any way I like. -- Manfred (mathmcn@hotmail.dev.null.com) ^^^^^^^^ === Subject: Re: Quolity vs. Affordable (read: CCC) >> With CPUs getting faster and gaster there's no need for specialised >> HW like a FPU anymore > I agree completely. The internal optimizations in e.g. the ARM core > also renders much of the specialized processors obsolete. Just the > latencies involved in transferring data between two processors will > kill any advantages it might have had (in a small computation device > like a calc or a PDA). > In heavier DAQ equipment you don't use FPUs either - you use cus > DSPs and FPGAs (maybe ASICs). That's the way to go if you have a big Ah-haaa! So a bui.9ad-in DSP might not hurt. Ti OMAP for the [NXT] HP-50GX ??? :-P > budget and need alot of number crunching power. But it'd be a waste in > a calc. So much time is wasted inputting data anyway. A good > multi-threaded OS would be nice though > === Subject: Re: Quolity vs. Affordable (read: CCC) > A) A hp 49g+ with it's variable quality keyboard 150 USD Well, the HP49G+ retails for ca. 2000 kroner in Denmark. That's at the current exchange rate something like USD 360! I'd happily pay that amount for a HP49G+ with a flawless keyboard. Qonos? Not for me I think (but we haven't seen the finished product yet, so it's tough to tell). I have so many gadgets it's hard to find time to use them all. I focus on spending my life in a more enrichng fashion - that means cutting down on work and spending alot of time with my son, friends and family. My calculator is used for work, and I cannot use the HP49G+ for that as it is. I don't care if a quality HP49G+ cost a thousand dollars, money is no object for me (now). The house is paid for, my car and motorbike the same. I own half of a small consulting firm, and business is good. And I'm a few months short of 29 years old. I don't have the patience for the HP49G+ keyboard. It's very simple really === Subject: Debug4x Version 2.2 Updated Eric! The big change with V2.2 is support for HP49G+ and 48Gii emulation. BUT, there are no ARM windows in Debug4x AND I personally have no clue as to whether the EMU supports ARM - if you can test, let us all know that answer. (I don't code the EMU or even try, I let the really smart folks do that!). -- - - - - - - - - - - - - - - - - Graves RKBA! bgraves@ix.netcom.com === Subject: Re: Debug4x Version 2.2 Updated WinXP machine. >Eric! >The big change with V2.2 is support for HP49G+ and 48Gii emulation. >BUT, there are no ARM windows in Debug4x >AND I personally have no clue as to whether the EMU supports ARM - if you >can test, let us all know that answer. (I don't code the EMU or even try, I >let the really smart folks do that!). >-- - - - - - - - - - - - - - - - - === Subject: Re: Debug4x Version 2.2 Updated EMU1.36 (in this package) does NOT support ARM programs :(( Y81xd.3787$RH4.2638@newsread1.news.pas.earthlink.net... > Eric! > The big change with V2.2 is support for HP49G+ and 48Gii emulation. > BUT, there are no ARM windows in Debug4x > AND I personally have no clue as to whether the EMU supports ARM - if you > can test, let us all know that answer. (I don't code the EMU or even try, > I let the really smart folks do that!). > -- - - - - - - - - - - - - - - - - === Subject: Re: Debug4x Version 2.2 Updated > Eric! > The big change with V2.2 is support for HP49G+ and 48Gii emulation. > BUT, there are no ARM windows in Debug4x > AND I personally have no clue as to whether the EMU supports ARM - if you > can test, let us all know that answer. (I don't code the EMU or even try, > I let the really smart folks do that!). The ARM emulation doesn't really support the ARM CPU Instead it supports the new (virtual) Saturn II (or Saturn+ ;the choise is yours :) CPU instructions to emulate the new calculators and their ROM. Use HPgcc (or OpenFire for us mere UserRPL people) in order to use the ARM CPU for programming purposes. -- === Subject: Re: CNA423 batch. Good keyboard? posting-account=PUKtNgwAAACqPi8kDc99J0TU9omMMXD5 > I recently purchased one at Fry's in Portland, OR and it has the new CNA > serial number. So far I have had no problems with it, all the keys register > all the time. I'd been using a 48GX for years and loved it. I don't think > I am pressing the keys any harder in the 49G+ than I did in the old 48GX. > On the other hand, I am not lightning fast when typing on it. Finally my 49g+ arrived here in my city. I will grab it on monday. Can't wait anymore!!! :D I hope it's a lucky keyboard :D btw, hpcalc lives! new update after a month. but no games ;.( === Subject: Re: HP49g+ keyboard still crappy posting-account=lP616QwAAACWtQ4L_ZTOCL9ql87Oylbz I just got a replacement for my HP49G+ two months ago. I have logged about 10hr on it so far, classes and writing a new chemistry equation library (coming soon to hpcalc.org) and haven't had a single missed key! The old calc would miss all the time, especially the first key after completing a command. However, the new calc (CNA436...) is a dream. HP cuser service was very understanding about the problem when I told them about the keyboard missing. I would encourage you all with problems to keep sending them back till you get a good one. Jason Anthes CSUS Chemistry > I just got a new HP49g+ a few weeks ago, but the keyboard is crappy, > these keyboards havent seem to improved. My serial number > CN419something something so im guessing this is one of the newer ones, > but still the keyboard is crappy, im guessing 1/30- 1/60 keys miss. > Other than bad keys, I cant see much else wrong with it. === Subject: Re: HP49g+ keyboard still crappy X > HP cuser service was very understanding about the problem > when I told them about the keyboard missing. I would encourage you all X LOL You could say that the keyboard is missing... -- === Subject: On object sizes, etc. (was: Old-timers' mini-challenge) takes more bytes than 1 GET. Just a tiny hint will be fine. > Initially I just assumed that HEAD was a 2.5 byte command - or > are all the commands that were new on the 48G XLIB names - yes > even ADD is a 5.5 byter. The 48G Advanced User's Reference > Manual seems to give no hint of this though. But I guess it > makes sense, if true. Okay, perhaps I'll over-simplify a little, but I'll try. I hope that someone else will correct my mistakes. When I use the word command, I'll usually mean it in an inclusive sense, that is, any built-in named (in the calculator) procedural object, whether it happens to be a type 19 command, a type 18 function, or a type 14 XLIB name. These are the ones that the calculator can compile and decompile as UserRPL code without any added application. Note that constants such as pi and MAXR are actually type 18 functions. In the 48SX/S, all such commands are compiled as 5-nibble pointers, really the addresses of the objects. The obvious advantage is relatively fast execution and decompilation for display. XLIB names, also known as ROM pointer objects, were intended to be used for external library commands stored in ports, whose addresses are fixed after configuration. An XLIB name is actually compiled as the 5-nibble prologue (the address of the code that tells the calculator how to handle a particular object type) for this type of object, followed by the 3-nibble library number, followed by the 3-nibble library command number (within the object, the library could be anywhere within the ports, but rather like a ROM object, it's expected to stay at the same place until the calculator goes through the library configuration process again. If you purge the library, and then try to execute one of the corresponding XLIB names, the calculator won't be able to find the library, so will error out instead. If you just recall it to the stack, then it will be displayed as XLIB l c, where l is the (real) library number and c is the (real) command number. If you install a library, then the library configuration procedure has to be done before the operating system knows where to find it. The operating system has to do a little extra work to look up where XLIB names are actually stored in memory. In the 48G series, all of the commands inherited from the 48SX are still 5-nibble pointers, but all of the new commands added with the 48G series are XLIB names. Why did they do it that way? I don't know. Perhaps simpler and faster development, or limits in addressing ROM. Also note that the 48GX memory management differs significantly from the 48SX, so that was another thing that they had to contend with while developing these new commands. Of course the built-in XLIB names are at a fixed location in ROM for any particular ROM revision, but I suppose that this makes it easier to move the libraries to different ROM locations during development. For the 49G, as far as I've noticed anyway, the only XLIB name inherited from the 48G that's changed to to a 5-nibble pointer is NOVAL, now a type 19 command. I suppose that some 5-nibble pointers could've been changed to 11-nibble XLIB names, but I rather doubt it. What about new commands added with the 49G? Some are 5-nibble pointers, and some are 11-nibble XLIB names. I suspect that non-CAS commands such as NIP and UNROT are 5-nibble pointers, and CAS commands such as AXL are 11-nibble XLIB names, but I don't know whether this is always (or even usually) true. Why should this be? Just guessing, maybe Bernard was developing the CAS more or less independently of the other development, and it was easier to just leave his new CAS commands as XLIB names. Perhaps JYA could comment on the development of the 49G? I doubt that any changes to object sizes occurred with the 49g+, but I can't entirely rule it out. Of course, each object type has it's own size. Although all reals are 21 nibbles, and zints (exact integers) are variable in size, some reals and zints (and various other objects) are actually compiled as 5-nibble pointers to built-in objects, rather than the built-in objects themselves. Sometimes an object type has a fixed size. For example, all reals are 21 nibbles: 5 nibbles for the prologue, 3 nibbles for the exponent, 12 nibbles for the mantissa, and 1 nibble for the sign. Other objects are variable length; for example, character string objects start with the 5-nibble prologue, then a 5-nibble length field, then the characters within the string. So a character string's size (in bytes) is 5+number_of_characters. Note that, as always, each part (prologue, length field, and each character) is stored in memory with the nibbles reversed. Note that length fields are usually self-inclusive (including the length of the length field itself), but not always; a tagged object's length field being at least one exception. I expect that most length fields refer to nibbles, but for a tagged object, it's the number of characters in the tag. Perhaps a tagged objects length field would be better called a character count as it doesn't include the rest of the object, just the characters in the tag part. To see how an object is stored in memory, transfer it to a PC in binary mode and view it with a hex editor, ignoring the 8-byte binary transfer header, and reversing the two nibbles within each byte. Note that the last byte may be padded with a zero nibble to make it a complete byte. If you have a 49 series, it's even easier; just put the object on the stack and use the library 256 ->H command to change it into a character string of the nibbles that make it up. But note that the above methods don't always quite work; for example, 5-nibble pointers to built-in reals and zints are changed from pointers to the objects pointed to by storing them (by themselves) in a global variable or using ->H on them. To work around this, enter the object within a list, then ignore the 5-nibble list prologue 47A20 and epilogue B2130 (nibble-reversed notation) and look at just the nibbles between them. Note that various references for the internal SysRPL/assembler languages explain the objects structures, at least for objects before the 49 series. I'm not entirely certain of the structure of a zint. I think that it's the 5-nibble prologue, a 5-nibble length field, then the (BCD) digits in the number, starting with a leading 0. Well, actually, with each part being written in memory with the nibbles reversed, the leading 0 is at the end in memory. So, the size, in nibbles, of a zint is 11+number_of_digits. Sometimes there's a size advantage to using a zint or a real, but the calculator is rather quirky as to where zints can be substituted for reals. Of course, for the built-in reals and zints compiled as 5-nibble pointers, there's no size difference, unless you store them in global variables, and not being elements of composites. Composite objects, that is, programs, lists, algebraics, and unit objects, aren't fixed length, but don't have any length or dimension fields either; instead they have a pointer to the SysRPL object SEMI to mark the end. Note that the size in memory of a composite object isn't known or easily computed; the operating system has to look at each object within the composite until it gets to the closing delimiter. If you have a lot of elements extracted from composites (actually pointers) on the stack that point into composite objects in temporary memory, it can slow garbage collection drastically. A workaround is to store the composite in a global variable. A tagged object strikes me as rather curious. Of course it starts with the 5-nibble prologue, then a 2-nibble length field, then the characters in the tag, and finally the object that's tagged. Note that this means that adding an empty tag to an object adds only 7 nibbles to it's size, and allows us to get it on the stack without it being evaluated as a command would be. The object that's tagged can only be a single object, but note that it can be a composite object, or even another tagged object. Note that you can't have a tag that isn't attached to another object. Note that sometimes objects that look the same are actually very different. An example is if we compile the source code , we get a 10-nibble empty character string; the 5-nibble prologue, 5-nibble length field, and no characters following. It's decompiled to for the stack display. But if we use Werner's example of C$ 0 as source code, it's compiled as the 5-nibble pointer 055DF (the SysRPL object NULL$) that's the address of an empty string, also decompiled to for UserRPL stack display. If you set flag -85, then you can see the difference. Wickes gives an excellent example of objects that look the same but are different. Keep in mind that the various 5-nibble pointers to built-in objects are changed to the built-in objects themselves when stored in a global variable by themselves. Do the following: 1. 'FOO' STO FOO 1. ->LIST { 1. } You should now have two lists that look the same (at least in UserRPL display mode). Now do: DUP2 ->H SWAP ->H Note that the strings are different. Now do: patterns. Now do: DROP == Note that == also returns 0., because for lists, the bit patterns Note that == and =/ evaluate only reals, zints, complex numbers, and algebraics before testing for equality. The BYTES command is the way to find out an object's size for certain, but how to get a command onto the stack unevaluated? One way is to enter it as an element of a list; for example { HEAD }, then do LIST-> (or OBJ->) DROP to leave HEAD on the stack unevaluated, then BYTES tells us that HEAD takes 5.5 bytes. Another way is to tag it with the empty tag, for example, ::HEAD, and then do BYTES, which tells us that the tagged object has 9 bytes, so subtract 3.5 bytes for the empty tag, to find that HEAD takes 5.5 bytes. Yet another way is to run BYTES on the list { HEAD }, which tells us that the list takes 10.5 bytes, and subtracting 5 bytes for the overhead of having it in a list, we arrive at 5.5 bytes for HEAD. The operating system logic requires that certain program structure clauses be a single object. In particular, THEN...END, THEN...ELSE, ELSE...END, IFERR...THEN, and REPEAT...END clauses all contain exactly one object. If the source code has more than one object for the clause, then the compiler encloses them within a single secondary, but if the source code has only a single object there, this isn't done. Also note that if you leave one of these clauses empty, then an empty secondary (10 nibbles) is inserted there. That's why going from a single object in such a clause to two objects in it adds not just the size of the added object, but an extra 10 nibbles besides, and removing the only object in a clause may actually increase the size. If you can find a way to have exactly one object in such a clause, that helps keep the size down. Note that the above doesn't apply to the clauses IF...THEN, CASE...THEN, the END...END in a case structure, WHILE...REPEAT, or to the structures DO...UNTIL...END or START/FOR...NEXT/STEP. If you set flag -85, you can see the added secondary, as well as various different kinds of THEN and END. Of course, you can figure out how big a program should be depending on what it contains, but it's not as straight-forward as one might naively think, so to be sure of it's size, use the BYTES command on it. One more note. If you store an object in a variable and then run BYTES on the variable's name, then the size returned includes the size of the variable's name, although the checksum is for only the contents of the variable. Recall the contents to the stack and run BYTES on that to get the size of the object only. -- === Subject: Re: On object sizes, etc. (was: Old-timers' mini-challenge) X > Okay, perhaps I'll over-simplify a little, but I'll try. I hope > that someone else will correct my mistakes. When I use the word > command, I'll usually mean it in an inclusive sense, that is, > any built-in named (in the calculator) procedural object, whether > it happens to be a type 19 command, a type 18 function, or a > type 14 XLIB name. These are the ones that the calculator can > compile and decompile as UserRPL code without any added > application. Note that constants such as pi and MAXR are > actually type 18 functions. X If you key in pi directly from the keyboard (instead of { pi } HEAD) it will have a type of 9. 'Algebraic' The same goes for oo, i, e Just to tell you all about this bug -- === Subject: Re: On object sizes, etc. (was: Old-timers' mini-challenge) <10663271ROBOTLX@news.individual.ne t> <8Nwwd.191$qw2.75@fe61.usenetserver.com> <11435669ROBOTLX@news.individual.net> <11477117ROBOTLX@news.individual.net> <%69xd.575$VQ2.515@fe39.usenetserver.com> X-NNTP-Client: ROBOT/LX -=[ Sun, 19.12.04 8:17 p.m. +1300 (NZDT) ]=- , in message ID <%69xd.575$VQ2.515@fe39.usenetserver.com> : [...big snip, but all read, and will be re-read too] > The BYTES command is the way to find out an object's size for > certain, but how to get a command onto the stack unevaluated? One > way is to enter it as an element of a list; for example { HEAD }, > then do LIST-> (or OBJ->) DROP to leave HEAD on the stack > unevaluated, then BYTES tells us that HEAD takes 5.5 bytes. > Another way is to tag it with the empty tag, for example, ::HEAD, > and then do BYTES, which tells us that the tagged object has 9 > bytes, so subtract 3.5 bytes for the empty tag, to find that HEAD > takes 5.5 bytes. Yet another way is to run BYTES on the list > { HEAD }, which tells us that the list takes 10.5 bytes, and > subtracting 5 bytes for the overhead of having it in a list, we > arrive at 5.5 bytes for HEAD. To find the size of HEAD I do << HEAD >> BYTES and subtract 10. Empirically this works but my 48G AUR states that the SIZE of a program object is 12.5 + size of included ongjects. I never figured out that 12.5, as it appears to be 10. In future I think I'll do the empty tag method and subtract 3.5. -- === Subject: Re: On object sizes, etc. (was: Old-timers' mini-challenge) > in message ID <%69xd.575$VQ2.515@fe39.usenetserver.com> : > [...big snip, but all read, and will be re-read too] >> The BYTES command is the way to find out an object's size for >> certain, but how to get a command onto the stack unevaluated? One >> way is to enter it as an element of a list; for example { HEAD }, >> then do LIST-> (or OBJ->) DROP to leave HEAD on the stack >> unevaluated, then BYTES tells us that HEAD takes 5.5 bytes. >> Another way is to tag it with the empty tag, for example, ::HEAD, >> and then do BYTES, which tells us that the tagged object has 9 >> bytes, so subtract 3.5 bytes for the empty tag, to find that HEAD >> takes 5.5 bytes. Yet another way is to run BYTES on the list >> { HEAD }, which tells us that the list takes 10.5 bytes, and >> subtracting 5 bytes for the overhead of having it in a list, we >> arrive at 5.5 bytes for HEAD. > To find the size of HEAD I do << HEAD >> BYTES and subtract I do: {HEAD} [ENTER] [ENTER] [EVAL] BYTES [ENTER] :-D > 10. Empirically this works but my 48G AUR states that the SIZE > of a program object is 12.5 + size of included ongjects. > I never figured out that 12.5, as it appears to be 10. > In future I think I'll do the empty tag method and subtract > 3.5. > -- > === Subject: Re: Old-timers' mini-challenge <10663271ROBOTLX@news.individual.ne t> <8Nwwd.191$qw2.75@fe61.usenetserver.com> <11435669ROBOTLX@news.individual.net> <11477117ROBOTLX@news.individual.net> X-NNTP-Client: ROBOT/LX -=[ Sun, 19.12.04 1:06 p.m. +1300 (NZDT) ]=- Darn I see looking back at Khanh-Dang's veru first post on 1 Dec he has OVER TYPE OVER where Virgil has DUP2. So, the recursive program can use an example_of_type as input but the program needs modification a little deeper in (than the non-recursive ones), and costs 5 bytes, and keeps taking the TYPE over and over . -------- 1 day 11h45m ago, on Fri, in message ID : > -=[ Fri, 17.12.04 10:18 p.m. +1300 (NZDT) ]=- > Hutchins, : >>Hi >>in message ID <8Nwwd.191$qw2.75@fe61.usenetserver.com> : >> Also, the >>non-recursive leaders all take type as input, but that can be >>changed to take an example of type by adding an initial TYPE. >>But because of the way the recursive program had to be >>written, to be competitive, it can *only* take type as input. How so? Insert a TYPE command at the beginning of the program. It >looks to me as if that works just fine. >>But it can't because it is fully recursive. If you add a >>TYPE up front and input say >>{1 2 3} 4 >>The output will be {2 3} instead of {} >>Because first up TYPE(4)=28. and that drops out the 1, but the >>second time through the TYPE(28.)=0. and thereafter it will >>only drop reals. > Okay, now I see what you mean. [...] -- #209 The noisiest drum has nothing in it but air. English Proverb === Subject: Re: Old-timers' mini-challenge > -=[ Sun, 19.12.04 1:06 p.m. +1300 (NZDT) ]=- > > Darn I see looking back at Khanh-Dang's veru first post on 1 > Dec he has OVER TYPE OVER where Virgil has DUP2. > So, the recursive program can use an example_of_type as input > but the program needs modification a little deeper in (than > the non-recursive ones), and costs 5 bytes, and keeps taking > the TYPE over and over . Can you PUT out such a program -- === Subject: Re: Old-timers' mini-challenge <10663271ROBOTLX@news.individual.ne t> <8Nwwd.191$qw2.75@fe61.usenetserver.com> <11435669ROBOTLX@news.individual.net> <11477117ROBOTLX@news.individual.net> <10894889ROBOTLX@news.individual.net> X-NNTP-Client: ROBOT/LX -=[ Sun, 19.12.04 4:28 p.m. +1300 (NZDT) ]=- Veli-Pekka Nousiainen, in message ID : > -=[ Sun, 19.12.04 1:06 p.m. +1300 (NZDT) ]=- > > Darn I see looking back at Khanh-Dang's veru first post > on 1 Dec he has OVER TYPE OVER where Virgil has DUP2. > So, the recursive program can use an example_of_type as > input but the program needs modification a little deeper > in (than the non-recursive ones), and costs 5 bytes, and > keeps taking the TYPE over and over . > Can you PUT out such a program Working from Virgil's 72.5 byte 49G/g+ entry: @ Level 1 argument: Real type number << OVER SIZE { SWAP OBJ-> 1 - ->LIST UNROT DUP2 TYPE =/ NDUPN ->LIST UNROT RELMTYPE + } :: DROP IFTE and replacing DUP2 with OVER TYPE OVER we obtain this 77.5 byte version @ Level 1 argument: Example << OVER SIZE { SWAP OBJ-> 1 - ->LIST UNROT OVER TYPE OVER TYPE =/ NDUPN ->LIST UNROT RELMTYPE + } :: DROP IFTE It now looks more like Khanh-Dang's initial version, except he was writing for the 48G, favouring the use of ROT, although converting K-D's version to the 49G using NDUPN brings it to just .5 bytes of Virgil's! Fascinating - Instead of the 7.5 byte =/ NDUPN ->LIST above, K-D has the 27.5 byte =/ SWAP 1. ->LIST 1. ->LIST {{}} IFTE Sears' ingenious 20 byte =/ 1 {DROP 0} IFTE ->LIST seems the best for the 48S/G. I'm sure K-D would like 's code as in his post he was complaining about two extra lots of 5 bytes that he felt shouldn't be required (extra 1 ->LIST and {}). gives him back 7.5 of them ;-) K-D's original post is very interesting - especially the reference to the caml programming language - I must give it a try. -- #28 Wife:Whisper something dirty in my ear.Husband:Kitchen. === Subject: Re: Old-timers' mini-challenge X >> Can you PUT out such a program > Working from Virgil's 72.5 byte 49G/g+ entry: > @ Level 1 argument: Real type number > << OVER SIZE { SWAP > OBJ-> 1 - ->LIST UNROT > DUP2 TYPE =/ NDUPN > ->LIST UNROT RELMTYPE > + } :: DROP IFTE > and replacing DUP2 with OVER TYPE OVER we obtain this 77.5 > byte version > @ Level 1 argument: Example > << OVER SIZE { SWAP > OBJ-> 1 - ->LIST UNROT > OVER TYPE OVER TYPE =/ NDUPN > ->LIST UNROT RELMTYPE > + } :: DROP IFTE > It now looks more like Khanh-Dang's initial version, except he > was writing for the 48G, favouring the use of ROT, although > converting K-D's version to the 49G using NDUPN brings it to > just .5 bytes of Virgil's! Fascinating - > Instead of the 7.5 byte > =/ NDUPN ->LIST > above, K-D has the 27.5 byte > =/ SWAP 1. ->LIST 1. ->LIST {{}} IFTE > Sears' ingenious 20 byte > =/ 1 {DROP 0} IFTE ->LIST > seems the best for the 48S/G. X I think I GET it I also DROP the subject (object :) 'cause I have nothing to ADD I'm NOT satisfied with my recursive VERSION OR IF it is a SIN THEN I ASSUME the END is near... AXES are hanging above my HEAD (which is a BLANK BOX - isn't that CLEAR ? - I have to ERASE my memory) AND I have my TAIL between my legs I will NOT go to a BAR to take a NIP of ROOT beer I will not ROLL OVER OR take a STEP in wrong direction IF I can CHOOSE my END and the TYPE of life I can live. my BASIS is on Bible. God RULES ! He is the way and the TRUTH Men and woman have some SORT of PARITY in this SPHERE Just don't try to CONVERT me: I will NOT KILL: I'm NOT MEAN My soul will be FREE, He will UNBIND me and PURGE me from SIN The Lord will RESTORE me AND I will sit on His LAP When I move an item from any of the BINS to this BIN OFF the record: I will MERGE the MODULAR approach I have in STORE AND APPLY the NEXT generation SERIAL process [with great POTENTIAL to SCALE down in SIZE RATIO in ORDER to to take a PATH. Don't PEEK through the keyhole OR as a RESULTANT I come to VISIT you and PICK your eyes out (OR POKE them OR strangle you UNTIL they POP out). I will SCATTER you all OVER the place AND REORDER your ROOT canals AND SEND you to a SHOW that you will remember A POLAR bear will eat your REMAINDER Don't PUSH me, don't PROMPT me - OR I will PUT you to death (using my PSI talents, which I RANK as good Psi) there will be no TRACE of you OR your country on any MAP. You may ROT in hell! You can QUOTE that in any tv SERIES! They need to REWRITE the history. I DO hear a BEEP WHILE CONSTANTS are variables I REPEAT UNTIL the END (Will hell FREEZE OVER?) I have a DATE with a CON - what TIME it is ? DELAY guests, they can WAIT, I need to DETACH my HEAD FIX it OR it will DROP in to the FLOOR before I can ATTACH it back I will EXPAND my FACT on this CASE with a FACTOR OR FACTORS FOR nothing. I will SWAP a tank into a SUB. Oh, it will NOT FUNCTION (I ASSUME) if I don't GET HELP from HOME - where is my KEY? DEFINE MAD AND DEGREE of madness OR ELSE... I DRAW a grazy IMAGE OR PICTURE out of an ARCHIVE. The MAIN thing is: there is a thin LINE between a PLOT against me you - you ZEROS can SIMPLIFY and ANIMATE like ARC of a womans CURL, which you can COLLECT using a COMB LEGENDRE, RISCH, TCHEBYCHEFF AND VANDERMONDE out of this OR I will go HYBERBOLIC Can you AUGMENT that in this CASE ? Is in on the MAP ? THEN END is END but I can't FINISH this START to SOLVE (AND fast, TIME TICKS away) how many KEY words where NOT used in this TEXT that's in the MAIN MENU -- Subject: Re: Old-timers' mini-challenge OFFICIAL ENTRY revised X-NNTP-Client: ROBOT/LX -=[ Sat, 18.12.04 1:40 p.m. +1300 (NZDT) ]=- Veli-Pekka Nousiainen, in message ID : > One more time I just have to say this: > I love recursion OK, we must go back and have another look then ;-) [...] > Think about 'RT' - how short it is. Indeed it is 66.5 byes then on the 49G/g+ = JoGa - .5 Let's have fun and go for 66. I'd like to see NDUPN jump to the front again [...] > Finally JoGa beat us all (but was one hour late) > The + trick before ->PRG was as neat as my ->PRG > and made me bow to this new Jedi Knight I took the 70.5 byte one my dog did specifically for the 49g+, with the 5 PICK, and jumped on it till it actually shrunk enough. The + + ->PRG hard codes the input type(T) *and* the List size below, so these don't need removing after the DOLIST - that saved 5 bytes and luckily the rest only added an extra 0.5 bytes overall. Input 2: List = {e1 e2 ...} 1: T (real or Zint) Output 1: { ei s.t. TYPE(ei) # T } << { } UNROT 1 PICK3 SIZE ROT @stack={} List 1 SIZE(List) T { PICK3 TYPE =/ AND NDUPN ->LIST + } + + ->PRG DOLIST 66 bytes, checksum #AF64h. Purely for the 49g+ as it relies on the DOLIST bug whereby an empty input list doesn't error out. The SIZE is just used to filter out the empty program the 49g+ DOLIST spies in an empty input list. It looks ugly and verbose, but BYTES=66 indeed! I think I liked your challenge because RELMTYPE discards the objects conforming to a certain type. This means it saves the oddballs! -- === Subject: Re: Old-timers' mini-challenge OFFICIAL ENTRY revised <10989145ROBOTLX@news.individual.net> X-NNTP-Client: ROBOT/LX -=[ Sat, 18.12.04 3:58 p.m. +1300 (NZDT) ]=- in message ID <10989145ROBOTLX@news.individual.net> : > Input > 2: List = {e1 e2 ...} > 1: T (real or Zint) > Output > 1: { ei s.t. TYPE(ei) # T } > << { } UNROT 1 PICK3 SIZE ROT @stack={} List 1 SIZE(List) T > { PICK3 TYPE =/ AND NDUPN ->LIST + } + + ->PRG > DOLIST > 66 bytes, checksum #AF64h. Purely for the 49g+ Again following JoGa's method of {...} + ->PRG here we have another 66 byter, for the 49G/g+. Input 2: List = {e1 e2 ...} 1: Obj Output 1: { ei s.t. TYPE(ei) # TYPE(Obj) } <<{ } OVER 2 ->LIST ROT + SWAP TYPE @stack={{} Obj} TYPE(obj) { OVER TYPE =/ NDUPN ->LIST + } + ->PRG 49g+ Checksum:E918h -- #321 A life spent making mistakes is more useful than a life spent doing nothing. G-B Shaw *