It's a tough decision whether case should be significant, insignificant or simply "preserved but ignored".
If you think of filenames in the more generic sense as "references in a name space", do you opt for rules that make things easy on the user (i.e., case isn't important)? Or, the implementor (case IS important -- think, esp, UTF16)? Or, neither?
The unfortunate thing is that each system wants to define it's own rules for this namespace. So, if you have to work with more than one different scheme, you're never 100% aware if some identifier in a given hierarchy will be incompatible with some *other* namespace.
We could $ALWAYS$ go back $TO$ VAXen... :-/
I would have thought you had finished that and were working on the Model 4 by now!! ;-)
(Have you thought about this "portability" issue regarding your naming implementation?)
Yeah, Kahan is the same way. I wonder why those processors like the M4F don't have double precision. The original 8087 had double and extended precision, gradual underflow in the hardware, and a transcendental library, all in 40k transistors. This compares to over a billion SRAM cells (don't know how many transistors per cell) in an STM32 (Cortex M4). So the absence of double precision in any modern cpu with floating point seems pretty weak.
Uhm, so would have I but I am not short of distractions so it took longer. It has been stable for quite a while now but I am not quite done with all the commands which use the longnamed directories. Many of them just work but there are surprises and I have to dig. E.g. now I am fixing the "md" command, its buffer for the text to go into the . and .. files is too short.
I think I got it right (though only time will tell). I made the names stored upper case only, with the case info (bit per byte) separately after that. Then since the names can be up to 254 bytes long but can also be just 1 byte, I made the entry length variable.
If a call searches for a file it will compare 32-bit wise only upper case text (so the search is case independent); if I want to implement case dependent search all I have to do is let the compare go on for another subsequent longwords (which contain the case data).
Now I have that "default" file name to pass to the highest level "open" call (called fetch$, now I have a newer one fetchx$). If the name (passed as text) is null, the default name is taken; if the name has no suffix, the suffix from the default name is taken; and if the name text carries only a suffix (suffix being what is past the last "." character in the name) the default name but not suffix is taken. I made a call which now will insert any part of a name - text AND case info - into any other name, opening space for both the text and the case info... This took me a while (with all the distractions, normally it would have been much much faster). But hey, I have it working and usable... well, almost usable. I mean I can copy, delete etc. files but by no means all applications are happy with the longnamed thing yet... Uh, how come the moaning paragraph got by far the longest :-)
"Specifically, the time in tenths of second as measured by the system's internal clock was multiplied by 1/10 to produce the time in seconds. This calculation was performed using a 24 bit fixed point register. In particular, the value 1/10, which has a non-terminating binary expansion, was chopped at 24 bits after the radix point."
It was a failure to understand floating point arithmetic and its limitations.
Like specifying physical dimensions without considering a common reference point ("Why is this 96 inch long board NOT 8 ft?")
I think people get lulled into seeing what they want to see (whereas the machine sees "reality" -- "No, this is NOT 1/10. If you wanted 1/10, then use a rational or decimal data type!")
Amusingly, Limbo doesn't perform many optimizations that you would *expect* from other compilers. So:
Either you made a typo, you missed something in the article or I have no idea what you are talking about. The quoted text above refers to a calculation done in fixed point arithmetic.
That was just the time used to establish a time base. It doesn't matter what time you use as a zero time. Look at all the various OS time calculations. Every OS uses a different time as "zero".
It was cut and pasted from the patriot.html reference.
AFAIK, 1/10 only has a non-terminating binary expansion in floating point. Division by 10 would have a different effect, but the article explicitly states multiplication was used.
I suspect that article is poorly written.
If interested, I would look through comp.risks archives for pointers to more definitive statements.
Yes, just so.
Now all we have to consider is the way in which some OSs incorrectly convert the milliseconds-since-epoch to a date-time. The currently proposed solution to this is to eliminate leap seconds so that clock time will drift away from astronomical time.
I think this is being done for years now. A few (5, may be more) years ago I wrote an NTP command for DPS. Time from timeservers comes in UTC, (milli? micro? don't remember)seconds since 1900 or something like that. I spent some time locating tables with each year's deviation from 365.25 days, built my own lookup tables based on that etc., did what I thought was the right thing to do. Only to find out my result was in total error; it turned out the NTP servers simply returned the already corrected value.
I'm not referring to the article. It makes perfect sense. I'm referring to your comment about the "failure to understand floating point arithmetic".
And what is wrong with that? We deal with daylight saving time by adding or subtracting an hour, why not deal with leap seconds by adding or subtracting seconds before displaying the time? My understanding is that this is an issue with the time systems, not any OS itself.
NTP gets leap seconds right, but I wasn't referring to that. There are problems between NTP and POSIX time when leap seconds occur, since one has a step and the other doesn't.
That's a gross simplification, of course. See
formatting link
for more gory details, including a reference to the proposals to introduce "International Time".
Google has invented its own internal time framework to work around the problems.
Here is an example of what is being done in FPGA synthesis these days. Not quite a "nightmare".
formatting link
It doesn't even require the use of an HDL. :) It doesn't run as fast as might be expected, only 164 MHz and this is pipelined with 33 stages.
He didn't specify any details of how to implement the floating point operations, so it would seem they have implemented the math.h library in Vivaldo. It would be interesting to see the results of using doubles.
The article gives numbers for LUT usage. Read the C code for details on precision. I believe "float" was used. I expect he could have used doubles. Dig in a little and read the entire article. This is *very* on topic to the discussion we have been having although I'm not sure about the "changing diapers" issue.
Is there any further question about whether doing a KF on an FPGA is a "nighmare"?
I'd like to know how many LUT's it used, compared to doing the calculation in a sensible way. I'd also like to know the precision and whether it was IEEE floating point. The degree-13 Taylor approxmation (terrible way to compute sin) suggests single precision or so.
Time is one of those issues in the user interface/experience that is almost impossible to "get right".
Machines want to be able to order events in time in a consistent way. Time always flows in one direction (baby can't be born BEFORE conception!).
Yet, the user can (and does!) freely alter the "time reference".
Create a file. Close said file. Set "clock" back one hour. Create another file. Which one is older?
Two hours pass. How do you convey to user *when* he created each of these files? *Both* were created "two hours ago". Though the timestamps indicate one was a whole hour more recent!
Schedule an appointment "72 hours from now". Set clock forward
10 minutes. Is appointment now 71:50 from now? Or, is it still
72:00 from now? In the latter case, did you create the appointment "10 minutes ago"? (gee, it seems like it was just 10 *seconds* ago!)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.