Why is the outcome of 3/4 in bc zero?

Why is the outcome of 3/4 in bc zero?

Post by Gui Xi » Sun, 20 Apr 2003 20:26:43



I use bc in AIX to calculate 3/4. The outcome is 0, not 0.75. Why? I am a
beginner of UNIX. Please help me.

Thanks.

 
 
 

Why is the outcome of 3/4 in bc zero?

Post by Dan Foste » Sun, 20 Apr 2003 19:52:50



> I use bc in AIX to calculate 3/4. The outcome is 0, not 0.75. Why? I am a
> beginner of UNIX. Please help me.

Because by default, bc uses 'scale=0' which means only integer results.

3/4 = 0.75... and .75 is truncated, leaving you with an integer 0.

If you want 0.75, then you need to do:

scale=2
3/4

in bc and it will return .75 as desired.

Not an AIX issue, just a 'bc' usage issue. You may want to review the
bc man page for more information about that program by doing the command:
'man bc' (if it is installed on that system).

-Dan

 
 
 

Why is the outcome of 3/4 in bc zero?

Post by Daniel Packm » Mon, 21 Apr 2003 00:43:38




>I use bc in AIX to calculate 3/4. The outcome is 0, not 0.75. Why? I am a
>beginner of UNIX. Please help me.

"man bc" will give you a manual page describing this command.

The "scale" value determines how truncation is handled.

scale = 20
3/4
.75000000000000000000

--
Daniel Packman
NCAR/ACD

 
 
 

1. Floppy reports size as zero sectors, zero tracks, zero bytes

My 3-1/2" floppy drive has stopped responding properly to requests for
its geometry.  The low-level "fdformat" utility will query the hardware,
find out that the disk has zero sectors and zero tracks, and exit (it
seems to think its work is done).  The drive doesn't show any other
problems: I can put filesystems on the floppies and mount them, and I can
splat kernels directly onto the media with "dd".  I can even do a
low-level format with "superformat" (which doesn't seem to ask for the
geometry).  The sector/track error is only an issue with "fdformat" and
with Mach---Mach always wants to check the geometry before mounting the
floppy disk.

I'm trying to figure out what is causing the problem.  In the past, the
floppy drive worked fine.  Unfortunately, I can't tell when the problem
occurred; I don't do low-level formats that often.  I can think of three
possibilities:

 1. My 1992 floppy drive has had a hardware failure, or is simply
    incompatible with modern hardware.  (It moved from B: to A: a while
    back, but I doubt that's the problem).
 2. My PCI motherboard's built-in floppy controller is buggy.  It's an
    Intel Zappa ED, with the Triton 82430FX chipset.  It's fairly recent.
 3. The Linux floppy driver (which Mach is using) is incompatible with
    one of the two pieces of hardware.

Does anyone have suggestions on how to proceed?  Thanks.

Derek

--
Derek Upham

"Ha!  Your Leaping Tiger Kung Fu is no match for my Frightened Piglet style!"

2. moving home

3. Reliability of `bc' (or: is `bc' buggy?)

4. Windows NT vs UNIX

5. Subject: Ksh93 question: special built-ins: why are they special?

6. /usr/local/libexec/tcpd... could somebody help me? ;)

7. "ld: fatal: file /dev/zero: cannot mmap file: Not enough space"... but why ?

8. How to check for keypress?

9. Why can't one make a link to a file with link count of zero?

10. Why is /dev/zero so SLOW?

11. Why would a valid DVD show zero files on Linux?

12. Why socket keep receiving string whose length is ZERO?

13. Why would rcp (remote copy) return anything but zero?