Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #53464 > unrolled thread
| Started by | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| First post | 2014-11-26 21:54 +0100 |
| Last post | 2014-12-19 02:34 +0100 |
| Articles | 20 on this page of 177 — 31 participants |
Back to article view | Back to comp.lang.c
the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:54 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:56 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:45 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:52 +0100
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-01 23:25 -0500
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-02 00:56 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-04 14:52 +0100
Re: the language "Osmium" <r124c4u102@comcast.net> - 2014-12-04 08:07 -0600
Re: the language Geoff <geoff@invalid.invalid> - 2014-12-04 10:20 -0800
Re: the language Mark Storkamp <mstorkamp@yahoo.com> - 2014-11-26 15:11 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:16 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:18 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:12 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-27 00:37 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-27 01:13 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-11-26 22:45 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 07:41 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 08:12 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-27 01:43 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:56 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 09:08 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 20:58 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 19:22 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-02 02:59 +0100
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 02:53 +0000
Re: the language Les Cargill <lcargill99@comcast.com> - 2014-12-01 21:25 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 06:22 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-27 08:37 +0000
Re: the language Reinhardt Behm <rbehm@hushmail.com> - 2014-11-27 16:44 +0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-27 15:35 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-27 11:58 -0500
Re: the language jt@toerring.de (Jens Thoms Toerring) - 2014-11-27 22:44 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 09:52 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 12:53 -0800
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 10:07 +0100
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 14:57 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:09 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:01 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 14:46 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:16 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 22:09 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:40 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 14:42 -0800
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:22 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 23:09 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 16:14 -0800
Re: the language BartC <bc@freeuk.com> - 2014-11-29 01:42 +0000
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 01:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 04:03 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-01 00:55 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-02 05:42 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-28 19:25 -0500
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-01 14:02 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-05 10:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 08:25 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 10:44 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 19:17 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 15:48 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 05:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:27 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-08 06:00 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 06:17 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:37 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 12:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 12:43 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 14:46 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 00:23 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-17 07:01 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 07:22 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-17 11:56 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-17 05:43 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:30 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:41 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 14:34 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 02:15 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:31 -0500
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:19 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 07:52 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:21 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:15 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 07:48 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 07:40 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 12:54 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 09:54 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 15:19 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:00 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:13 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:27 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:45 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:48 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 19:10 +0000
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:17 -0600
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:32 -0600
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 16:49 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:00 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:57 -0500
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 14:31 -0800
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 20:29 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 20:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 15:45 +0000
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 16:50 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:24 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:07 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:04 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-18 08:06 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-18 08:30 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 00:11 -0500
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-19 07:00 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-19 08:43 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 23:29 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 00:37 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-20 08:45 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-20 09:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-20 03:17 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 06:09 -0800
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:30 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:23 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-18 08:18 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-20 12:22 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-20 13:36 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:43 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:37 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:10 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:02 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-21 22:02 +0000
Re: the language Stephen Sprunk <stephen@sprunk.org> - 2014-12-21 23:49 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-21 17:45 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:29 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-20 05:29 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:32 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:23 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-22 23:39 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:22 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-19 09:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:48 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 02:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 08:31 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 09:31 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 10:10 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 07:08 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-20 06:39 +0000
Re: the language John Forkosh <forkosh@panix.com> - 2014-12-20 07:32 +0000
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 17:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-04 12:40 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 18:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 09:47 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-05 15:14 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-05 08:42 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-06 00:14 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:19 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2015-01-04 15:59 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-04 14:30 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:44 -0800
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:36 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:07 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-02 23:16 +0100
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-03 02:23 -0800
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-03 15:55 +0100
Re: the language Nobody <nobody@nowhere.invalid> - 2014-12-03 15:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 04:49 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 09:07 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 10:08 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 11:49 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-05 12:32 +0100
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-04 22:17 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:17 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:12 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:15 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:50 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-19 02:34 +0100
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2014-11-28 09:08 -0600 |
| Message-ID | <m5a364$vac$1@speranza.aioe.org> |
| In reply to | #53566 |
On 11/28/14 4:56 AM, Rosario193 wrote:
> On Thu, 27 Nov 2014 01:43:59 -0600, Morris Dovey wrote:
>
>> On 11/27/14 1:12 AM, Rosario193 wrote:
>>
>>> than it seems nobody think about multi instruction for line
>>> and minimize key words of the language for make fit all the routine in
>>> one screen of PC and artistic apparence of routine self explained
>>> what it does using indentation
>>
>> I think you can do all of this in C - but some applications will require
>> larger screens than others. :-)
>
> the routines that not fit in a 8'' tablet screen are not ok or to be
> only very few...
I’m just getting started and already I’m in trouble (8" tablet isn’t
working for me - mind the wrap)...
#include <math.h>
/*----------------------------------------------------------------------------*/
/* Physical Constants */
/*----------------------------------------------------------------------------*/
#define Vm 24.78959842 /* Molar Volume (L/mol) at 25˚C */
#define Na 6.0221E23 /* Avogadro Number (/mol) */
#define R 8.314462175 /* Ideal Gas Constant */
#define MI 25.4 /* Millimeters per inch */
#define ND 8.908 /* Density of Nickel (g/cc) */
/*----------------------------------------------------------------------------*/
/* Calculate net reaction chamber volume */
/*----------------------------------------------------------------------------*/
double volume(double nm)
{ double nv = nm / ND; /* Nickle volume */
double ch = 3.250 * MI; /* Height of reaction chamber */
double cd = 0.875 * MI; /* Diameter or reaction chamber */
double cr = cd / 2; /* radius of reaction chamber */
double cv = cr * cr * M_PI * ch; /* Volume of reaction chamber */
double hh = 3.000 * MI; /* Height of heater tube */
double hd = 0.375 * MI; /* Diameter of heater tube */
double hr = hd / 2; /* Radius of heater tube */
double hv = hr * hr * M_PI * hh; /* Volume taken by heater tube */
return cv - hv - nv; /* Net reaction chamber volume */
}
/*----------------------------------------------------------------------------*/
/* Calculate molecules of hydrogen as Na * (n = PV/RT) */
/*----------------------------------------------------------------------------*/
double molecules(double p,double v,double t)
{ double n = (p * v) / (R * t);
return Na * n;
}
/*----------------------------------------------------------------------------*/
/* Calculate mean distance between molecules as cube root of
volume/molecule */
/*----------------------------------------------------------------------------*/
double distance(double nm,double p,double v,double t)
{ return pow(volume(nm)/molecules(p,v,t),1.0/3.0);
}
/*----------------------------------------------------------------------------*/
/* Calculate approximation of energy from T = E / m as E = m * T */
/*----------------------------------------------------------------------------*/
double energy(double m,double t)
{ return m * t;
}
/*----------------------------------------------------------------------------*/
/* https://en.wikipedia.org/wiki/Kinetic_energy
/*----------------------------------------------------------------------------*/
double velocity(double e,double m)
{ return sqrt(2 * E / m);
}
:-)
--
Morris Dovey
http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-11-28 20:58 +0100 |
| Message-ID | <odkh7adlr9t08ie16v7n87lhclhuvcbs44@4ax.com> |
| In reply to | #53586 |
On Fri, 28 Nov 2014 09:08:55 -0600, Morris Dovey <mrdovey@iedu.com>
wrote:
>On 11/28/14 4:56 AM, Rosario193 wrote:
>> On Thu, 27 Nov 2014 01:43:59 -0600, Morris Dovey wrote:
>>
>>> On 11/27/14 1:12 AM, Rosario193 wrote:
>>>
>>>> than it seems nobody think about multi instruction for line
>>>> and minimize key words of the language for make fit all the routine in
>>>> one screen of PC and artistic apparence of routine self explained
>>>> what it does using indentation
>>>
>>> I think you can do all of this in C - but some applications will require
>>> larger screens than others. :-)
>>
>> the routines that not fit in a 8'' tablet screen are not ok or to be
>> only very few...
>
>I’m just getting started and already I’m in trouble (8" tablet isn’t
>working for me - mind the wrap)...
>
>#include <math.h>
>/*----------------------------------------------------------------------------*/
>/* Physical Constants */
>/*----------------------------------------------------------------------------*/
>#define Vm 24.78959842 /* Molar Volume (L/mol) at 25?C */
i not would use tab... than one way for use the code is cut and paste
and if something going wrong with these long lines would be a
problem...
i not see any problem to make that code fit in a 5'' cell phone...
#include <math.h>
/*-------------------*/
/* Physical Constants*/
/*-------------------*/
/*-----------------------------------*
* Vm = Molar Volume (L/mol) at 25?C *
* Na = Avogadro Number (/mol) *
* R = Ideal Gas Constant *
* MI = Millimeters per inch *
* ND = Density of Nickel (g/cc) *
*-----------------------------------*/
#define Vm 24.78959842
#define Na 6.0221E23
#define R 8.314462175
#define MI 25.4
#define ND 8.908
/*--------------------------------------*/
/* Calculate net reaction chamber volume*/
/*--------------------------------------*/
double volume(double nm)
{double nv= nm/ND; /* Nickle volume */
double ch= 3.250*MI; /* Height of reaction chamber */
double cd= 0.875*MI; /* Diameter or reaction chamber*/
double cr= cd/2 ; /* radius of reaction chamber */
double cv= cr*cr*M_PI*ch; /* Volume of reaction chamber */
double hh= 3.000*MI; /* Height of heater tube */
double hd= 0.375*MI; /* Diameter of heater tube */
double hr= hd/2; /* Radius of heater tube */
double hv= hr*hr*M_PI*hh; /* Volume taken by heater tube */
return cv-hv-nv; /* Net reaction chamber volume */
}
/*----------------------------------------------------*/
/* Calculate molecules of hydrogen as Na*(n= PV/RT) */
/*----------------------------------------------------*/
double molecules(double p,double v,double t)
{double n=(p*v)/(R*t); return Na*n;}
/*------------------------------------------*
* Calculate mean distance between *
* molecules as cube root of volume/molecule*
*------------------------------------------*/
double distance(double nm,double p,double v,double t)
{return pow(volume(nm)/molecules(p,v,t),1.0/3.0);}
/*-------------------------------------------------------*/
/* Calculate approximation of energy from T=E/m as E=m*T */
/*-------------------------------------------------------*/
double energy(double m,double t){return m * t;}
/*----------------------------------------------*/
/* https://en.wikipedia.org/wiki/Kinetic_energy */
/*----------------------------------------------*/
double velocity(double e,double m){return sqrt( 2*E/m );}
i dont know if it is correct to use the letter E and e... because of
1.0e24 etc
if one use as double "f64" could be even more restrict...
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2014-11-28 19:22 -0600 |
| Message-ID | <m5b750$472$1@speranza.aioe.org> |
| In reply to | #53612 |
On 11/28/14 1:58 PM, Rosario193 wrote: > On Fri, 28 Nov 2014 09:08:55 -0600, Morris Dovey <mrdovey@iedu.com> > wrote: > >> On 11/28/14 4:56 AM, Rosario193 wrote: >>> On Thu, 27 Nov 2014 01:43:59 -0600, Morris Dovey wrote: >>> >>>> On 11/27/14 1:12 AM, Rosario193 wrote: >>>> >>>>> than it seems nobody think about multi instruction for line >>>>> and minimize key words of the language for make fit all the routine in >>>>> one screen of PC and artistic apparence of routine self explained >>>>> what it does using indentation >>>> >>>> I think you can do all of this in C - but some applications will require >>>> larger screens than others. :-) >>> >>> the routines that not fit in a 8'' tablet screen are not ok or to be >>> only very few... >> >> I’m just getting started and already I’m in trouble (8" tablet isn’t >> working for me - mind the wrap)... > > i not would use tab... than one way for use the code is cut and paste > and if something going wrong with these long lines would be a > problem... “Something” is nearly always programmer. I use the methods that have worked most reliably for me. Those may, or may not, be the same methods that work most reliably for you. If you don’t like tabs, then don’t use them. :-P > i not see any problem to make that code fit in a 5'' cell phone... I don’t have time to search through that compressed mess... ...and, in time, you too will have difficulty reading text on a 5" screen. I guarantee it. :-) This code isn’t intended for cell phone or tablet. After test and debug it will be used to add predictive / heuristic capabilities in a new version of the project described at the link below – there is a link near the bottom of that page to images of some of the original C source. -- Morris Dovey http://www.iedu.com/Solar/Electricity/
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-02 02:59 +0100 |
| Message-ID | <r77q7apfstf1g7flonp2k42oo5293at438@4ax.com> |
| In reply to | #53637 |
On Fri, 28 Nov 2014 19:22:40 -0600, Morris Dovey wrote:
>On 11/28/14 1:58 PM, Rosario193 wrote:
>> On Fri, 28 Nov 2014 09:08:55 -0600, Morris Dovey <mrdovey@iedu.com>
>> wrote:
>>
>>> On 11/28/14 4:56 AM, Rosario193 wrote:
>>>> On Thu, 27 Nov 2014 01:43:59 -0600, Morris Dovey wrote:
>>>>
>>>>> On 11/27/14 1:12 AM, Rosario193 wrote:
>>>>>
>>>>>> than it seems nobody think about multi instruction for line
>>>>>> and minimize key words of the language for make fit all the routine in
>>>>>> one screen of PC and artistic apparence of routine self explained
>>>>>> what it does using indentation
>>>>>
>>>>> I think you can do all of this in C - but some applications will require
>>>>> larger screens than others. :-)
>>>>
>>>> the routines that not fit in a 8'' tablet screen are not ok or to be
>>>> only very few...
>>>
>>> I’m just getting started and already I’m in trouble (8" tablet isn’t
>>> working for me - mind the wrap)...
>
>>
>> i not would use tab... than one way for use the code is cut and paste
>> and if something going wrong with these long lines would be a
>> problem...
>
>“Something” is nearly always programmer. I use the methods that have
>worked most reliably for me. Those may, or may not, be the same methods
>that work most reliably for you. If you don’t like tabs, then don’t use
>them. :-P
>
>> i not see any problem to make that code fit in a 5'' cell phone...
>
>I don’t have time to search through that compressed mess...
>...and, in time, you too will have difficulty reading text on a 5"
>screen. I guarantee it. :-)
>This code isn’t intended for cell phone or tablet.
is not intended but it is possible read it in a tablet or in a phone
and think on it
>After test and debug
>it will be used to add predictive / heuristic capabilities in a new
>version of the project described at the link below – there is a link
>near the bottom of that page to images of some of the original C source.
it seems something about gas variables
i would write it so:
#include <math.h>
/*-------------------*/
/* Physical Constants*/
/*-------------------*/
/*-----------------------------------*
* Vm = Molar Volume (L/mol) at 25?C *
* Na = Avogadro Number (/mol) *
* R = Ideal Gas Constant *
* MI = Millimeters per inch *
* ND = Density of Nickel (g/cc) *
*-----------------------------------*/
#define Vm 24.78959842
#define Na 6.0221E23
#define R 8.314462175
#define MI 25.4
#define ND 8.908
#define f64 double
/*--------------------------------------*/
/* Calculate net reaction chamber volume*/
/*--------------------------------------*/
f64 volume(f64 nm)
{f64 nv= nm/ND; /* Nickle volume */
f64 ch= 3.250*MI; /* Height of reaction chamber */
f64 cd= 0.875*MI; /* Diameter or reaction chamber*/
f64 cr= cd/2 ; /* radius of reaction chamber */
f64 cv= cr*cr*M_PI*ch; /* Volume of reaction chamber */
f64 hh= 3.000*MI; /* Height of heater tube */
f64 hd= 0.375*MI; /* Diameter of heater tube */
f64 hr= hd/2; /* Radius of heater tube */
f64 hv= hr*hr*M_PI*hh; /* Volume taken by heater tube */
return cv-hv-nv; /* Net reaction chamber volume */
}
/*----------------------------------------------------*/
/* Calculate molecules of hydrogen as Na*(n= PV/RT) */
/*----------------------------------------------------*/
f64 molecules(f64 p,f64 v,f64 t)
{f64 n=(p*v)/(R*t); return Na*n;}
/*------------------------------------------*
* Calculate mean distance between *
* molecules as cube root of volume/molecule*
*------------------------------------------*/
f64 distance(f64 nm, f64 p, f64 v, f64 t)
{return pow(volume(nm)/molecules(p,v,t),1.0/3.0);}
/*-------------------------------------------------------*/
/* Calculate approximation of energy from T=E/m as E=m*T */
/*-------------------------------------------------------*/
f64 energy(f64 m, f64 t){return m * t;}
/*----------------------------------------------*/
/* https://en.wikipedia.org/wiki/Kinetic_energy */
/*----------------------------------------------*/
f64 velocity(f64 e, f64 m){return sqrt( 2*e/m );}
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-12-02 02:53 +0000 |
| Message-ID | <20141201184558.179@kylheku.com> |
| In reply to | #53732 |
On 2014-12-02, Rosario193 <Rosario@invalid.invalid> wrote: > #define f64 double Failed code review; we got typedef in the 1890's, so it's okay to use it.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2014-12-01 21:25 -0600 |
| Message-ID | <m5jbdf$8cm$1@dont-email.me> |
| In reply to | #53733 |
Kaz Kylheku wrote: > On 2014-12-02, Rosario193 <Rosario@invalid.invalid> wrote: >> #define f64 double > > Failed code review; we got typedef in the 1890's, so it's okay to use it. > Epic typo! It only feels like that long ago. McKinley for President! -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-12-02 06:22 +0000 |
| Message-ID | <20141201221942.571@kylheku.com> |
| In reply to | #53734 |
On 2014-12-02, Les Cargill <lcargill99@comcast.com> wrote: > Kaz Kylheku wrote: >> On 2014-12-02, Rosario193 <Rosario@invalid.invalid> wrote: >>> #define f64 double >> >> Failed code review; we got typedef in the 1890's, so it's okay to use it. >> > > Epic typo! It only feels like that long ago. McKinley for President! That is not a typo for 1980, because of course, typedef is older than 1980; it is described in K&R1, 1978. I really wanted 1800's, and went through several edits, in which I ascribed the invention of typedef to some historic personalities from that era. That was too elaborate.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-11-27 08:37 +0000 |
| Message-ID | <kpBdw.5607$n97.3994@fx05.am4> |
| In reply to | #53464 |
Rosario193 wrote: > one language for program has to have no undefinite behaviour > and has to be simple...the one that program has to think to the > problem one want resolve more than language laws etc It turns out to be surprisingly difficult to design a language that has both of the following characteristics: (a) has no undefined behaviour; (b) is sufficiently powerful to be interesting. Imagine a one-bit machine (by which I mean the address bus is one bit wide, giving two addressable locations, each one bit wide), with a single register that is automatically zeroed when the program is loaded, and which has an LED attached to it so that you can see the state of the register, OFF or ON. Here is an assembly language for that machine: Opcode 0: HALT - stop the program Opcode 1: FLIP - toggle the register bit. This machine only has four possible programs: 00 - HALT HALT 01 - HALT FLIP 10 - FLIP HALT 11 - FLIP FLIP The first three are all right, but what about the fourth? It's the only interesting program out of the four of them, and the reason it's interesting is that it doesn't have a HALT instruction, so the question arises of what happens when it doesn't stop. Does it stop anyway? Does it wrap around? At present, this is undefined. But you could define it, of course, and then carefully make sure that the hardware does in fact behave as you define it to behave. It's trivial to write a VM to support the above machine. I suggest you try it as an exercise. Make sure that the assembly language does not allow the possibility of undefined behaviour. Then write a high level language that will save you from having to write in assembly language, and make sure that /that/ language has no undefined behaviour. Since the language has no need to deal with data, iteration, selection, or functional decomposition, it shouldn't be that difficult. One-bit machines are interesting only in the same way that 1x1 Sudoku is interesting. So the next stage is to increase the machine's power. Design a machine with 2-bit bytes, a 2-bit data bus and address bus, and an assembly language consisting of four single-byte (i.e. two-bit) instructions. What they are is up to you, but remember the goal: no undefined behaviour. Then write the assembler, and then a high-level language, again making it impossible for the behaviour to be undefined. You will find that this is more difficult. By three bits, you have eight instructions, so you can afford a primitive jump command. Now things start to get more difficult. What happens if the program doesn't quite fill memory, and the program flow jumps outside the memory occupied by the program into some other zone. Your language must define what happens in this circumstance. Otherwise, it has undefined behaviour. Keep playing this game, with ever-wider bytes, until you realise just how impossible a task it is. It's like playing tennis and rugby at the same time - you can only keep it up for so long before you start losing at least one of the games. There comes a point where you either give up the game of making the computer more powerful/useful, or give up the game of keeping every possible behaviour well-defined. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2014-11-27 16:44 +0800 |
| Message-ID | <m56o8r$g27$1@dont-email.me> |
| In reply to | #53498 |
Richard Heathfield wrote: > Rosario193 wrote: > >> one language for program has to have no undefinite behaviour >> and has to be simple...the one that program has to think to the >> problem one want resolve more than language laws etc > > It turns out to be surprisingly difficult to design a language that has > both of the following characteristics: > > (a) has no undefined behaviour; > (b) is sufficiently powerful to be interesting. > This reminds me very much of Gödel. ;-) -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-11-27 15:35 +0000 |
| Message-ID | <m57gcm$20f$2@news.xmission.com> |
| In reply to | #53500 |
In article <m56o8r$g27$1@dont-email.me>,
Reinhardt Behm <rbehm@hushmail.com> wrote:
>Richard Heathfield wrote:
>
>> Rosario193 wrote:
>>
>>> one language for program has to have no undefinite behaviour
>>> and has to be simple...the one that program has to think to the
>>> problem one want resolve more than language laws etc
>>
>> It turns out to be surprisingly difficult to design a language that has
>> both of the following characteristics:
>>
>> (a) has no undefined behaviour;
>> (b) is sufficiently powerful to be interesting.
I think you need to add:
(c) Is "arbitrarily portable" like C. [*]
That is, you *can* achieve (a) and (b) if you control all implementations
and platforms.
[*] Although I haven't defined the term, I hope it is reasonably clear what I
mean by "arbitrarily portable".
--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.
- John Kenneth Galbraith -
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-11-27 11:58 -0500 |
| Message-ID | <YKIdw.878897$yK.495811@fx14.iad> |
| In reply to | #53516 |
On 11/27/14, 10:35 AM, Kenny McCormack wrote: > In article <m56o8r$g27$1@dont-email.me>, > Reinhardt Behm <rbehm@hushmail.com> wrote: >> Richard Heathfield wrote: >> >>> Rosario193 wrote: >>> >>>> one language for program has to have no undefinite behaviour >>>> and has to be simple...the one that program has to think to the >>>> problem one want resolve more than language laws etc >>> >>> It turns out to be surprisingly difficult to design a language that has >>> both of the following characteristics: >>> >>> (a) has no undefined behaviour; >>> (b) is sufficiently powerful to be interesting. > > I think you need to add: > > (c) Is "arbitrarily portable" like C. [*] > > That is, you *can* achieve (a) and (b) if you control all implementations > and platforms. > > [*] Although I haven't defined the term, I hope it is reasonably clear what I > mean by "arbitrarily portable". > It strictly isn't portability that cause some things to be undefined, but the desire to make valid code run as fast as possible. I believe that virtually all of the "undefined behavior" in C could be defined at the cost of a lot of run-time checking and enforcing defined results. (Pointers would need to become "fat" to hold/point to bounds checking info). What can't be checked at run time should be able to be checked at (post) compile time to find all the undefined behavior caused by mis-matches between translation units. Portability may make something go from Language Defined to Implementation Defined to keep any semblance of performance on some platforms, but because all Turing complete machines are "equivalent" at one level, you can enforce common behavior if you want (some systems may become "too small" to implement it, but that is really a given, as some are already too small for C)
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2014-11-27 22:44 +0000 |
| Message-ID | <cdpnqnFr5qjU2@mid.uni-berlin.de> |
| In reply to | #53520 |
Richard Damon <Richard@damon-family.org> wrote:
> It strictly isn't portability that cause some things to be undefined,
> but the desire to make valid code run as fast as possible. I believe
> that virtually all of the "undefined behavior" in C could be defined at
> the cost of a lot of run-time checking and enforcing defined results.
> (Pointers would need to become "fat" to hold/point to bounds checking
> info). What can't be checked at run time should be able to be checked at
> (post) compile time to find all the undefined behavior caused by
> mis-matches between translation units.
What about stuff also not uncommon to be done in C (or, more
precisely, very often is done in C), i.e. controlling hardware?
If a certain device is for example memory-mapped (i.e. to com-
municate with the device one has to write data to that memory
location or read from it), then one needs to be able to access
that address without C keeping you from doing that. According
to the standard this invokes "undefined behaviour" - you are
going to use a pointer to something you didn't allocate. And
no standard will ever be able to "define" what such accesses
will do (the standard can't prescribe, at least in any reason-
able way, what kind of hardware is to be mapped to a certain
memory address and what that hardware is supposed to do). So
any attempt to disallow at least this kind of "undefined be-
haviour" would rob C of what it was initially written for,
writing operating systems and code near to the metal. A huge
chunk of what C is regularly used for would vanish.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-11-28 09:52 +0100 |
| Message-ID | <kadg7atpirefkhqe6ss4thu8raeho935l1@4ax.com> |
| In reply to | #53528 |
On 27 Nov 2014 22:44:41 GMT, jt@toerring.de (Jens Thoms Toerring) wrote: >Richard Damon <Richard@damon-family.org> wrote: >> It strictly isn't portability that cause some things to be undefined, >> but the desire to make valid code run as fast as possible. I believe >> that virtually all of the "undefined behavior" in C could be defined at >> the cost of a lot of run-time checking and enforcing defined results. >> (Pointers would need to become "fat" to hold/point to bounds checking >> info). What can't be checked at run time should be able to be checked at >> (post) compile time to find all the undefined behavior caused by >> mis-matches between translation units. > >What about stuff also not uncommon to be done in C (or, more >precisely, very often is done in C), i.e. controlling hardware? >If a certain device is for example memory-mapped (i.e. to com- >municate with the device one has to write data to that memory >location or read from it), then one needs to be able to access >that address without C keeping you from doing that. According >to the standard this invokes "undefined behaviour" - you are >going to use a pointer to something you didn't allocate. And >no standard will ever be able to "define" what such accesses >will do (the standard can't prescribe, at least in any reason- >able way, what kind of hardware is to be mapped to a certain >memory address and what that hardware is supposed to do). So >any attempt to disallow at least this kind of "undefined be- >haviour" would rob C of what it was initially written for, >writing operating systems and code near to the metal. A huge >chunk of what C is regularly used for would vanish. > > Regards, Jens pheraps UB about: basic type size and all operator on these... one time one has basic types size u8 u16 u32 u64 one time one had basic pointers size pointers8u,pointers16u, pointers32u, pointers64u[means 64 bit pointer act as unsigned in operators] one time one has operators on them act the same in all computer remain only UB of some address as above
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-11-28 12:53 -0800 |
| Message-ID | <kfnk32ft5ce.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53528 |
jt@toerring.de (Jens Thoms Toerring) writes: > Richard Damon <Richard@damon-family.org> wrote: >> It strictly isn't portability that cause some things to be >> undefined, but the desire to make valid code run as fast as >> possible. I believe that virtually all of the "undefined behavior" >> in C could be defined at the cost of a lot of run-time checking and >> enforcing defined results. (Pointers would need to become "fat" to >> hold/point to bounds checking info). What can't be checked at run >> time should be able to be checked at (post) compile time to find >> all the undefined behavior caused by mis-matches between >> translation units. > > What about stuff also not uncommon to be done in C (or, more > precisely, very often is done in C), i.e. controlling hardware? > If a certain device is for example memory-mapped (i.e. to com- > municate with the device one has to write data to that memory > location or read from it), then one needs to be able to access > that address without C keeping you from doing that. According > to the standard this invokes "undefined behaviour" - you are > going to use a pointer to something you didn't allocate. [snip] I disagree. There is nothing in the Standard that says no other objects exist. The semantics of '*' requires only that the pointer designate an object, not one allocated by the program. Obtaining such a pointer most likely depends on implementation-defined behavior (eg, by converting an integer), but as long as that pointer refers to "a region of data storage in the execution environment, the contents of which can represent values", the behavior is defined, not undefined (assuming of course alignment requirements are satisfied, appropriate qualifier restrictions are observed, etc). Nothing prevents an implementation from designating a specific memory location as such a region; the behavior in such cases can be implementation specific, but it is not ipso facto undefined.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jahns <jahns@idontlikespam.dkrz.de> |
|---|---|
| Date | 2014-11-28 10:07 +0100 |
| Message-ID | <m59dvr$2kar$1@gwdu112.gwdg.de> |
| In reply to | #53520 |
On 11/27/14 17:58, Richard Damon wrote: > It strictly isn't portability that cause some things to be undefined, but the > desire to make valid code run as fast as possible. I believe that virtually all > of the "undefined behavior" in C could be defined at the cost of a lot of > run-time checking and enforcing defined results. (Pointers would need to become > "fat" to hold/point to bounds checking info). What can't be checked at run time > should be able to be checked at (post) compile time to find all the undefined > behavior caused by mis-matches between translation units. One example of things in C that cannot be converted to "defined behaviour" in this way is e.g. the conversion of pointers to intptr_t and back. See the documentation of MemSafe[1] where some very motivated people tried to get all illegal references out of C run-time, which is hard enough already. Thomas [1] http://www.ece.umd.edu/~barua/scam.pdf
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jahns <jahns@idontlikespam.dkrz.de> |
|---|---|
| Date | 2014-11-28 14:57 +0100 |
| Message-ID | <m59v0j$6kv$1@gwdu112.gwdg.de> |
| In reply to | #53556 |
On 11/28/14 10:07, Thomas Jahns wrote: > One example of things in C that cannot be converted to "defined behaviour" in > this way is e.g. the conversion of pointers to intptr_t and back. See the > documentation of MemSafe[1] where some very motivated people tried to get all > illegal references out of C run-time, which is hard enough already. Also there's SoftBoundCETS[2] Thomas [2] http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-11-28 13:09 -0800 |
| Message-ID | <kfnfvd3t4li.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53556 |
Thomas Jahns <jahns@idontlikespam.dkrz.de> writes: > On 11/27/14 17:58, Richard Damon wrote: >> It strictly isn't portability that cause some things to be >> undefined, but the desire to make valid code run as fast as >> possible. I believe that virtually all of the "undefined >> behavior" in C could be defined at the cost of a lot of run-time >> checking and enforcing defined results. (Pointers would need to >> become "fat" to hold/point to bounds checking info). What can't >> be checked at run time should be able to be checked at (post) >> compile time to find all the undefined behavior caused by >> mis-matches between translation units. > > One example of things in C that cannot be converted to "defined > behaviour" in this way is e.g. the conversion of pointers to > intptr_t and back. See the documentation of MemSafe[1] where > some very motivated people tried to get all illegal references > out of C run-time, which is hard enough already. This conclusion isn't right. It may not be easy or convenient, but it is possible. The people who did MemSafe were operating under additional constraints that ruled ways of doing this that would allow 100% safety in such cases.
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-11-28 12:01 +0100 |
| Message-ID | <tblg7at61jsr06vv4b4j8gceg34g7alqs0@4ax.com> |
| In reply to | #53498 |
On Thu, 27 Nov 2014 08:37:36 +0000, Richard Heathfield <invalid@see.sig.invalid> wrote: >Rosario193 wrote: > >> one language for program has to have no undefinite behaviour >> and has to be simple...the one that program has to think to the >> problem one want resolve more than language laws etc > >It turns out to be surprisingly difficult to design a language that has both >of the following characteristics: > >(a) has no undefined behaviour; >(b) is sufficiently powerful to be interesting. > >Imagine a one-bit machine why one bit machine [that are far[lontane] from human think] if we have good 32 bits cpus?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-11-28 14:46 +0000 |
| Message-ID | <gV%dw.11067$u_7.339@fx08.am4> |
| In reply to | #53567 |
Rosario193 wrote: > On Thu, 27 Nov 2014 08:37:36 +0000, Richard Heathfield > <invalid@see.sig.invalid> wrote: > >>Rosario193 wrote: >> >>> one language for program has to have no undefinite behaviour >>> and has to be simple...the one that program has to think to the >>> problem one want resolve more than language laws etc >> >>It turns out to be surprisingly difficult to design a language that has >>both of the following characteristics: >> >>(a) has no undefined behaviour; >>(b) is sufficiently powerful to be interesting. >> >>Imagine a one-bit machine > > why one bit machine [that are far[lontane] from human think] if we > have good 32 bits cpus? It's for the same reason that mathematicians consider a spherical cow. You start off with a simple case, make sure you understand it thoroughly, and then proceed to a more complicated case. It turns out that, even in a one-bit machine, you have to have pretty close control over the hardware (or virtual hardware) design if you are to avoid undefined behaviour in the case of a program with no HALT instruction. Either that, or you make both opcodes mean HALT, which kind of defeats the point of having the computer in the first place. As you increase the power of the machine, its capacity to do crazy stuff expands exponentially. Show me a language with no undefined behaviour, and I'll show you a language that is insufficiently powerful. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-11-28 13:16 -0800 |
| Message-ID | <kfnbnnrt49d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53498 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Rosario193 wrote: > >> one language for program has to have no undefinite behaviour >> and has to be simple...the one that program has to think to the >> problem one want resolve more than language laws etc > > It turns out to be surprisingly difficult to design a language > that has both of the following characteristics: > > (a) has no undefined behaviour; > (b) is sufficiently powerful to be interesting. > > [snip elaboration] Either what you mean is different from what it appears you are saying, or the claim is, well, let's say wrong in the high-order bit. An ordinary deterministic Turing machine (ie, as a class of programs) satisfies both properties.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web