HPGCC related ... - Hewlett Packard
This is a discussion on HPGCC related ... - Hewlett Packard ; Hello,
Can somebody simply explain me why my
scanf("%f",&variable);
not working on my HP 50G?
I have gone over this before but I just can not now!
I am also open to other ways of entering float numbers from keyboard.
...
-
HPGCC related ...
Hello,
Can somebody simply explain me why my
scanf("%f",&variable);
not working on my HP 50G?
I have gone over this before but I just can not now!
I am also open to other ways of entering float numbers from keyboard.
Thanks in advance
Onur
-
Re: HPGCC related ...
On Mar 3, 3:27 pm, ilko...@gmail.com wrote:
> Hello,
>
> Can somebody simply explain me why my
>
> scanf("%f",&variable);
>
> not working on my HP 50G?
>
> I have gone over this before but I just can not now!
>
> I am also open to other ways of entering float numbers from keyboard.
>
> Thanks in advance
> Onur
I get the same result. It seems that %f is being treated at %lf. For
example:
float f;
double d;
scanf("%f",&f); // should work but doesn't
scanf("%lf",&d); // works as expected
scanf("%f",&d); // should fail but doesn't
The value of the variable f is consistent with trying to store a IEEE
double in a IEEE float. It appears that %f is being treated as a
double instead of a float. You could get around the problem by
declaring your variables as double instead of float. Or if you really
need the space saving float, you could do
scanf("%lf",&d);
f = (float)d;
If I understand correctly, the ANSI C99 scanf() format arguments are:
%f - float
%lf - double
%Lf - long double
Some implementations treat %llf as long double.
These are often confused with the printf() format arguments:
%f - double (not float)
%Lf - long double
Notice printf() has no float format as floats are automatically cast
to doubles. Also, printf() has no %lf or %llf, but many
implementations treat them as double or long double.
-wes
-
Re: HPGCC related ...
I am getting more curious!?
I really would like to know which version of the HPGCC compiler you
are using and the header file.
I am using HPGCC ver 2.0.6.1 and hpgcc49.h and as you have said, I
have switched all my variables from float to double like this:
double d;
scanf("%lf",&d);
printf("%f",d);
and nothing happened.
I have also tried : printf("%lf",d);
I really wonder if anything has the possibility to go according to the
book with this HP calculators
? I really wonder if there is a more
simple command to implement on HPGCC than scanf or printf?
/Onur
-
Re: HPGCC related ...
I have read your comments on HPGCC Wes, and the answers which were
given from the other party are interesting.
Anyway, I really need to enter some float or double values for my
equations therefore I need a way to scan my I/O and put the typed
characters into variables. Can you please share with me how you do it?
I can not care less how scanf works in HPGCC since it is not standard
C after all and I refuse to learn their way of doing things ...
Thanks for your kind answer.
/Onur
-
Re: HPGCC related ...
I already responded once before but must have not clicked "send"
because my message seemed to have disappeared.
> Anyway, I really need to enter some float or double values for my
> equations therefore I need a way to scan my I/O and put the typed
> characters into variables. Can you please share with me how you do it?
I take values from the stack. That seems to be the best way for
integration with the calculator system. The functions like scanf and
so on always seemed like overkill for everything I've done.
Also, in the HPGCC blog they say in 2006 that the scanf are pre-alpha
and don't have all ANSI features implemented yet. I am not certain as
I've never used scanf, but I don't think they were ever completed for
hpgcc2. I would **guess** that they are more thoroughly tested/
completed in hpgcc3, but I don't have any knowledge.
> I can not care less how scanf works in HPGCC since it is not standard
> C after all and I refuse to learn their way of doing things ...
I don't really understand what you mean. Yes, not all functions are
included, but everything that is there follows ansi C. The fact that
there are special functions to interact with the stack, screen and
keyboard doesn't mean you "have to do it their way". Rather, there
aren't hundreds of people working on the project and there are things
that haven't been implemented yet.
If you are set on using scanf. . . feel free to contribute your
improvements if it doesn't meet your needs right now.
TW
-
Re: HPGCC related ...
,gzip(gfe),gzip(gfe)
Bytes: 3214
Xref: number1.nntp.dca.giganews.com comp.sys.hp48:203466
> If you are set on using scanf. . . feel free to contribute your
> improvements if it doesn't meet your needs right now.
I hate when a conversation comes to this point. "If you are not
feeling well with the current situation/solution, don't complain, do
something to make it better" This is the origin of what you are
saying, right? I know that heaps of people are coding C for HP 4x or
5x series of calculators. I am sure that they are going under heaps of
troubles to get their code working. However, I don't see much
contributions to HPGCC compiler. I am fully aware of what type of
compiler I am using and I am fully aware of the fact that, with
contributions, things can get better. On the other hand, how long for
this HPGCC thing going on? Did you send the same message to everybody,
who asked questions about such functions, or do you pick the ones who
complain about such simple functions not being implemented correctly?
Am I mistaken or receiving numbers from keyboard entery is not
essential for the software which you use on those series of
calculators? If not, than I would surely agree with you that this, is
an exceptionnaly special issue and I have to bare the consequences of
being the pioneer in my area of interest. I don't really know if I
have to remind you about the function we are talking on right now...
You have got a point though, I have to leave my wavelet Haar filter
software and start coding some C interpretter for ARM processors. Why
not, I have free time from 22:00 to 7:00 am, so that those guys who
couldn't be able to implement a simple function properly can be able
to sleep like babies, which they do from the very beginning of their
lifes!
/Onur
PS: Stack, how can I access stack?
-
Re: HPGCC related ...
> I hate when a conversation comes to this point. "If you are not
> feeling well with the current situation/solution, don't complain, do
> something to make it better"
I hate it when it gets there as well and for that reason I have never
said it to anyone before. It was just because you kept saying how
easy it is to implement. . .
The problem has been that most of us have been aware hpgcc3 would be
out sometime and were told that essentially everything had already
been rewritten and was completely different internally. I remember a
conversation two months ago or so discussing scanf or the keyboard
reading routines or something and it was mentioned that NONE of the
code being discussed exists in hpgcc3 anymore.
The real reason it hasn't been fully implemented is that it really
isn't that necessary for using hpgcc. Scanf is quite important when
you are writing a command line program for windows or whatever, and
need to be able to get input by typing. However, almost all program's
I've seen and have written are used to do some heavy calculations. In
this instance, you will want something that interfaces with the native
calculator system. Does that mean it wouldn't be nice to have a fully
compliant scanf? Nope, but it doesn't stop the system from being
useful.
On the calculator, you already have plenty of tools for getting input
built into the OS - primarily the stack. To get values from the
stack, simply do this:
double my_var = sat_pop_real();
That removes one real number from the stack and stores it as a
double. So if you want to bring in three numbers, do it three times:
double my_var3 = sat_pop_real(), my_var2 = sat_pop_real(), my_var1 =
sat_pop_real();
To put a result back on the stack, use sat_push_real(my_var);
There are functions available to pop and push almost every data type
including lists, strings, binary integers, arrays, etc.
TW
-
Re: HPGCC related ...
On Mar 3, 4:44 pm, TW wrote:
> Scanf is quite important when
> you are writing a command line program for windows or whatever, and
> need to be able to get input by typing.
True, scanf can be used for command line arguments, but scanf is also
used quite a bit for reading flat input files. I have multiple
applications that read flat file point data from the SD card. I also
use scanf to parse large or complex datasets from the stack, something
HPGCC3 does well that HPGCC2 does not, so I have to convert it to a
string and send to my HPGCC2 application to be parsed by scanf.
I have also had my share of frustration with scanf and HPGCC2 (I have
not tested scanf with HPGCC3). Some of my code has custom scanf
replacements specific to the data I have to parse, others use scanf
work-a-rounds like Wes posted above (i.e. scan as a double into a
double, then assign double to a float). When working with large data
point sets, floats do save a lot of RAM.
HPGCC2 scanf can be a nuisance especially with more complex
expressions to match. In that case my advice is that you write your
own parser.
-
Re: HPGCC related ...
> used quite a bit for reading flat input files. *I have multiple
> applications that read flat file point data from the SD card.
True, but when you pull in the fsystem lib, your code has increased in
size by 34kb. You don't have to use it. . . but get dismal
performance on the SD cards using the KOS system calls. Everything
I've used on the card has to have the fsystem lib or it delays it up
to several seconds which for the application were unacceptable. :-(
TW
-
Re: HPGCC related ...
On Mar 3, 9:32 pm, TW wrote:
> > used quite a bit for reading flat input files. I have multiple
> > applications that read flat file point data from the SD card.
>
> True, but when you pull in the fsystem lib, your code has increased in
> size by 34kb. You don't have to use it. . . but get dismal
> performance on the SD cards using the KOS system calls. Everything
> I've used on the card has to have the fsystem lib or it delays it up
> to several seconds which for the application were unacceptable. :-(
>
> TW
I am not linking with libfsystem.a at all. I have HPGCC2 object code
that is < 34Kb that uses fopen, fclose, fprintf, and fgets. I just
read 10,000 points from a flat file and computed the convex hull in 5
seconds. Is that too slow?
I have not use fsystem before. What it is used for exactly?
Thanks.
-
Re: HPGCC related ...
> I am not linking with libfsystem.a at all. *I have HPGCC2 object code
> that is < 34Kb that uses fopen, fclose, fprintf, and fgets. *I just
Those are using the native filesystem in the kinpo OS. Reading isn't
too terrible UNLESS you use fseek, but writing is horribly slow.
> read 10,000 points from a flat file and computed the convex hull in 5
> seconds. *Is that too slow?
Yes. In my case I read in data for geodetic (mapping) calculations. A
tenth of a second is about the limit as it may need to run in a loop
several times a second. Using the normal filesystem commands would
slow it down to anywhere from .3-1.2s *randomly* (the same exact input
fluctuates how long it would take).
Writing large data files was even worse. A 7000 point datafile
(around 260k) would take about 35 seconds to write. The same exact
with filesystem lib takes about 2 s. Reading in the data went from
around 5 seconds to less than a second. That is with no code changes
other than using the hpgcc filesystem.
> I have not use fsystem before. *What it is used for exactly?
It is much more flexible and faster. In addition, it can do things
like delete folders, copy files from one location to another directly,
and some other spiffy things I can't remember at the moment. The
built in one has some bugs that stopped things like fscanf from being
implemented (at least I think I read that somewhere). Unless you
really have a need for speed, most stuff is probably fine with the
regular calls.
TW
-
Re: HPGCC related ...
On Mar 3, 8:55 pm, ilko...@gmail.com wrote:
> I am getting more curious!?
>
> I really would like to know which version of the HPGCC compiler you
> are using and the header file.
HPGCC_VERSION: 2.0
HPGCC_REVISION: 563
The entire file is:
-----------------------------------
#include
int main()
{
float f;
double d;
clear_screen(); //clear the screen
scanf("%f",&f); // should work but doesn't
scanf("%lf",&d); // works as expected
scanf("%f",&d); // should fail but doesn't
printf("%f, %f, %f\n",f,d,d);
WAIT_CANCEL;
return 0;
}
-----------------------------------
In any case, I would highly recommend using sat_pop_real(),
sat_push_real().
The HPStack library has: hps_pop_real(), hps_push_real(),
hps_pick_real().
> I really wonder if there is a more
> simple command to implement on HPGCC than scanf or printf?
Hmmm. I would have thought that these functions would be two of the
largest functions to implement.
-wes
-
Re: HPGCC related ...
ilkorur@gmail.com wrote:
> Hello,
>
> Can somebody simply explain me why my
>
> scanf("%f",&variable);
>
> not working on my HP 50G?
>
> I have gone over this before but I just can not now!
>
> I am also open to other ways of entering float numbers from keyboard.
>
> Thanks in advance
> Onur
C is very powerful high-level programming language originally written by
Bell Laboratories for use in the Unix OS.
Not all C functions are needed and apparently have not been implemented
for the HPCC on the calculator.
The authors are assuming that users have good fundamental C coding
skills as well as a working knowledge of the HP OS.
Pick up "C Programming Language" by Dennis Ritchie at the local library
and read it or some other text on C and consider the comments that are
being offered here.
-
Re: HPGCC related ...
Hi, please allow me to jump in
On Mar 3, 11:59*pm, "dataj...@gmail.com" wrote:
>
> I have not use fsystem before. *What it is used for exactly?
>
It's used for the same purpose as any file system: to read and write
data files.
The HPGCC filesystem has a few advantages with respect to the builtin:
* Full support for long file names. The OS stores long names but is
unable to distinguish between them (LONGNAME1.DAT is the same as
LONGNAME2.DAT, for example).
* Full case sensitivity support. This feature allows you to store
variables 'a' and 'A' as different files, therefore you can store
calculator objects using their original names, which is not possible
with the OS (it was possible in early rom revisions, but the files
were incompatible with Windows so the feature was removed).
* Rename file is broken in the OS.
* Delete directories is inexistent in the OS.
* Speed is boosted a great deal. On large files, you can get read
speeds of 900 kbytes/second, so if you use very large data sets, this
can come handy.
* It supports partitioned SD cards in up to 4 volumes (:3:, :4:, :5:
and :6
, to better organize your data and for speed too (large
volumes = large FAT tables = slower data throughput). From Windows you
can only access one partition, but Linux will give you full access to
all of them.
* It supports DOS syntax C:\, D:\, etc. and calculator syntax :3:. It
also supports unix-style forward slashes or backward-slashes. This
helps porting applications written for other devices to the
calculator.
The only drawback is that it adds quite a bit of "weight" to your
executable. This issue has been completely resolved in HPGCC3 (no
heavy executables anymore).
Did I convince you?
Regards,
Claudio
-
Re: HPGCC related ...
On Mar 5, 5:22 pm, Claudio Lapilli wrote:
> Did I convince you?
Yes you did.
Thanks.
-
Re: HPGCC related ...
> The only drawback is that it adds quite a bit of "weight" to your
> executable. This issue has been completely resolved in HPGCC3 (no
> heavy executables anymore).
>
> Did I convince you?
> Regards,
> Claudio
HUGE improvement if size is significantly reduced.
You are doing an amazing work, thank you.
-
Re: HPGCC related ...
On Mar 4, 4:07*pm, Wes wrote:
> On Mar 3, 8:55 pm, ilko...@gmail.com wrote:
>
> > I am getting more curious!?
>
> > I really would like to know which version of the HPGCC compiler you
> > are using and the header file.
>
> HPGCC_VERSION: 2.0
> HPGCC_REVISION: 563
>
> The entire file is:
> -----------------------------------
> #include
>
> int main()
> {
> * * * * float f;
> * * * * double d;
>
> * * * * clear_screen(); //clear the screen
>
> * * * * scanf("%f",&f); *// should work but doesn't
> * * * * scanf("%lf",&d); // works as expected
> * * * * scanf("%f",&d); *// should fail but doesn't
>
> * * * * printf("%f, %f, %f\n",f,d,d);
>
> * * * * WAIT_CANCEL;
>
> * * * * return 0;}
>
> -----------------------------------
>
> In any case, I would highly recommend using sat_pop_real(),
> sat_push_real().
> The HPStack library has: hps_pop_real(), hps_push_real(),
> hps_pick_real().
>
> > I really wonder if there is a more
> > simple command to implement on HPGCC than scanf or printf?
>
> Hmmm. *I would have thought that these functions would be two of the
> largest functions to implement.
>
> -wes
I have tried your code and none of my enteries could be printed on the
screen. I really want to know what is different with your way of doing
it and mine.
Besides, your suggestion about using the stack library. It is working,
but you can realize that it is working when you QUIT the program. That
is, you see all your displayed data in stack. As you can surely
understand without my saying that, after calling CLEAR_SCREEN() you
lost all your visual contact with the STACK? Am I wrong? There is no
use to print values to stack after calling the CLEAR_SCREEN()
function.
I am currently entering my variables as strings. Then I use the atof()
function. This is working as far as input is concerned. I am still
having problems to display floats or doubles on screen. I have used
sprintf() fuction and it is not working properly. It behaves just like
printf() function. All I can have is some numbers which I couldn't be
able to give any meaning to them. My plan was to convert the float or
double into string and print the converted string on screen. In worst
case I will code a small function to convert floats or doubles into
strings. If I have the enough amount of memory, though.
/Onur
-
Re: HPGCC related ...
On Mar 19, 6:23*am, ilko...@gmail.com wrote:
> On Mar 4, 4:07*pm, Wes wrote:
>
>
>
>
>
> > On Mar 3, 8:55 pm, ilko...@gmail.com wrote:
>
> > > I am getting more curious!?
>
> > > I really would like to know which version of the HPGCC compiler you
> > > are using and the header file.
>
> > HPGCC_VERSION: 2.0
> > HPGCC_REVISION: 563
>
> > The entire file is:
> > -----------------------------------
> > #include
>
> > int main()
> > {
> > * * * * float f;
> > * * * * double d;
>
> > * * * * clear_screen(); //clear the screen
>
> > * * * * scanf("%f",&f); *// should work but doesn't
> > * * * * scanf("%lf",&d); // works as expected
> > * * * * scanf("%f",&d); *// should fail but doesn't
>
> > * * * * printf("%f, %f, %f\n",f,d,d);
>
> > * * * * WAIT_CANCEL;
>
> > * * * * return 0;}
>
> > -----------------------------------
>
> > In any case, I would highly recommend using sat_pop_real(),
> > sat_push_real().
> > The HPStack library has: hps_pop_real(), hps_push_real(),
> > hps_pick_real().
>
> > > I really wonder if there is a more
> > > simple command to implement on HPGCC than scanf or printf?
>
> > Hmmm. *I would have thought that these functions would be two of the
> > largest functions to implement.
>
> > -wes
>
> I have tried your code and none of my enteries could be printed on the
> screen. I really want to know what is different with your way of doing
> it and mine.
>
> Besides, your suggestion about using the stack library. It is working,
> but you can realize that it is working when you QUIT the program. That
> is, you see all your displayed data in stack. As you can surely
> understand without my saying that, after calling CLEAR_SCREEN() you
> lost all your visual contact with the STACK? Am I wrong? There is no
> use to print values to stack after calling the CLEAR_SCREEN()
> function.
>
> I am currently entering my variables as strings. Then I use the atof()
> function. This is working as far as input is concerned. I am still
> having problems to display floats or doubles on screen. I have used
> sprintf() fuction and it is not working properly. It behaves just like
> printf() function. All I can have is some numbers which I couldn't be
> able to give any meaning to them. My plan was to convert the float or
> double into string and print the converted string on screen. In worst
> case I will code a small function to convert floats or doubles into
> strings. If I have the enough amount of memory, though.
>
> /Onur- Hide quoted text -
>
> - Show quoted text -
First of all, there are no known problems displaying floating point
numbers on the screen, so the problem is in your code. Second, you
probably don't deserve my help due to your arrogance in posts above,
but here it is anyway...
To print a double:
double mydouble;
printf("%lf",mydouble);
to print a float:
float myfloat;
printf("%lf",(double)myfloat);
to read a number from the console:
double mydouble;
scanf("%lf",&mydouble);
and if you want to read it as float:
double temp;
float myfloat;
scanf("%lf",&temp);
myfloat=temp;
The forced conversion to double is required because we dropped support
for low-precision floats in HPGCC, in favor of higher-precision
doubles and even higher decNumbers.
When you use variable-argument functions, it is your responsibility to
provide proper argument type conversion.
All math functions use doubles internally, so using float will only
add unnecessary overhead to your calculations, though saving storage
space.
Regards,
Claudio
-
Re: HPGCC related ...
I want to close this thread by clarifying this situation:
On Mar 4, 11:07*am, Wes wrote:
<...>
> The entire file is:
> -----------------------------------
> #include
>
> int main()
> {
> * * * * float f;
> * * * * double d;
>
> * * * * clear_screen(); //clear the screen
>
> * * * * scanf("%f",&f); *// should work but doesn't
> * * * * scanf("%lf",&d); // works as expected
> * * * * scanf("%f",&d); *// should fail but doesn't
Since HPGCC does not support floats, %f is mapped to doubles. This
explains why the 1st scanf fails (you need to provide a pointer to a
double, not a float), and why the 3rd option works.
>
> * * * * printf("%f, %f, %f\n",f,d,d);
If you want to write correct ANSI-C, this should be:
printf("%f %lf %lf\n",f,d,d);
It only worked because %f is also mapped to doubles in HPGCC, being
equivalent to %lf.
On HPGCC, you should have written:
printf("%lf %lf %lf\n",(double)f,d,d);
Claudio
-
Re: HPGCC related ...
On Mar 19, 12:44*pm, Claudio Lapilli wrote:
>
> If you want to write correct ANSI-C, this should be:
>
> printf("%f %lf %lf\n",f,d,d);
>
> It only worked because %f is also mapped to doubles in HPGCC, being
> equivalent to %lf.
>
> On HPGCC, you should have written:
>
> printf("%lf %lf %lf\n",(double)f,d,d);
Disregard this part. It doesn't clarify anything... %f = double. %lf =
long double in ANSI-C, as well as in HPGCC.
Claudio