I have considered and dreamt about going J64 but my client base runs only on 32 bit and only on Windows. The head scratching thing is that I still actually have some client-side machines that is running Windows98 SE although the bulk are already in Win2K Pro. My wife (who's the IT manager for the factory in china) is slowly trying to get all of their machines to WindowsXP Pro but this means "upgrading" not only the hardware but also the skill set (re-training) of users ... particularly the ones on the factory floor.
I did asked about getting a 64bit server ... unfortunately with the cost of the server ... I have to share the server with 3 other projects and the problem is that they are NOT 64bit ready and doesn't have the manpower to do the testing and stuff. Btw, we are also doing something weird with this. Take for example the number 20080401.5 ... this can mean two things: 1. 04/01/2008 12:00 2. 04/01/2008 15:00 with only 4 hours working time starting at 1pm I actually had to code a lot of crud just to convert from SQL datetime to a 24Hours time format to a ManPower (variable hours) time format and back. This is one part of the project where I tell people that "I just work here ... please don't hit me!". Hehehehehehe. Hmmm. A bit more of an explanation. The driving reason for using relative decimals (0.5 for 1/2 day or 0.25 for 2 hours in an 8 hour workday) is because the front end system is a Production Planning application. The idea is that the front end will draw a GANTT chart type of graph and each of the bars represents the capacity/time that an operation will be loaded on the production line. Since the front end will just draw the bars and query J for the actual data. It relies on the whole number part to know what days to draw and the decimal part to actually position the start and stop values within a day cell. Still with me? Basically the front end (written in VB.NET using GDI+) has no concept of days and mins ... it just gets the numbers and tries to draw it onto a viewport on the screen (it looks very similar to MS-Project). I actually saw a something very-very similar done by Chris but using pure J. It was capable of drag and drop of bar lines and automatic adjustment of bars according to the schedule. I am actually seriously considering doing something like that but I am worried about political hurdles if I do so. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Guinn Sent: Wednesday, April 30, 2008 10:14 AM To: Programming forum Subject: Re: [Jprogramming] RE: [Jgeneral] NUB Problem Have you considered the possibility of going to J64? Then the number would be an integer instead of floating point. Another possibility, specify the number as an extended integer. That would probably take more space, but would avoid fuzz and the limits of floating point. On Tue, Apr 29, 2008 at 8:01 PM, Alex Rufon <[EMAIL PROTECTED]> wrote: > Hi Chris, > > Unfortunately, the use of the 200801010000 as 01/01/2008 00:00 is > tightly embedded into our system that yanking it out is no mean feat. :( > > > Thanks anyway. :) > > r/Alex > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Burke > Sent: Tuesday, April 29, 2008 5:50 PM > To: General forum > Subject: Re: [Jgeneral] NUB Problem > > Alex Rufon wrote: > > I've encountered a problem with ~. > > > > Normally, if I do this it works: > > > > ~. 1 1.00000057 1 > > > > 1 1.00000057 > > > > Then, this morning, a bug was reported in our Cebu factory for a > length > > error. It took me a while then I realize that the problem was this: > > > > ~. 20080516 20080516 20080516.00000057 > > > > 20080516 > > > > The code actually calculates how the daily WIP or how many items are > > going to be produced by a certain factory line given a start and end > > date-time. Hence the code is failing because it expects two values and > > is only getting one. > > > > Since this is critical for me, I had to replace that very simple code > > with this: > > > > ".&>~.":&.><&> 20080516 20080516 20080516.00000057 > > > > 20080516 20080516.00000057 > > > > Is this a bug? I've read the documentation and it says that the > > comparison is tolerant. Is there an intolerant comparison much like > the > > intolerant index of (i.!.0)? > > I think you are unwise to work with such data, since it relies on about > 17 decimal digits being precisely handled. > > You should be able to improve this. For example, there is no need to use > the millenium in current dates. Also, the large number of zeroes in the > decimal part are presumably also not needed. Perhaps a format like the > following would be better: > > 80516.0057 > > Incidentally, this is a programming forum question, not general. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
