binarys in a matrix
Madeleine Ansford
Can you enter binary integers into a matrix on a 49g?
My calculator tells me it is a bad argument type.
Thanks,
Blair
Steen Schmidt
Not in the normal user environment. It's not a problem in SysRPL though.
Regards
Steen
Veli-Pekka Nousiainen
VPN
"Steen Schmidt" <ssch...@nospam.dk> wrote in message
news:8RM99.13311$ww6.1...@news010.worldonline.dk...
Steen Schmidt
It doesn't work - I tried it before writing here. It was the first thing
that sprung to mind ;-)
Regards
Steen
Veli-Pekka Nousiainen
and ->ARRY did not work
anything I tried on the matrix writer didn't work
Only hackering with ->H H-> might work
but I will let Steen to try that one
;-)
VPN
"Steen Schmidt" <ssch...@nospam.dk> wrote in message
news:T%P99.13366$ww6.1...@news010.worldonline.dk...
Nick Karagiaouroglou
(Old greek trembling voice)
My son, these things are only for those incombatible with the rest of
the human race!
Here thy solution!
What is allowed to be in a matrix? Right, reals complex numbers
integers and algebraic objects. Is there any command that will turn
anything to one of these types? Yes, its name is ->ALG.
Whatever it is, though shall put it in a list, make it algebraic thru
->ALG and then compose your array with AXL.
Example:
{ POS } ->ALG. (Returns a nice algebraic containing POS
{ ^ } ->ALG (Returns and algebraic 'Invalid Expression'.)
2 ->LIST (first row)
<< 0 1 10 FOR I I SQ + NEXT >> ->LST ->ALG (Also 'Invalid Expression')
2 (let's put a normal element)
2 ->LIST (second row)
2 ->LIST (list of lists now contains algebraic objects)
AXL
Voila! A new WOB (weird object) appears. Or is it GIOB? (Greek
Incombatible OBject?) Or HIOB? (Hellenic Incompatible Object) ;-)
Greekkings,
Nick
"Veli-Pekka Nousiainen" <DROP...@welho.com> wrote in message news:<yBQ99.1092$D8.3...@reader1.news.jippii.net>...
Veli-Pekka Nousiainen
Did you try your ->ALG on a binary or sysbin ??
Obviously not :(
Leave out the spaces from the next object:
"68620 11920 FF000 11920 AF000 11920 BB000 B2130"
then use H-> to get a symbolic matrix with system binaries on it.
Note that this is in Hebrew eg. right to left.
VPN
"Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
news:cd9ca36b.0208...@posting.google.com...
X
Veli-Pekka Nousiainen
> Leave out the spaces from the next object:
> "68620 11920 FF000 11920 AF000 11920 BB000 B2130"
> then use H-> to get a symbolic matrix with system binaries on it.
> Note that this is in Hebrew eg. right to left.
but anyone keying in that string leaves out the spaces,
which are there for clarity and to separate object prologs from
the actual system binary values.
02911 = call 911, you've got a system binary in your matrix !!
0312B = end of a list or a symbolic matrix
02A74 = list
02686 = symbolic matrix
Hey! I'm learning SysRPL (when I have to :)
VPN
Nick Karagiaouroglou
> Hi, Nick!
> Did you try your ->ALG on a binary or sysbin ??
> Obviously not :(
May I interrupt you, oh my son, I did, I did. It was quite a surprice
but it worked. Remember though shall put your binary or system binary
or whatever, in a list and then let ->ALG convert it to an algebraic
object. Example:
#27d 1 ->LIST ->ALG @At this point you have the algebraic
@'# 27d' on stack.
1 ->LIST AXL @Gives you the 1-dimensional vector
@[ '# 27d' ]
Or:
27 R~SB 1 ->LIST ->ALG @Here you get 'Invalid Expression'.
@Nosy will tell you that the HP49G just can't
@*show* the object correctly, but the object
@is just fine in its inner world.
1 ->LIST AXL @Leaves [ 'Invalid Expression' ] on stack.
Example of a bigger matrix with binaries:
1 5 FOR I
1 5 FOR J
I J * R->B 1 ->LIST ->ALG
NEXT
5 ->LIST
NEXT
5 ->LIST
AXL
Apply Nosy to the result to see:
MATRIX
MATRIX
SYMBOL
HXS 00010 1000000000000000
;
SYMBOL
HXS 00010 2000000000000000
;
SYMBOL
HXS 00010 3000000000000000
;
SYMBOL
HXS 00010 3000000000000000
;
;
....and so on....
;
Same with system binaries
Example of a bigger matrix with binaries:
1 5 FOR I
1 5 FOR J
I J * R~SB 1 ->LIST ->ALG
NEXT
5 ->LIST
NEXT
5 ->LIST
AXL
Apply Nosy to the result to see:
MATRIX
MATRIX
SYMBOL
BINT1
;
SYMBOL
BINT1
;
SYMBOL
BINT3
;
SYMBOL
BINT4
;
;
....and so on....
;
> Leave out the spaces from the next object:
> "68620 11920 FF000 11920 AF000 11920 BB000 B2130"
> then use H-> to get a symbolic matrix with system binaries on it.
> Note that this is in Hebrew eg. right to left.
> VPN
I prefer Greek left to right. But it's good to have many methods that
can be used to do the same thing.
Greetings,
Nick.
Nick Karagiaouroglou
In this case we can do without SysRPL. But nice to know the way, thanks.
Greetings,
Nick.
Jean-Yves Avenard
"Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
news:cd9ca36b.02082...@posting.google.com...
> 27 R~SB 1 ->LIST ->ALG @Here you get 'Invalid Expression'.
> @Nosy will tell you that the HP49G just can't
> @*show* the object correctly, but the object
> @is just fine in its inner world.
This is by choice.
The MetaKernel v2.0 used to display ALG blahblah END
But we took the decision to display Invalid Expression instead.. Less
confusing
Jean-Yves
Still wondering why people would want to put a binary in a matrix and not
use a list of list
Madeleine Ansford
> Jean-Yves
> Still wondering why people would want to put a binary in a matrix and not
> use a list of list
Thankyou everyone for the responses,
My rational for using binary in a matrix,
I am writing a series of programs which simulate the instructions of a
pic16f84 microcontroller,
as I am both new at assembly and system rpl, I am writing a working version
in user rpl, to get it going,
then perhaps translate it to system rpl or assembly.
The matrix is to simulate the memory map of the pic, which is, 1024 by 14
bits for the instructions, 256 by 8 bits for ram (including control
registers) and 64 by 8 bit for the eeprom.
I use the matrix writer to enter the "instructions" directly into the
"memory" and was hoping to use it to view the results.
But at the moment I have to convert from binarys to reals to put it into the
matrix.so I cant view the binarys in the matrix writer.
Blair.
Veli-Pekka Nousiainen
Why not please the lady and let us all work with "symbolic" matrices
of *any* type directly in the MatrixWriter in the 1.19-7 *BETA*
Note:
When my method of using the ->H H-> to construct the Sysbin Matrix
it is displayed properly AND can be _viewed_ in the MatrixWriter.
But in order to modify/create you have to do some ->H H-> again.
VPN
"Madeleine Ansford" <mans...@powerup.com.au> wrote in message
news:P_za9.16606$Cq.6...@ozemail.com.au...
John H Meyers
> at the moment I have to convert from binaries to reals
> to put it into the matrix,
> so I can't view the binaries in the matrix writer.
The Matrix Writer can view (but not edit) any elements
in a matrix; your only problem is to construct a matrix
containing binary elements, which can be done
by first making a list of those elements,
then converting the list to an "array" (object type 29).
The following version of AXL, just like the original built-in version
(before all this fun was censored out), will make a "matrix"
from lists of binaries -- or almost anything else (e.g. programs!)
For example:
{ #1234 #5678 } LXA ==> [ #1234 #5678 ]
Or, if you prefer a "vertical" matrix:
{ { #1234 } { #5678 } } LXA
Resulting in:
[[ #1234 ]
[ #5678 ]]
Note that these results can still be viewed (but not edited)
in the Matrix Writer.
Repeat LXA (or AXL) to change back to a list.
The 'LXA' program (HP49 only):
\<< \<< DUP TYPE 5. == { 1. \<- DOSUBS 9862.
#262F1h SYSEVAL #5AB3h SYSEVAL } IFT \>> \-> \<- \<<
IF DUP TYPE 5. == THEN \<- EVAL ELSE AXL END \>> \>>
Note that this program requires the "left arrow" symbol \<-
(character number 142) from the CHARS menu, which is used
three times (whereas the "right arrow" symbol is used only once).
It is a good idea to first make a precautionary memory backup,
because any mistakes with SYSEVAL may trash the memory.
-------------------
"Imagination is more important than knowledge" [Albert Einstein]
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Nick Karagiaouroglou
> Hello
>
> "Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
> news:cd9ca36b.02082...@posting.google.com...
> > 27 R~SB 1 ->LIST ->ALG @Here you get 'Invalid Expression'.
> > @Nosy will tell you that the HP49G just can't
> > @*show* the object correctly, but the object
> > @is just fine in its inner world.
>
> This is by choice.
> The MetaKernel v2.0 used to display ALG blahblah END
> But we took the decision to display Invalid Expression instead.. Less
> confusing
Nevertheless a user binary number *is* displayed properly when brought
in an algebraic and is still displayed properly when this algebraic is
in a matrix. Without saying that displaying 'Invalid Object' is a bug,
I rather consider it somehow misleading, because the object doesn't
seem to be invalid as it has the proper structure. On the other hand
of course, it could be called invalid, since the system - the directly
available system for the UserRPL users - will not handle such objects
most of the time, so from this point of view it's good to "warn" the
user that such an object isn't supported.
> Jean-Yves
> Still wondering why people would want to put a binary in a matrix and not
> use a list of list
Hmmm, everybody who wants to do so has surely reasons. Even if these
reasons are "just for the fun of it".
The main reason though, is generalization. Exactly the same reason, I
think, that makes many of us (including me) wishing to have for
example units, matrices or even programs in algebraics. I don't say
that the supported objects are not powerful enough, it's more kind of
thoughts and wishes for a (hypothetical) super CAS and its
(hypothetical) power.
Greetings,
Nick.
Jean-Yves Avenard
"Madeleine Ansford" <mans...@powerup.com.au> wrote in message
news:P_za9.16606$Cq.6...@ozemail.com.au...
[snip]
> I use the matrix writer to enter the "instructions" directly into the
> "memory" and was hoping to use it to view the results.
These are all good reasons, but I still don't see the reasons for using the
MATRIX type to what you want over the use of list of list.
Lists are supported and designed exactly what you're doing.
If you want to use a matrix to do some operations in it, just use reals you
can always convert them when required into binary
> But at the moment I have to convert from binarys to reals to put it into
the
> matrix.so I cant view the binarys in the matrix writer.
And if you want to use the matrix writer to edit a list of lists, it's
perfectly possible.
Just set the flag -91 and run the matrix writer in your list of list.
Sometimes, you really wonder what's going on in this newsgroup, somebody ask
a question, and you get the most wierd answers when an easy answer is
usually available...
Jean-Yves
Cyrille de Brébisson
> I am writing a series of programs which simulate the instructions of a
> pic16f84 microcontroller,
>
> as I am both new at assembly and system rpl, I am writing a working
version
> in user rpl, to get it going,
>
> then perhaps translate it to system rpl or assembly.
>
> The matrix is to simulate the memory map of the pic, which is, 1024 by 14
> bits for the instructions, 256 by 8 bits for ram (including control
> registers) and 64 by 8 bit for the eeprom.
My advice, especially if you are planning to convert the whole thing to ASM
at one point is to use strings rather than Matrices... You can edit the
string easely in command line (or even make a small program to edit them in
a more easy way), you can then use the S->H to convert the Hexa characters
in binary and you will have rocket fast access to the data in your program,
making your whole simulator faster. in addition, when you switch to ASM, it
will make things much easier as all your 'programs' will be compatible..
regards, Cyrille
John H Meyers
> Lists are supported and designed exactly what you're doing.
> And if you want to use the matrix writer to edit a list of lists,
> it's perfectly possible.
> Just set the flag -91 and run the matrix writer in your list of list.
Eureka!
> Sometimes, you really wonder what's going on in this newsgroup,
> somebody ask a question, and you get the most wierd answers
> when an easy answer is usually available...
Same thing when it comes to stopping wars, ending terrorism,
curbing crime, solving the health care crisis,
and many other human problems, where the whole of society
and its leaders continually follow paths of struggle,
expense, effort, and even great destruction, when in fact
there is a path of simplicity and success which is vastly easier,
operating at the root of all of these matters,
which is the field of consciousness, where all intelligence comes from.
You see the manifestation of the power of intelligence
in your own work, and we see it in every human activity,
encouraged by an all-encompassing educational initiative.
.
Jean-Yves Avenard
"Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
news:cd9ca36b.02082...@posting.google.com...
> Hmmm, everybody who wants to do so has surely reasons. Even if these
> reasons are "just for the fun of it".
Yes, and this reason was just to use the Matrix Writer... So my claim to use
list of lists (which is a very similar structure as the Matrix, except that
it's officially supported, is even more accurate
>
> The main reason though, is generalization. Exactly the same reason, I
> think, that makes many of us (including me) wishing to have for
> example units, matrices or even programs in algebraics. I don't say
I totally disagree as you can achieve the same goals by using existing
objects like list or programs. Algebraic objects have a meaning and a
definition which has to be respected if you don't want to make a system even
less intuitive for users.
Flexibility has a dark side sometimes and I personnaly find the HP49 way too
flexible. At the end, it becomes so hard to use that not many people are
using it.
Jean-Yves
Madeleine Ansford
Flag -91 didn't occur to me, thanks for that Jean-Yves
However, looking at Cyrille's idea, I like that the most as it uses up very
little memory and is much faster.
Having made a string of 256 8 bit blocks, I have no trouble fetching the
characters from the string using the SUB command,
and then converting them back to their hex equivilant using S->H. This gives
me "0F" for example.
might be easier with an example:
on the stack is the string, as well as position to retrieve,
2:"*********"
1:3
Program is << DUP SUB S->H "#" SWAP "h" + + OBJ-> >>
This nicely converts the character back into a binary.
However, I cannot seem to figure out how to do it the other way round in a
simple manner.
If I have # 1h on the stack, converting it to a string would be "# 1h" and
that will not be right. what i want to do is go from
# 1h to "01" or # Fh to "0F" as i can convert "0F" with H->S but not # Fh.
any number that I convert using H->S must be in the form of "00" as say "A"
and "0A" give me different results when using H->S
I am sure there is probably a simple command in there somewhere which will
do it for me, just like i didnt know about flag -91 :) but I dont know
where.
Thanks for the feedback
Blair.
"Cyrille de Brébisson" <cyrille_de...@hp.com> wrote in message
news:akfvoo$kl5$1...@web1.cup.hp.com...
Veli-Pekka Nousiainen
> Flag -91 didn't occur to me, thanks for that Jean-Yves
> However, looking at Cyrille's idea, I like that the most as it uses up
very
> little memory and is much faster.
X
> If I have # 1h on the stack, converting it to a string would be "# 1h" and
"# 1h" (or anything else in hex binary)
3 OVER SIZE 1 - SUB
> that will not be right. what i want to do is go from
> # 1h to "01" or # Fh to "0F" as i can convert "0F" with H->S but not # Fh.
"F0" rather than "0F", see 2) if from hex to string,
but a character is 2 digits, see 1)
> any number that I convert using H->S must be in the form of "00" as say
"A"
> and "0A" give me different results when using H->S
Even "A0" and "A" will give different results
but the data is intact and can be restored, you need to operate with
2 hex digits at time (or 4, 6, 8,...64) in order this to work, see 1
****************************************************************************
****
I'm not sure what to say, others will probably give a more clear answer
but let's try anyway:
1) Padding with a zero to form a character
# Ah << 3 OVER SIZE 1 - SUB >> EVAL => "A" @ pad this !!!
"0" + => "A0" H->S => newline-character NUM => 10. R-> B => # Ah
***
a single nibble=4 bits= 1 hex digit can not form a character=8 bits=byte
You can operate only one even number of hex digits in order to form
proper characters in a string.
2) Little/Big endian. Some processors, like the Saturn CPU reads and writes
the data from right to left like Hebrew. The problem is that in many
Middle-east
nations (Arabian is right to left, too) the poor programmers have to think
of
those CPU's (TI 89 has MC68000 variant) which read and write awkwardly
from left to right (like in English, French, Finnish, ...)
Note: data is always ok, no matter how the CPU interprets it
UNLESS...
"0A" and "A0" are the same if you change the CPU style in-between
(some CPU can be mode-switched eg. not "hardwired" in R/W)
I hope you simulated CPU is at most 64-bit and R/W right to left
in order to help you to cope with the bytes and strings and all
Veli-Pekka - always trying to be helpful...
PS: Now _I_ am confused, somebody help - please!
Nick Karagiaouroglou
> Hello
>
> "Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
> news:cd9ca36b.02082...@posting.google.com...
> > Hmmm, everybody who wants to do so has surely reasons. Even if these
> > reasons are "just for the fun of it".
>
> Yes, and this reason was just to use the Matrix Writer... So my claim to use
> list of lists (which is a very similar structure as the Matrix, except that
> it's officially supported, is even more accurate
Lists of lists just don't show as nicely on the stack as matrices do.
In addition many of the operations that are possible with matrices,
will not be possible with lists of lists that contain objects that are
not allowed in matrices. Or could we find the trace of a list of lists
with binaries as elements? (Of course these things can be programed
easily, but the programs for such purposes aren't as tightly
integrated in the CAS as the built-in commands/functions are.)
>
> >
> > The main reason though, is generalization. Exactly the same reason, I
> > think, that makes many of us (including me) wishing to have for
> > example units, matrices or even programs in algebraics. I don't say
>
> I totally disagree as you can achieve the same goals by using existing
> objects like list or programs. Algebraic objects have a meaning and a
> definition which has to be respected if you don't want to make a system even
> less intuitive for users.
No definition has to be respected for ever. Quite the contrary,
*reasonable* generalization of existing definitions is one of the main
powers that lead to new things. Consider for examle the "old"
calculators that could calculate the absolute value of some real
number. Now compare it to the ABS command on the HP48 and you'll see
what I mean.
> Flexibility has a dark side sometimes and I personnaly find the HP49 way too
> flexible. At the end, it becomes so hard to use that not many people are
> using it.
Yes, that's the drawback sometimes. Especially when there are so many
ways to achieve the same thing. I already said that the HP49G is
already powerful enough and I just think of such "generalizations" as
dreams for the future and not so much as complains for the present.
But, flexibility and plurality is always a part of an underlying CAS
that allows the user to exactly define "the world" in which the
working session takes place. Don't get me wrong here, I know that the
HP49G offers so much possibilities. It is not my point that it
doesn't. My point goes more on the theoretical part of such systems.
Perhaps sometime in future we will see such a machine with almost no
built-in objects but with the capability to let the user define his
objects and operations for these objects.
Just to make an easy example. Mathematica has no built in operation
for multiplying strings. None the less it is possible to *expand* the
already existing multiplication operation and add your own definition
of a multiplication for string arguments. Note that this is *not* just
defining a new function. The already available multiplication that is
already a tight integrated part of the CAS, receives an additional
argument type upon it can act and from now on can do what it could do
before the new definition and the new operation that you just defined.
A second example: Mathematica doesn't have a built in object for a
set. (Lists are *not* sets). But it is very easy to define a new
object for a set, with all the general properties and all the general
operations (union intersection etc) for sets. From now on until the
end of the session, the new objects and operations for them are very
very tightly integrated to the existing CAS, so that benefits of the
CAS itself are also benefits of the new defined objects.
I don't say that the HP49G isn't good because it is as it is, I only
say that the examples given above should be the direction to which
development of new calcs should go, if of course there is going to be
such a thing like the successor og the 49. (Which I doubt very
strongly :-( )
Jean-Yves Avenard
"Veli-Pekka Nousiainen" <DROP...@welho.com> wrote in message
news:tpEa9.1829$D8.6...@reader1.news.jippii.net...
> Hi Madelein & Jean-Yves !
>
> Why not please the lady and let us all work with "symbolic" matrices
> of *any* type directly in the MatrixWriter in the 1.19-7 *BETA*
> Note:
> When my method of using the ->H H-> to construct the Sysbin Matrix
> it is displayed properly AND can be _viewed_ in the MatrixWriter.
> But in order to modify/create you have to do some ->H H-> again.
> VPN
Because I believe that there's absolutely no need for it.
A symbolic matrix has been put in a way so there's no need to check
sub-elements and see if they are usable by the CAS. Much faster to handle
If you want to mess up around, use list of lists. That's what they are for.
I'm yet to see any practical use for a so-called symbolic matrices. Just
show me ONE example where it would be needed in a way that list of lists
can't be used (using the Matrix Writer being the least important reason)..
Jean-Yves
Veli-Pekka Nousiainen
news:3d6cc52a$1...@duster.adelaide.on.net...
X
> > Why not please the lady and let us all work with "symbolic" matrices
> A symbolic matrix has been put in a way so there's no need to check
> sub-elements and see if they are usable by the CAS. Much faster to handle
VPN
Cyrille de Brébisson
here is how I would do it:
get a value:
2: "*****"
1: position
<< DUP SUB NUM R->B @if you really need the binary value...@ >>
> However, I cannot seem to figure out how to do it the other way round in a
> simple manner.
3: "*****"
2: #value
1: position
<< SWAP B->R @if you really need the binary value...@ CHR REPL >>
regards, Cyrille
Gene Wright
"Jean-Yves Avenard" <PLEASEj...@NOaveSPAMnard.org> wrote in message
>At the end, it becomes so hard to use that not many people are
> using it.
>
> Jean-Yves
Gene: Sorry, but I disagree with this being a major issue. There are many
reasons people are not using the HP-49G.
1) Keyboard. Richard Nelson lists this as the PRIMARY reason he still uses
the HP-48GX.
2) Manual (or lack thereof). Anything with a good manual is easier to use
than without one. The HP-67 for example, was complicated but had a wonderful
manual. The 49G HP books are a big reason people are not using the 49G.
3) Speed vis' a vis' TI products.
4) Bugs. Too many things took too long to get fixed. Yes, this is a result
of it being a complicated product and I know you were forced to rush it to
market, but this is a consequence.
I'm sure there are others.
But, I think it is a mistake to conclude that "overflexibility" has led to
few people using the 49G.
Gene
P.S. I'm very very sad thinking of what might have been.
Veli-Pekka Nousiainen
news:akil4e$9o...@eccws12.dearborn.ford.com...
X
> 1) Keyboard. Richard Nelson lists this as the PRIMARY reason he still uses
> the HP-48GX.
than the 49G, but with a click and that this was considered at HP
at some point. It's still not too late for the HP to release a 49G+ version
!!!
> 2) Manual (or lack thereof). Anything with a good manual is easier to use
> than without one. The HP-67 for example, was complicated but had a
wonderful
> manual. The 49G HP books are a big reason people are not using the 49G.
It has been succested here often that the Urroz' 49G book Vol.I
would be a great User's Guide (after a total proof-read)
I tcould be released together with 49G+ (+=docs now included :)
> 3) Speed vis' a vis' TI products.
You can't much for this unless HP desides to go to a modern process
for Saturn CPU (2000nm -> 150nm)
EXCEPT that I had my 49G "double-speed up" back from Cynox.de
A separate mail give you first impressions...
> 4) Bugs. Too many things took too long to get fixed. Yes, this is a result
> of it being a complicated product and I know you were forced to rush it to
> market, but this is a consequence.
The rush is over now and the (fictional) HP 49G+ could be released
with the 1.19-7 Beta renamed as v2.00
VPN
Aaron
Cyrille's idea is common practice if you're using assembly. It's really easy to
convert to other data types if you wish to do that, and strings are the least
"picky" on internal structure so it's hard to crash the machine with a string
object. If, later on, you need the matrix type, then all you have to do is
rewrite the prologue and other required "headers" for the matrix and shift the
data down to accomodate those headers. Plus, it's easy to allocate memory in
assembly with string objects.
Regards,
Aaron
Nick Karagiaouroglou
> news:3d6c...@duster.adelaide.on.net...
> >At the end, it becomes so hard to use that not many people are
> > using it.
> >
> > Jean-Yves
>
>
> Gene: Sorry, but I disagree with this being a major issue. There are many
> reasons people are not using the HP-49G.
>
> 1) Keyboard. Richard Nelson lists this as the PRIMARY reason he still uses
> the HP-48GX.
> 2) Manual (or lack thereof). Anything with a good manual is easier to use
> than without one. The HP-67 for example, was complicated but had a wonderful
> manual. The 49G HP books are a big reason people are not using the 49G.
> 3) Speed vis' a vis' TI products.
Well, :-(
> 4) Bugs. Too many things took too long to get fixed. Yes, this is a result
> of it being a complicated product and I know you were forced to rush it to
> market, but this is a consequence.
The never ending story. I've found another two. Just where I would
never expect them. (Post them soon.) What can I say? We just have to
learn to live with them.
> I'm sure there are others.
>
> But, I think it is a mistake to conclude that "overflexibility" has led to
> few people using the 49G.
Exactly, Gene!
> Gene
>
> P.S. I'm very very sad thinking of what might have been.
Sigh!
Nick.
Nick Karagiaouroglou
> > of it being a complicated product and I know you were forced to rush it to
> > market, but this is a consequence.
> The rush is over now and the (fictional) HP 49G+ could be released
> with the 1.19-7 Beta renamed as v2.00
Too optimistic here VPN. Even 1.19-7 would not eliminate the mass of
bugs on this machine. Catch another one:
Enter
d / /X \
--- | | SIN(X) dX |
dX \ /0 /
If you EVAL this, you get:
/X
SIN(X) + | COS(X) dX which is *wrong*!
/0
If you prefer to EXPAND instead of EVALuating, you get:
SIN(X)+SIN(X) which is also *wrong*!
Enter now:
d / /Y \
--- | | SIN(X) dX |
dX \ /0 /
and EVAL it to get:
/Y
| COS(X) dX
/0
which EVALuated again will give SIN(Y), which is again *wrong*!
If you again prefer to EXPAND you will get the same erroneous SIN(Y).
Should I continue?
Greetings and good bug hunting,
Nick.
Veli-Pekka Nousiainen
Can you please give the examples in the old algebraic
single-line mode (instead of the pretty-print) I got lost ??
VPN
Gene Wright
"Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message
news:cd9ca36b.02082...@posting.google.com...
> "Gene Wright" <dwri...@ford.invalid> wrote in message
news:<akil4e$9o...@eccws12.dearborn.ford.com>...
> > "Jean-Yves Avenard" <PLEASEj...@NOaveSPAMnard.org> wrote in message
> > news:3d6c...@duster.adelaide.on.net...
> > >At the end, it becomes so hard to use that not many people are
> > > using it.
> > >
> > > Jean-Yves
Gene: And, Jean-Yves, please do not consider me as one of the ungrateful
masses. I appreciate what you've done, I just disagree with your conclusion
about the failure of the 49G to grab hold of any real market share.
> > Gene: Sorry, but I disagree with this being a major issue. There are
many
> > reasons people are not using the HP-49G.
> > 2) Manual (or lack thereof). Anything with a good manual is easier to
use
> > than without one. The HP-67 for example, was complicated but had a
wonderful
> > manual. The 49G HP books are a big reason people are not using the 49G.
Gene: Nick, I should say that your marathons are some of the best
documentation out there for the HP-49G. Wonderful work. When are you going
to tackle another topic? :-)
> > 4) Bugs. Too many things took too long to get fixed. Yes, this is a
result
> > of it being a complicated product and I know you were forced to rush it
to
> > market, but this is a consequence.
>
> The never ending story. I've found another two. Just where I would
> never expect them. (Post them soon.) What can I say? We just have to
> learn to live with them.
Gene: I don't think anyone expects a bug free machine of this capability.
That's being VERY unreasonable. However, look at the number of revisions the
ROM went through before it got to be stable. Flash or not, that's
unacceptable, since MOST people will not flash upgrade the rom of their
machine, PARTICULARLY BECAUSE THEY DON'T HAVE A CABLE TO DO SO INCLUDED IN
THE BOX!
> Sigh!
> Nick.
Gene: Loud Sigh!
--
* All opinions herein expressed are mine and *
* mine alone. You may choose to ignore them *
* but I own them. *
Steen Schmidt
> single-line mode (instead of the pretty-print) I got lost ??
Here are the exmaples in algebraic notation (d denotes differentiation, S
denotes integration):
'd(S(0,X,SIN(X),X),X)' EVAL -> 'SIN(X)+S(0,X,COS(X),X)' (wrong) EVAL ->
'2*SIN(X)' (easier to see that it is wrong).
'd(S(0,X,SIN(X),X),X)' EXPAND -> 'SIN(X)+SIN(X)' (wrong).
'd(S(0,Y,SIN(X),X),X)' EVAL -> 'S(0,Y,COS(X),X)' (wrong) EVAL -> 'SIN(Y)'
(easier to see that it is wrong). EXPAND doesn't make a difference in this
example.
The problem seems to be with the 'd(S(...))' structure - the bug is apparant
even with the simplest of expressions:
'd(S(0,X,X,X),X)' EVAL EVAL -> '2*X' (should have been merely 'X').
The 'S(d(...))' structure doesn't seem to be affected by this bug.
I think this is the most serious bug found in v1.19.6. Auch.
Regards
Steen
parisse
> denotes integration):
>
> 'd(S(0,X,SIN(X),X),X)' EVAL -> 'SIN(X)+S(0,X,COS(X),X)' (wrong) EVAL ->
> '2*SIN(X)' (easier to see that it is wrong).
>
> 'd(S(0,X,SIN(X),X),X)' EXPAND -> 'SIN(X)+SIN(X)' (wrong).
>
> 'd(S(0,Y,SIN(X),X),X)' EVAL -> 'S(0,Y,COS(X),X)' (wrong) EVAL -> 'SIN(Y)'
> (easier to see that it is wrong). EXPAND doesn't make a difference in this
> example.
>
> The problem seems to be with the 'd(S(...))' structure - the bug is apparant
> even with the simplest of expressions:
>
> 'd(S(0,X,X,X),X)' EVAL EVAL -> '2*X' (should have been merely 'X').
>
> The 'S(d(...))' structure doesn't seem to be affected by this bug.
>
> I think this is the most serious bug found in v1.19.6. Auch.
Then 1.19.6 is a really good rom release:-), because in all these
examples it should return an error instead of an answer. Indeed
X has two meanings in your examples, a mute integration variable
and a normal variable. Especially the notation S(0,X,X,X)
has no mathematical meaning at all... It should be noted
S(0,X,t,t). I agree an error would be better as a strange
answer but it is impossible to think to all such cases...
Steen Schmidt
But it is! It is very good actually :-) Wonder how the future of the HP49G
had been, had it had ROM v1.19.6 to begin with?
> because in all these
> examples it should return an error instead of an answer.
Something like "Dependent limit"? I agree, when the integration variable is
the same as a variable in the expression to be integrated. The other
examples (without the variable duality) are equally bugs - for example:
'd(S(0,Y,SIN(X),X),X)' EVAL -> 'S(0,Y,COS(X),X)' (wrong) EVAL -> 'SIN(Y)'
(this should be 'SIN(X)')
> Indeed
> X has two meanings in your examples, a mute integration variable
> and a normal variable.
Yes.
> Especially the notation S(0,X,X,X)
> has no mathematical meaning at all... It should be noted
> S(0,X,t,t).
Sure, but even on the HP48 series it's allowed. In fact, the G-series manual
(HP 48G Series User's Guide, page 20-9) suggest one to do this, when trying
to find an indefinite integral.
Actually I hate when the TI89 tells me which variables I can use and which I
can't. Usually, this is when doing substitutions though. X^2-3|X=X+2 isn't
allowed on the TI89, while X^2-3|X=Y+2 is. The two examples seem alike, even
though they aren't mathematically. Often it's practical they are treated
alike.
What could be done programmatically, is to substitute the dependent limit
with something else, and then subsitute it back when the indefinite integral
is calculated. The result will usually not make much sense, but in some
cases it might be needed - to demonstrate the danger in doing exactly that
(in class), for instance.
I can live happily with an error message though :-)
> I agree an error would be better as a strange
> answer but it is impossible to think to all such cases...
No one would expect you to find all bugs before release. ROM v1.05 was a bit
premature though ;-)
Regards
Steen
mbel...@mindspring.com
Actually the calculator is right! Recall that you are using Leibnitz'
rule for differentiating an integral. This integral is a function of
x both in its upper limit and in the function in the integrand. If
you make the variable of integration t instead of x, and you keep the
upper limit as x, you get the result you were expecting.
Regards,
Mike Elzinga
J.C. Randerson
expression of 'S(0,X,SIN(X),X)', then EVAL the result
'dX(-(COS(X)-1))' you get the expected answer of 'SIN(X)'.
It also does the same with the example of 'd(S(0,X,X,X),X)', EVAL the
inner expression, then EVAL the result gives the expected 'X'. So the
bug must be somewhere in trying to do several EVALs at once. An
interesting but deadly bug - thanks for the warning!
J.C. Randerson
Laramie, Wyoming
"Steen Schmidt" <ssch...@nospam.dk> wrote in message news:<_uqb9.37662$ww6.2...@news010.worldonline.dk>...
Andrew Hall
> machine, PARTICULARLY BECAUSE THEY DON'T HAVE A CABLE TO DO SO INCLUDED IN
> THE BOX!
I got a cable with my 49g
Andrew
Steen Schmidt
No.
> Recall that you are using Leibnitz'
> rule for differentiating an integral.
Yes, but that is no different than doing the integral first, and then the
differentiation. Leibnitz' Rule can (rarely) help in situations where the
integral either has no closed form or (very often) when the result of the
direct approach is very complex.
Leibnitz' Rule (for those who don't remember): d(S(A(Z),B(Z),F(X,Z),X),Z) =
S(A(Z),B(Z),d(F,Z),X)+F(B(Z),Z)*d(B,Z)-F(A(Z),Z)*d(A,Z)
The problem with the calculator is that there is no destinction between X
and Z. I proposed that solved by introducing a dummy variable, but a cleaner
approach is to return an error message.
> This integral is a function of
> x both in its upper limit and in the function in the integrand. If
> you make the variable of integration t instead of x, and you keep the
> upper limit as x, you get the result you were expecting.
Yes, but the two variables are identical, hence Leibnitz' Rule doesn't apply
as written - that's the problem.
Regards
Steen
mbel...@mindspring.com
Steen:
I'm not disagreeing about the ambiguity of using identical variables. It is
not appropriate to do that when doing the integrals by hand either. It would
be similar to making a variable and a summing index identical in discrete
sums. One needs to be careful to make a distinction between the variable of
integration and the variables in the limits of integration.
What I noticed when I tried your example is that the calculator appears to be
making the distinction when you make all the variables identical, whether or
not that was intended in the design. I agree that this is not good form, but
it gives the answer that Leibnitz' rule would give if the F(x,z) in your last
example were replaced by F(z) and the variable of integration changed to z
also. I guess I would not have called it a bug, but rather an instance of
garbage in, garbage out. In this case, getting the "right" answer for the
wrong reasons. Maybe I'm being a little too forgiving by not expecting a
machine to correct ambiguities in the input.
I like your idea of an error message for ambiguous input, but I tell my
students to know their mathematics well and they will use their machines more
intelligently. The HP calculators have generally required intelligent users,
which I consider a good thing. It may be too much to ask that we have
machines that can anticipate every possible misunderstanding in mathematics.
I can't even imagine how one would tell a machine how to do that. Notation
varies in order to adapt to context, so somehow the machine would have to
know something about the context in which it was being used. A machine that
corrects everything according to a particular set of standards could get to
be as annoying as these text editors that keep correcting you when you input
exactly what you mean. ;-)
Regards,
Mike
Steen Schmidt
> garbage in, garbage out.
I like the GIGO principle - explains so much in such a little space :-)
> A machine that corrects everything according to a particular set of
> standards could get to be as annoying as these text editors that
> keep correcting you when you input exactly what you mean. ;-)
Oh, I know what you mean ;-)
I still vote for an error message, or at least a warning (it should be easy
to check wheather the integration variable is part of the integration
limits, the same goes for limits, sums aso.).
The HP48G series handles these cases as one would expect them to be handled.
It would be nice to hear the '48 designers input to this discussion ;-)
Regards
Steen
Nick Karagiaouroglou
> Gene: Nick, I should say that your marathons are some of the best
> documentation out there for the HP-49G. Wonderful work. When are you going
> to tackle another topic? :-)
Thanks you very much for the good words. I'm just correcting the
corrections of the corrections of the first part of the calculus
marathon. I started it as a little bit of how to find bounds and
condenstation points and if functions are continuous or not, but since
days there is always a bit more to add, to correct and modify.
Especially the coming programs for finding bounds and condenstation
points make me mad everyday. But I still hope that it will get
finished soon.
Greetings,
Nick.